Accounting in Lerian

Everything in this guide covers accounting in general. Midaz implements that accounting rather than reinventing it. The terms you’ve already learned have direct counterparts in the product, and once you see the mapping, the documentation reads like a language you already speak.

​

The same ideas, renamed for a ledger

---

From here on, the words get more product-specific. The accounting ideas stay the same and only the names change. In the table below, each accounting idea on the left maps to something concrete in Midaz on the right. The rest of this page walks through the rows that matter most.

​

Chart of accounts → the account hierarchy

---

A chart of accounts organizes the buckets a business sorts its money into. In Midaz, an account belongs to one asset code and can have one or more keyed balance records. Accounts form a hierarchy, not a flat list. You can nest and group them to mirror the structure of a real business. The five accounting families (assets, liabilities, equity, revenue, expenses) are the kind of grouping that hierarchy expresses. A Ledger is one self-contained book of records, and an Organization can hold several. So your chart of accounts lives as the structured set of accounts inside a Ledger. It is the same map of “where value lives,” given room to scale.

​

Journal entry → transaction + operations

---

A journal entry records one event as matching debits and credits. Midaz splits that single idea into two precise words you’ll see everywhere in how money moves:

• A transaction is one complete movement of value: the whole event, start to finish. That’s the journal entry.
• An operation is one part of that movement: the smallest Midaz record of a balance effect. Non-pending transfers can produce debit and credit operations. Pending or canceled flows can also include ON_HOLD or RELEASE.

So when you recorded “Cash debited $2,000, Revenue credited $2,000” as a journal entry, the Midaz version is one transaction made of two operations. It is the same event and the same two sides, in the product’s vocabulary.

​

Double-entry → transactions always balance

---

Midaz builds the iron rule of accounting, debits must equal credits, into its processing. Midaz validates resolved source, destination, and transaction totals before processing. If they differ, the movement will not go through. Its source separates atomic hot-balance mutation from append-only transaction and operation persistence, so this page does not make an all-or-nothing persistence promise. Midaz validates every accepted movement with a clear source and a clear destination. The system enforces this instead of a person. Because balance mutation and history persistence are separate, reconciliation and recovery controls surface any persistence gap between them. The core-banking explanation of how the ledger records money covers this from the ledger’s side.

​

Accounting routes → which accounts may take part

---

In plain accounting you decide by judgment which accounts a given kind of entry should touch. Midaz captures that judgment once as an accounting route. The route is a reusable rule for who can send, who can receive, and which debits and credits a movement should record. With route validation enabled for the Ledger, Midaz checks transactions against that rule. A fee means more balanced operations on the same transaction. For example, a wallet transfer’s route defines which customer account may be debited, which customer account may be credited, and which fee accounts join in when a fee applies. With route validation enabled, Midaz checks those rules. The core-banking guide to routes and fees walks through it in full.

​

A note on holders and accounts

---

In Midaz the account is the balance container. The real-world owner is a separate holder record and friendly nicknames are aliases, kept separate so the Ledger’s record of value stays clean. If that distinction matters for your work, who owns what untangles it.

​

Next steps

---