How to design your ledger

Ledfra guarantees every transaction balances. It cannot tell you that you put the money in the wrong account. That is the failure mode nobody warns you about: a chart of accounts can be structurally wrong, balance perfectly to the cent, and still report revenue you never earned. These are the design rules that keep your ledger honest - decide them once, up front, because accounts are hard to change after they have history.

This page is the working checklist: category by category, which accounts to create and why. The theory behind it lives in two guides and is worth the read when a rule here feels arbitrary - create the ledger structure teaches the five categories from zero, and model normal debit and credit accounts derives why each one increases on the side it does. Examples use Firecnc, the fictional rental marketplace from the How to build a marketplace ledger.

A new ledger already has the five categories

You do not create them, and you cannot add a sixth. Create a ledger and the editor already lists all five, empty and waiting for you to file accounts under them. Each one carries a fixed normal balance, the side that makes it go up, and you never choose that per account either - it comes with the category you file under.

So the work is never "design the top level". It is filing: every account you add goes under one of these five, and that choice is the design decision. Put an account in the right place and its sign is right forever - which is why most design mistakes are really filing mistakes, the right amount correctly recorded under the wrong root. The rest of this page walks the five in the order worth building them, and spends the most time on the two that get confused - income and liabilities.

Define your asset accounts: one per place money sits

Start with the easy category. List every place your money physically sits, and give each one its own account:

assets
├── mercury               your operating bank account
├── stripe                money Stripe holds for you
├── paypal                money PayPal holds for you
└── payouts-in-transit    left Stripe, not landed in a host's bank yet

The rule of thumb: if a real statement exists for it, it gets an account. Your bank issues a statement, Stripe reports a balance, PayPal reports a balance - one account each, so every balance in your ledger can be checked against the source that produced it. Add an in-transit account for money that has left one place and not yet landed in another, because for those days it genuinely sits nowhere a statement can see.

Do not invent structure you do not have. If all your cash sits in one bank account, one asset account is enough. And resist filing things here that are really costs: the boundary between an asset and an expense is whether the value is still worth something next month, and create the ledger structure covers the cases that hesitate, prepaid contracts especially.

Define income and expenses: only money you keep is income

This is the most common structural mistake, and the most expensive one to unwind. If you collect $230 from a guest and $200 of it belongs to the host, your income is $30, not $230. The $200 was never yours. It is a debt from the instant you collect it until you pay it out.

A guest pays $230. $200 belongs to the host, $30 is your service fee.

❌ Book the whole $230 as revenue, the host's share as a cost
   DEBIT   assets:stripe          USD:230.00
   CREDIT  income:bookings        USD:230.00
   DEBIT   expenses:host-payouts  USD:200.00   (when you pay the host)
   CREDIT  assets:stripe          USD:200.00

✅ Split it the moment you collect it
   DEBIT   assets:stripe          USD:230.00
   CREDIT  income:service-fees    USD:30.00    ← yours
   CREDIT  liabilities:hosts/42   USD:200.00   ← the host's, you just hold it

Here is what makes this sting: both versions report the same $30 profit. Both balance. Nothing errors. But the first reports $230 of revenue and the second reports $30 - and revenue is the number on your board deck, your investor update, and your tax return. You will not notice from the ledger. You will notice from the conversation.

So the income side of your tree is usually short: one account per thing you actually charge for (service fees, listing fees, subscriptions). The expense side is whatever you consume to operate - processing fees, hosting, salaries. Two rules keep both sides honest:

• Paying out is not an expense. Paying the host $200 settles a debt - it moves money, it does not consume it. An expenses:host-payouts account double-counts: you already recorded the obligation when you took the booking.
• A cost you pay has no matching income. The processor charges you $7. That is an expense, full stop. Inventing an income:processing-fees account to cancel it out inflates both revenue and costs while netting to the same profit.

Define your liability accounts: model every state money passes through

Money in a platform is rarely just "in" or "out". It is usually collected, then held for a while, then owed, then paid. If your ledger jumps straight from collected to paid out, it can answer "what did we pay?" but not "how much of other people's money are we sitting on right now?", which is the question a regulator, an auditor, or your own finance lead will ask first.

Give each state its own account, and make each transition its own transaction:

• Held (escrow) - collected, but the host has not earned it yet: the stay is not over, or the dispute window is still open.
• Owed (payable) - confirmed and ready to pay out.

Key escrow per host (liabilities:escrow/42), not per booking. "How much are we holding for this host?" is then a balance you can read, instead of a report you have to build. It also keeps the number of accounts proportional to your hosts rather than your order volume.

Equity: usually just paid-in capital

For most platforms this is the shortest section of the tree: one account for what the owners and investors put in. When Firecnc raises a Series A, the cash lands in an asset account and the same amount lands in equity:paid-in-capital - the money and the claim on it, recorded together.

Do not create an account for retained earnings. The balance sheet computes it from your income and expenses since inception, so it is always right and never posted. If earning money made you reach for an equity account, the amount probably belongs under income instead.

Name the leaf, not the path

Accounts live in a hierarchy, and the app shows the full path. Repeating the parents in the name is noise you read on every screen and every report line.

✅ Expenses › Stripe › Processing fees
❌ Expenses › Stripe › Stripe Processing Fees Expense

✅ Assets › Current assets › Stripe
❌ Assets › Current assets › Current Stripe Assets

If you catch yourself prefixing a name, you probably want a subcategory instead. Group with structure, not with longer strings. This is also what accounting software does, so the people reviewing your numbers read it without translating.

Slugs are the exception: they are identifiers, not labels. Nobody reads them in a report, so keep them explicit and stable (expenses:stripe-fees, liabilities:hosts) rather than pretty. A slug is forever, which is what the next rule is about.

Key per-object accounts by a stable id

A template account gets one account per object, and the id you use becomes part of that account's identity permanently. Ledger accounts carry posted history, so they are not safely renamable.

✅ liabilities:hosts/42          ← your database id for the host
❌ liabilities:hosts/jane-doe    ← breaks when Jane changes her name
❌ liabilities:hosts/jane@x.io   ← breaks when Jane changes her email

Use the primary key from your own database, the id you already use for that user, host, or company. If you bill companies rather than people, key on the company. Anything a human can edit is a trap: usernames, emails, display names, handles. They look better in the slug right up until someone changes one and you are holding an account named after a person who no longer exists.

Usernames are safe only if they are immutable in your system - genuinely immutable, not "we don't have that feature yet."

Block overdrafts on accounts that must never go negative

Some accounts have no meaning below zero. A host's payable cannot go negative - you cannot owe them less than nothing. Your PayPal balance cannot go below zero, because the real one cannot.

Every account has an Allow negative balance switch, and it is on by default. Turn it off on accounts like these. Ledfra then rejects any transaction that would overdraw the account, so a bug fails loudly at write time instead of quietly producing a balance that cannot exist.

This does more than catch bugs - it forces you to model funding honestly. If you collect on Stripe but pay out from PayPal, PayPal cannot go negative, so you have to post the real Stripe-to-PayPal transfer before the payout. That transfer happens in the real world. Now it is in your books too.

Write descriptions a reviewer can scan

Someone reviewing a month of transactions wants to know what kind of transaction each one is. They do not need the booking details - they can open the booking. Describe the transaction type and the counterparty. Keep your own identifiers in metadata, where you can filter on them.

✅ "Payout to host 42 via Stripe"
✅ "Escrow released to host 42"
❌ "Loft in Berlin Mitte, 3 nights, cleaning included"

Keep the vocabulary small and closed: booking payment, payout, refund, transfer. A short list you reuse becomes a reporting dimension. A free-text field written by five engineers becomes nothing.

Your structure is what your reports look like

Every rule above is really a reporting decision made early. The balance sheet and profit & loss render your categories and accounts directly - they do not reorganize anything on your behalf. So a chart of accounts that files held funds under income produces a P&L that is arithmetically perfect and commercially wrong, and no report will flag it.

This is the part worth sitting with before you post anything real. Double-entry catches arithmetic mistakes. Nothing catches structural ones. The statements simply show you what you told them, which is why the design happens first and the integration second.

Design checklist

Before you post your first real transaction, walk this list:

• Every place money physically sits has its own asset account.
• Only money you actually keep sits under Income.
• No account treats paying a debt as an expense.
• Money you hold for someone else is a liability, from the moment you collect it.
• Money that sits somewhere for a while has an account for that state.
• Every per-object account is keyed by an id that can never change.
• Account names do not repeat their parents. You group with subcategories.
• Accounts that cannot go below zero have Allow negative balance turned off.
• Descriptions say what kind of transaction it is. Your ids live in metadata.

Where to go next

1. How to post first transaction - turn this structure into its first balanced entries.
2. How to build a marketplace ledger - every rule on this page, applied end to end.
3. Sandboxes - try a design against throwaway data before committing to it.
4. What is Ledfra? - the model these rules sit on.
5. Guide: Create the ledger structure - the five categories from scratch, for a reader meeting them for the first time.
6. Guide: Why marketplace accounting becomes so hard - why a schema without these rules reports revenue it never earned.

For the mechanics behind the rules, read Accounts, Transactions, and Money, then post through the API reference.