> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# Why accounting matters?

> The "so what?" for builders: why double-entry is a system requirement, what balancing does and does not guarantee, and why financial systems rely on it.

You already know *what* accounting is: an honest record of money in, money out, and what's owned versus owed. That record matters for what you build: a ledger, a wallet, a payments flow, a banking platform. The moment software starts holding other people's money, it inherits accounting's rules whether it names them or not.

The same ideas that keep a shopkeeper's books honest 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 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.

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

***

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:

```mermaid theme={null}
flowchart LR
    A["User sees<br/>a balance"]:::step --> B["System keeps<br/>ledger records"]:::step
    B --> C["Each movement<br/>has two sides"]:::step
    C --> D["Books stay<br/>balanced"]:::step
    D --> E["Recorded amounts<br/>are consistent"]:::trust
    classDef step fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
    classDef trust fill:#dcfce7,stroke:#16a34a,color:#14532d
```

## 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.

Learn the accounting once and a lot of system design stops feeling arbitrary. The constraints you keep bumping into are centuries-old rules for not losing track of money, written down as code.

<Note>
  **See it in the product**

  These ideas have direct counterparts in Lerian and Midaz: accounts, transactions, operations, and balanced movements. See how they map in [Accounting in Lerian](/en/start-here/fundamentals/accounting/accounting-in-lerian), or step into the [Core banking fundamentals](/en/start-here/fundamentals/core-banking/what-is-core-banking).
</Note>

## Next steps

***

<Note>
  **Next up**

  Start with [Assets, liabilities & equity](/en/start-here/fundamentals/accounting/assets-liabilities-equity), the equation everything rests on.
</Note>