Three reimbursement scenarios most FBA tools miss

When operators talk about Amazon reimbursements, they usually mean one scenario: lost inventory. A SKU went into a fulfillment center, it never came out, the inventory adjustment report shows the loss, you file a case and Amazon reimburses you. It's the well-known, well-handled scenario, and most FBA tools cover it adequately.

It is also a small fraction of the total reimbursement opportunity. The unglamorous scenarios — the ones that don't make it into the marketing copy of most FBA tools — are usually where the bigger numbers live. This post is about three of them.

Scenario 1: Overcharged dimensions

Amazon measures your SKUs' cube and weight at intake and on a periodic basis afterward. The measured values determine which dim-weight tier the SKU is billed at, and the dim-weight tier feeds directly into fulfillment fees and storage fees. When Amazon's measurement disagrees with your manifest — and it sometimes does, often by enough to push a SKU into the next tier — you end up paying fees calculated on the inflated tier.

This is recoverable. The case category is "billed dimensions don't match seller-provided dimensions." The supporting data you need:

• Your manifest dimensions and weight for the SKU.
• Amazon's measured dimensions and weight (from the _GET_FBA_FULFILLMENT_DIMENSIONS_DATA_ report).
• The fee lines billed at the inflated tier.
• A calculation showing the expected fee at the correct tier.

The detector pattern is mechanical: compare manifest vs measured for every active SKU, daily. When they diverge by more than a configurable tolerance, flag the SKU and recompute fees retroactively. Most FBA tools don't run this detector because the data is annoying to wire up. MarginLock's fee engine ships it as a default detector.

Scenario 2: Miscounted returns

A return arrives at a fulfillment center. Amazon's intake operator scans it, records a count, and processes it back into inventory or marks it as unsellable. Most of the time the count is correct. Sometimes it isn't.

The two common patterns:

• Under-count of returned units. A buyer returns three units; the intake scan records two. The third unit is silently absorbed; you never see it back in inventory and never get reimbursed for the missing unit.
• Over-count of unsellable units. Units returned in good condition are flagged unsellable. You're charged the unsellable-disposition fees and potentially miss the resell opportunity.

Detecting these requires reconciling the return reason report against the inventory adjustment report. A return that's logged as a "return" event but doesn't produce a corresponding inventory increment is a miscount. A return that produces an unsellable disposition for a SKU that's not historically prone to unsellable returns is suspicious.

The reimbursement case category is "return processed incorrectly." The recovery rates on these cases are good — Amazon's documentation is on your side, and the data trail is unambiguous.

Scenario 3: Removal-order miscredits

Removal orders are when you ask Amazon to send some of your inventory back to you, or to dispose of it. Each removal incurs a fee, and units that are returned to you should appear in the removal shipment.

The two ways this scenario goes wrong:

• Removal-order shorts. You requested 100 units back, you got 95. The removal-order detail report shows 95. The five missing units are reimbursable, but you have to detect the discrepancy and file the case. Most operations that don't run this detector simply absorb the loss.
• Damaged-in-removal credits. Units that arrive damaged at your warehouse are reimbursable if the damage occurred during the removal. The case requires photos and dated documentation, but the claims are routinely approved when filed correctly.

Detection here is reconciling the requested removal quantity against the actual returned quantity, per removal order. MarginLock's reimbursement detector does this on every removal report import.

Why these three matter

Tools that catch only the lost-inventory scenario will, in our experience working with operations across a wide range of volumes, recover roughly the top 30% of available reimbursements. The remaining 70% sits in the three scenarios above, plus a handful of smaller categories.

Operations that we've seen layer comprehensive detectors on top of their existing tooling consistently report meaningful incremental recovery — not because the SKUs are different, but because the audits weren't being run.

The detector pattern

Every reimbursement detector follows the same shape:

1. 1

   Pull the relevant report

   Inventory adjustments, return reason, removal-order detail, dimension data — each detector reads from one or two of these.

2. 2

   Reconcile against the source-of-truth

   Manifest vs measured for dimensions; requested vs actual for removals; return events vs inventory deltas for returns.

3. 3

   Emit a case-ready row

   Each discrepancy produces a row with the SKU, the dollar amount, the supporting evidence, and the recommended case category.

4. 4

   Queue for human review

   The operator decides whether to file, batch, or write off. The detection is automated; the filing decision is not.

What's next

If your reimbursement workflow today is "lost inventory only," the lift to add the three scenarios above isn't huge. The reports are available in SP-API, the detection logic is well-defined, and the cases file in the same flow as your existing ones. The biggest blocker is usually engineering bandwidth — which is exactly the gap MarginLock was built to fill.