Concepts map

Understand how Organizations, Ledgers, Assets, Accounts, Routes, and Transactions depend on each other before you start configuring the Midaz Module.

The Midaz Module uses a small set of core objects with explicit dependencies. Organization, Ledger, Assets, and Accounts are the core setup; Account Types, CRM records, Portfolios, Segments, and Accounting Routes are configured when the workflow needs them.

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	An optional classification such as checking, treasury, or expense	Use it when configured account or route rules need it.
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 ledger-scoped persisted grouping of accounts, such as by 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	An optional rule set for transaction participants and posting behavior	Midaz applies configured route rules when route validation is enabled.
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

---

The required prerequisites depend on the Transaction and Ledger settings. Assets and Accounts are required; Accounting Routes are required only when route validation is enabled.

Practical reading of the UI

---

Use this interpretation when you guide users:

• Foundation defines where the system lives: Organization, Ledger, Asset.

• Accounting defines optional participation and posting rules: Account Types and Accounting Routes.

• Accounts defines who holds balances and how you classify them: Accounts, Holders, Aliases, Segments, Portfolios.

• Transactions exercises the configured structure.

• Plugins extend the model after the core behavior already works.

When users usually get lost

---

Account vs Holder vs Alias

The Account is the balance container. The Holder is the CRM identity. An Alias Account is an optional CRM Instrument linked to a Holder and an existing Ledger Account; the Account’s own alias is its human-friendly identifier.

Account Type vs Segment vs Portfolio

Account Type is an optional classification. Segment and Portfolio are ledger-scoped persisted groupings of Accounts; they are not merely labels or direct Holder relationships.

Accounting Route vs Transaction

The Route is an optional reusable rule. The Transaction is the individual movement; it is checked against configured route rules only when route validation is enabled.

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 you onboard new users. One page explains the model. The other explains the order.