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.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.
Core hierarchy
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
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
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 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
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
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.