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

# How money is recorded

> Why every movement of money has two sides, what debit and credit really mean in a ledger, and how double-entry keeps every transaction balanced and auditable.

If you've ever looked at a banking system and felt lost the moment someone said "debit" and "credit", this page is for you. You don't need an accounting background. You just need one idea — and once it clicks, almost everything else in core banking falls into place.

Here it is: **money never appears out of nowhere, and it never simply vanishes. It moves.** Every time money moves, it leaves one place and arrives at another. Recording *both* sides of that movement is the whole idea behind **double-entry accounting**.

## Money always comes from somewhere

***

Think about pouring water between two buckets. The water that leaves the first bucket is exactly the water that fills the second. Nothing is created, nothing is lost — it just changes place. You can always check that the amounts match.

A core banking system records money the same way. Every movement has two parts:

* **Where it came from** — the source
* **Where it went** — the destination

If a customer sends R\$100 to a merchant, the system doesn't just say "the merchant has R\$100 more". It records the *full story*: R\$100 **left** the customer and R\$100 **arrived** at the merchant. Two sides of one movement, always equal.

<Note>
  This is why it's called double-entry: every movement is written down on both sides — once as it leaves, once as it arrives. A single-sided record makes mismatches harder to detect; recording both sides gives the system an arithmetic constraint to check.
</Note>

## The two sides have names: debit and credit

***

The two sides of a movement have traditional names. Don't let them intimidate you — in this movement, they describe the recorded source and destination:

* A **debit** is the entry on the account that money moves **out of**.
* A **credit** is the entry on the account that money moves **into**.

When the customer pays the merchant, the system records a **debit** on the customer's side and a **credit** on the merchant's side. Same amount, opposite directions. In accounting more broadly, debit and credit are sides of an entry; whether either increases or decreases a balance depends on the account type and its configured direction.

You'll sometimes see debit and credit described as "decrease" and "increase", but that's not always true — it depends on the kind of account. For the transfer shown here, **debit is the source and credit is the destination**; don't treat that example as a universal rule for every account type.

## Why both sides are always required

***

Because every movement is recorded on both sides, the totals always have to match. The sum of everything that left equals the sum of everything that arrived. If they don't balance, something is wrong — and the system won't let the movement through.

```mermaid theme={null}
flowchart LR
  A["Customer account<br/>(source)"] -->|"– R$100 · debit"| T(("Movement<br/>R$100"))
  T -->|"+ R$100 · credit"| B["Merchant account<br/>(destination)"]
  classDef bal fill:#fff8e1,stroke:#f4b400,color:#333;
  class A,B bal;
```

This rule — *the two sides must balance* — is an important consistency control: Midaz validates that the source total, the destination total, and the sent value all match. This check catches a recorded amount mismatch, but it does not by itself prove authorization, classification, or completeness. Every recorded movement can still be traced to its source and destination.

<Tip>
  Each individual part of a movement — a single debit or a single credit — is called an **operation**. A movement of money is built from operations that balance out. You'll see this word a lot, so it's worth remembering: **an operation is one part of a movement.**
</Tip>

## In short

***

* Money doesn't appear or disappear — it **moves** from a source to a destination.
* **Double-entry** means every movement is recorded on both sides. In the transfer shown here, the source has a **debit** and the destination a **credit**.
* Matching sides are a consistency control: the source total, the destination total, and the sent value must match. This catches recorded amount mismatches, while authorization, classification, and completeness need separate controls.
* A single debit or credit is called an **operation**.

Keep this mental model close. Everything that follows — accounts, balances, transactions, fees — is just this idea, applied.

<Note>
  **See it in Lerian**

  See these ideas in practice: [Transactions](/en/midaz/transactions) and the [Glossary](/en/glossary).
</Note>