Yes, it makes it both really simple to spot mistakes and also allows you to easily audit the whole thing after the fact. In corporate contexts it's a straightforward way to make sure your bookies are also honest, just have an external firm look through the whole thing every now and then.

I must have read half a dozen intro-to-accounting books, and it never ever clicked for me. I understood the concepts, the benefits, but it just felt 'wrong'.

It wasn't wrong of course, there is so much history, ingenuity and the invention of double entry accounting, but I just couldn't get my brain to understand it.

The way the concepts settled in my head was: double entry accounting is just an excellent way of modelling a graph with nodes and edges. Accounts are nodes, transfers are edges. Every edge has a source and a destination.

For a paper ledger, each column is graph node, and each row is a graph edge.

That was enough for me to be able to learn the rest of the things I needed for interacting with the accounting world.

But I also realised that that description really only helps a very small part of the population. :D It makes things so much worse for most people.

"Hey could you help me understanding this accounting thing?"

"Sure, but first thing is, let's learn graph theory! You know who Dijkstra right?"

Whole buckets of nope.

But thats a digression from your actual question - whats the point?

It presents a rigid set of rules of recording transfers, everything has to have a from account and to account (i.e. a graph edge), every row must add up to zero.

Because of that, it makes it easy to spot any mistakes in data entry. If any of your rows dont add up to zero - then you've made a mistake.

Here is my explanation for "software people who understand databases". The structure of the explanation will be as follows:

  1. Explain how you would do simple accounting with a database
  2. Point out which indices you'd create for performance
  3. Show how the "double entry" part of double entry accounting is about the indices

1. The way you'd do accounting in a database is with two tables: One table for accounts (e.g. your checking account, or the supermarket account, which you don't own) and another table for transactions. The transactions move an amount of money from one account to another, e.g. from your checking account to the supermarket account. Or if you use it for budgeting, you might split your checking account into a groceries account, a rent account etc. (think "categories").

2. For performance, you would create indices based on the accounts in the transaction table, so you could easily check what's going on e.g. in your groceries account or how much you spent at the supermarket.

3. Double entry accounting was formalized in the 15th century, way before computers became a thing, but bound paper books were already somewhat affordable. The way you'd do accounting is like this: During the business day, you would write down your transactions as they happen, into a scrapbook, similar to the transactions table mentioned above. At the end of the day, you'd do the "double entry" part, which means you take your "index" books where each book is about one account and you transcribe each transaction from your scrap book into the two books of the two accounts that are mentioned in the transaction, e.g. if you spent $10 from your groceries account into the supermarket account, you'd double enter that transaction both into your "groceries" book and into your "supermarket" book. Then, when you want to check on how much you spent at the supermarket in a particular month, you could easily look it up in the supermarket book (this would be very tedious when using the scrap book). These account centered books are like the indices in the database mentioned above.

So the double entry part is about clever index building for making it easier and faster to understand what's going on in your accounting system.

For a FOSS alternative: Actual budget isn't dissimilar from what YNAB was years ago when it was an on device budgeting software

I dont mind paying for a personal finance tool, but I feel like most of them are made for an average consumer who spends in one currency and needs budgeting. I operate in at least 3 currencies, don’t care about budgeting, and need support for tracking stocks and automatic currency conversions.

The only tools that were able to provide that were GnuCash and PTAs like beancount.

My point is, there is a big segment of people who are not served by existing personal finance tools simply because they operate in more than 1 currency, or have a slightly more complicated setup than envelope budgeting.

I used YNAB since back when they used to just sell the software and maintained a subscription for a little while. I will say that their approach to budgeting has changed the entire way of how I look at money, and even though I have switched to GNU Cash, I have essentially replicated the envelope method there (it requires four entries per transaction instead of the standard two).

For anyone who wants to use this envelope method without paying for YNAB, I recommend checking out Buckets, which is another software that works similarly.

I guess it depends on the complexity of ones personal finances? The author had multiple currencies, investments, and who knows what else.

I ran a small business for a while, and I would draw a parallel to that. Once a family's finances hits the complexities of a small business, multiple assets, loans, cars, long term savings, investments, I'd say the granularity is worth it. I would certainly like to try it out.

Interesting! You might want to try Tabula in that case.

For that type of "obfuscated" PDFs I've come across, it does well, it's just a lot slower to run than pdf2text.