Double-entry bookkeeping as a directed graph

I think it is a great article and graph representation would be very useful to have in accounting. There are a few things I would add:

1. It may be beneficial to segregate ledgers (used to record transactions with customer accounts, i.e. with assets you do not own) vs. books (transactions recorded to present own assets and liabilities). Books are used to account for all possible types of assets and liabilities, while ledgers are usually strictly limited to reflection of cash movements. I think the article is about ledgers.

2. Regarding the state of each account at each period in time, I think there is a lot of confusion between reflecting activity / transactions in the period and adjustments related to how prior transactions were recorded. I personally thought that adjustments could be better accounted for using something like a model with slowly changing dimensions where you can see history of each change. So it is not something you want to see on the directed graph by default, but something you want to be able to trace.

3. There was one idea that I really don’t like because although it make sense on surface, it has really bad implications for accounting and analytics. The idea I am talking about is that you don’t need to have one debit and credit for transaction, rather you just need to make sure that total debits equal total credits. say, Bob has several types of accounts and multiple customer. Now Bob asks you to tell him, how much of the current balance of a specific account was generated from proceeds by customer. To answer it, you now have to solve many-to-many relationships between customers and Bob’s accounts. And sometimes it has no deterministic answer because we balanced multiple accounts in one entry. And accountant now have to use imagination and excel to prepare a manual report that uses multiple assumptions to answer this question.

> Don't store the account data. Instead store the transactions. Compute the accounts from that. The table "Transactions" should have the fields: Date, Amount, SourceAccount, TargetAccount, Description.

This is a bad design, please don't do this.

The better design is to have header and detail tables:

Header: TransactionID, Date, Description, (other fields as required, e.g., posting status, reconciliation status, etc) Detail: TransactionID, LineNumber, Account, Amount, Description, (other fields as required, e.g., reference numbers for subledgers, etc)

This allows a transaction to affect any number of accounts. In effect, the transaction ends up reflecting a business transaction which may affect many accounts.

And that is how people invented blockchain (it is slightly more complicated, particularly that each transfer should include the source address in the output, but the idea is the same). As mentioned elsewhere in the thread, we also need multiple inputs/multiple outputs for each transaction.

In all fairness, if you're trying to understand a piece of software like Quickbooks and are not coming from an accounting background, anthropomorphizing each "account" at your company as an individual actor with their own ledger can actually be a helpful mental model. Everything needs to be a dance between actors, and, for instance, when you make a vendor payment in cash, you can only do so as a message sent simultaneously to the Accounts Payable actor and the Cash actor, and each actor must accumulate the effects of that message/event in the way that makes sense. (Namely, each one will translate the event into credits/debits based on the characteristics of who they are, and maintain a balance accordingly. Double-entry, I suppose, means each event must be ingested exactly once by an even number of actors.)

If you're building payment rails, that event might itself be one of a pair of events, sourced from a meta-event tracking the transaction intent. (As a meta-point, I find it much more useful to think of the "graph" in accounting as having edges not made of money, but of data in a derived-event hierarchy.)

And a first step towards being able to have that mental model is ensuring that you have a good mental model of multiple physical-human actors accumulating events in a structured and atomic way.

But the OP doesn't actually make it clear that this is what the analogy is in service of! And I fear that the OP article will cause more confusion than it solves.

> if you're trying to understand a piece of software like Quickbooks and are not coming from an accounting background

Unfortunately, QuickBooks won't help you understand accounting. It's not a true double-entry accounting system, at least it wasn't the last time I touched it. That said, it still does its job and does it well enough, and real accountants are fine with dealing with it.

Simply Accounting is a better example of a true double-entry system.