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

# The rules that govern movement

> The reusable transaction routes that keep each kind of money movement recorded correctly, and why a fee is just a few more operations on the same journey.

You know how money moves and how it's recorded. But who decides the *rules*? When a payment happens, something has to check that the right kinds of accounts take part. It must also record the right parts the same way every time. And when a fee shows up, where does it come from?

Think of a paper form built for one kind of request. Someone designed it once: the boxes it has, the line for who's allowed to sign, the rule for how it's filed. After that, any clerk just fills in the details, and every request of that kind comes out identical, with no guessing. That's the idea behind a route: set the rule once, and it's applied the same way every time.

## A route is a reusable rule for one kind of movement

***

A **route** is a reusable rule for one *kind* of movement. It answers three questions, once, so you don't answer them again on every transaction:

* **Who can be the source?** Which accounts may send.
* **Who can be the destination?** Which accounts may receive.
* **Which parts belong in the record?** Which debits and credits the movement should produce.

Define the rule once. When a Ledger has route validation enabled, it checks transactions of that kind against the route. A "customer payment" route spells out that a customer account sends, a merchant account receives, and exactly which operations to write.

When a Ledger has route validation enabled, it checks the record of each movement of that kind against the rule. It also checks that the participating accounts are valid for it. Without that setting, a route is still a reusable definition but does not enforce those checks.

<Note>
  A route is like a **form template** for one kind of transaction. It lays out the intended participants and booking. When a Ledger has route validation enabled, it checks movements against the route. A fee is just an extra line on that form.
</Note>

## Fees are just more operations

***

Fees feel mysterious, but they are not magic. A transaction consists of **operations**, each one a single debit or credit. A fee is *more operations* in the same transaction, sending value into a fee or revenue account.

Take the one-to-many example from before. A customer pays **R\$103**:

* **R\$100** lands at the **merchant**.
* **R\$3** lands in a **fee account**.

That's one transaction with three operations. The customer's R\$103 leaving balances exactly against R\$100 + R\$3 arriving. No value appears and no value disappears. The fee is real money that moves to a real account, recorded like any other part.

```mermaid mermaid theme={null}
flowchart LR
  C["Customer<br/>– R$103"] --> R{{"Route<br/>(rule + parts)"}}
  R -->|"+ R$100"| M["Merchant"]
  R -->|"+ R$3"| F["Fee account"]
  classDef bal fill:#fff8e1,stroke:#f4b400,color:#333;
  class M,F bal;
```

Because the fee is part of the same transaction, it is all-or-nothing too. Either both the payment and the fee happen, or neither happens.

## When you'd reach for routes and fees

***

You don't need a route for a one-off movement. You reach for one when a *kind* of movement repeats and you must book it the same way every time: payments, transfers, settlements. And you add a **fee** whenever a movement should also send a slice of value into a revenue or cost account. You define these deliberately up front, as part of the ledger plan that comes next.

## Next steps

***

<Note>
  **See it in Lerian**

  See these ideas in practice: [Accounting Routes entities](/en/products/midaz/transaction-routing-entities) and the [Fees Engine](/en/products/midaz/fees/fees-engine-overview).
</Note>