Fee detection: the audit Amazon doesn't do for you

Amazon does not audit its own fee charges for you. The fee schedules are published, the rules are knowable, and the data is in the settlement reports you already have access to — but reconciling actual charges against expected charges is operator work, and most operations don't do it. This guide is the working playbook: the five fee dimensions Amazon charges, how to detect overcharges in each, and the failure modes that let fees slip past unnoticed.

The five fee dimensions

Every cent Amazon charges you on the FBA program falls into one of five categories. Memorize these. Every detector below is scoped to exactly one of them.

1. Referral fees — a percentage of sale price, charged on every order. The percentage depends on the SKU's category and whether it's above or below a per-category threshold price.
2. Fulfillment fees — flat per-unit charges for picking, packing, and shipping. Tiered by size and weight.
3. Storage fees — monthly charges by cube, with a higher long-term rate that kicks in after 271 days for most marketplaces.
4. Returns and removal fees — fees for return processing, removal orders, and disposal.
5. Inbound and prep fees — fees for receiving, labeling, polybag, and bubble-wrap services Amazon performs on your behalf.

A "fee" line in a settlement is always exactly one of these. The audit question is whether the amount Amazon charged matches the amount the schedule implies.

Detecting overcharges

Referral fees

The detector logic is straightforward but the failure modes are sneaky.

1. 1

   Pull the SKU's category at sale time

   Not the current category — the category as of the order date. Amazon sometimes recategorizes a SKU after the fact, and you want to bill against the historical state.

2. 2

   Look up the per-category rate and threshold

   Each category has a percentage and (usually) a threshold price below which a different rate applies.

3. 3

   Compute expected fee, compare to actual

   If the actual fee differs from expected by more than a fraction of a cent per order line, raise a FeeAdjustment row.

The most common reason referral-fee detection misses is using the SKU's current category instead of its as-of category. MarginLock's fee engine pins category at order time and tracks recategorizations as their own event, so the audit always uses the right reference.

Fulfillment fees

Fulfillment-fee detection requires knowing the SKU's dim-weight tier, which depends on the SKU's measured cube and weight at the warehouse — not the manifest. Amazon will sometimes measure a different number than your manifest declared. When that happens, the dim-weight tier shifts, and the fulfillment fee shifts with it.

Detect this by storing two cube/weight numbers per SKU: the manifest value and the most-recent Amazon-measured value. If they diverge, the fulfillment fee should reflect the divergence. If your settlements are billing against an inflated dim-weight that disagrees with your manifest, that's the discrepancy.

Storage fees

The two storage-fee discrepancies worth catching:

• Long-term storage charged on inventory under threshold. Amazon's long-term rate kicks in at the 271-day mark. If a SKU's oldest unit at the charge date was under that threshold, the long-term rate shouldn't apply.
• Cube measurement drift. Same pattern as fulfillment fees — if Amazon's cube measurement disagrees with your manifest, your storage bill is being computed on the wrong number.

Returns and removals

The big one here is duplicate return processing. A return gets processed, then for whatever reason gets reprocessed (system bug, buyer reships, Amazon intake error). You see two return-processing fees for one physical return. The detector pattern: count return-processing fees per order-id. Any count

1 is suspicious.

Inbound and prep

Detection here is mostly about checking that the prep services billed for match the prep services your shipment plan declared. If you declared "no prep" and Amazon's bill shows polybag, somebody at intake decided your SKU needed polybagging. That's a dispute case.

Why fees go uncaught

In our experience, when fees slip past it's almost always because of one of these patterns:

How MarginLock automates the audit

Every fee dimension above ships as a detector in MarginLock's fee engine. After every settlement, every detector runs against every line. Discrepancies produce FeeAdjustment rows that show up in the review queue with a recommended action and a link to the underlying settlement line.

You still make the call on whether to dispute, batch, or write off — the detection layer just makes sure nothing slips by silently.