> ## 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. This is the page where 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 actually does".

Here's the mindset shift: a **ledger plan** — sometimes called a **chart of accounts** — is not a list of accounts you rush to create. It's a *deliberate classification* of the accounts your business needs, and how they relate. 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 rest of this page is a simple, four-step method for doing exactly that.

## 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>
  A good rule of thumb: if you'd ever want to ask "how much is in *here* right now?" — 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

***

This is the heart of the method. 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 collapsing these three into one. *Classification* (what an account is allowed to be) is not the same as a *reporting slice* (how you'd group it in a report), which is not the same as an *operational group* (which accounts belong to one customer). 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. This is where your plan comes alive — and it's exactly 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 — yes. Fees collected need their own balance — yes. Settlement needs its own balance to mirror the outside world — yes.

**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 — add a **label** for region.
* *Operational group?* A premium customer might hold several wallets — **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.

## In short

***

* A **ledger plan** is a deliberate classification of the accounts your business needs — not a list to rush.
* Design it like rooms in a house: decide purpose and access **before** you build.
* The method: (1) list real-world actors, (2) keep the ones that need their **own truth**, (3) classify and group them with the **three questions**, (4) sketch the movements.
* Keep the three questions — *validation*, *reporting slice*, *operational grouping* — separate. Collapsing them is the classic mistake.

<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/midaz/accounting-in-midaz), then put your plan to work with the console [Setup path](/en/lerian-console/midaz-console/midaz-console-setup-path) and [Concepts map](/en/lerian-console/midaz-console/midaz-console-concepts-map).
</Note>