Money is a promise, and promises need a ledger
A balance in an app is a promise, not cash sitting in a box. The promise is a claim that some amount belongs to someone and can be moved or withdrawn. The only thing making that promise real is the record behind it. Lose the record, or let it drift, and the money effectively doesn’t exist. Or worse, it exists twice. That’s why every financial product, underneath the UI, is a record-keeping problem first. Transfers, fees, settlement, and statements all sit on top of one question: who owns what, right now? Accounting is the discipline that has answered that question reliably for centuries.
Why double-entry is a system requirement, not a convention
Imagine a customer moves $50 from one wallet to another. If the first wallet goes down by $50 and the second goes up by $50, matching recorded totals let the system check its internal record of that transfer. If only one side gets recorded, the mismatch is a signal to investigate rather than proof that the business event was correct. That’s why double-entry exists. It gives a transaction a checkable constraint: the recorded sides must match. Encode that as a rule and you get a consistency control:
- A movement records its participating accounts. The record identifies the accounts affected by the transaction.
- The recorded sides must equal. Matching totals make the entry arithmetically checkable.
- A mismatch surfaces immediately. If the recorded sides do not match, the transaction can be rejected before the inconsistency compounds.
Balance is a consistency control
Balanced records make one part of a transaction continuously testable: the recorded amounts agree. Matching debits and credits detects a recorded amount mismatch. In accounting, Assets = Liabilities + Equity is a statement-level equation, not a runtime assertion Midaz applies after each operation. Records can balance while an account is wrong, a transaction lacks authorization, a value has the wrong classification, or another required record does not exist. Financial systems still rely on this control. Recording both sides gives balance a useful tripwire: when it breaks, the recorded amounts are inconsistent and the system must investigate before proceeding. Balanced records keep the amounts behind a balance consistent. You still need reconciliation and separate controls to trust it fully:
Financial systems are accounting systems wearing different clothes
Strip a core banking platform down to its foundation and you find a ledger. Strip the ledger down and you find double-entry accounting, enforced by code instead of by a clerk with a pen. The product vocabulary changes (accounts, transactions, operations, balances), but the same accounting ideas remain, now at scale and in real time. That shapes what you build:
- Accounting is the data model. Accounts, entries, and balances are the app’s source of truth, not an implementation detail bolted onto a payments app.
- The safety properties use accounting controls. A balanced posting detects mismatched recorded amounts. Authorization, classification, and completeness require additional controls.
- The hard problems come from accounting at scale. You handle many transfers at once, keep every copy of the data in agreement, and prove what happened long after the fact. All of it comes down to keeping that balanced record correct across millions of movements.
See it in the productThese ideas have direct counterparts in Lerian and Midaz: accounts, transactions, operations, and balanced movements. See how they map in Accounting in Lerian, or step into the Core banking fundamentals.
Next steps
Next upStart with Assets, liabilities & equity, the equation everything rests on.