Review of Plain Text Accounting: An Opinionated View (2022)

I always enjoy whatever I see of Peter Bengtsson's accounting and Haskell videos, and I was inspired to check back and watch his review of plain text accounting again.
I remember enjoying it in 2022, and I also remembered it being fairly critical of PTA.
So I wanted to watch again and remind myself of the criticisms/weak points identified.
Usually people only write about PTA when they're enjoying it, so thoughtful critical reviews are uncommon and valuable.

I ended up formatting the youtube transcript, trying not to change the meaning, and summarising the essentials as I understood them.
I might or might not do more cleanup, but hopefully others will find this useful as-is.

My summary:
It's a quite positive PTA intro, despite the negative tone and spilt ice-cream keyframe;
it recommends it for learning and light accounting,
but not for heavy accounting (>100 txns/week), complex transactions, or his own accounting needs.
The top criticism is the lack of data entry validation to keep errors out of the system.

Thanks to Peter for the video!
--Simon 2024-11-15

Plain Text Accounting: An Opinionated View, Peter Bengtsson 2022 (12m43s, Tea Leaves channel):

Part of the Double-Entry Bookkeeping playlist:
https://www.youtube.com/watch?v=ZDF7xVtKLu0&list=PLu6SHDdOToSdlAqYhy11hTrkhMc8VfCs3&index=8

Transcript (formatted)

Hello and welcome to tea leaves programming. Today we're accounting like it's 1479

living as i do at the precise intersection of nerdy computer stuff and financial accounting
i knew it was only a matter of time before someone asked me about plain text accounting
this is a bit of a fad among the hacker news set
I've kind of held off talking about it for a while because my feelings on it are fairly nuanced
and as we all know talking about nuance on the internet is hopeless
but my viewers are generally smarter more beautiful and just generally better people than average so i'm going to give it a shot
in this video i'm going to talk about what plain text accounting is and give a few examples of plain text accounting software in action,
talk about what's good about it,
and also talk about what's bad about it
and then wrap up by explaining why it's not really the right tool for me, even if it might be the perfect tool for you

1:16
I dipped into these plain text systems in the beginning of 2020 when I was on a kick to try every possible accounting system that existed on the mac.
Look, you get bored during quarantine, what can i say?

I spent about five months maintaining my plain text books in the package called beancount, alongside my existing accounting system.
I found it sort of fun, definitely a neat hack, but ended up setting it aside
because, from the perspective of my personal finances, it was optimized to solve the wrong problems.
But i don't regret experimenting with it at all.

1:50
Let me describe exactly what we're talking about.
Plain text accounting is a way of doing bookkeeping using plain text files and command line friendly software.
in fact i prefer to call it plain text bookkeeping .
The underlying philosophical belief is the idea that using sophisticated bookkeeping tools and proprietary database formats makes your financial data harder to access
the claim of plain text accounting enthusiasts is that this type of ledger is more future proof, it's easier to integrate with other tools, and it's simpler for the user to understand
there are a number of plain text bookkeeping systems in common use by far the three most common are ledger hledger and beancount

2:39
here's an example of a bean count ledger i made for an intro video a while ago and it sure does look pretty simple.
Adding data to my general ledger is as simple as typing a new line.
So we can see that keeping track of your transactions is really as simple as typing in some formatted plain text, whenever you spend, receive, or transfer money.
But how do you get information out of the ledger? Do you just read it?
No, each of these systems comes with the ability to very quickly and easily query the ledger and generate financial reports.
For example, in beancount if i want to generate a balance sheet summarizing my current financial position,
I'd go to the command line and type bean-report, the name of my file, and balsheet.
You can also easily make more specific queries as well
if i want to know how much i spent on groceries or to display a list of those transactions that's easy to do as well
i've used bean count for the examples on screen but similar principles apply for ledger and h ledger just with minor variations in file format and command line

3:52
and one unquestionable advantage of doing things this way is that these tools are very easy to chain or connect to your own tools
so if you want to be doing a lot of scripting it's as simple as hooking up the output of these tools which is text to the input of whatever script you write
that could be pretty powerful for some people

so let's start off by recognizing the biggest virtue of plain text bookkeeping:
i think this is a great way to learn double entry accounting

most of the plaintext systems are basically implementing what an accounting software we call the general ledger module
the specific account journals exist but are usually sort of constructed synthetically or inferred by the tools after the fact
although most of the tools go out of their way to avoid using the terms debit and credit the concepts are absolutely there

using a plain text tool at small scales feels very natural
essentially you're taking notes on your transactions and annotating them in a straightforward way so that they can be processed systematically

5:04
the other aspect of plain text bookkeeping that i like a lot is that the community is really enthusiastic
there are multiple competing systems but the creators and users generally are very cooperative with each other
and getting help is as simple as popping a question on a reddit forum
basically it has that good vibe you get when a bunch of really enthusiastic amateurs want to evangelize a thing that they love
if you need help getting into plain text accounting you'll have no shortage of friendly strangers eager to help you out

5:33
so what's the fly in the ointment - if plain text accounting is so great why didn't i keep using it ?
i'll break this down into three reasons

5:39
first my financial life is comparatively complex
i describe the plain text accounting tools as simple but there is such a thing as too simple
accounting software isn't complicated because software developers hate you
accounting software is complicated because accounting is complicated
i need my software to handle a large number of bank and brokerage accounts with a large number of transactions
that are modeled in many different ways accounts payable accounts receivable
and i need a per transaction audit trail
beancount provides a a general ledger
yes with enough elbow grease and custom scripting and github actions
i probably could implement an accounts payable system that's auditable on top of a general ledger
but who would want to do that
and to be clear all of the plain text accounting systems emphasize that they're for tracking your personal finances
so i don't blame them for not being purpose built for my complex suite of use cases
it's no shame to say that a screwdriver isn't the right tool to hammer in a nail
and the main reason i set the plain text tools aside is just that the tools were fine but they weren't a match for my needs

7:01
beyond that though the more i used bean count the more i began to feel that i had philosophical disagreements about what problems are important to solve
from my point of view even at the level of the simplest personal finances the single biggest problem is we are human and humans make mistakes
double entry accounting is great at catching those mistakes and ledger and bean count will and hledger will definitely help you do that eventually
but saying that your primary interface to data entry is "type free form text with syntactic white space in a text editor"
means that there's an entire class of simple errors that can't or rather won't be caught immediately
for example if i'm in gnucash and i type a number with two decimal points it will see right away that i've made an error
and will insist that i correct that specific transaction before even allowing me to proceed
i find value in that
that type of feedback really is invaluable in preventing me from propagating the same type of error over a large number of transactions
in plain text systems you generally only find your errors when you run the tools some time after saving the file
in many ways this is a lot like the programmer's edit test compile cycle applied to finances
now there are GUIs available to sit on top of your plain text system that act more like the traditional accounting systems we're used to
but at that point i would argue you are no longer using the systems as they were pitched to you
and instead you should just choose which gui you like best
so the plain text bookkeeping tools are trying to maintain this invariant of plain text file
and privileging solving that problem over the problem of solving and validating ui input
that's a valid choice but it's not one that i like

9:06
and this brings up my other philosophical objection to this class of tools - what does plain text even mean
does it just mean that the text is utf-8 and human readable in a unix-style text file
in actuality all of the plain text accounting systems have fairly complicated file formats
those formats are just invisible to the eye
yes they're plain text in the sense that i can open them in a text editor
but if i want to use bea count i have to remember to separate the date from the payee with an asterisk
to indent all of the split lines detailing cash flows
and to have declared the accounts before using them
and if tomorrow i decide i want to switch to ledger or hledger i need to either write my own tool to convert the file format
or hope someone else has written one and that it works
while i was doing research for this video for example I used someone's recommended script to convert beancount to hledger,
and it worked for my simple transactions and failed dramatically for the more complicated ones
all of which is to say sure i can print out my ledger and read it
or pop it into a text editor and search for the word pizza
but that's not the same thing as having actual data portability
almost any piece of accounting software will let you export the ledger to csv comma separated values
heck you can open a quickbooks file in excel and export that to csv if your copy of quickbooks has gone missing
that's almost as plain text in my opinion as what bean count ledger and hledger are offering
and what you buy for that is better input validation
and a database that isn't just a flat text file with all of the risks associated with that

10:56
so where does this leave you gentle viewer if you're considering this for your own books ? here's what i think
if you don't know a lot about double entry accounting and you have a relatively straightforward financial life
any of hledger, ledger or beancount are a great way to jump on.
you'll learn a lot you'll become more financially literate and you might even have fun doing it
if you're doing a relatively small number of transactions per day
and deal primarily with cash bank accounts credit cards maybe the occasional stock purchase or sale
the tools should scale to your needs just fine

11:40
if however you either have to deal with a large number of transactions each week - i'd say about more than about 100
or if you have to structure a lot of complicated transactions - such as for example accruals based payables or receivables
maybe treat these tools as a nifty hack and then reach for something more appropriate to your needs

this has been tea leaves programming
counting like it's 1479
thanks so much for watching

PB's PTA experience

He used Beancount for 5 months in parallel with his main accounting system.
He has experience with many non-PTA accounting systems.

PB's criticisms of PTA

  1. Input validation is lacking; error checking happens later, like a programmer's compiler, not immediately to prevent you entering invalid data.

  2. The plain text file formats have complex structure.

  3. The plain text file formats differ between PTA apps and it's not easy to convert between them.

PB's verdict on PTA

"If you don't know a lot about double entry accounting, and you have a relatively straightforward financial life, any of hledger, Ledger or Beancount are a great way to jump on.
You'll learn a lot, you'll become more financially literate, and you might even have fun doing it.
If you're doing a relatively small number of transactions per day and deal primarily with cash bank accounts, credit cards, maybe the occasional stock purchase or sale, the tools should scale to your needs just fine.

If however you either have to deal with a large number of transactions each week ... more than about 100 ... or if you have to structure a lot of complicated transactions, such as for example accruals based payables or receivables ... reach for something more appropriate."

SM's questions / thoughts

PTA's not right for everyone and isn't best at everything

Absolutely right !

Within PTA too, there are various workflows and distinct types of user using it quite differently.

Accounts receivable/accounts payable

These are mentioned as a problem for PTA, by a few people (see also youtube comments) - why ?

Input validation

PTA tools aim to provide as much error checking as possible on top of relatively free form plain text data, for both manually-entered and imported data. Post-checking works best for validating imported data, and also for certain validations which can't be done immediately at the time of manual data entry.

Pre-checking as much as possible at data entry time is certainly desirable. There are various data entry UIs in the PTA world which do a bit of this. I'd like to call out a particularly effective (though programmer-oriented) setup: flycheck-ledger, and particularly flycheck-hledger, in Emacs. While it doesn't disallow saving bad data, it does give immediate and precise visual feedback of most detectable errors (not just syntax errors), while you type. This is (to a programmer :joy:) very pleasant .

One can also set up a version control pre-commit hook that disallows committing error-causing data.

Complex plain text formats

Why is the (sometimes) complex structure of the plain text file formats a problem ?
They aim to represent both simple and complex things, while also being human-readable and version-controllable. The alternative is binary or inaccessible data ?

Converting between plain text formats

Yes, this can require some text processing work and/or know-how.
The conversion tools are definitely limited, as mentioned.
This really needs to be handled by each PTA app.
hledger 1.41 will have excellent support for exporting to Beancount.

How hard is it to convert data between non-PTA apps ?
I would guess, a lot harder in most cases.

All accounting apps have some kind of (limited, lossy) CSV export; PTA apps have this too.

Transaction-level audit trail

If I understood that rightly, the PTA solution, fun for programmer types, would be to keep every transaction in its own version-controlled file.

1 Like

Thanks for the summary. I agree with your comments. Most of his criticisms are just puzzling, especially the bits about how he can’t figure out how to maintain specific accounts and about the per transaction audit trail, which PTA seems perfect for in multiple ways.

Any reason you're working on this? It certainly is nice to have feature but It sounds like it's a lot of work for limited use cases.

Well, a few:

  • Fava is known to be a great PTA GUI and I and other hledger users would benefit from being able to use it
  • hledger print already has a beancount output format but I found it still requires a lot of manual fixups in practice
  • Interop or migration between beancount and h/ledger becomes easier