Amazon settlement report does not match orders

What it is

You add up the order totals in the All Orders report for a two-week period, look at the settlement deposit for the same two weeks, and the two numbers are not close. The deposit is smaller, sometimes by more than the fees you expected, and a handful of orders you know shipped are not in the settlement at all. The report is not wrong. It is answering a different question from the one you asked: not what was sold, but what Amazon moved on the account, line by line, between the settlement-start-date and the settlement-end-date.

A settlement report has one row per money movement, not one row per order. An ordinary FBA order produces four to eight rows: Principal, Shipping, Tax, one or more Commission lines, an FBA per-unit fulfillment fee, sometimes a Promotion, sometimes a MarketplaceFacilitatorTax line. Rows carry transaction-type (Order, Refund, other-transaction, ServiceFee, Adjustment), amount-type (ItemPrice, ItemFees, Promotion, ItemWithheldTax), amount-description (the specific line), order-id, sku, quantity-purchased and posted-date. Matching this to orders means folding those rows back into one net figure per order-id and comparing it to what you think the order was worth.

How it happens

Timing by ship date, not order date. Amazon posts order money when the item ships, on posted-date. An order placed on the last day of the period and shipped two days later belongs to the next settlement. So the order report filtered by purchase date and the settlement filtered by settlement period never describe the same set of orders. Orders that are missing from the settlement are usually just late, not lost, and orders from the previous period show up unexpectedly.

Facilitator tax nets to zero. Where Amazon collects and remits sales tax, the settlement shows Tax as a positive ItemPrice line and MarketplaceFacilitatorTax as a matching negative line. If your order export counts tax in the order total, every order is overstated by the tax amount before any fee is considered. Compare pre-tax revenue, or subtract the withheld tax explicitly.

Fees are many lines with unfamiliar names. Commission is the referral fee. FBAPerUnitFulfillmentFee is the pick, pack and ship charge. ShippingChargeback and Shipping HB move seller-funded shipping. VariableClosingFee applies to media categories. RefundCommission is the part of the referral fee Amazon keeps when it refunds a buyer. Account-level charges such as monthly storage, long-term storage, the professional subscription, advertising and inventory reimbursements arrive as other-transaction or ServiceFee rows with no order-id and are easy to blame on orders they have nothing to do with.

Promotions and reserves. Seller-funded promotions post as negative Promotion lines against the order, so a coupon or Lightning Deal reduces the settled principal without touching the order report's item price. Reserves appear as Previous Reserve Amount Balance and Current Reserve Amount rows; the difference between them changes the deposit without corresponding to any order. Refunds in the period reverse Principal and Tax and return part of the Commission, so a settlement with heavy returns can settle less than the orders shipped in it even after fees.

Why it matters

The unexplained part of the difference is your exposure, and nothing else is. Per order: expected_net = principal + shipping_credit + gift_wrap − seller_promotions − referral_fee − fba_fees − other_per_order_fees. Then settled_net = sum(amount) over all settlement rows with that order-id and transaction-type Order. The gap, expected_net − settled_net, should be zero for every order once the fee schedule is applied correctly. A non-zero gap is either a mis-applied fee, a fee charged twice, a weight or size tier you disagree with, or a promotion you did not fund.

At account level: deposit = sum(Order rows) + sum(Refund rows) + sum(other-transaction rows) + sum(ServiceFee rows) + sum(Adjustment rows) + reserve_change. Most of the headline difference between orders and deposit lives in the refund, service-fee and reserve terms, none of which is a leak. The per-order gaps are where money actually goes missing, and they are small individually, which is why they are rarely chased by hand.

How to diagnose

1. Download the settlement report as a flat file (Payments, Reports repository, Settlement, Flat File V2). Note settlement-start-date, settlement-end-date and total-amount from the first row. 2. Pivot the rows by order-id and amount-description so each order becomes one line with a column per fee type. Rows with a blank order-id go to a separate account-level table.

3. Pull All Orders for a window that starts several days before settlement-start-date and ends at settlement-end-date, and keep only orders whose ship date falls inside the period. This is the set that should be in the settlement. 4. Join on amazon-order-id. Orders present in the order set but absent from the settlement, with a ship date inside the period, are the ones to raise with Seller Support; orders absent because they shipped after the period end are expected.

5. For each joined order compute expected_net with your fee schedule (referral percentage by category, FBA fee by size tier and weight) and compare it to settled_net. Sort by the gap. 6. Read the account-level table separately: storage, subscription, advertising, reimbursements and reserve movements explain the rest of the deposit. If total-amount still does not equal the sum of every row, the report is truncated; re-download it.

7. Check refunds against the RefundCommission line: Amazon keeps a fixed share of the original referral fee, capped, on each refund. A refund whose commission reversal is smaller than that rule allows is a fee overcharge worth a case.

How AXIOTRA detects it

AXIOTRA works from your imported ledger, so the settlement rows must become CSV first: each fee line as one row in the fees file (fee_id, source amazon, kind such as referral or fba, amount as a positive number, order_id, charged_at from posted-date), and each order's buyer-paid amount as one row in the payments file. The mapping guide linked below shows the column renames.

The duplicate_fee detector groups fees by source, order_id, kind and amount and raises a finding whenever two or more rows with distinct fee ids share that key and no reversal exists. That is the settlement pattern where a financial event is retried and both copies post; it is classed as verified loss because the cash left twice. The order_payment_mismatch detector compares the payments row to the order total for the same order id, and reports any Amazon order that has no payment row at all, which is how a shipped order missing from the settlement becomes a finding with the order total as potential exposure.

The true_margin_anomaly detector uses the referral fee row you imported, plus the cost record for the SKU, to compute contribution per unit and raises a likely-loss finding when the SKU sells at a negative contribution on Amazon. Per-order fee-schedule verification (checking that the FBA fee matches the size tier) is not something AXIOTRA does today; step 5 above remains a spreadsheet job.