Skip to main content
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.
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.

​
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 yourselfWhat 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: 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. 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.
See it in LerianThose 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, then put your plan to work with the console Setup path and Concepts map.