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 make sure the right kinds of accounts are involved and the right parts get recorded — every single time, the same way. And when a fee shows up, where does it actually come from? This page demystifies both. 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 — 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 are allowed to send.
  • Who can be the destination? Which accounts are allowed to receive.
  • Which parts get recorded? Which debits and credits the movement should produce.
Define the rule once, and every transaction of that kind follows it. A “customer payment” route spells out that a customer account sends, a merchant account receives, and exactly which operations to write. Why does this exist? So the same kind of movement is always recorded correctly, and only valid accounts take part. No clerk fills the form in wrong, because the form won’t let them.
A route is like a form template for one kind of transaction. It lays out who’s allowed and how the movement is booked, so every movement of that kind comes out identical. A fee, as you’ll see, is just an extra line on that form.

​
Fees are just more operations

Fees feel mysterious, but they’re not magic — and they’re not “subtract a number and move on”. Remember that a transaction is made of operations (each one part — a single debit or credit). A fee is simply 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. Nothing is invented or lost — the fee is real money moving to a real account, recorded like any other part. Because the fee is part of the same transaction, it’s all-or-nothing too: the merchant gets paid and the fee is collected together, 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 must always be booked the same way — payments, transfers, settlements. And you add a fee whenever a movement should also send a slice of value into a revenue or cost account. Defining these deliberately up front is part of planning your Ledger, which comes next.

​
In short

  • A route is a reusable rule for one kind of movement: who can send, who can receive, and which parts get recorded.
  • Routes keep every movement of a kind recorded correctly, with only valid accounts taking part.
  • A fee isn’t magic — it’s just more operations moving value into a fee or revenue account (customer R$103 = merchant R$100 + fee R$3).
  • Because the fee is part of the same transaction, it’s all-or-nothing with the rest.
See it in LerianSee these ideas in practice: Transaction routing entities and the Fees plugin.