- Sử dụng Beancount để ghi lại tài chính cá nhân suốt 10 năm bằng các tệp văn bản thuần túy, quản lý khoảng 45.000 dòng dữ liệu và 10.000 giao dịch
- Mỗi tháng dành 30–45 phút để nhập tệp CSV sao kê ngân hàng và sắp xếp thủ công/tự động, đồng thời tách theo từng năm để giữ khả năng đọc
- Tự phát triển thư viện importer dựa trên Python cho các ngân hàng Đức để tích hợp với Beancount, một số vẫn đang được duy trì
- Khi cảm nhận được khó khăn của người mới bắt đầu với Beancount, tác giả đã viết sách nhập môn dành cho người mới, và nhận được đánh giá tích cực từ cộng đồng
- Mọi dữ liệu đều được lưu trong thiết bị cục bộ và kho Git của chính mình, nên có độ bền và khả năng kiểm soát cao hơn so với một ứng dụng hay dịch vụ cụ thể
Cấu trúc sổ cái Beancount trong 10 năm
- Từ năm 2016, tác giả đã quản lý dữ liệu tài chính bằng Beancount, với tổng cộng 45.011 dòng mục được lưu trong 16 tệp
.beancount
- Lấy tệp
main.beancount làm trung tâm, rồi liên kết các tệp theo năm bằng cách include
- Tổng số giao dịch là khoảng 9.895, với posting (bút toán) bên trong là 19.743
- Có tổng cộng 1.086 tài khoản (account), nhưng đây không phải là tài khoản ngân hàng thực tế mà là các tài khoản phân loại ảo
- Ví dụ: có thể tạo tài khoản theo từng hạng mục chi tiết như chi tiêu siêu thị, thu nhập, dịch vụ đăng ký, v.v.
- 507 tài liệu PDF được đính kèm vào giao dịch, giúp dễ dàng kiểm tra hóa đơn liên quan khi khai thuế
- Số posting theo năm tăng từ 715 vào năm 2016 lên 2.651 vào năm 2023, và 2023 được ghi nhận là năm hoạt động nhiều nhất
Quy trình quản lý hằng tháng
- Mỗi tháng đầu tư khoảng 30–45 phút để tải sao kê ngân hàng dưới dạng CSV rồi nhập vào Beancount
- CSV được dùng vì dễ phân tích hơn PDF
- importer dựa trên Python chuyển đổi dữ liệu CSV sang định dạng Beancount
- Sau khi thêm các giao dịch đã chuyển đổi vào tệp
.beancount, sẽ điều chỉnh để số dư về 0 theo nguyên tắc ghi sổ kép
- Một phần được phân loại tự động, một phần được điều chỉnh thủ công
- Khi năm mới bắt đầu, các giao dịch của năm trước sẽ được chuyển sang tệp
<year>.beancount và được quản lý bằng cách đưa vào main.beancount
- Toàn bộ lịch sử giao dịch được sắp xếp thành các tệp văn bản trong một thư mục duy nhất
Phát triển Beancount Importer cho ngân hàng Đức
- Về cơ bản, Beancount không biết định dạng sao kê ngân hàng, nên cần chuyển đổi thông qua lớp importer
- Vì sử dụng tài khoản ngân hàng Đức, tác giả đã trực tiếp phát triển nhiều importer
- Ba thư viện đầu tiên hiện vẫn đang được duy trì và sử dụng tích cực
Từ người dùng thành tác giả
- Tài liệu của Beancount rất đồ sộ, nhưng rào cản tiếp cận đối với người mới bắt đầu khá cao
- Dựa trên kinh nghiệm học được qua quá trình thử và sai, tác giả đã viết sách nhập môn
- Công bố tại personalfinancespython.com
- Được nhắc đến trên trang external contributions của tài liệu chính thức Beancount
- Nhận được phản hồi tích cực trong các bài đánh giá của độc giả
Kết luận
- Toàn bộ dữ liệu tài chính được lưu dưới dạng tệp văn bản cục bộ có quản lý phiên bản bằng Git
- Dữ liệu tồn tại trên thiết bị của chính mình và không bị phụ thuộc vào một ứng dụng hay dịch vụ cụ thể
- Có thể tự do phân tích bằng cách tận dụng các công cụ trong hệ sinh thái Beancount
- Cách làm plaintext accounting này là một hình thức quản lý tài chính mạnh mẽ có thể tồn tại lâu dài hơn bất kỳ ứng dụng nào
1 bình luận
Ý kiến Hacker News
Hoàn toàn đồng ý với cuốn sách của OP. Đây là tài liệu nhập môn tốt nhất mình từng thấy để hiểu Beancount / plaintext accounting.
Mình cũng cả đời không thực sự hiểu rõ kế toán kép, cho đến khi đọc "Accounting for Computer Scientists" của Martin Kleppman thì mới bắt đầu thông suốt. Cách giải thích bằng lý thuyết đồ thị trực quan đến mức đáng ngạc nhiên.
Trước đây mình dùng Quicken, nhưng mỗi lần đổi phiên bản lại phải nhập lại dữ liệu nên cuối cùng chuyển sang GNU Cash. Tuy nhiên chuyện migration cũng có vấn đề riêng.
Sau đó mình phát hiện ra plaintext accounting (PTA) và chọn hledger (vì lo Beancount có thể gặp vấn đề hiệu năng). Khi học kế toán kép thì thấy nó đơn giản hơn tưởng tượng.
Mình parse các bảng sao kê đầu tư hoặc phiếu lương gửi dưới dạng PDF bằng script Python, rồi tự động phân loại CSV từ ngân hàng/thẻ. Nhờ vậy phần lớn công việc đã được tự động hóa.
Mỗi tháng chỉ tốn khoảng một giờ để tạo báo cáo đầu tư, ngân sách và tóm tắt thuế.
Vì là plain text nên dữ liệu vẫn an toàn ngay cả khi định dạng thay đổi, và còn có thể quản lý phiên bản bằng git.
Điểm yếu là không dùng được trên di động, và cần một ít kiến thức kỹ thuật. Nhưng nếu bạn coi trọng dòng chảy tiền bạc thì đây là lựa chọn đúng đắn.
Tuy vậy, tính năng đồng bộ tự động của Quicken vẫn là tốt nhất nên rất khó thay thế. Mình kiểm tra 27 tài khoản mỗi ngày để phát hiện gian lận hay lỗi, và việc cứ phải tải CSV rồi xử lý thủ công mỗi lần là cơn ác mộng.
Chưa kể dạo này các ngân hàng đang đóng OFX và dùng Intuit như một hub trung gian, khiến việc thoát ra ngày càng khó hơn.
Ý tưởng quản lý tài chính cá nhân như một hệ thống build dự án là điều mình học được từ full-fledged-hledger.
Bạn lưu nguyên trạng dữ liệu gốc nhận từ các tổ chức tài chính, dùng script để chuyển sang CSV, rồi dùng file quy tắc để ánh xạ sang các mục PTA.
Làm như vậy thì khi thay đổi logic chuyển đổi hoặc quy tắc phân loại, toàn bộ dữ liệu quá khứ sẽ tự động được cập nhật.
Ban đầu bạn có thể bắt đầu chỉ với dữ liệu một tháng rồi mở rộng dần — ví dụ thậm chí bao gồm cả lịch sử đơn hàng Amazon hay biên lai Paypal.
Mình đã dùng Beancount được vài năm.
Từ năm nay, mình cũng chuyển sang cấu trúc file theo từng năm giống OP. Trước đây mình có một file duy nhất dài 2 triệu dòng, và plugin Emacs bắt đầu chậm đi.
Điểm hay của cách này là có thể theo dõi mọi thứ — đầu tư, lương hưu, RSU, tài khoản ngân hàng, v.v. Thậm chí còn có thể mô hình hóa cả mức tiêu thụ điện (kWh).
Gần đây mình đang làm rất nhiều công cụ tự động hóa dùng LLM. Ví dụ, mình đã dùng Claude để refactor bộ máy quy tắc giao dịch thành một ứng dụng có UI. Việc mà trước đây phải mất vài ngày.
Có vẻ nhiều người đang nhầm lẫn giữa plain text và kế toán kép.
Beancount hỗ trợ cả hai, nhưng ngay cả khi không biết kế toán kép thì bạn vẫn có thể làm kế toán bằng plain text.
Tuy vậy, kế toán kép là một công cụ tuyệt vời để hệ thống hóa kiến thức, nên mình khuyên nên học.
Còn về ích lợi của plain text tự thân thì mình khá hoài nghi. Nó có vẻ là phản ứng ngược trước sự phụ thuộc vào cloud hay vendor lock-in, nhưng chỉ cần làm kế toán kép bằng phần mềm tự do trên máy local là đã đủ rồi.
Kết luận của mình như sau:
Mình đang dùng GnuCash, và dù không hoàn hảo, nó vẫn khá phù hợp với triết lý trên.
Gần đây mình mới bắt đầu PTA, và rào cản gia nhập khá cao.
Trước hết bạn phải học kế toán kép, rồi chọn một trong ledger-cli / hledger / beancount. Sự khác biệt khá tinh tế, và yếu tố quyết định thường là cộng đồng hoặc chất lượng tài liệu.
Sau đó lại phải nghĩ xem nên nhập tài khoản nào trước, lấy dữ liệu quá khứ đến mức nào, và thiết lập auto-importer ra sao.
hledger dùng DSL, còn Beancount dùng Python. Phần lớn thời gian vẫn là chỉnh sửa thủ công.
Tiếp theo là hàng loạt câu hỏi mới như ngân sách, thuế, chia sẻ với vợ/chồng, v.v.
Nhưng mình cảm thấy chính việc tự nhận ra những câu hỏi đó mới là giá trị thật sự của PTA.
Mỗi năm khi phải đưa ra vô số quyết định tài chính như lương hưu, bảo hiểm, hóa đơn internet hay lời mời công việc mới, việc hiểu chi tiết nền kinh tế cá nhân của mình là một sức mạnh rất lớn.
Mình dùng ledger-cli với Emacs đã 10 năm, trước đây cũng từng dùng GnuCash.
Mình còn có viết một giáo trình kế toán kép cho người mới bắt đầu.
Mình dùng PTA từ 2018, và đã rút ra nhiều bài học sau không ít lần thử sai.
Các dịch vụ thương mại chỉ cho thấy một phần tài khoản, còn PTA cho phép bạn nắm trọn toàn bộ dòng chảy tài chính.
Ví dụ, bạn có thể theo dõi toàn bộ xuất xứ (provenance) của quá trình từ lúc nhận cổ phiếu từ công ty cho đến khi chúng được bán và tiền vào tài khoản ngân hàng.
Với mình, bảng tính Excel là công cụ hoàn hảo. Mỗi tuần chỉ thêm những con số mình cần.
Tài liệu thì mâu thuẫn và khó hiểu, thậm chí ngay cả kế toán viên đôi khi cũng hiểu sai về mặt khái niệm.
Mình đã quản lý tài chính bằng bảng tính theo cách đơn giản suốt 20 năm.
Mỗi tháng chỉ cập nhật khoảng 5 phút, và chỉ theo dõi các hạng mục chính như điện, sưởi, bảo hiểm, tiết kiệm.
Mục tiêu là nắm xu hướng chi tiêu và đảm bảo ngân sách hằng năm. Tiền còn lại thì cứ tiêu thôi.
Mình chỉ ghi riêng các khoản chi trên $100 để theo dõi những món lớn.
Mỗi tháng mình tải CSV ngân hàng/thẻ về rồi phân tích bằng script Python.
Mình dùng đoạn mã do LLM viết để phân tích xu hướng chi tiêu theo từng cửa hàng, và dành riêng một thẻ chỉ cho các khoản thanh toán định kỳ để dễ nhận ra biến động.
Mình khuyên dùng Fava, một GUI frontend cho Beancount.
https://beancount.github.io/fava/
Nó trực quan hóa toàn bộ tài khoản, và giao diện tìm kiếm/truy vấn cùng khả năng chỉnh sửa theo thời gian thực rất hữu ích.
Hệ thống này trông thực sự rất hay, nhưng mình tự hỏi khi quản lý tài chính cùng với một người bạn đời không rành kỹ thuật thì phải làm sao.
Bọn mình đang dùng YNAB vì UI gọn gàng và dễ cộng tác. Liệu có thể làm một giao diện như vậy cho Beancount không?
Trước đây mình cũng từng sa vào PTA và bắt đầu ghi log, nhưng việc phải tải giao dịch thủ công từ nhiều ngân hàng quá phiền phức.
Ai cũng nói tự động hóa là câu trả lời, nhưng mình tò mò thực tế họ làm thế nào — dùng API kiểu Plaid, hay tự làm web scraper hoặc PDF parser?
Cuối cùng mình trả $130/năm cho YNAB. Vợ/chồng mình cũng rất hài lòng, và mọi thứ đều kết nối tự động.
Có lẽ còn có thể sao lưu dữ liệu qua YNAB API và song song duy trì PTA nữa.
Ngành tài chính đang tụt hậu quá nhiều ở mảng này. Tự động hóa ngày càng tăng, nhưng hiện tại vẫn hiệu quả không tương xứng với công sức bỏ ra.
Trước đây mình từng dùng YNAB, nhưng vấn đề giao dịch bị trùng xảy ra thường xuyên nên cuối cùng bỏ cuộc.
Mình đã reset đến ba lần mà lỗi vẫn tiếp diễn, nên rốt cuộc quay lại theo dõi thủ công.
Giờ PTA ổn định hơn nhiều, và cho mình cảm giác là mình đang kiểm soát mọi thứ.