Concepts map - Lerian

The Midaz Module uses a small set of core objects, but they depend on each other in a strict way. If the user does not understand that structure, the UI feels arbitrary. This page is the shortest path to the mental model.

Core hierarchy

Core Midaz Module hierarchy, from Organization and Ledger down through Assets, Accounts, Routes, and Transactions

What each object means

Object	What it represents	Why it exists first or later
`Organization`	The legal or operational owner of the setup	It is the top-level boundary. Nothing below exists without it.
`Ledger`	The accounting environment where balances and movements are recorded	It groups the structure that a team will operate day to day.
`Asset`	The unit of value moved in the ledger, such as `BRL` or `USD`	Accounts and transactions depend on it.
`Account`	A balance container that can send or receive value	Transactions happen between accounts.
`Account Type`	A structural classification such as `checking`, `treasury`, or `expense`	It becomes important when the ledger enforces type validation.
`Portfolio`	A grouping of accounts, often by customer or wallet structure	Useful for reporting and organization, but not a prerequisite for every account.
`Segment`	A classification tag for accounts, such as department, region, or tier	Useful when the business needs slicing or policy grouping.
`Holder`	The person or entity that owns accounts in CRM flows	Needed when account ownership matters operationally.
`Alias`	A human-readable identifier used to find or refer to an account	Especially important in transaction creation.
`Accounting Route`	The rule set that validates participants and defines posting behavior	It turns a movement request into a consistent accounting pattern.
`Transaction`	The actual balance movement recorded in the ledger	It is the output of the whole setup.

How a transaction actually depends on prior setup

How creating a transaction depends on the prior setup of organization, ledger, assets, accounts, and accounting routes

If any one of these prerequisites is missing, the transaction page becomes confusing because the operator is trying to complete a movement that the ledger model still cannot support.

Practical reading of the UI

Use this interpretation when guiding users: • Foundation defines where the system lives: Organization, Ledger, Asset. • Accounting defines the rules of participation and posting: Account Types and Accounting Routes. • Accounts defines who holds balances and how they are classified: Accounts, Holders, Aliases, Segments, Portfolios. • Transactions is where the configured structure is exercised. • Plugins extend the model after the core behavior is already working.

When users usually get lost

Account vs Holder vs Alias

The Account is the balance container. The Holder is the owner identity in CRM flows. The Alias is just a human-friendly way to reference the Account.

Account Type vs Segment vs Portfolio

Account Type controls structural classification and validation. Segment is a grouping label. Portfolio is an operational grouping of accounts, often around a wallet or customer structure.

Accounting Route vs Transaction

The Route is the reusable rule. The Transaction is the individual movement that follows the rule.

Why the ledger matters so early

Almost every object below it is ledger-scoped. Users who treat the ledger as a cosmetic container usually misconfigure accounts and routes later.

Pair this page with Setup path when onboarding new users. One page explains the model; the other explains the order.

​Core hierarchy

​What each object means

​How a transaction actually depends on prior setup

​Practical reading of the UI

​When users usually get lost

Core hierarchy

What each object means

How a transaction actually depends on prior setup

Practical reading of the UI

When users usually get lost