Skip to main content

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.

Accounting Routes answer three operational questions:
  • Which type of transaction is being configured?
  • Which accounts are allowed to participate?
  • Which accounting entries should be recorded when the transaction runs?
Create routes only after the main Accounts and Account Types are clear. Routes are easier to model when you already know which accounts represent customers, treasury, fees, settlement, revenue, and expenses.

​
How the pieces fit together

PieceWhat it controlsExample
Accounting RouteThe transaction-level route that groups the operation rules.Pix transfer route
Operation RouteThe account side and validation rule.Source must be customer, Destination must be merchant
Validation ruleHow Midaz decides whether an account can be used.Account Type customer or alias @treasury_main
Accounting scenarioWhich debit and credit entries are posted for the transaction lifecycle.Direct, Two-Step, Reversal

​
Choosing the operation type

Use Source for accounts where value originates.Example: a customer account can send funds in a payment flow.
Use Destination for accounts where value lands.Example: a merchant account can receive funds in a payment flow.
Use Bidirectional when the same account class can send and receive.Example: checking accounts can transfer value to other checking accounts.
A route must have at least one Source and one Destination operation route, or one Bidirectional operation route.

​
Choosing the validation rule

Validation typeUse whenExample
Account TypeAny account in a class should be valid.Any customer account can send.
AliasOnly one exact account should be valid.Only @treasury_main can send.
Empty validationYou intentionally do not want account validation at this route level.Rare; use carefully.
Use Account Type validation for scalable flows. Use alias validation for fixed operational accounts, such as treasury, fee, settlement, or suspense accounts.

​
Common route patterns

​
Customer to merchant

Use separate Source and Destination routes when each side has a different role.
Operation routeValidation
SourceAccount Type customer
DestinationAccount Type merchant

​
Peer-to-peer transfer

Use a Bidirectional route when the same account type can be both source and destination.
Operation routeValidation
BidirectionalAccount Type customer

​
Fee collection

Use a Destination route with alias validation when fees must always land in one operational account.
Operation routeValidation
SourceAccount Type customer
DestinationAlias @fee_revenue

​
Accounting scenarios

ScenarioUse whenWhat the user configures
Direct TransactionThe movement is executed in one step.Debit and credit entries for immediate posting.
Two-Step TransactionThe movement has hold, commit, and cancel phases.Entries for reservation, confirmation, and cancellation.
ReversalA completed transaction may need to be reversed.Debit and credit entries for the reversal event.
Do not enable route validation in Ledger settings until the required routes exist. If route validation is enabled without matching routes, transactions will fail validation.

​
What to do next

After the route model is clear, create it in Creating an Accounting Route.

Create Transaction Route

Create the transaction-level route via API.

Create Operation Route

Create operation-level routing rules via API.