10 years of personal finances in plain text files

Perceptions of the post and book

• Some readers see the post as de facto advertising for a Beancount book and initially question the author’s “FOSS dev” credentials, noting minimal commits to the core repo.
• Others counter that contributions to plugins, resource lists, and documentation, plus writing the book itself, are real ecosystem contributions.
• Several argue you don’t need to be a core maintainer to write a user-facing book; expertise as a user/evangelist is enough.

Why plain text accounting appeals

• Multiple commenters report 10–14+ years of history in Beancount, hledger, or ledger-cli, often after trying many other apps.
• Benefits cited: single source of truth across bank accounts, credit cards, pensions, RSUs, loans, utilities, even energy or fuel usage; strong versioning with git; reproducible ETL-style pipelines; long‑term independence from vendor changes and file-format breakage.
• Users like the “archaeology” aspect and the empowerment of understanding every part of their personal economy.

Niche, complexity, and learning curve

• Many stress this is niche and best suited to technically inclined users; most people won’t tolerate manual imports or scripting.
• Learning double-entry accounting plus choosing among ledger-cli/hledger/Beancount and designing import workflows is seen as a major barrier.
• There’s disagreement on difficulty: some say concise docs and examples are enough; others find mainstream accounting explanations confusing or wrong and want deeper conceptual clarity.

Time cost and return on effort

• 30–45 minutes per month is defended as reasonable to stay on top of finances; critics call it toil and question whether detailed tracking meaningfully changes behavior.
• Some report 3 hours/week and conclude the ROI wasn’t there; they later switch to lighter approaches (net-worth snapshots, tracking only big fixed costs or savings rate).
• A recurring theme is that more detail is worthwhile when money is tight; when finances are comfortable, coarse tracking may suffice.

Automation, bank feeds, and tooling

• Common workflows: monthly CSV/PDF exports; custom Python parsers; Beancount/hledger import rules; build-like pipelines where improved rules retroactively fix history.
• Automation is seen as essential to reduce error and drudgery, but bank APIs and aggregators are fragmented and unreliable; many banks offer no APIs at all.
• Some make ledgers fully generated from raw data; others rely on GUIs like Fava or non-PTA tools (GnuCash, MoneyMoney, YNAB, Monarch, Tiller, etc.), especially for non-technical spouses.

Granularity and modeling choices

• Ongoing debate about how fine-grained to be: single “Groceries” vs splitting into food/household, or one Costco line vs detailed itemization.
• Advice: start simple, avoid decision paralysis, and only add granularity where it provides insight; receipts can allow later refinement.
• Similar issues arise with mortgages, loans, pensions, ETFs, and utilities; they are possible to model but add conceptual and scripting complexity.

Plain text vs. other formats and LLMs

• Some argue plain text itself is less important than double-entry, open formats, and avoiding cloud lock‑in; others value text specifically for durability, tooling, and git.
• LLMs are being used to generate import scripts, transaction rules, and UIs, and occasionally to draft entries; several commenters warn against outsourcing core financial understanding to LLMs, but see value in using them to handle tedious transformation work.