Reconciling Amazon payouts with your accounts
An Amazon payout is neither revenue nor a customer settlement: it is the net balance of a batch of heterogeneous financial events, over a period that lines up with nothing else. This guide covers the real data structure, the journal entries, VAT treatment and the checks to run on every payout.
Three flows, three calendars, one transfer
Almost every difficulty on Amazon comes from one initial confusion: treating the payout as a customer settlement. It is not one. Amazon is not your customer, and the transfer is not the payment of an invoice.
The correct model separates three flows that follow three different calendars and have no reason to meet in a single entry.
The control account is the checkpoint
As long as those three flows run through a dedicated control account, the accounts stay verifiable: the balance must always be explainable. As soon as they are merged into a sales entry for the amount of the transfer, no check is possible at all.
What a payout group actually contains
Understanding why a payout resists reconstruction means knowing how Amazon structures its financial data. The payout does not exist as a standalone object: it is a group of financial events, identified by its own reference, closed on a date, and tied to a fund transfer dated separately.
Inside that group the events are heterogeneous. Each type has its own structure, its own nested amount lists, and its own way of attaching — or not attaching — the amount to an order.
| Event type | Contents | Attachment |
|---|---|---|
| Shipment | Amounts charged to the customer (price, shipping, gift wrap, taxes) and the associated fees (commission, FBA, digital services tax, variable closing fee) | Order number |
| Refund | Adjustments to customer amounts and to fees, including the partial commission returned | Order number, often from an earlier period |
| Service fee | Account-level or order-level fees: environmental levies, assorted logistics charges | Varies, sometimes none |
| Adjustment | Reserve movements, withholdings, corrections, repayments | None |
| Advertising | Charges for sponsored campaigns | None |
| Safe-T reimbursement | Amazon covering a customer refund granted outside the return policy | Claim number |
This list is not exhaustive: groups also contain chargebacks, payment disputes, promotional rebates, gift card movements and fees tied to optional programmes.
Three properties of that structure explain most of the discrepancies seen in practice.
The source data has a shelf life
Tabular settlement reports stay downloadable only for a limited window. A reconciliation started at year end therefore hits periods whose detailed source is no longer available. The detail has to be collected continuously, not reconstructed after the fact.
The journal entries
The scheme below is the one most commonly used by firms handling Amazon volume. It routes every flow through a dedicated control account — here a sub-account of French class 411 — and records the transfer only as a cash movement.
Journal entries — French plan comptable général
1) Sale — at the delivery date, one entry per order or per daily batch
411AMZ Amazon – control account 120.00
707 Sales of goods 100.00
44571 Output VAT 20.00
2) Credit note — at the refund date, never as a negative on the original sale
707 Sales of goods 30.00
44571 Output VAT 6.00
411AMZ Amazon – control account 36.00
3) Payout fees — by nature, at their gross amount
6222 Commissions on sales 6,764.80
6241 Outbound freight (FBA) 4,512.00
6135 Rental charges (storage) 380.45
6231 Advertising 2,145.60
6281 Subscriptions (selling plan) 39.00
4456x Input / reverse-charge VAT per regime
411AMZ Amazon – control account 13,841.85
4) Payout — the transfer received, to the cent
512 Bank 29,782.61
411AMZ Amazon – control account 29,782.61The reserve deliberately appears in none of these four entries: it is neither revenue, nor a cost, nor a movement of the company’s cash. It is simply the portion of the receivable Amazon has not yet settled, and therefore stays in the control account balance until it is released.
The account numbers are debatable and will be debated: some firms prefer a class 467 account to a 411 sub-account, post FBA to 6224 rather than 6241, or isolate all Amazon fees in a single 622 subdivision. What matters is not the number — it is that the four entries stay separate and that the control account carries the timing difference.
The zero or negative payout
A payout can be zero, or negative when the period’s fees exceed its sales. Amazon then deducts nothing: the balance carries forward to the next group. Entry 4 does not exist, but entries 1 to 3 are still due — which is exactly the case where accounts based on bank movements alone lose a whole period.
VAT treatment
Three separate questions, none of which a payout line can answer.
VAT is where approximation costs the most, because the error is both lasting and sanctionable. Three questions have to be settled separately.
These three questions share one practical consequence: VAT can never be derived from the payout. It is built from the orders, with their destination country, regime and rate — and from the fee invoices, with their own regime. A payout that aggregates all of that into a net balance is, for VAT purposes, unusable data.
Five controls to run on every payout
A reliable Amazon reconciliation is not judged by the absence of a visible discrepancy, but by the existence of controls that fire when something is missing. Five controls cover most of the anomalies encountered.
- 1
Control 1 — payout integrity
For each group: the sum of gross amounts less the sum of fees must equal the amount transferred exactly. A discrepancy, even of one cent, signals incomplete pagination, an unhandled event type or an amount counted twice. It is the most discriminating check, and it should block ingestion rather than raise a warning.
- 2
Control 2 — line attachment
Every sale or refund line must point to an order your system knows. Unmatched lines are not inevitable: they reveal orders never imported, orders cancelled then re-invoiced, or different marketplace identifiers. They must be counted and displayed, not absorbed.
- 3
Control 3 — control account justification
At any date, the control account balance must equal sales shipped but not yet paid out, plus the reserve withheld, less accrued fees not yet deducted. This is the only control that detects an entire missing period — typically a payout never ingested because its transfer was not identified in the bank.
- 4
Control 4 — consistency with fee invoices
Amazon’s fee invoices must reconcile, by nature and over a widened period, with the total fees deducted in the payouts. Strict month-on-month equality does not exist: the expected difference corresponds to period-edge orders, and must itself be explained.
- 5
Control 5 — bank reconciliation
The amount transferred must appear as a credit on the bank account, at value date, possibly reduced by currency conversion fees. A persistent gap between the announced and received amounts is a currency or withholding matter, and should be tracked in a separate account rather than buried in the control account.
Cut-off, reserve and year end
Payouts straddling two financial years are where the year’s approximations become visible. Four points deserve explicit treatment before the accounts close.
- Orders shipped before the reporting date and paid out after must be invoiced in the year of delivery and sit in the control account balance — not be attached to the year of the transfer
- Commissions and fees relating to those orders, deducted on the next payout, are accrued liabilities of the closing year
- The reserve withheld at the reporting date is a receivable: it stays on the balance sheet and is neither provisioned by default nor offset against future fees
- Refunds granted after the reporting date on sales of the closing year follow the usual rules for returns: they are not treated as a simple movement of the payout they appear in
- Payouts in foreign currency must be translated at the transaction rate, with the difference against the amount actually credited recognised as an exchange result
The detail drives the cut-off
A payout straddling the reporting date cannot simply be cut in half: you need its event-level detail to allocate each line to the right year. That is the most concrete reason why line-by-line reconciliation is not a luxury but a condition for clean year-end accounts.
Automating collection and controls
None of the above is conceptually hard. The difficulty is volume: a payout group can hold several thousand events, there are two a month per marketplace, and the detailed source stops being available after a while. This is continuous collection and control work, not a month-end task.
That is what Order Invoicer does. The platform connects to the seller account, collects each payout group with its full event-level detail, and returns it in a form directly usable in the accounts.
- Every order becomes an invoice and every refund a credit note, at their own date and amount, in your invoicing or accounting software
- Payout lines are matched to the corresponding orders and refunds; those that are not are counted and surfaced for review, with the option to explicitly exclude them from scope
- Fees are broken out by category — commission, logistics, advertising, adjustment, reserve — instead of being aggregated into a net balance
- The gross-less-fees-equals-net integrity check runs automatically on every payout: one that does not balance is flagged and held for review, never ingested silently
- The batch settlement matching the payout is pushed into the accounting tool, so the bank line clears in one operation against all the invoices and credit notes concerned
- The collected detail stays available after Amazon’s own reports expire, which makes a review possible months after the fact
The firm keeps control of the chart of accounts, the cost allocation and the VAT treatment. What changes is that the raw material arrives complete, dated, attached and checked — and that a payout which does not justify itself is visible when it lands, not at year end.
Frequently asked questions
Need a version to hand to the business?
If you need to explain this to a founder, a partner or a client, the short version covers the same mechanics without a chart of accounts or API vocabulary, with one payout broken down line by line.
Read the non-technical versionThis guide is editorial and reflects the practices we see among the merchants and accounting firms we work with. The account numbers shown follow the French plan comptable général and are defensible defaults, not a prescription: the allocation is a matter for the company’s chart of accounts and its accountant. VAT treatment depends on where you are established, your registrations and which Amazon entity invoices you — verify it on your own fee invoices.
Amazon payouts your accounts can actually use
Order Invoicer collects every Amazon payout with its event-level detail, matches lines to orders and refunds, isolates fees by category and feeds Pennylane, Sellsy or your invoicing software. Your entries stay yours: what changes is that the raw material arrives clean.