Most Amazon FBA sellers are owed money they never claim. Not because Amazon is hiding it on purpose, but because the discrepancies live across four different reports that never line up on their own, and the claim windows quietly expire.
I build reconciliation tooling on the Amazon Selling Partner API (SP-API). This is the exact logic I use to find recoverable reimbursements — no black box, so you can build it yourself or sanity-check anyone who runs it for you.
The three gaps that actually produce money
Forget the "we'll audit everything" pitch. In practice, three categories produce almost all defensible claims:
- Inventory lost or damaged in the fulfillment center, never reimbursed. An adjustment shows the unit left your sellable inventory (lost/damaged), but there is no matching reimbursement.
- Customer returns refunded but never put back in sellable stock. The customer was refunded; the unit was never returned to inventory (or came back unsellable) — and no reimbursement followed.
- Removal orders lost in transit. You asked Amazon to send units back to you; fewer arrived than left, with no reimbursement for the difference.
Everything else (fees, weights, dimensions) is noisy and often gets auto-corrected. These three are where the signal is.
The reports you reconcile
All read-only, via SP-API Reports:
- GET_FBA_FULFILLMENT_INVENTORY_ADJUSTMENTS_DATA — the lost/damaged events
- GET_FBA_REIMBURSEMENTS_DATA — what Amazon already paid you (critical: this is your dedup source)
- GET_FBA_FULFILLMENT_CUSTOMER_RETURNS_DATA — returns and their disposition
- GET_FBA_FULFILLMENT_REMOVAL_ORDER_DETAIL_DATA — removal quantities requested vs delivered
The logic, in plain terms
For each candidate event, the question is always the same: did a reimbursement already cover this? So the reimbursements report is not an afterthought — it is the join key that prevents you from claiming something Amazon already paid.
Pseudocode for gap #1:
for adj in inventory_adjustments where reason in LOST/DAMAGED:
already = reimbursements.filter(fnsku == adj.fnsku,
date within window of adj.date)
if sum(already.quantity) < adj.quantity:
claimable = adj.quantity - sum(already.quantity)
emit_claim(adj, claimable)
The same shape applies to returns (refunded but not restocked and not reimbursed) and removals (shipped-out minus received, minus anything already credited).
Two details that separate a real audit from a fake one
1. Amazon reimburses at estimated manufacturing cost, not sale price (policy change 31 March 2025). If a tool still values your claims at retail price, the number is fiction. Value each claimable unit by your unit cost. This makes the recoverable total smaller than the old pitches promised — and honest.
2. Claim windows and the auto-reimbursement grace period. Amazon auto-reimburses many cases within a window. File too early and you double-file; file too late and it's expired. So each case needs a "wait" vs "file now" state based on its age and category, not a blind blast of claims.
Why the dedup step matters most
The fastest way to lose a seller's trust (and get claims rejected) is to file for something already reimbursed. That's why the reimbursements report is the backbone: every candidate is checked against what Amazon already credited, by FNSKU and within a date window, before it's ever emitted as claimable.
A note on credibility
When I was reconciling listTransactions behavior for the Finances API, the specific reconciliation approach I described was acknowledged publicly by Amazon's SP-API team on the SDK tracker (issue #5353). I mention it because "trust me" is not an argument — the mechanism above is either correct against your own reports or it isn't, and you can verify it line by line.
If you'd rather not build it
I run this as a read-only audit and show you the recoverable number before anything is filed — and I only charge a percentage of what Amazon actually credits back. If nothing comes back, you pay nothing. The initial audit is free.
If that's useful, my contact is at proficientstack.com. Either way, the logic above is yours — reconcile your four reports and see what's sitting there.
Top comments (0)