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.
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'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.
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?
If SQLite supported WASM UDFs...