Yeah that was my thought as well. Ledgers have tons of benefits but they’re not going to fix your dancing cents problem. You’re going to have bad number on the ledger.
Sure, maybe that points you to the bugs, but so would writing basic tests.
A ledger where you insist that every entry touches exactly two accounts, in a business where transactions regularly involve various types of fees, could easily misplace or misattribute a few cents here and there.
This type of business can also have fun dealing with accruals. One can easily do a bunch of transactions, have them settle, and then get an invoice for the associated fees at variable time in the future.
> where you insist that every entry touches exactly two accounts
A ledger is where every transaction balances to 0. It can involve multiple accounts, but the sum of all transfers between all accounts in a single transaction must sum to 0. This is the property of double entry that actually matters.
Maybe I'm being naive, but this seems to be not too difficult... You have a general ledger in which the invariant that it always balances is properly enforced. The hard bit is scaling and performance. There are policies around fractional transactions, but you should never get mismatched entries.
I think the trick is to store the movement not the balances. You may cache the balance, but what matters is the journal of money moving from one account to another.
Exactly. Any proper ledger is a transaction log. Balances and turnovers are calculated, not stored. I've seen a lot of attempts to 'cache balances', and this was always the point where anything could go wrong.
Sure, maybe that points you to the bugs, but so would writing basic tests.