How do you reconcile an Amazon payout that includes last month’s reserve?
Under accrual accounting, match the payout to the unpaid transactions already recorded at month-end. Debit bank and credit the existing reserve, debtor or clearing balance for the amounts settled. Separate any new-period activity and carry forward only the supported unpaid remainder. Receiving last month’s reserve does not make it this month’s sales.[1]
What went wrong with the monthly reserve calculation?
The previous process used “sales − fees − settlements = reserve”, then repeated the calculation each month. When subsequent payouts included earlier reserved amounts, those amounts were not cleared against the existing reserve balance.
That arithmetic can be a useful control. For a single month, it may describe a movement in the amount owed, not the closing balance. You still need the opening balance, refunds and other adjustments, and evidence of what later payments settled. Repeating an accrual without clearing the paid items leaves old amounts sitting on the balance sheet.
For a growing seller, that means the bank can reconcile while the amount supposedly still owed by the marketplace becomes unreliable.
What should be accrued at month-end?
The true month-end reserve must be recognised as an asset to the extent it represents earned, recoverable money still owed. Start with the transactions earned by the reporting date, after fees, refunds and other supported adjustments. Reconcile the amount to the platform records and the ledger. In this Amazon UK example, the August balances before the September receipt were:
| Already recorded in the accounts | Amount |
|---|---|
| Outstanding August invoice | £3,674.56 |
| Marketplace reserve asset | £23,349.02 |
| Total still due from the marketplace | £27,023.58 |
“Accrue the reserve” means get the true balance into the accounts once. These amounts were already recorded, so they needed no second income accrual. If transactions are missing, recognise the supported sales, fees, refunds and applicable tax correctly. If an amount already sits in debtors or clearing, reclassify it if necessary; do not add it again.
Here, “book reserve” means the receivable account used for unpaid marketplace balances. The book reserve is not automatically the same as the platform’s deferred balance. In this case, £10,332.99 was marked deferred; other unpaid August amounts were allocated to upcoming payouts. Together, those groups explained the £27,023.58 total.
How much of the next payout releases the reserve?
The bank received £15,014.58 on 4 September. Matching the native settlement report to the August transactions separated the receipt into three parts:
| What the payment settles | Amount |
|---|---|
| Existing August invoice | £3,674.56 |
| Existing reserve released | £11,334.71 |
| September reimbursement, net of reversals | £5.31 |
| Debit to bank | £15,014.58 |
Existing debtor + existing reserve released + new-period adjustment = bank receipt
The receipt debits bank £15,014.58, credits the existing debtor £3,674.56, credits the reserve £11,334.71 and credits the established fee/reimbursement account £5.31. The first two credits settle assets already recorded. They do not create September sales.
The £5.31 was an evidenced inventory reimbursement net of reversals, not a rounding plug. It also had to be marked as already posted before the September report was booked, to avoid recognising it twice.
This was supported by 5,041 settlement component rows. All 1,027 order/refund groups matched by transaction type, order reference and SKU between the August transaction report and the settlement file. The bank total agreed exactly. A checked summary kept the posting simple; the transaction detail made it defensible.
What reserve remains after that payment?
Existing August reserve − amount settled = August reserve still outstanding
The remaining £12,014.31 equalled £1,681.32 allocated to a following payout plus £10,332.99 deferred. The August invoice was fully paid. These figures describe the August balances after that receipt, not today’s total marketplace wallet.
If the next payout instead settled the entire opening reserve, that old balance would reduce to £0. New-month holds could still create a separate balance. For the total account, reconcile opening reserve + new amounts due − releases ± supported adjustments = closing reserve.
How do you stop the same error next month?
- Prove the closing balance. Keep a schedule of unpaid transactions or identifiable groups, their accounting periods, expected payouts and existing ledger entries. Amazon’s V2 report supplies order references and posting dates.[2] Check the recognition basis and reporting timezone; a posting date alone is not enough.
- Allocate each later receipt. Separate old debtors, reserve releases and new-period activity. Use the actual bank date. Clear each settled amount once and retain the explanation for anything still unpaid.
- Check the next close. Reconcile opening balance, movements and closing balance. A controlled reversal and replacement accrual can also work, but do not reverse an amount and then clear it a second time.
The same discipline applies when the payment crosses a quarter-end or financial year-end. The receipt date does not move already recognised income into a new reporting period. This is an accrual-accounting example; cash-basis tax timing differs,[3] and VAT needs its own treatment.
Put the reserve roll-forward on your month-end checklist. The useful answer is straightforward: how much was owed, how much arrived, and exactly what is still outstanding.