Comment by BillyTheKing
1 year ago
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.
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.
> 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...
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.
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.
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.
1 reply →
okay but how do you model a three-party transaction? say you want to collect fees or taxes
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
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”
1 reply →
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.