Technical guide · Accounting

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.

The model

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.

Flow 1 — sales revenue
The sale is made to the end consumer, on the date of delivery. It carries revenue and, depending on the applicable regime, output VAT. It is independent of when Amazon will transfer anything. A credit note follows the same logic, on its own date.
Flow 2 — intermediation costs
Referral commissions, FBA fulfilment and prep fees, storage, long-term storage, advertising, the professional subscription, environmental levies, inventory removals: these are services purchased from Amazon, with their own VAT regime, to be booked as costs at their gross amount.
Flow 3 — the cash movement
The payout settles the balance between those two flows, increased or reduced by reserve movements, reimbursements and adjustments. It creates neither revenue nor cost: it extinguishes a receivable and settles liabilities. It is a treasury entry, nothing more.

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.

The source data

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 typeContentsAttachment
ShipmentAmounts charged to the customer (price, shipping, gift wrap, taxes) and the associated fees (commission, FBA, digital services tax, variable closing fee)Order number
RefundAdjustments to customer amounts and to fees, including the partial commission returnedOrder number, often from an earlier period
Service feeAccount-level or order-level fees: environmental levies, assorted logistics chargesVaries, sometimes none
AdjustmentReserve movements, withholdings, corrections, repaymentsNone
AdvertisingCharges for sponsored campaignsNone
Safe-T reimbursementAmazon covering a customer refund granted outside the return policyClaim 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.

Allocation follows the event date
Whether an event belongs to a group depends on its posting date at Amazon, never on the order date. A late-period order, a delayed shipment or a late refund mechanically roll into the next group. Any attempt to rebuild a payout as “the fortnight’s sales minus commissions” fails for that reason alone.
Some amounts are returned twice
Several events restate the same amount at two levels of detail: a total at the top, then a breakdown that repeats that total. Adding both doubles the amount. This is the first cause of a reconciliation that “almost” balances, with a gap matching one fee category exactly.
Rounding happens at line level
Amounts are rounded to the cent at line level, and taxes are computed per line. Invoicing software that computes VAT at document level will therefore produce a few cents of difference per order — negligible individually, structural across several thousand lines.

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 entries

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.61

The 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

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.

1. Which VAT on the sale?
Depending on the dispatch country, the customer’s country and where you are established, the sale falls under the domestic regime, the one-stop shop for intra-EU distance sales, or a local regime if you hold stock in another member state. Pan-European programmes physically move your stock and trigger local registration obligations — with no payout line signalling it, since a stock transfer is not a financial flow.
2. Is Amazon the deemed supplier?
For low-value imports and for sellers not established in the EU, the platform is deemed to buy and resell: it collects and remits the VAT due by the consumer. Your transaction then changes nature. The information exists only at order level, which rules out any aggregated treatment at payout level.
3. Which VAT on Amazon fees?
Long invoiced by a Luxembourg entity under the intra-EU reverse charge, European sellers’ fees are now, for many, invoiced by a local Amazon establishment and carry deductible domestic VAT. Both treatments coexist across accounts, countries and periods. The only reliable source is the fee invoice itself: issuing entity, VAT number, reverse-charge wording.

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.

Controls

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. 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. 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. 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. 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. 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.

Year end

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.

Tooling

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

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 version

This 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.