[accrual]

Great article. I love ledgers too. While I've only used one for personal accounting, this makes it clear there are a lot of other practical use cases.

Other commentor brings up a good point though - how do we efficiently get the balance of a certain account at a certain date time? Does using a ledger require constantly summing up columns? What happens when we have 1M, 10M, or 100M+ records?

Maybe the ledger would need to be broken into separate "completed" or "sealed" groups once we verify the balance is zero, so like the other commenter mentioned, we could have "checkpoints" where the balance is known to be zero and can calculate from that point forward, instead of from record 0.

[2Gkashmiri]

In manual system, we used to have a "page total" for a single page of a ledger/book so you just had to query last page total and bring that forward. In immutable ledgers, if you have a running total, the last balance is your current one.....

And you are certain about going 1 month (or period) going back that at a particular date, at he last entry the balance was something.

Same as in paper books. Just see page total of that particular date....

[pgr0ss]

> how do we efficiently get the balance of a certain account at a certain date time?

This depends on how you implement the ledger. For pgledger, I store the balance in every entry, so to find a historical balance, you just need to find the most recent entry before that time:

https://github.com/pgr0ss/pgledger/blob/df5541dcf25f416a6a24...

I have a mental TODO to add a query function to make this simpler.

[pgr0ss]

I updated the README and added an example test: https://github.com/pgr0ss/pgledger?tab=readme-ov-file#histor...

[accrual]

That makes sense and is an elegant solution. This way one can check the balance at any time without recalculating, but we still have an audit log to find discrepancies when the balance is expected to be zero but is not.

[gamblor956]

Depends on the ERP. Some store a running balance in the account ledger; others sum and cache the results until the data changes; and the some actually sum everything every time because accuracy matters more than speed.

Generally, the most practical way to do is to "finalize" a number periodically (monthly and annually) when the books for the prior period have been "closed" (locked from further edits) and then sum only transactions taking place since the last closed balance. Most major ERPs do this.