A payout arrives as one net amount covering orders, commissions, advertising, refunds, reserves and adjustments drawn from overlapping periods.
A marketplace pays a seller a single net amount on a settlement cycle. That amount is the residue of a large number of separate economic events, and treating it as revenue is the most common accounting error in e-commerce.
The process
Orders are placed and fulfilled. The marketplace deducts commission, fulfilment fees, storage, advertising and various per-transaction charges; processes refunds and returns; holds a reserve against future returns; makes occasional adjustments and reimbursements; and remits the balance.
The seller sees a bank credit and a settlement report. The bank credit is one number. The settlement report contains everything.
Where it breaks
Net is booked as revenue. Recording the payout as sales understates both revenue and costs by the full value of the fees. Margin analysis built on this is wrong in a way that gets worse as advertising spend grows, because advertising is netted off before the seller ever sees it.
Settlement periods and accounting periods do not align. A settlement window rarely coincides with a month end, so a payout routinely spans two accounting periods. Recognising it in the period it landed shifts revenue across the boundary in both directions.
Refunds relate to earlier periods. A refund deducted in one settlement reverses a sale recognised in a previous one. Netting it against current sales understates the current period and leaves the earlier one overstated.
Reserves are cash timing, not cost. An amount withheld against future returns is the seller’s money, deferred. Treated as a fee it becomes a permanent expense that never reverses, and the reserve balance grows unnoticed.
The same event appears under several names. Fee schedules change, categories are renamed, and new charge types appear without announcement. A mapping built once and left alone silently drops unmapped types into whatever the default bucket is.
Multi-currency settlements carry an embedded conversion. The rate applied is the marketplace’s, at its timing, and the difference against the rate used in the ledger is a real gain or loss that belongs recorded as one rather than absorbed into revenue.
How we would build it
Decompose every settlement into typed components at the finest granularity the report offers — per order, per fee, per refund, per adjustment. The payout total is then never used as an input to anything; it is used only as a check.
Recognise revenue gross and fees as costs, so that both appear at their true magnitude. This is the change that makes margin by product meaningful, and it usually reveals that ranking by revenue and ranking by contribution produce different lists.
Allocate to the period the event occurred in, not the period the money moved in. A refund reverses against the original sale’s period. Settlements spanning a boundary are split, not assigned whole.
Treat unmapped charge types as an exception, never as a default. Every settlement line has a type; any type not in the mapping stops the run and is reported. This is the single control that keeps the reconciliation honest as the marketplace changes its fee schedule, and it is the one most often omitted because it is inconvenient the first few times it fires.
Track the reserve as a balance, with movements in and out, reconciled to the marketplace’s own reserve reporting.
What the system proves about itself
The reconciliation is self-proving in a way most are not: the sum of the decomposed components must equal the payout, and the payout must equal the bank credit. Two independent equalities, both exact, both checkable without judgement.
Where they hold, every component figure is trustworthy, because there is nowhere for an error to hide — a misclassified line would break the total. Where they do not, the difference is the unexplained residue and is reported as such rather than absorbed.
That property is worth designing for. It means the same process that produces the accounting entries also proves them, and the month-end question changes from “does this look about right” to a check that either passes or names what is wrong with it.