Why do fintechs need double-entry bookkeeping?
The first version stores a balance and adds to it. The first serious incident is the day two numbers disagree and nobody can prove which one is right.
Every amount left somewhere. That is what makes it checkable.
Why a balance column fails
The obvious design is a `balance` field you add to and subtract from. It works immediately and fails permanently, for four reasons.
No history. The current value tells you nothing about how it got there. When a customer disputes a figure, you have an assertion and no evidence.
No proof of conservation. Nothing structurally prevents money appearing. A bug that credits without a matching debit produces value from nothing, and the system cannot detect it, because there is no invariant to violate.
Concurrency. Two simultaneous updates to a mutable field lose one of them. The classic double-spend is not exotic; it is two requests arriving at once.
No reconciliation. When your total disagrees with the bank's, you have two numbers and no way to find the difference, because you never recorded the movements that would let you compare.
What double entry actually gives you
Every movement is written as two entries that must sum to zero across the system. Money leaves one account and arrives in another. Nothing is edited; entries are only appended.
That produces four properties directly.
An invariant you can test. The sum of all entries must be zero. Run it continuously. If it breaks, you have a bug, and you know within minutes rather than at the quarter end.
A complete history. Every balance is a derived figure, computed from entries. A customer's balance at any past moment is reconstructible exactly.
Immutability. Corrections are new entries reversing old ones, not edits. The record of what you believed and when survives, which is what auditors and regulators actually ask for.
Reconciliation that terminates. When your ledger and the bank disagree, you can diff two lists of movements and find the specific one that is missing. With balance columns you can only observe that two totals differ.
The accounts people forget to create
The mistake that follows adopting double entry is modelling only customer accounts.
Money in flight has to live somewhere. When a payment has left a customer's wallet and not yet settled with the merchant, an account must hold it, and if you have not created one, the entries will not balance and someone will "fix" it by inventing a credit.
You need accounts for the settlement float, for fees you have earned but not collected, for money owed to and from each payment provider, for suspense where unmatched receipts sit until identified, and for your own cash at each bank. Suspense in particular is not an admission of failure; it is the account that lets an unexplained receipt be recorded honestly instead of forced somewhere it does not belong.
A sofa in a living room did not appear there. It came out of another room, or through the front door, and either way something somewhere is now missing a sofa. A ledger that lets furniture materialise is not describing a house.
Where you meet it
Every fintech that could not explain a discrepancy. Every month-end where the total was close but not equal. Every product that needed a full transaction history and discovered it had been overwriting the only copy.
Building this? A second pair of eyes on the architecture is what the advisory is for. →