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

# Designing your ledger plan

> How to model your own business as a set of accounts: a simple, worksheet-style method for designing a chart of accounts before you build anything.

By now you know the pieces: accounts, balances, movements, the rules that govern them. Now you put them to work on *your* business. The goal is to move from "I understand the terms" to "I can model what my company does".

A **ledger plan** (sometimes called a **chart of accounts**) is a *deliberate classification* of the accounts your business needs, and how they relate. It is not a list of accounts you rush to create. Designing it well, up front, saves you from painful restructuring later.

## Think rooms before you build

***

Imagine designing a house. Before you pour any concrete, you decide what each room is for (kitchen, bedroom, office) and who's allowed in. You don't start laying bricks and figure out the floor plan afterward.

A ledger plan works the same way. You decide what each account is *for*, what rules it follows, and how money flows between rooms, **before** you create anything. The four steps below are that method.

## Step 1: List your real-world actors

***

Start away from the software entirely. On paper, list every real-world party that touches money in your business. Don't worry about structure yet. Just name them.

A typical list looks like this:

* **Customers**: the people or companies who hold value with you
* **Treasury**: your own operating funds
* **Revenue**: money you earn
* **Fees**: charges you collect on movements
* **Settlement**: money in transit to or from the outside world
* **Expenses**: money you pay out

This is your raw material. Every business has its own version of this list.

## Step 2: Decide what needs its own truth

***

Not every actor needs its own account. The test is simple: **does this thing need its own separate, trustworthy balance, its own truth?**

If you need to know, at any moment, exactly how much value sits with this actor, it needs its own account. If it's just a label or a detail of something else, it doesn't.

<Tip>
  As a rule of thumb, if you'd ever want to ask "how much is in *here* right now?" then that's an account. If two things should never share a balance, they should never share an account.
</Tip>

## Step 3: Classify and group with three questions

***

For each account you kept, ask **three universal questions**. Together they tell you how to structure and group your accounts.

| Ask yourself                                                                       | What it's about                                                                                     |
| ---------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| Do these accounts need a **rule that validates** what they are or how they behave? | Classification — enforcing that an account is a certain *kind*, with its own constraints.           |
| Do I need to **slice them for reporting**?                                         | Labeling — tagging accounts so you can later filter and report by group (region, tier, department). |
| Do I need to **group them operationally** around a customer or wallet?             | Operational grouping — bundling several accounts that belong together for one owner.                |

These three questions are independent. An account might need all three, or just one. Keep them separate in your mind:

```mermaid mermaid theme={null}
flowchart TD
  A["An account in your plan"] --> Q1{"Needs a rule that<br/>validates its kind?"}
  Q1 -->|yes| C["Give it a classification"]
  A --> Q2{"Needs to be sliced<br/>for reporting?"}
  Q2 -->|yes| L["Give it a reporting label"]
  A --> Q3{"Belongs to a customer<br/>or wallet group?"}
  Q3 -->|yes| G["Put it in an operational group"]
  classDef q fill:#fff8e1,stroke:#f4b400,color:#333;
  class Q1,Q2,Q3 q;
```

The big mistake here is to collapse these three into one. A *classification* controls what kind an account can be. A *reporting slice* is how you group an account in a report. An *operational group* is which accounts belong to one customer. Each is different, and treating them as one tangled thing is how ledger plans become unmanageable.

## Step 4: Sketch the movements

***

Finally, draw the arrows. For each kind of movement your business makes, sketch which account is the source and which is the destination. That sketch is the input you'll need when you later define reusable rules for those movements.

## A worked example: a simple wallet business

***

Say you run a wallet app. Customers load money in, send it to each other, and you take a small fee on transfers. Walk the method:

**Actors:** customers, your fee/revenue account, and a settlement account for money entering from the outside world.

**Own truth?** Each customer wallet needs its own balance. So do the fees you collect. So does settlement, which mirrors the outside world.

**Three questions:**

* *Validation?* Customer wallets behave differently from your fee account, so they're a different **kind**. Classify them.
* *Reporting slice?* You want to report customers by country, so add a **label** for region.
* *Operational group?* A premium customer might hold several wallets, so **group** them together.

**Movements:** a transfer moves value from one customer wallet to another, plus a small part into the fee account. Money entering the app moves from settlement into a customer wallet.

```mermaid mermaid theme={null}
flowchart LR
  S["Settlement<br/>(outside world)"] -->|load| C1["Customer wallet A"]
  C1 -->|transfer| C2["Customer wallet B"]
  C1 -->|fee part| F["Fee / revenue"]
  classDef bal fill:#fff8e1,stroke:#f4b400,color:#333;
  class C1,C2,F,S bal;
```

That's a complete ledger plan for a small business, sketched before touching any tool.

## Common first-timer mistakes

***

* **Over-classifying.** Creating a dozen account kinds when two would do. Start coarse. Refine only when a real rule demands it.
* **Mixing reporting into structure.** Don't bake a reporting slice (like "region") into an account's *kind*. Keep how you classify separate from how you report.
* **Treating the plan as a list.** Rushing to create accounts before sketching movements leaves you reorganizing later.
* **Skipping the "own truth" test.** Giving everything its own account, or cramming unrelated things into one, both cause pain.

## Next steps

***

<Note>
  **See it in Lerian**

  Those three questions map onto how Lerian models accounts:

  * *Validation rule?* → **Account Types**
  * *Reporting slice?* → **Segments**
  * *Operational grouping?* → **Portfolios**

  See it all together in [Accounting in Midaz](/en/products/midaz/accounting-in-midaz), then put your plan to work with the console [Setup path](/en/products/midaz/console/midaz-console-setup-path) and [Concepts map](/en/products/midaz/console/midaz-console-concepts-map).
</Note>