UbicutoThere is a class of error in marketplace bookkeeping that no check catches. The payout reconciles, the ledger balances, the bank agrees with the receivable, and the VAT return is still wrong. That happens because reconciling and booking correctly prove two different things, and most bookkeeping only verifies the first.
Reconciling proves completeness: every line from the settlement report ended up somewhere in your books. It does not prove they ended up in the right place. Move an amount from one account to another and the balance stays identical. A fee on the wrong account therefore reconciles exactly as perfectly as a fee on the right one.
Where this goes wrong in practice
Advertising is not commission. Both appear in the same report, both are marketplace costs, and when booked by hand they often land on the same account. But advertising is regularly invoiced by a different entity than the selling fees, which means a different VAT treatment. On a single combined account that distinction is gone for good, and your input VAT is systematically wrong.
An EPR contribution is not the fee for collecting it. Amazon puts two lines in your report: the environmental contribution it remits on your behalf, and its own service fee for doing so. Those are two different things fiscally. They also appear per country, and that is not a detail: the schemes differ per country, so one combined line for all countries is wrong from the start.
Withheld VAT is not an expense. Where the marketplace withholds and remits VAT as a platform, that shows up as its own line in the balance. Book it as a fee and your payout reconciles while you declare VAT someone else has already paid, or you omit revenue you should have declared.
A reimbursement is not revenue. Being paid for stock lost or damaged in the warehouse is compensation, not a sale. On a revenue account it counts towards your revenue per rate, and from there into your return.
Two traps everyone building this themselves runs into
The first: the same fee appears under more than one spelling. Within a single file a cost type sometimes carries spaces in its name and sometimes does not. Hardcode your booking on the exact string and you will miss half of them.
The second: some codes contain the settlement period. An annual levy can carry the year inside the source text. Match on the literal string and every one of those codes is unknown again on 1 January, and your exception list fills up each year with costs you assessed long ago.
Both are why the translation from source code to account should be data rather than code: a list you extend, carrying a date and the name of whoever assessed it. A new cost type is then a row you add, not a change that has to pass a developer.
The only defence that works
An unknown line type must never be placed automatically. No suspense account, no "other costs", no clever guess based on a similar-looking name. The moment that happens your payout reconciles again and the evidence that something new occurred is gone.
The workable rule is simpler and stricter: a code you do not recognise goes onto a list someone looks at. The rest of the payout stays reconciled, so one unknown fee does not block your period. But nothing has been booked, and that is the point. The question "what is this and where does it belong" gets answered once, by someone qualified to answer it, and that answer then holds for every occurrence after.
What to do with this
Check two things in your own books. First: how many distinct cost types from the settlement report have their own account, and how many ended up on one combined line? Second: what happens next month when the marketplace introduces a cost type that did not exist before?
If the answer to the second question is that it disappears somewhere automatically, then your payouts will reconcile neatly from now on. That is exactly the problem.