The refund happened. Did the unit come back?
Every Amazon return is two separate events: money leaving your account and a unit re-entering inventory. Reconciling the two is where quiet losses hide.
September 22, 2026 · 7 min read
A return feels like one event. It is not. It is at least two, and they are recorded in different places at different times: the buyer is refunded, and — separately, later, sometimes never — a physical unit arrives back at a fulfillment center and gets dispositioned as sellable, unsellable, or nothing at all.
Most sellers only ever look at the first half. The refund shows up in the payments report, the return rate shows up as a percentage, and the assumption is that the unit came back. Often it did. Sometimes it did not, and nothing in the normal reporting flow points at the gap.
The four outcomes behind one return rate
Reconciliation means matching each refunded order to what actually happened to the unit. There are only four endings, and they have very different costs:
- Refunded and restocked as sellable — you lost the fulfillment cost and the returns processing cost, and you got the unit back. This is the cheap case.
- Refunded and restocked as unsellable — the unit exists but cannot be sold. It is now sitting in the network accruing storage until you remove or dispose of it. Cost of goods is gone.
- Refunded and never returned — the buyer kept the item, or it was lost in transit back. You paid out the money and hold no unit.
- Returned but not refunded, or refunded twice — rarer, and it can run in your favor as well as against you. Either way it means your books do not match Amazon’s.
Why a return rate tells you nothing useful
A 6% return rate is not a diagnosis. Two SKUs with the same rate can behave completely differently: one returns because buyers ordered the wrong size and the units come back clean and resellable; the other returns because the product arrives damaged, and every unit comes back unsellable with the cost of goods written off.
The rate is identical. The economics are not close. The only way to tell them apart is to split returns by reason and by disposition, per SKU, and look at what share of returned units ever becomes sellable again.
A reconciliation you can run by hand
You do not need software to start. Pick your top ten SKUs by unit volume and, for a single recent month, line up three things per SKU: units refunded, units received back, and units restocked as sellable. Then compute two ratios.
- Return receipt rate — units received back divided by units refunded. A persistent shortfall here is money out with no unit in, and it is the category worth investigating first.
- Resale recovery rate — units restocked sellable divided by units received back. A low number points at product, packaging, or grading, not at logistics.
- True cost per return — refund amount plus fulfillment cost plus returns processing, minus the value of the unit you actually recovered. Do it per SKU; the average across the catalog is useless.
- Reason-code mix — group the reasons into buyer-caused (changed mind, wrong size ordered), listing-caused (not as described, wrong item), and product-caused (defective, damaged). Only the last two are yours to fix.
What each pattern tells you to do
Reconciliation is only worth the effort if the output is an action. In practice the patterns map fairly cleanly onto fixes.
- High listing-caused returns: the detail page is over-promising or the variation data is wrong. Fix images, dimensions, sizing guidance, and the variation matrix before touching anything else — this is the cheapest return to eliminate because it never should have been a sale.
- High product-caused returns: usually packaging, not manufacturing. Units that arrive damaged came through the same journey as the ones that did not; the difference is protection. Test a sturdier pack on one SKU and compare.
- Low resale recovery: check how units are being graded and whether your packaging survives a round trip. Retail-ready packaging that tears on opening turns a resellable unit into a write-off.
- Low return receipt rate: this is the one that belongs in a claims workflow. Where a refund was issued and no unit was received back, that discrepancy is exactly the kind of thing Amazon has a reimbursement process for — but it is on you to identify the case and open it, and the eligibility window does not stay open forever.
Do it on a schedule, and do it soon after the fact
The reason reconciliation gets skipped is that it feels like accounting archaeology. It gets much easier if you do it monthly on a fixed date, because the population is small, the reports are still fresh, and anything eligible for a reimbursement claim is still comfortably inside its window rather than close to the edge.
The other reason to keep it recent: returns data is the earliest honest feedback you get on a listing change. If you edited images or copy six weeks ago, the return reason mix for the orders placed after that edit tells you whether the change helped, long before the review pipeline does.
Keep a one-line note per SKU: what the pattern was, what you changed, what month you changed it. Next cycle you are comparing against a written baseline instead of a memory.
Where MySellerHQ fits
MySellerHQ reads orders, returns, fees, and inventory from Amazon’s Selling Partner API with read-only permissions, and lines refunds up against units received and restocked so the gaps — refunded-but-never-returned, returned-but-unsellable — surface per SKU instead of hiding inside a return rate. It also flags the discrepancies that look like reimbursement candidates so you can review them while they are still actionable.
It does not file claims for you, edit listings, or change prices — writes are off by design. The judgement stays with you; the matching does not have to.