The marketplace payout ledger: balances, reserves and reversals
An order is not a payout. How to model seller obligations, available and reserved balances, rolling reserves and chargeback clawbacks so month-end reconciles.
Most guides to split payments stop at the arithmetic. Take £100 from a buyer, keep £15, send £85 to the seller. Every processor has an API that does exactly that.
What breaks marketplaces is everything after the money moves — or rather, the gap between when it moves and when your books agree that it moved. Sellers chase missing payouts. Finance spends the first week of every month matching gross settlements to net obligations. A chargeback three months after the fact quietly turns a paid-out order into an unrecoverable loss.
This is about the system underneath: the ledger of what each seller is owed, the balances that ledger has to expose, and the reversals that break naive designs. It applies whichever payment model your platform runs — the legal structure changes who carries the liability, not who has to get the balances right.
An order is not a payout
Here is what separates marketplaces that scale cleanly from ones that don’t: they treat the payout ledger as a first-class system, not a derived report.
Between an order and a payout sit commission tiers, promotional discounts funded by the platform versus the seller, refunds, partial refunds, cancellations, seller-side adjustments, tax withholding and fees. Each changes what a seller is owed. Each arrives on its own timeline.
If your only record of what a seller is owed is a query that sums orders and subtracts fees at payout time, you have no auditable history. When a seller disputes a payout — and they will — you can’t reconstruct what the balance was on the day the calculation ran.
Three properties of a ledger that survives scale
Every obligation is an immutable entry. A refund doesn’t edit the original entry; it creates an offsetting one. You can replay any seller’s balance as at any point in time. This is the difference between a ledger and a subledger view assembled on demand.
Obligations and payouts are separate objects. You accrue what a seller is owed continuously; you release it on a schedule — the mechanics of which we cover in how to pay out marketplace sellers. Conflating the two makes holdbacks and rolling reserves impossible to model, because there is nowhere for money to sit that is owed but not yet payable.
Every entry references its source. Order ID, refund ID, fee schedule version. Without this, reconciliation is manual forever — you can see that the numbers disagree but not which of four hundred entries caused it.
This reads like accounting pedantry until the first time a seller escalates a £40,000 discrepancy and you answer in ten minutes instead of ten days.
The three balances every seller has
The moment you introduce any kind of hold, a seller stops having a balance and starts having three. All three have to be correct simultaneously in the seller’s dashboard, your accounting system and your cash forecast.
| Balance | What it means | Who needs it right |
|---|---|---|
| Available | Earned, cleared, payable on the next run | The seller, deciding whether to restock |
| Pending | Earned but inside the clearing or delivery window | Support, answering “where’s my money?” |
| Reserved | Withheld against refund and chargeback risk | Finance, forecasting the release schedule |
Most reconciliation work in a marketplace comes from these three numbers drifting apart. A seller sees one figure in their dashboard, finance sees another in the ledger, and the bank shows a third — because a reserve released overnight and nothing wrote it back.
Holdbacks: three mechanisms, and when each fits
Marketplaces pay out before they are certain the money is theirs to pay. Card chargebacks can arrive months after the transaction — under the major card scheme rules, dispute windows commonly extend to around 120 days from the transaction or expected delivery date, and longer in some categories. If you paid the seller on day two and the buyer disputes on day 90, you’re chasing a counterparty who has already spent the money.
Three mechanisms manage this, and most platforms need a combination:
Delayed release. Hold funds until a service is delivered or a return window closes. Clean for goods, awkward for services where “delivery” is ambiguous. This is the payout-side cousin of the buyer-side techniques we cover in holding funds in a marketplace.
Rolling reserve. Withhold a fixed percentage of each payout for a set period, releasing on a rolling basis. Predictable for you, unpopular with sellers, and only tolerable if the reserved amount is visible in their dashboard rather than discovered.
Risk-tiered release. New sellers wait; sellers with a clean twelve-month history get paid faster. This is where most mature marketplaces land, because it prices risk where it actually sits instead of taxing everyone equally.
The operational cost of all three is in the ledger, not the policy. Deciding to hold 5% is a meeting. Making 5% correct across three balances, a dashboard, an accounting export and a cash forecast is the system.
Reversals are ordinary entries, not exceptions
Refunds and chargebacks are where a payout ledger either holds together or reveals that it was a spreadsheet in disguise.
Take a €200 order: €30 platform commission, €170 to the seller, paid out on day 3. On day 40 the buyer refunds. You now need to return €200 to the buyer, claw back €170 from the seller, and reverse your own €30.
If the seller has a zero balance, you have three options — net it against future earnings, invoice them, or absorb it. Your system needs all three, because which applies depends on seller tier, contract terms and how much future volume they’re likely to generate. A platform that only implements “net against future earnings” has no answer for a seller who has already left.
Partial refunds multiply this. Does the commission scale proportionally, or does the platform keep its full fee on a partially fulfilled order? Both are defensible commercial positions. Only one of them is what your contract says, and your ledger has to implement that one.
The design principle: if handling a chargeback requires an engineer to run a script, you will have unhandled chargebacks.
Where reconciliation actually breaks
At month end three numbers must agree: what your processor settled to your bank, what your ledger says you owed, and what your accounting system recorded. In most marketplaces they don’t, and the culprits are predictable:
- Processor fees deducted from gross settlement but recorded separately in your books
- FX applied at a different rate or timestamp than your ledger assumed
- Payouts initiated but not yet settled, sitting in limbo across a period boundary
- Correspondent bank deductions on cross-border payouts that never appear in any statement you receive
- Refunds processed on the payment rail but never written back to the payout ledger
None of these is hard individually. They’re hard because they compound across thousands of transactions, and because the matching work is repetitive and unrewarding — which is exactly the kind of work that gets deferred until it’s a week long.
Matching properly means resolving every settlement line to specific orders, fees and payouts with tolerances, and surfacing only genuine exceptions for a human to judge. That’s the difference between finance closing in two days and finance closing in two weeks, and it’s a job that automates well.
It’s also the layer Fynex runs for marketplaces and platforms: agents that hold the obligation ledger, apply the holdback rules, execute the payout on the cheapest reaching rail, and book what actually arrived back against the original order — rather than producing a report telling your team to go and do it.
A checklist before you build
If you’re specifying a payout system now, answer these before writing code:
- Can you replay a seller’s balance as at an arbitrary past date, from immutable entries?
- Are obligations and payouts separate objects, or does one query do both?
- What are the seller balance states, and can the seller see all of them accurately in real time?
- What happens when a payout fails — wrong IBAN, closed account, sanctions hit? Who is notified, and what retries?
- How do you reverse a payout to a seller with a zero balance, in all three of the ways you’ll need to?
- Does a partial refund scale the commission, and does your contract agree with your code?
- How does the ledger reconcile to your accounting system, and how often?
If you can’t answer four of these, that’s your roadmap. The split itself was never the hard part.