[GianFabien]

I've lost count of the number of clients/projects where I had to implement double-entry ledgers. The surprising thing is that no two were the same. Almost in every case there were some specifics that were novel. And trying to determine the current balance of an account when all you have is thousands of prior transactions is tedious at best. In the old days, there was a process called closing off which was effectively a checkpoint in time. The most convoluted example I suffered through was a ledger handling multiple currencies with a mixture of spot and forward contract exchange rates.

[HelloNurse]

Obviously there are novel parts, because the transactions that alter balances are different in every application, and each has its complex "business" logic: undoing a reversed sale is completely different from undoing a mass of accumulated incorrect VAT amounts.

[pgr0ss]

The idea is that the ledger implementation itself is generic and shared, and then how you use the ledger is the novel part.

[HelloNurse]

My idea is that a reusable ledger, as a service or library, would be too distant from actual needs to provide much value.

Consider the example database state in the article:

Transfer ID Description ┃ user receivables available 1 order created ┃ -$10 $10 2 payment received ┃ -$10 $10 3 partial refund ┃ $5 -$5

A real application cannot go very far with this kind of "description": every type of transaction needs specific data, whose complexity dwarfs the double-entry ledger mechanism.

For example "order created" transactions need a reference to an order with details of what has been ordered, "payments" need a reference to a collections of debts that they are meant to pay and details of how they have been paid, "refunds" are actually many types and need a reference to what they are refunding.

Real accounts are also much more complex than a history of changes and a computed balance: for example, some of them need to be included in accounting calculations and reports in various roles, with largely arbitrary relationships and accounting criteria, while some are linked to real-world persons.

Comparing the two ledger implementations that the article references is instructive: Pgledger has simple ID columns for accounts and transfers, and it is up to the application to use them as foreign keys from the interesting tables, while TigerBeetle also offers some generic "user data" and "code" columns with arbitrary data and suggests having a separate "control plane" database.

[pgr0ss]

My idea for for this to add metadata to the transfers, likely with a jsonb column. But I agree that the ledger won't encompass everything. You would still have other database tables and then you'd store domain identifiers in the ledger and/or ledger identifiers in your other tables.

[rwmj]

Maybe I'm not understanding it, but don't you keep a record of the current balance all the time? And only need to go through the transactions in order to verify the ledger invariants, which I guess would only happen fairly rarely?

[jgalt212]

I guess, but often, or often enough, you don't just need the balance now, but also then.

[accrual]

Makes sense. It seems like one would need a wrapper like "getBalance(accountName, dateTime)" which would abstract iterating over the ledger to find the balance at a certain time.

But I could see this being a performance hotspot - looping over rows and tallying a running sum across many accounts seems like a waste of cycles.

What's the alternative to the "what was the balance at date/time" in non-ledger based systems?

[em-bee]

shouldn't the balance be calculated and and compared with the actual balance after every transaction? i have an account where money went missing. the only way to find out when that happened was to have a record of the actual balance after every transaction.

[_boffin_]

Problem is solved with 4 timestamps.