Skip to main content
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.
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.

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

See it in LerianSee these ideas in practice: Accounting Routes entities and the Fees Engine.