[BillyTheKing]

yes, agree, I think a 'source' 'destination' model is significantly more straight-forward. Just record the 'source' account and the destination account and you essentially end up with a ledger as a directed graph (Martin Kleppmann wrote a great post on it)

I also wrote a super short post on how to model such a system on postgres https://blog.nxos.io/A-simple-double-entry-ledger-with-sourc...

Blockchain actually kinda nails it, that's in essence a source/destination ledger, no 'postings' or similar needed, and from a balance calculation POV has been working pretty well

One reason this model isn't applied in accounting, in my personal view :), is simply historical and the fact that the number 0 didn't exist when accounting principles were created.

Wrote another post on how to model debit/credits on a source/destination ledger here: https://blog.nxos.io/Debit-and-Credits-on-a-Source-Destinati...

It's very straight-forward, you just have to accept that asset accounts have negative balances and present the absolute amount instead of a negative amount in a view.

[jnwatson]

It isn't always clear which is "source" and which is "destination" and now you need a bunch of new conventions about these things. Accounting already has these (admittedly arbitrary) conventions so we might as well use those.

[qwertox]

> you essentially end up with a ledger as a directed graph

The page contains a comment from Matheus Portela who pointed to a blogpost of his about "Double-Entry Bookkeeping as a Directed Graph" [0].

"I've also had the same problems you described here and double-entry bookkeeping is the way to go for financial accuracy. As a programmer, things clicked when I realized this system is an extended directed graph.". It turned out that: "Hi Matheus! Would you believe me if I told you that I read your post in preparation for this article?"

[0] https://matheusportela.com/double-entry-bookkeeping-as-a-dir...

[bvrmn]

Source/destination seems fail on actual DB implementation. How to sum all entries for a particular account? It could be on either side. It complicates queries and could trigger unoptimal query plans.

[kdmtctl]

An account could be only on one side. The side and chapter is the meaning of this account. Account on the left just negates the increase/decrease direction.

In a bank ledger when a loan appears on a checking account, both increased. Loan on the left, checking on the right. DT Loan → CT Checking. Loan is an asset for a bank, Clients money is a liability.

On a client's balance sheet everything is mirrored. Checking is an asset, Loan is a liability.

Queries are quite simple. Volumes are problematic. In a big institution you would find several ledgers included in the general ledger by totals. You just don't need all the details in one place.

[bvrmn]

As I understand parent comment it assumes following transaction records: (source_account, dest_account, amount). I argue it complicates things.

You talk more about how to make db data simultaneously a representation of final reports. I believe it's not related to this thread.

[kdmtctl]

You’re right. Missed it while scrolling. Regarding the parent discussion, a classic statement is also two-sided. So, you need to collect sources (debit) and destinations (credit).

It is definitely possible to make each side of transaction a different record, but you have to link them, so there would be another ID for a transaction to group later. It is always there in any case, but you are either joining while getting a balance or grouping while reconstructing transactions for reports. So, it depends on the primary load: lots of transactions to register or lots of reports to provide. Both are used.

[jes5199]

okay but how do you model a three-party transaction? say you want to collect fees or taxes

[BillyTheKing]

you simple create two records linked by one 'transaction', the source in both cases is the same account, while the destination for one of those postings is the fee account and the other destination is a merchant or similar account. And you can link as many of those postings under a single transaction

[jes5199]

okay so now you’ve got double-entry bookkeeping except all of your credits/debits have two dollar values instead of one. let’s call it “quadrupal-entry”

[BillyTheKing]

yes, it's a form of double-entry bookkeeping - that's the base. If it weren't double-entry then indeed it would be a pretty poor choice. This design enforces double-entry at a fundamental level, it's never possible to create a record that doesn't affect 2 accounts - and that's actually the whole point of it :)

You have a single USD (or other) value - so in the simplest form it just looks like this:

From: Alice To: Bob Amount: 10 Currency: USD

And the balances are simply sum(transactions where account is receiver) - sum(transactions where account is sender)

[tossandthrow]

You never have 3 party transactions - if you do, you would not be able to track money flow.

You can have multiple transactions. One to pay tax, one to pay fees and one to pay the actual thing.

You bundle these things in another abstraction, eg. An invoice.