A customer returns an item and your next Amazon payout drops. The instinct is to book the whole drop as a refund and move on. That is where the books start to drift, because a single Amazon refund is not a single number: it is a returned item price, a returned referral fee, and a separate fee Amazon keeps for processing the refund. Each part belongs in a different place, and two of them are not refunds at all.
Here is what an Amazon refund really contains, where each piece belongs in your chart of accounts, and the timing trap that quietly distorts per-SKU margin.
See the refunds in your own settlement (free, local, no login)In the Settlement Flat File V2, a refund is a group of lines that share a Refund transaction type. The common ones:
| Line | What it means |
|---|---|
Principal (negative) | The item price you are giving back to the buyer. This is the actual sales reversal. |
Commission (positive) | The referral fee from the original sale, returned to you. Amazon gives most of it back. |
RefundCommission (negative) | The fee Amazon keeps for administering the refund. This is a new cost, not a reversal. |
Tax and facilitator lines | Sales tax or VAT reversing along with the item, on both sides where Amazon collects and remits. |
| Returned fulfilment fees | On some return types part of the FBA fee comes back, on others it does not. |
Notice that only the first line is genuinely a refund of revenue. The second is an expense reversal, and the third is a fresh expense.
The mapping rule that keeps this clean is simple to state: a refund or reversal of X belongs in X's own account, with its own sign. Returned referral fees fold back into referral fee expense and reduce it. The refund commission is a referral-family charge, so it folds into the same account and increases it. The returned item price folds back into sales and reduces revenue.
The result is that each account tells the truth on its own: your referral fee expense is the net referral cost of the period, and your sales figure is net of returns. Nothing is scattered into a catch-all bucket where you can no longer tell what it was.
There is a legitimate case for a dedicated contra-revenue Refunds account: when you want to analyse return activity on its own, for example to track a return rate, to watch a problem SKU, or because your accountant reports returns separately. That is an analysis choice, not an accounting requirement.
What you should not do is dump every refund-related line, including the fees, into one Refunds account. That mixes a revenue reversal with an expense reversal and a new expense, and once mixed you cannot recover the parts. If you want returns visible, split only the item price out. Leave the fee lines in their own fee accounts.
A 54.20 item is returned. The settlement shows the item price coming back out, the original 8.13 referral fee returned to you, and a 1.63 refund commission that Amazon keeps. The payout for the period is 47.70 lower than it would otherwise have been.
| Account | Effect | Debit | Credit |
|---|---|---|---|
| Amazon Sales | Revenue reduced by the returned item price | 54.20 | |
| Amazon Referral Fees | 8.13 returned less 1.63 kept, so net expense falls by 6.50 | 6.50 | |
| Amazon Clearing | Cash you will not receive | 47.70 |
Debits of 54.20 equal credits of 54.20, and the clearing account moves by exactly the amount the payout dropped. Revenue is honest, referral expense is honest, and no separate refunds bucket was needed.
A refund that settles this period usually belongs to a sale from an earlier period. For the books, that is fine: the refund belongs in the settlement where it landed, and your period totals still reconcile to the deposit. For per-SKU margin, it is a real problem. A product that sold well last month and got returned this month can look unprofitable this month, and a product that is genuinely failing can hide behind last month's sales.
The practical habit is to keep the refund in the current settlement for accounting, but flag it before drawing conclusions about that SKU. Ask whether the sale being refunded belongs to the period you are analysing. If it does not, the margin number needs a note, not a decision.
Where Amazon acts as marketplace facilitator, the tax it collected and the tax it withheld both reverse, and the pair tends to net out. Where you collect tax yourself, the returned tax reduces the sales tax liability you owe. Either way the tax lines belong in the tax account, never in sales and never in fees.
All of the above is correct whether you sort the lines by hand or not. If you would rather not, that is what SkuSum does. It reads the settlement file locally in your browser, with nothing uploaded and no Amazon login, applies the mapping described here, and outputs a balanced QuickBooks or Xero journal along with a per-SKU profit view. Refund lines are surfaced in a review list precisely because of the period-timing problem above, so a refunded sale from a prior month cannot silently blame the wrong SKU. Every line type it recognizes is documented in the fee types glossary, and anything it does not recognize is flagged instead of guessed.
If the deposit itself is the thing that does not make sense, start with why your Amazon deposit does not match your sales, then come back here for the refund detail.
Run your settlement file now