UbicutoYou sold just over 38 thousand euro this period and 23 thousand landed in the bank. That gap is not a marketplace error and usually not yours either. A payout is a balance, and a balance contains items that have nothing to do with the revenue of that period. As long as you book that balance as one amount, your revenue is understated, your costs are invisible, and your VAT return cannot be right.
What is in the balance
Take a fictitious payout, used only to show the mechanism:
| Item | Amount |
|---|---|
| Orders in this period, including VAT | 38,412.60 |
| Commission | -5,761.89 |
| FBA fulfilment fees | -3,204.00 |
| Storage fees | -412.75 |
| Advertising costs | -1,850.00 |
| Refunds from an earlier period | -2,106.40 |
| Reimbursement for damaged stock | +184.20 |
| Previous reserve released | +4,900.00 |
| Current reserve withheld | -6,220.00 |
| Payout | 23,941.76 |
Four of those nine lines are not about this period. The refunds belong to earlier orders. The reimbursement is compensation, not a sale. And the two reserve lines only move money through time.
The reserve is the item most people miss
Amazon holds back part of your balance as a buffer against returns and claims, and releases it in a later settlement. The report shows this as two separate lines: the previous reserve being released and the new one being withheld. In this example that is 1,320 euro less cash, with nothing changed about your revenue or your costs.
In accounting terms that reserve is a receivable from the marketplace that has not been settled yet, not an expense. Book it as an expense and you depress one month's result, inflate the next, and end up with a bank account that structurally fails to agree with your ledger.
Where the VAT return breaks
The return asks for revenue per rate and per country. That information lives in the order line and nowhere else. It cannot be recovered from a payout balance: you cannot tell which part went to a German or a French customer, and therefore not which rate applies.
For sellers holding stock in more than one country this is sharper than the familiar threshold discussion. The moment your goods sit in Germany or Poland and you ship from there, that is a domestic supply in that country. The EU-wide distance selling threshold of 10,000 euro, in force since 1 July 2021, does not even come into it: you need a registration there regardless. The question is not whether you are over a threshold, but where your stock was at the moment of supply.
The same applies on the cost side. Whether the marketplace charges VAT on its fees depends on which establishment issues the invoice, and that changes: since 1 August 2024 Amazon invoices selling and FBA fees to German sellers through its German branch with German VAT, where this was previously reverse charged from Luxembourg. So take the treatment from your fee invoice rather than from memory, and check it again whenever the amount moves.
How to do it instead
The workable unit is the order within its payout batch. Per order you know the amount, the country, the VAT treatment and the fees withheld on it. Per payout you know which orders it contains.
- Fetch the settlement report belonging to the payout. It lists every line in the balance, reserve lines included.
- Book revenue per order, with that order's country and treatment. Book each fee type to its own account. Book the reserve as a receivable, not as an expense.
- Book the payout as settlement of the receivable from the marketplace. The difference between the receivable and what arrived in the bank should be zero.
That last step is the actual control. A few cents is a rounding question. Tens of euros almost always means there is a line type in the report you have not seen before: a new levy, a correction, a reimbursement under a code that never appeared until now.
Such an unknown line must never quietly disappear into a suspense account. The moment you write it off to "other costs" your payout reconciles again and you have solved precisely nothing. That deserves its own treatment, because a payout that reconciles and a booking that is correct are two different things.