Marketplace Ledger: Why Balances Must Match the Transfer

A seller sees one number in your panel, and a different one arrives in their bank account. Usually nobody made a mistake, and nobody stole anything.

The difference comes from the fact that "balance" is not one thing. But the seller has no way to tell that apart from an error, and your accounting team finds out fairly quickly that this is a reporting problem.

This is one of the few areas of a marketplace where a flaw in the architecture shows up in the first month after launch and costs the seller support team time every single day.

A marketplace ledger is the append-only record of every amount you owe a seller and every amount you have withheld from them. It is what makes a balance explainable. A seller sees one number in the panel, a different number arrives in their bank, and usually nobody made a mistake. Without a ledger underneath, nobody can say which orders, refunds, and deductions produced either figure.

This article breaks down:

• What is a marketplace ledger, and which 4 balances does it hold?
• Why can you never edit an accounting entry?
• Why does every entry need two dates?
• Where does the amount drift with nobody at fault?

Key insights

• "Balance" means at least four things: the moving preview, the amount due, the amount already paid out, and the statement for a closed period.
• A correction is an opposing entry with an author, a reason, and a reference. Overwriting a row destroys the only record of what happened.
• Every entry needs two dates: when the event happened and which period it belongs to. Without both, a refund from March lands in May.
• The sum of the statement lines has to equal the transfer to the cent, with no difference line and no adjustment line.

What is a marketplace ledger and which 4 balances does it hold?

When a seller says "I have €40,000 with you" and you say "we will pay out €32,000," you are both right, because you are talking about different objects.

1. The current balance, the preview number

This is the sum of orders that have already come in but have not yet matured for payout. It moves with every new order, every cancellation, and every refund.

2. The balance due waiting to be paid out

This is the amount that will go into the next payout if nothing changes before the cycle cuts off. It moves as well.

That is the source of most of the misunderstandings, because it looks like a promise and it is not one.

3. The paid-out balance

This is the only one of these numbers that is a fact about the world: the sum of transfers that were actually made. It is worth noticing that this is not a balance at all.

It is a sum of events. The consequence is practical: nobody should be able to "set" a seller's status to "paid out." You can only post a transfer that genuinely left the account.

4. The statement for a period

This is the fourth thing, the one nobody usually calls a balance, and the most important of them. It is an itemized list of lines that adds up to exactly one transfer.

A balance answers the question "how much." A statement answers the question "why that much."

There is a fifth thing: reserves and holds on the balance. That is a separate subject, and "How Marketplace Seller Payouts Work: Cycles, Holds, and Reserves" on payout cycles covers it.

This split is not something we invented: payment providers separate balances in exactly this way (pending funds, available funds, reserved funds, next payout), so your seller already knows it from other tools. If your panel shows a single number and calls it "the balance," that is concealment.

How do the 4 balances compare?

The example of a marketplace ledger

Conditions: One seller, a commission of 12%, payout after the month closes.

March. They sell 10 orders at €1,000 each, so €10,000.

The commission is €1,200. The amount due is €8,800.

That is what they receive at the beginning of April.

May. They sell €5,000, the commission is €600, so the panel shows a balance due of €4,400.

In that same May, a customer returns one of the March orders. The seller refunds €1,000 but gets €120 of commission back, so what they really lose is €880.

The June payout is €3,520, not €4,400.

And now the part that matters: that payout is correct. March has already been paid, so the correction has nowhere to go except the current settlement.

The mistake is not that the money moved in this direction. The mistake is that the seller has no way to see that inside those €3,520 there is a minus €880 line labeled with a March order number.

They have to write to support to find that out.

Let us also check that the cash adds up. €8,800 in April plus €3,520 in June is €12,320.

After the correction, March is worth €7,920 and May €4,400, which together is €12,320. The flow of money is correct, and the picture of March still changed after the fact.

Those are two different truths, and the system has to be able to produce both.

That is where the title of this article comes from. The point is not that the number shown in April should equal the transfer sent in June.

The point is that the statement that produces the transfer adds up to it down to the cent, and that every line on it carries the period it belongs to.

Why can you never edit an accounting entry?

The instinct is natural: the commission was calculated wrong, so fix the amount. That is exactly the instinct that ruins marketplace accounting.

Once an entry is posted, it has to be immutable, and every correction is a new entry that reverses the effect of the previous one. This rule is shared by classical bookkeeping and by modern ledger systems: a correction goes in as an opposing entry with a reference to the original rather than as an overwrite of a row.

Systems built for finance often have no path to edit or delete an entry at all. The attempt ends in an error.

If a balance can be recalculated, you lose the ability to answer the question "what did this look like at the end of March?" Today's number is the only one you have.

And that is exactly what an auditor, an inspector, and a seller in a dispute will ask you. Immutability costs one extra entry per correction and gives you a complete, reproducible history in return.

The practical consequence for you as a buyer: if the system has a screen where an employee types a seller's balance in by hand, that is not a feature. It is a hole.

Manual correction is necessary, but it has to be an entry with an author, a reason, and a reference rather than an overwrite of a number.

Why does every entry need two dates?

This is the whole difference between a system that will serve your accounting team and a system that will weigh on it.

• The posting date. When the entry went into the book. Always "now," never backdated.
• The source period. The period that the business event described by this entry belongs to.

On an ordinary sale, both point at the same month and nobody notices there are two of them. They come apart on corrections: our refund is posted in May and belongs to March.

Because of that, the same set of entries answers two different questions without contradicting itself. "What happened in May" groups by posting date and gives €3,520.

"How does March finally look" groups by source period and gives €7,920 instead of €8,800. Your own revenue from March drops the same way, from €1,200 to €1,080.

A system that keeps a single balance and recalculates it on correction can answer only the first question. The second one then lands on your finance team, in a spreadsheet, by hand, every month.

With several hundred sellers, that is not a job for a spreadsheet. The distinction is not industry exotica: separating the date an entry was made from the date it applies to is a standard pattern in ERP systems and in the design of financial ledgers.

The two dates also give you period close. Once a month is closed, you no longer post anything into it.

You post into the current month and point the entry at its source period. This is the same rule for which accounting systems lock entries in closed periods: reopening a period destroys the audit trail.

The practical conclusion: you issue the commission invoice for a closed period, because in an open one the commission total is not final yet.

Which 3 places make the amount drift with nobody at fault?

Each of them generates a phone call from a seller, and none of them is an error.

1. The rounding level

A commission calculated on each line separately, rounded there and then summed, gives a different result than one calculated on the total. It is cents on a single order, but across tens of thousands of orders it turns into a line item nobody can explain.

Insist on one rounding level, declared openly.

2. Currency

A balance exists for a pair: one account and one currency. A single "consolidated balance after conversion" is untrue the next day, because the rate moved.

The rate has to be frozen on the entry at the moment of posting.

3. The cut-off moment

An order that matured five minutes after the cycle cut-off is in the balance due and is not in the transfer. That is correct.

It also makes no sense to the seller if the statement does not show the cut-off moment.

What does the ledger decide?

1. Explaining settlements stops being human work

In marketplaces, the question "why did I get this much" is one of the heaviest loads on the seller support team. If every line of a statement expands into a specific order, refund, or fee, the conversation turns into a link.

That is a bigger saving than any single accounting feature.

2. Seller trust is a function of predictability rather than of the size of the commission

A seller will forgive 12% instead of 10%. What they will not forgive is being unable to predict their own income.

That is their working capital.

3. Your periodic reporting stands on the same structure

If corrections cannot be assigned to the period they concern, accounting gets one bucket instead of a breakdown and untangles it by hand at every month-end close. Operational practitioners describe this as the most burdensome part of running a marketplace.

It is also why many teams build their own settlement layer next to the platform, a cost the business case usually does not contain.

4. This settles the neighboring decisions as well

The articles on refunds and on commission on a refunded order determine which amounts arise at all. The article on reconciling the money checks whether what the book recorded really left the account.

All three assume that there is a ledger underneath rather than a single number.

How do you check the ledger with a vendor? 6 questions

Six questions that take a quarter of an hour and separate a financial system from a screen with a number on it. Ask them at the demo and ask to be shown rather than told.

1. "Produce a statement for March for me today. Will it contain the May refund that relates to a March sale?" That one question tests whether the two dates exist. If the answer is "the March statement is closed and does not change" or "the correction sits in May only," you have a single balance rather than a ledger.
2. "Show me a transfer and break it down into lines." The sum of the lines has to equal the transfer to the cent, with no "difference" line and no "adjustment" line.
3. "What happens when a commission calculated wrong two months ago has to be fixed?" The answer "we edit the entry" is disqualifying. The correct answer is "we post a correcting entry with a reference to the original."
4. "Can the status be set to paid out without a transfer having been made?" If it can, "paid out" means nothing.
5. "At what level do you round, and how many currencies live inside one balance?" You are looking for one explicit rounding level and a balance per currency, with the rate frozen on the entry.
6. "What does a seller see when they ask why they received this amount?" You want an expandable statement with links back to orders rather than an export to a spreadsheet.

One control question for you rather than for the vendor: can anyone in your organization say today who is responsible for making the number in the panel equal the transfer? If the answer is "the platform," the answer is nobody.

Which mistakes do operators make about the ledger?

1. Treating the gap as a UX problem

"We will improve the wording in the panel" does not work, because the problem is not in the presentation. It is that underneath there is one recalculated number instead of a history of events.

Cosmetics buy you a quarter, and then the problem returns.

2. One balance instead of a ledger

The cheapest architecture at the start and the most expensive one a year later, because it cannot be added retroactively. A history you never recorded cannot be reconstructed.

3. A manual balance correction with no trace

Convenient right up to the first dispute with a seller, or the first inspection.

4. A commission invoice from an open period

Issued before the total is final, it generates a correction to your own document on every refund.

5. Your own spreadsheet next to the platform, and the matter treated as closed

It works, and it is very common, but it means two sources of truth about money. On every discrepancy, somebody has to decide which one is lying.

What do you still have to settle yourself about the marketplace ledger?

It does not settle which period your correction belongs to in your tax accounting. That depends on the jurisdiction, on the type of correction, and on the scheme under which you account for the sale.

The rule can differ between ordinary accounting and special schemes. Confirm this with a tax advisor and with your own accounting team before you fix the rules in the system.

Our claim is narrower and independent of that answer: the data has to let you answer both ways, because it is your advisor who picks the rule rather than your platform. A separate article on corrections and periods, in the chapter on taxes and invoices, develops the document side: credit notes, invoices, and how they are assigned to periods.

It also does not deal with reconciliation against the payment provider and the bank, meaning the check of whether the recorded state matches the actual one. That is a separate mechanism and a separate article.

Nor with the retention of financial records, which carries legal requirements of its own, also to be confirmed for your country.

Summary: What makes a balance credible?

A ledger rather than a number: append-only entries, two dates on each, and a statement whose lines add up to the transfer exactly. Then explaining a settlement stops being human work.

Ask a vendor to show you a correction being posted rather than to describe one. Talk to a marketplace expert if you want the questions sharpened before the demo.

Frequently Asked Questions on Marketplace Ledger

What is a marketplace ledger?

A marketplace ledger is the append-only record of every amount owed to and withheld from a seller. It holds entries rather than a single figure, which is what makes a balance explainable: every number in the panel can be traced to the orders, refunds, and deductions that produced it.

Why does the seller balance not match the payout?

Because the panel shows a moving forecast and the transfer shows a closed period. A refund posted after the cut-off, a rounding rule applied per line rather than per total, or a currency conversion between the two can each move the figure without anybody making an error.

Can you correct a seller balance manually?

Only as a new entry, never as an edit. A manual correction needs an author, a reason, and a reference to the original entry.

Overwriting the number leaves an auditor, an inspector, or a seller in a dispute with nothing to look at.