Create the ledger structure: assets, liabilities, equity, income, expenses

The first thing an empty ledger shows you is a tree with five root categories:

Ledger
├── Assets
├── Expenses
├── Income
├── Equity
└── Liabilities

You need accounts for your Stripe balance, the money you hold for sellers, your commission, and the processor’s fees. Nothing on the screen says which root each one belongs under, and that choice matters more than it looks: almost every expensive mistake in a platform’s books is a filing mistake - the right amount, correctly recorded, in the wrong category. File a seller’s $900 under income instead of liabilities and your reported revenue is ten times what you actually earned, with nothing anywhere to flag it.

This guide makes the five categories useful rather than vocabulary to memorize. By the end you can look at any amount your platform handles and file it, which is the whole job: the structure you create here decides what every report says later. No accounting background is assumed, and nothing here requires knowing what a debit is - that mechanism has its own guide, and it is easier once the structure exists.

An account is a named measurement

In product engineering, an account usually means a login or a bank account. In a ledger, the word is broader. An account is a named place where you accumulate changes to one economic quantity.

• A Stripe balance account measures money Stripe currently holds for you.
• An Accounts receivable account measures amounts customers owe you.
• A Seller payables account measures amounts you owe sellers.
• A Commission account measures value you earned during a period.
• A Processing fees account measures value consumed during a period.

An account is not necessarily a place where cash sits. A receivable, an obligation, and a month’s worth of fees are accounts too. They measure different facts about the same business, and that is the point: a ledger is a set of measurements, and the tree you are about to build decides which facts get measured.

Names are yours to design. Types are not. Whether you call an account Stripe, Processor balance, or assets:stripe-balance, if it measures money a processor holds for you, it is an asset regardless of its name. The type comes from which of the five roots the account sits under.

The five categories

Every account in every ledger, in every country, sits under one of five roots. Each answers a different question about the business.

The five split into two groups that answer different kinds of question, and the split is worth internalizing early because it is also how the reports divide:

State at a point in time:          Changes during a period:
Assets, Liabilities, Equity        Income, Expenses

"What do we hold and owe           "What did we earn and consume
 right now?"                        this month?"

Assets, liabilities, and equity describe the company’s position: a snapshot that is true at one instant. Income and expenses describe activity: they accumulate over a reporting period and reset when the next one starts. An engineer can think of the first group as state and the second as a counter over a time window. That is not the accounting definition, but it is the right instinct for why both kinds exist.

Why these five and not six

The list is not a taxonomy somebody invented and everyone else agreed to. It falls out of one idea: every amount of money has a source and a use. There are two kinds of use and three kinds of source, and that is the whole list.

Money you used either turned into something you still have, or it is gone:

• Assets are uses that still have value to you. You move $50,000 from your bank account into your Stripe balance to fund this week’s payouts. The money changed places and you are exactly as rich as you were a minute ago.
• Expenses are uses that are consumed. You pay last month’s cloud infrastructure bill, or Stripe charges you a $15 fee on a disputed payment. Neither one leaves you holding anything.

Money you got came from one of three places:

• Liabilities are amounts somebody else has a claim on. A seller waiting to be paid, a buyer owed a refund, a vendor bill you have not settled yet.
• Equity is what the owners put in, plus what the business has accumulated since.
• Income is what you earned by doing the thing the business does.

Two uses, three sources. There is no sixth category because there is no sixth answer to “where did it come from and where did it go”.

Income and expenses are equity in motion

A natural question about the position-versus-activity split: if equity is what is left for the owners, and earning money leaves more for the owners, why are income and expenses separate categories at all?

Because equity is a total and income is a rate. “The owners’ stake is $200k” is a fact about right now. “We earned $40k” is meaningless without a period attached. Every dollar you earn makes the business worth more to its owners, and every dollar you consume makes it worth less - income and expenses are equity, measured while it moves. They accumulate over a reporting period, get reported as that period’s performance, and then fold into equity as accumulated profit so the next period can start counting from zero.

Classify one marketplace order

Take a $1,000 order on a marketplace charging a 10% platform commission, paid through Stripe at its published 2.9% + $0.30, which on $1,000 is exactly $29.30. Four amounts, four decisions.

Look closely at the first two rows, because they describe the same dollars at the same instant. You hold $1,000 and you owe $900 of it. Both statements are completely true, they are about the same money, and they belong to different categories. A single balance column can express one of them. This is the clearest reason a platform that holds money for other people needs two-sided bookkeeping and not a spreadsheet.

The mistake that inflates revenue tenfold

Now the classification that goes wrong most often, and the one that costs the most to unwind. Here is the same order filed two ways. Both record every dollar. Neither errors.

WRONG                                    RIGHT
-----                                    -----
$1,000 arrives                           $1,000 arrives
  -> income:sales           $1,000.00      -> income:commission              $100.00
                                            -> liabilities:payables-sellers  $900.00

$900 paid to the seller                  $900 paid to the seller
  -> expenses:seller-payouts  $900.00      -> settles the payable, consumes nothing

Revenue reported:  $1,000.00             Revenue reported:  $100.00
Costs reported:      $929.30             Costs reported:      $29.30
Profit:               $70.70             Profit:               $70.70   <- identical

Both versions report the same $70.70 profit. That is what makes this so durable. Nobody scanning the bottom line will spot it, and the ledger has no opinion, because arithmetically nothing is wrong. What differs is the two numbers people actually quote: revenue reads $1,000 instead of $100, and costs read $929.30 instead of $29.30.

Revenue is not a vanity metric. It is load-bearing in places that are awkward to correct:

• It is the number in a board deck and an investor update, and it is what a revenue multiple is applied to.
• Registration and audit thresholds in most jurisdictions are stated as turnover. A tenfold overstatement can put you over a line you are not actually near.
• Every derived metric inherits it. Your take rate, your revenue per customer and your gross margin are all wrong by the same factor, in the same direction, quietly.

The reason it happens is that $1,000 genuinely did arrive in your account. It feels like revenue because it looks like revenue in the bank feed. But the cash arriving and the revenue being earned are two separate facts, and only one of them is about you.

Note what the test does not ask: whether the money is still in your account. It usually is, often for weeks, and you may well be earning interest on it the whole time. That changes nothing. Holding the cash and owing the cash are two facts, both recorded, both true.

Paying out is not an expense

The first mistake nearly always brings a second one with it. If the $900 was booked as income when it arrived, then paying the seller has to be booked as something, and the obvious-looking answer is an expense account called something like expenses:seller-payouts.

It is not an expense. An expense is value consumed. Paying the seller consumes nothing: it settles a debt you already recorded when you took the order. Cash goes down, and an obligation goes down with it. Nothing about the business got poorer, because the $900 was never yours to lose.

The two errors are self-concealing as a pair, which is exactly why they survive audits by eyeball. Overstated revenue plus overstated costs nets to the correct profit. Only the two totals are wrong, and only one report shows them.

A cost you pay has no matching income

The mirror image of the same instinct. Stripe charges you $29.30. That is an expense, full stop, and nothing else about your structure needs to change to hold it.

What sometimes gets built instead is an income:processing-fees account, to “offset” the cost so the books feel symmetrical. They net to the same profit and they inflate both revenue and costs, for no gain at all. A cost you pay to a vendor does not generate income, because nobody paid you.

There is one case that looks like this and genuinely is income, and the difference is worth being precise about. If your terms say the seller pays the processing fee, then you have charged them for something and that charge is income to you. Stripe’s bill to you is still an expense. Two independent events, and the fact that the amounts happen to match does not make them one thing.

Asset or expense? Ask when the value is used up

The other boundary people hesitate at, and it has a clean question behind it: will this still be worth something to us next month?

• $50,000 moved from your bank into your Stripe balance is still an asset. It changed accounts, not owners, and you can move it back tomorrow.
• $4,000 of cloud infrastructure for last month is an expense. It bought you a month that has already been served.

For a platform this boundary is quieter than a textbook makes it look, and it is worth saying why. Almost everything on your asset side is money sitting somewhere: a bank account, a processor balance, a payout in transit, an amount a processor owes you but has not released. Almost everything you buy is a service that is consumed as it is delivered. The equipment-and-depreciation machinery that fills half an accounting course barely applies to a business whose largest asset is its Stripe balance.

The one case that does need a decision is paying up front. You commit $24,000 in January for twelve months of a vendor contract. On the day you pay, you hold something real: twelve months of service you have not used. Strictly that is an asset, and $2,000 of it becomes an expense each month as you consume it.

Most early platforms book the whole $24,000 as a January expense instead, which overstates January and flatters the eleven months after it. That is a defensible shortcut when the amounts are small against your monthly costs and an actively misleading one when they are not. Pick a threshold above which you split it, write the threshold down, and apply it the same way every time.

One category, many accounts

The five are roots, not accounts. Real ledgers have hundreds of accounts hanging off them, and the category’s only job is to fix the meaning and the report. The tree carries the detail:

assets
├── mercury                      operating bank account
├── stripe-pending               captured, not settled yet
├── stripe-balance               settled, available to pay out
└── payouts-in-transit           sent, not landed

liabilities
├── payments-processing          collected, not settled yet
├── escrow                       settled, not confirmed yet
└── payables-sellers
    ├── 9001                     confirmed, withdrawable
    └── 9002

income
├── commission                   what you charge for the service
└── listing-fees

expenses
├── processing-fees              what the payment processor keeps
├── chargeback-fees              what a dispute costs you, win or lose
├── cloud-infrastructure
└── salaries

Notice where the five stages a payments table cannot tell apart went: they are spread across the asset side and the liability side at once, because each stage is two facts. Money captured but not settled sits in assets:stripe-pending and is owed under liabilities:payments-processing. A stage is not a status flag on a row. It is an account, so “how much is still settling” and “how much is withdrawable today” become balance lookups rather than queries with a business rule buried in each:

-- What do we owe sellers right now?
select balance from account where slug = 'liabilities:payables-sellers';

Two structural habits are worth adopting on day one, because both are painful to change later. Key per-object accounts by a stable id (payables-sellers/9001, never a name or an email) since accounts are referenced by posted history and are not safely renamable. And name the leaf, not the path, because the hierarchy already carries the context. Both, with the reasoning, are in how to design your ledger, and Accounts covers how per-object accounts get created without a migration for every new seller.

Your categories are your reports

Here is the part that makes filing worth caring about. You do not build financial statements. You file accounts, and the statements are what those categories mean when you group them.

• The balance sheet is assets, liabilities and equity: what you have, what you owe and what is left, at one instant.
• The profit and loss is income and expenses: what you earned and consumed, over a period.
• The trial balance is all five at once, and it is the proof the books still agree with themselves.

Which is the good news and the bad news in one sentence. File an account correctly and it lands in the right report forever, with no reporting code to write. File it wrongly and the report is wrong forever too, with nothing anywhere to tell you, until somebody outside engineering reads a number and asks a question you cannot answer.

The questions that settle almost every account

When you are staring at an amount and cannot decide, work down this list and stop at the first yes.

1. Would we ever have to give it back or forward it to somebody? Liability. This one goes first on purpose, because it is the one that gets missed and the only one that is expensive.
2. Do we hold it, and will it still be worth something next month? Asset.
3. Did an owner or investor put it in? Equity.
4. Did we earn it by doing what the business does, and do we keep it? Income.
5. Is it consumed and gone? Expense.

The order matters more than the list. Question one catches the mistake that inflates revenue, and it catches it before the money ever feels like yours.

Where this goes next

The structure now exists: five roots, real accounts under them, and a rule for filing anything new. What it cannot do yet is move. Recording an actual event needs the two operations every account accepts, and those only make sense now that the structure is in place: model normal debit and credit accounts derives both from the tree you just built.

For how a payments schema ends up needing all this in the first place, why marketplace accounting becomes so hard is the case study these five categories are the fix for. The full set of structural rules, including the states money passes through and how to keep overdrafts from being possible, is at how to design your ledger, and a complete worked marketplace, from structure through postings to the resulting statements, is at how to build a marketplace ledger.