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

# Setting up accounting in the Console

> A practical, Console-first guide to building your accounting model in Midaz — from your chart of accounts to a working Pix payment, without writing a single API call.

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](/en/midaz/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.

<Note>
  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.
</Note>

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

<Steps>
  <Step title="Plan your chart of accounts">
    Decide which balances your product needs (customer funds, fees, settlement, treasury, revenue).
  </Step>

  <Step title="Create Account Types">
    Define the categories that classify your accounts.
  </Step>

  <Step title="Create Accounts">
    Open the actual balance containers, each tied to an Account Type and an Asset.
  </Step>

  <Step title="Create Accounting Routes">
    Set the rules that say which accounts can take part in each transaction and how entries are posted.
  </Step>
</Steps>

<Tip>
  Work top to bottom. Routes are much easier to build once you already know which accounts represent customers, treasury, fees, and settlement.
</Tip>

## 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 need | What it represents                |
| ---------------- | --------------------------------- |
| Customer funds   | Money your end users hold         |
| Settlement       | Funds waiting to clear            |
| Fee revenue      | Fees you collect                  |
| Fee expense      | Fees you pay to providers         |
| Treasury         | Your own internal operating funds |

This list is your blueprint. The next steps turn each line into something concrete in the Console.

<Note>
  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](/en/midaz/console/creating-an-asset).
</Note>

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

<Card title="Create an Account Type" icon="plus" horizontal href="/en/midaz/console/creating-an-account-type">
  Open the New Account Type form and define a category with a clear name and a stable key value.
</Card>

A typical payments setup uses these Account Types:

| Account Type | Use it for                 |
| ------------ | -------------------------- |
| `customer`   | Liquid customer balances   |
| `settlement` | Funds awaiting clearing    |
| `fee`        | Fees collected as revenue  |
| `treasury`   | Internal operations        |
| `expense`    | Fees paid out to providers |

<Warning>
  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.
</Warning>

<Note>
  The Account Types menu only appears when **Validate Account Type** is enabled in your Ledger settings. See [Managing Ledgers](/en/midaz/console/managing-ledgers-via-console#ledger-settings) to turn it on.
</Note>

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

<Card title="Create an Account" icon="plus" horizontal href="/en/midaz/console/creating-an-account">
  Open the New Account form, choose its Type and Asset, and give it a clear alias.
</Card>

When you fill in the form, a few choices are permanent and worth getting right the first time:

| Field             | Why it matters                                                                              |
| ----------------- | ------------------------------------------------------------------------------------------- |
| **Account Alias** | The name routes and transactions use to find the account. Cannot be changed after creation. |
| **Type**          | The Account Type that classifies it. Cannot be changed after creation.                      |
| **Asset**         | The currency or unit it holds. Cannot be changed after creation.                            |

<Warning>
  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.
</Warning>

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

| Bucket        | What it means when you look at an account                                                                                                                                                                |
| ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Available** | Money that is free to spend or send **right now**. This is the number that goes up and down with normal payments.                                                                                        |
| **On hold**   | Money 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. |
| **Scale**     | Not 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.                            |

<Note>
  "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.
</Note>

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

<Card title="Manage Accounting Routes" icon="route" horizontal href="/en/midaz/console/managing-accounting-routes">
  See how the Accounting Routes page works and what each part of the wizard does.
</Card>

<Card title="Create an Accounting Route" icon="plus" horizontal href="/en/midaz/console/creating-an-accounting-route">
  Walk through the 3-step wizard to define a route, its operation rules, and its entries.
</Card>

If you are still deciding how to shape a route, [Accounting rules](/en/midaz/console/mc-accounting) explains the choices in plain terms. The essentials:

<AccordionGroup>
  <Accordion title="Source, Destination, or Bidirectional?">
    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.
  </Accordion>

  <Accordion title="How should an account be validated?">
    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.
  </Accordion>

  <Accordion title="Which accounting scenario?">
    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.
    * **Overdraft** — entries recorded when a debit exceeds the account's available funds and draws on an overdraft line (available for source and bidirectional routes).
  </Accordion>
</AccordionGroup>

<Warning>
  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.
</Warning>

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

<Steps>
  <Step title="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](/en/midaz/console/creating-an-account-type).
  </Step>

  <Step title="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](/en/midaz/console/creating-an-account).
  </Step>

  <Step title="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](/en/midaz/console/creating-an-accounting-route).
  </Step>

  <Step title="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](/en/midaz/console/creating-a-transaction).
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Tip>
  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.
</Tip>

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

<Card title="Accounting Walkthrough (developer)" icon="code" href="/en/midaz/accounting-walkthrough">
  The end-to-end developer version of this guide, including the data model and double-entry detail.
</Card>

<Card title="Accounting overview" icon="book" href="/en/midaz/accounting-in-midaz">
  How the core accounting primitives relate to one another.
</Card>

<Card title="Transaction Routing entities" icon="route" href="/en/midaz/transaction-routing-entities">
  The technical model behind Accounting Routes, operation routes, and entries.
</Card>

<Card title="Balances" icon="scale-balanced" href="/en/midaz/balances">
  The full balance model behind available, on-hold, and scale.
</Card>