Skip to main content
This guide walks you through setting up accounting in the Midaz Module of the Lerian Console, step by step, using only the screens and forms in the Console. It is the Console companion to the developer-focused Accounting Walkthrough: same destination, but expressed as what you click and configure, not what you send to an API. It is written for product managers, implementation teams, and developers who would rather model their accounting in the UI than assemble raw API payloads. We keep technical terms where they matter, but always explain what they mean when you are looking at them on screen.
You will not see any JSON or API calls here. Everything below is done through Console forms. If you later want to automate the same setup, each section links to the matching technical reference.

​
What you are building

Accounting in Midaz is built on double-entry bookkeeping. You do not have to do the bookkeeping by hand — the Console and the ledger enforce it for you. The one rule to keep in mind:
Every transaction moves value from one place to another. One side gives (debit), one side receives (credit), and the two always balance.
You set this up once by modeling your accounts and routing, and from then on every transaction is automatically balanced and auditable. The setup follows a logical order. Each layer builds on the one before it:
1

Plan your chart of accounts

Decide which balances your product needs (customer funds, fees, settlement, treasury, revenue).
2

Create Account Types

Define the categories that classify your accounts.
3

Create Accounts

Open the actual balance containers, each tied to an Account Type and an Asset.
4

Create Accounting Routes

Set the rules that say which accounts can take part in each transaction and how entries are posted.
Work top to bottom. Routes are much easier to build once you already know which accounts represent customers, treasury, fees, and settlement.

​
Step 1 — Plan your chart of accounts

In traditional accounting, a Chart of Accounts (CoA) is the master list of every account category your business uses — assets, liabilities, revenue, expenses — and how movements are classified against them. In Midaz there is no single “Chart of Accounts” screen to fill in. Instead, your CoA emerges from how you combine the building blocks you create in the Console: Assets, Account Types, and Accounts. Planning it up front is mostly a paper (or whiteboard) exercise. Before you open the Console, list the balances your product needs. For a typical payments product that might be:
Balance you needWhat it represents
Customer fundsMoney your end users hold
SettlementFunds waiting to clear
Fee revenueFees you collect
Fee expenseFees you pay to providers
TreasuryYour own internal operating funds
This list is your blueprint. The next steps turn each line into something concrete in the Console.
Before any account can exist, it needs an Asset — the unit of value it holds (for example BRL). If you have not created your assets yet, start with Creating an Asset.

​
Step 2 — Create your Account Types

Account Types are the categories that classify your accounts. Think of them as labels like customer, treasury, or fee that group accounts by their role. Later, Accounting Routes use these labels to decide which accounts are allowed in a transaction. In the Console you create one Account Type per category from your blueprint — not one per individual customer.

Create an Account Type

Open the New Account Type form and define a category with a clear name and a stable key value.
A typical payments setup uses these Account Types:
Account TypeUse it for
customerLiquid customer balances
settlementFunds awaiting clearing
feeFees collected as revenue
treasuryInternal operations
expenseFees paid out to providers
The Key Value of an Account Type (for example customer) is what routes and accounts rely on. Keep it short, lowercase, and stable — changing it later means recreating the accounts and routes that depend on it.
The Account Types menu only appears when Validate Account Type is enabled in your Ledger settings. See Managing Ledgers to turn it on.

​
Step 3 — Create your Accounts

Accounts are the actual balance containers — the things that hold value and that money moves between. Each account is tied to one Account Type (its category) and one Asset (its currency), and is identified by a human-readable alias that starts with @ (for example @customer_123_brl). For each line in your blueprint, create one Account in the Console.

Create an Account

Open the New Account form, choose its Type and Asset, and give it a clear alias.
When you fill in the form, a few choices are permanent and worth getting right the first time:
FieldWhy it matters
Account AliasThe name routes and transactions use to find the account. Cannot be changed after creation.
TypeThe Account Type that classifies it. Cannot be changed after creation.
AssetThe currency or unit it holds. Cannot be changed after creation.
Alias, Type, and Asset are locked once the account is saved. If you need to change any of them, you have to create a new account. Double-check before saving.

​
Understanding what a balance actually shows

When you open an account in the Console, its balance is not a single number. Midaz splits every balance into a few buckets so you always know what is genuinely spendable versus what is reserved. In plain language:
BucketWhat it means when you look at an account
AvailableMoney that is free to spend or send right now. This is the number that goes up and down with normal payments.
On holdMoney that has been reserved by a pending operation but not yet finalized. It still belongs to the account, but it is set aside and cannot be spent until the hold is either confirmed or cancelled.
ScaleNot a pool of money — it tells the Console how many decimal places to read. With a scale of 2, a stored amount of 100 means 1.00. It controls precision, not value.
“On hold” is what powers two-step payments. When a payment is authorized but not yet captured, the amount moves from Available to On hold. Confirming the payment releases it to the destination; cancelling returns it to Available. You will see these movements reflected on the account at each stage.

​
Step 4 — Create your Accounting Routes

Accounting Routes are the rules that govern every transaction before it touches the ledger. A route is a reusable rule for one kind of transaction (for example, Pix transfer or fee charge) that answers three questions:
  • Which accounts are allowed on the source (sending) side?
  • Which accounts are allowed on the destination (receiving) side?
  • Which debit and credit entries should be posted when it runs?
The Console builds these through a guided 3-step wizard, so you do not have to assemble anything by hand.

Manage Accounting Routes

See how the Accounting Routes page works and what each part of the wizard does.

Create an Accounting Route

Walk through the 3-step wizard to define a route, its operation rules, and its entries.
If you are still deciding how to shape a route, Accounting rules explains the choices in plain terms. The essentials:
Each rule inside a route applies to one side of a transaction:
  • Source — the sending side (where value comes from).
  • Destination — the receiving side (where value lands).
  • Bidirectional — the same rule applies to both sides, for cases where one kind of account can both send and receive.
A valid route needs at least one Source and one Destination, or a single Bidirectional rule.
Each rule checks accounts in one of two ways:
  • Account Type — any account of a given category is allowed (for example, any customer account can send). Use this for flexible, scalable flows.
  • @Alias — only one exact account is allowed (for example, only @fee_revenue can receive). Use this for fixed operational accounts like treasury, fees, or settlement.
Scenarios decide how the debit and credit entries get recorded:
  • Direct — a one-step movement, posted immediately.
  • Two-Step — a hold-then-commit flow, with separate entries for reserving, confirming, and cancelling funds (this is what uses the On hold bucket).
  • Reversal — entries recorded when a completed transaction needs to be undone.
Turn on Validate Routes in Ledger settings only after the routes you need already exist. If validation is on but a matching route is missing, those transactions will fail.

​
Putting it together — a simple Pix payment

Let’s run the whole flow in the Console for a basic Pix cash-out: a customer sends BRL out of their wallet to an external account. Assume your BRL asset already exists.
1

Create the Account Types

From the Account Types page, create:
  • customer — for end-user balances.
  • settlement — for funds leaving to the outside world.
See Creating an Account Type.
2

Create the Accounts

From the Accounts page, create:
  • @customer_123_brl — Type customer, Asset BRL. The customer’s wallet.
  • @external_brl — Type settlement, Asset BRL. Where funds settle when they leave the ledger.
See Creating an Account.
3

Create the Accounting Route

From the Accounting Routes page, start the wizard and build a Pix cash-out route:
  • A Source operation rule validating Account Type customer (the wallet sends).
  • A Destination operation rule validating Account Type settlement (the external account receives).
  • A Direct accounting scenario, with a debit entry on the source and a credit entry on the destination.
See Creating an Accounting Route.
4

Run a transaction

Create a transaction that moves, say, 100.00 BRL from @customer_123_brl to @external_brl using your Pix cash-out route. See Creating a Transaction.
5

Check the result

Open each account and look at the balance:
  • @customer_123_brl — Available drops by 100.00.
  • @external_brl — Available rises by 100.00.
Both movements share the same transaction, giving you a clean, balanced audit trail.
Need an authorize-then-capture flow instead of an instant one? Use a Two-Step scenario on the route. You will then watch the amount move into On hold when reserved, and out of it when you confirm or cancel.

​
What to do next

You now have a working accounting model built entirely in the Console. If you want to go deeper — automate the same setup, understand the underlying entities, or turn ledger activity into reports — these technical references pick up where this guide leaves off:

Accounting Walkthrough (developer)

The end-to-end developer version of this guide, including the data model and double-entry detail.

Accounting overview

How the core accounting primitives relate to one another.

Transaction Routing entities

The technical model behind Accounting Routes, operation routes, and entries.

Balances

The full balance model behind available, on-hold, and scale.