Skip to main content
You already know what accounting is: an honest record of money in, money out, and what’s owned versus owed. This page is about why that matters for the thing you’re actually building — a ledger, a wallet, a payments flow, a banking platform. The short version: the moment software starts holding other people’s money, it inherits accounting’s rules whether it names them or not. So this isn’t a detour into finance theory. The same ideas that keep a shopkeeper’s books honest are the ones that keep your system from quietly losing — or inventing — a customer’s balance.

​
Money is a promise, and promises need a ledger

A balance in an app isn’t cash sitting in a box. It’s a promise: 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, exists twice. That’s why every financial product, underneath the UI, is a record-keeping problem first. The interesting parts — transfers, fees, settlement, statements — all sit on top of one question that has to be answered correctly every single time: who owns what, right now? Accounting is simply the discipline that has been answering 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 an important 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.
Midaz applies this directly: it rejects a transaction when its resolved source, destination, and send totals differ. That check is valuable, but it does not prove authorization, account selection, classification, valuation, or complete business correctness.

​
Balance is a consistency control

Here’s the part worth internalizing as a builder. Balanced records make one part of a transaction continuously testable: the recorded amounts agree. Matching debits and credits detects a recorded amount mismatch. Assets = Liabilities + Equity is a statement-level accounting equation, not a runtime assertion Midaz applies after each operation. Records can balance while an account is wrong, a transaction is unauthorized, a value is misclassified, or another required record is missing. 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. Put end to end, that’s the chain in one line — balanced records keep the amounts behind a balance consistent; reconciliation and separate controls are still needed 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 bones are the same accounting ideas, now running at scale and in real time. That’s why this matters for what you build:
  • The data model is accounting. Accounts, entries, and balances aren’t an implementation detail bolted onto a payments app — they are the app’s source of truth.
  • The safety properties use accounting controls. A balanced posting detects mismatched recorded amounts; authorization, classification, and completeness require additional controls.
  • The hard problems are accounting at scale. Handling many transfers at once, keeping every copy of the data in agreement, and proving what happened long after the fact all come down to keeping that balanced record correct across millions of movements.
Learn the accounting once and a lot of system design stops feeling arbitrary. The constraints you keep bumping into aren’t the platform being fussy — they’re centuries-old rules for not losing track of money, finally written down as code.
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.

​
In short

  • The moment software holds money, it inherits accounting’s rules — a balance is a promise, and the record behind it is what makes that promise real.
  • Double-entry is a consistency control: every recorded transaction has participating accounts and matching recorded sides.
  • Balance is not a complete correctness guarantee. It detects amount mismatches; authorization, classification, and completeness need separate controls.
  • Strip any serious financial system down and you find an accounting system at its core, now enforced by code instead of by hand.
Next upTime to meet the equation everything rests on. Start with Assets, liabilities & equity.