Double-Entry Ledgers: The Missing Primitive in Modern Software
1–10 of 20 posts
Re: Double-Entry Ledgers: The Missing Primitive in Modern Software
#2I'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.
Re: Double-Entry Ledgers: The Missing Primitive in Modern Software
#3If SQLite supported WASM UDFs...
Re: Double-Entry Ledgers: The Missing Primitive in Modern Software
#4I'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…
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?
Re: Double-Entry Ledgers: The Missing Primitive in Modern Software
#5I'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…
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?
I guess, but often, or often enough, you don't just need the balance now, but also then.
Re: Double-Entry Ledgers: The Missing Primitive in Modern Software
#6I'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…
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.
Re: Double-Entry Ledgers: The Missing Primitive in Modern Software
#7Earlier quoted context omitted.
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?
I guess, but often, or often enough, you don't just need the balance now, but also then.
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?
Re: Double-Entry Ledgers: The Missing Primitive in Modern Software
#8Great 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.
Re: Double-Entry Ledgers: The Missing Primitive in Modern Software
#9Earlier quoted context omitted.
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?
I guess, but often, or often enough, you don't just need the balance now, but also then.
Problem is solved with 4 timestamps.
Re: Double-Entry Ledgers: The Missing Primitive in Modern Software
#10Great 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 nee…
> 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.