A Primer on Plain Text Accounting: Beancount vs. hledger

Accounting is, at heart, a text format. A company is a pile of transactions, each transaction is a few lines saying money moved from here to there, and if the lines all balance, congratulations, you have books. For about five hundred years humans have dressed this up in ledger paper, then green screens, then enterprise software that costs more than the accountants. But a small and devoted group of programmers looked at all of that and said: what if the books were just... a text file? In Git? That I edit in Vim?

That movement is called plain text accounting, and its two most popular tools are Beancount and hledger. They are both free, both excellent, and both opinionated in ways that make "which one?" a genuinely interesting question, one this post takes seriously.

At the same time, a much larger shift is underway: finance teams are starting to hand real accounting work to AI agents. Categorizing transactions, drafting journal entries, reconciling accounts: this is exactly the kind of structured, repetitive work LLMs are good at. Which raises a question: what software should the agents actually use? Here the plain text crowd got lucky. Text files and command lines, chosen because humans could script them, happen to be the easiest possible interface for an AI agent; no one has to teach an LLM to click through a GUI. So tools built for developers doing their personal books on Saturday mornings are suddenly candidates for autonomous finance. Whether they're sufficient for it is a different question, and it's the reason Bitwave Agentic exists, and the reason this comparison has three names in it instead of two.

What is plain text accounting?

Plain text accounting (PTA) means keeping your books as human-readable text files and working with them through command line tools. Every transaction is a few lines of text:

‍

The appeal, if you're technically inclined, is hard to overstate. Your financial data lives in a format you'll be able to read in thirty years. There's no vendor to lock you in or shut down. You can put the whole thing in Git, which means every change to your books is a tracked, attributable, reversible commit. And you can script anything, because it's all just text and CLI commands.

The tradeoff is equally clear: PTA assumes you're comfortable with a terminal, a text editor, and version control. It is command line accounting, by design and without apology. The community's own hub, plaintextaccounting.org, is upfront that these tools aren't for people who want a guided point-and-click experience.

Within that world, two tools dominate the conversation for anyone starting fresh today: Beancount and hledger.

Beancount vs. hledger: the core difference

You can read a hundred forum threads on this comparison and they all reduce to one sentence: Beancount is strict, hledger is forgiving.

Beancount

hledger

Beancount, written in Python and created by Martin Blais, treats your ledger like a compiler treats source code. Every account must be explicitly opened before you can post to it. Every account must belong to one of five root categories: Assets, Liabilities, Income, Expenses, or Equity. Every transaction must balance to zero, and if anything is off, Beancount refuses to process the file and tells you exactly why. This rigidity is a feature. Because the structure is guaranteed, Beancount can generate a proper balance sheet and income statement automatically, and entire classes of bookkeeping errors simply can’t happen.

hledger, written in Haskell and created by Simon Michael, takes the opposite bet. Its journal format is free-form and flexible. Accounts are created the moment you mention them, you can structure your hierarchy however you like, and the tool generally assumes you know what you’re doing. You can turn on strict checking; you just aren’t forced to. The result is a gentler on-ramp and a tool that adapts to your conventions rather than imposing its own.

Neither philosophy is wrong. Strictness catches your mistakes; flexibility stays out of your way. Most people know within a week of trying both which temperament fits them.

‍

Feature Comparison

A few of these deserve more than a table row.

Fava is Beancount's killer app. It's a web interface that gives you interactive charts, net worth over time, expense breakdowns, full financial statements, and a page where you can run BQL queries in the browser. For a lot of people, Fava alone decides the comparison. hledger-web is useful but much more modest.

hledger's reports are the fastest path from question to answer. Want an income statement for Q1?

hledger is -p 2026Q1

No query language, no web server, just an answer in your terminal. The CSV rules system for importing bank statements is similarly direct: a small rules file maps your bank's CSV columns and you're done.

‍

Queries vs. commands. Beancount's BQL is more powerful for ad-hoc analysis; it's essentially SQL over your transactions. hledger covers most real-world questions with built-in commands and flags. Power versus convenience, the same tradeoff as everywhere else in this comparison.

Performance is a non-issue for almost everyone. Both tools chew through tens of thousands of transactions in seconds (hledger's docs cite around 25,000 transactions per second on a laptop). Unless your books are enormous, speed won't decide this.

You can switch later. Your data is plain text. hledger can even export directly to Beancount format with

hledger print -o file.beancount

which some people use just to view their hledger data in Fava. The reverse direction takes more manual cleanup, but nothing about either choice is permanent.

So which one?

Choose Beancount if you want the tool to enforce correctness, you track investments with lots and cost basis, you'd use Fava's dashboards, or you'd rather extend things in Python.

Choose hledger if you want a gentle learning curve, you live in the terminal, you want answers from built-in reports without learning a query language, or you'd rather not declare every account before using it.

Honestly, for personal finances and small operations, you will be well served either way. Both are mature, actively maintained, free, and built by people who care a great deal about getting double-entry accounting right. The plain text accounting community's biggest problem is that its tools are good enough to make the choice hard.

Where plain text accounting hits its limits

Now for the part of the comparison that the forum threads usually skip, because the forum threads are mostly written by people doing their own books. What happens when it's not your books, but a company's?

Small companies do run on these tools. There are documented cases of multi-person businesses migrating to Beancount plus Git and being happy about it, precisely because Git gave them collaboration and change history that their previous software didn't. But as organizations grow, the gaps stop being engineering puzzles and start being control failures:

No roles, no approvals. Git tells you who changed what. It doesn't enforce who is allowed to, and there's no native concept of an approval workflow, segregation of duties, or a controller signing off on a journal entry. In a real close process, "who approved this and when" has to be enforced by the system, not maintained by team discipline.

Audit trails in the developer sense, not the auditor sense. A commit log is a wonderful thing, but a SOC-style control environment expects privileged actions to be attributable to accountable individuals under enforced policy. Period locks, immutable closed periods, reviewer attestation: all achievable in PTA, all manual, all on you.

Integrations are your job. There are no supported connectors to banks, ERPs, or payment systems. Every data feed is an importer somebody on your team wrote and now maintains forever.

Multi-entity is a modeling exercise. Consolidation, intercompany eliminations, and FX are things you build by convention in your file structure, not features the tool provides.

Digital assets are the widest gap of all. Crypto accounting needs lot-level cost basis across methods, fair value measurement under FASB's ASU 2023-08, ingestion of on-chain activity across many networks, and internal transfer detection. Beancount can record a token as a commodity. That's recording, not accounting.

None of this is a knock on Beancount or hledger. They weren't built for any of it, and their maintainers would be the first to say so. The point is that every one of these gaps becomes dramatically more important the moment you stop being the only one writing to the ledger.

Which brings us to the agents.

Command line accounting meets AI agents

This is not hypothetical. People are already feeding raw bank descriptions to an LLM and getting back categorized Beancount entries, converting arbitrary CSVs on the fly, and wiring up MCP (Model Context Protocol) servers so that an assistant like Claude can query account balances in natural language. No plugins, no vendor APIs, no integration project: the agent reads the file and runs the commands, same as a human would. The plain text accounting community accidentally built the most agent-legible accounting format in existence.

And the demand side is showing up fast. Gartner predicted in September 2024 that 90% of finance functions will deploy at least one AI-enabled solution by 2026, and in June 2025 that at least 15% of day-to-day work decisions will be made autonomously by agentic AI by 2028. Goldman Sachs has been co-developing Claude-based agents with Anthropic for accounting of trades and transactions. The question of whether AI agents will do accounting work has been answered. The open question is under what controls.

Because here's the uncomfortable arithmetic: an agent writing to a Beancount file inherits every gap from the previous section, at machine speed. No enforced approvals means an agent can post entries nobody reviewed. No role-based access means an agent's credentials are as powerful as whoever set it up. A community MCP server with API keys in a plaintext config file is a fine weekend prototype and a terrifying production system. Human-in-the-loop has to be an architectural property, not a comment in the README.

An open source ledger plus an LLM gets you a remarkable demo of autonomous finance. It does not get you something your auditors will sign.

Bitwave Agentic: accounting infrastructure for autonomous finance

This is the gap Bitwave Agentic is built for. It's a CLI and infrastructure layer that lets AI agents perform digital asset accounting, reconciliation, and financial workflows at scale.

A lot of companies running on QuickBooks today aren't going to migrate to another GUI; they're going to let their agents keep the books, and agents want a text-and-CLI ledger, not a web app full of buttons. Bitwave Agentic is that ledger, with the enterprise plumbing the open source tools don't have.

Here’s what that looks like:

Agentic expense reports

As agents go out and spend money, they need to account for it. An agent can prepare the report, categorize the spending, and collect receipts, then route the finished work to a human for approval. Picture telling an agent to order lunch for the team and getting back a clean, itemized expense report, closing the loop on agent spend instead of discovering it on a statement later.

Agentic corporate accounting

Agents automate routine workflows, prepare journal entries, and process banking activity.

Agentic corporate budgets

Agents create, update, and analyze budgets while finance keeps visibility and oversight.

Agentic bookkeeping

Transaction classification, reconciliation, reporting, and digital asset bookkeeping, the daily grind of the close, handled by agents.

Headless GL

General ledger capabilities exposed programmatically to agents, workflows, and applications, with no traditional accounting interface required.

Human in the loop

The connective tissue of all of the above. The tool runs locally, and the work only leaves the machine when a human is brought in: an agent shares a piece of accounting by inviting a person by email, who reviews and approves before anything is final. It's the simplest possible way for agents and humans to share the accounting load, and it's the actual crux of the design, not a checkbox bolted on at the end.

‍

It's MCP-compatible and built for the AI finance ecosystem taking shape around OpenAI, Anthropic, and LangChain, so it plugs into the agent tooling teams are already adopting rather than asking them to start over.

To be clear about who should use what: if you're an individual or a developer keeping personal or small-business books, Beancount and hledger are excellent and free, and nothing in this post should talk you out of them. Bitwave Agentic is for finance teams that want agents working on the company's books, where audit-grade controls, enforced approvals, and digital asset support aren't nice-to-haves but the whole point.

‍

The bottom line

Beancount versus hledger is a real choice with a happy ending either way: strict and dashboard-rich, or flexible and terminal-fast, both outstanding. The harder question is the one arriving behind it. Plain text and command line accounting turned out to be the perfect substrate for AI agents, and agents are coming for the ledger whether finance teams plan for it or not. When they arrive, the bar isn't "can I keep my books in text?" It's "can agents work the books with controls an auditor will accept?" That's what Bitwave Agentic was built to answer.

See how Bitwave Agentic brings audit-grade, human-in-the-loop controls to AI-driven accounting. Request early access.