Understanding Amazon Settlement Reports Line by Line
An Amazon settlement report is a list of every financial event Amazon recorded during one settlement period, ending in the single number it deposited to your bank. It is not a sales report. Most of the lines on it are not sales, and the deposit at the bottom will never match your revenue for the period. Reading it line by line is how you find out where the difference went.
Amazon generates these automatically for Seller Central accounts. In Amazon’s own Selling Partner API documentation the underlying data is published as the settlement report type, available as a flat file or XML, and the structure described there is the same structure you see in the report you download.
The one idea that makes the report readable
Every row is a transaction type, and every transaction type is either money Amazon collected on your behalf, money Amazon charged you, or money moving between periods. Once you sort rows into those three buckets the report stops looking like noise.
The deposit equals collected minus charged, adjusted for whatever crossed the period boundary. Everything below is an explanation of what falls into each bucket.
Column by column
settlement-id. The identifier for the whole period. One deposit, one settlement id. This is the join key between the report and the line on your bank statement, and it is the field your bookkeeper needs most.
settlement-start-date and settlement-end-date. The period boundary. These almost never align with your calendar month, which is the single largest source of month-end pain in Amazon accounting. A settlement running from the 28th to the 11th straddles two accounting periods and has to be split.
deposit-date and total-amount. The deposit and its value. If total-amount is negative, Amazon charged you more than it collected and will recover the difference from the next settlement rather than debiting you.
transaction-type. The most important column. Order, Refund, Transfer, Liquidations, Adjustment, ServiceFee, and others. Group by this field first, always.
order-id and shipment-id. Present on order-level rows, absent on account-level rows. That absence is meaningful rather than a data error; a monthly storage fee has no order attached to it.
amount-type and amount-description. The two-level classification. ItemPrice with a description of Principal is the item’s sale price. ItemFees with a description of Commission is the referral fee. ItemWithheldTax is marketplace facilitator sales tax Amazon collected and will remit. Promotion is a discount you funded. These pair together and you have to read both columns to know what a row is.
quantity-purchased. Populated on sale and refund rows. Useful for tying units back to inventory movement, which the money columns cannot do on their own.
amount. Signed. Positive is toward you, negative is away from you. A refund row shows negative principal because you are handing the money back.
A worked example on a single order
Take one $49.99 unit in a category carrying a 15% referral fee, with $5.99 shipping charged to the buyer and $4.12 of sales tax collected by Amazon under marketplace facilitator rules.
That order does not produce one row. It produces roughly six.
ItemPrice / Principal, positive $49.99. ItemPrice / Shipping, positive $5.99. ItemWithheldTax / MarketplaceFacilitatorTax-Principal, positive $4.12, and a matching ItemWithheldTax negative $4.12 because Amazon collected it and is remitting it, so it never becomes your revenue. ItemFees / Commission, negative $8.40, which is 15% applied to the $55.98 of principal plus shipping rather than to the item price alone. ItemFees / FBAPerUnitFulfillmentFee, negative, at whatever your size tier carries.
Net to you before fulfillment: $47.58 on a $49.99 item. If you booked this as $49.99 of revenue, you overstated sales by nothing and understated fees by $8.40, and your gross margin is wrong by that amount on every unit.
The specific referral percentage matters and it varies by category. Amazon publishes the current schedule on its selling fees page, and the percentages change, so date whatever you write down.
The account-level rows people skip
Order rows are intuitive. The rows without an order id carry storage, subscription and removal fees that never reach SKU-level margin unless you allocate them by hand.
ServiceFee rows carry the Professional selling plan subscription, FBA monthly inventory storage, long-term storage, removal orders, returns processing and labeling services. None of these attach to a SKU in the report, which means allocating them to product-level profitability is your problem, not Amazon’s.
Adjustment rows cover reimbursements for lost or damaged inventory, warehouse damage, and corrections to prior settlements. These are income, they are irregular, and treating them as a reduction of cost of goods rather than as other income will distort your gross margin.
Transfer rows record movement between Amazon accounts or currencies. They are not revenue and not expense. Book them as transfers or your revenue will be double counted.
Retrocharge and chargeback rows appear well after the original order, sometimes in a settlement two months later, which is why matching a settlement to a month is harder than matching it to a period.
Reserves, and why your deposit is short
Amazon holds a reserve balance against pending refunds, chargebacks and A-to-z claims. The reserve is not a fee and it is not lost. It is your money, held.
The practical consequence is that the deposit for a period can be materially below the net earnings the report shows, and the difference reappears in a later settlement. If you forecast cash from your settlement math without modeling reserve movement, your forecast will run consistently optimistic. Track the reserve balance as a receivable, because that is what it is.
How to reconcile one period without losing an afternoon
Four steps, in this order.
One: filter to a single settlement-id and confirm the sum of the amount column equals total-amount. If it does not, you have a truncated download rather than an accounting problem.
Two: pivot by transaction-type, then by amount-type, then by amount-description. You now have a trial balance for the period in about ninety seconds.
Three: post the pivot as a journal entry. Revenue at principal plus shipping, fees at their gross negative, withheld tax netting to zero, storage and service fees to their own expense accounts, adjustments to other income.
Four: match total-amount to the bank deposit. If the settlement crosses a month end, split it by settlement-start-date and settlement-end-date rather than by deposit date, or your revenue lands in the wrong period.
Doing this by hand once is educational. Doing it monthly across multiple marketplaces is where sellers start looking for automation, and where ConnectBooks does the work of turning settlement detail into posted entries in QuickBooks or Xero, either summarized or broken out per SKU.
Two references worth keeping open
Amazon’s public developer documentation for the settlement report types lists the exact report identifiers and formats, which is useful when your download does not look like the one your accountant described.
And IRS Publication 538 on accounting periods and methods explains why the settlement boundary problem is not optional to solve: a taxpayer carrying inventories generally uses an accrual method for purchases and sales, and accrual is exactly where a settlement straddling two months has to be split rather than booked when the cash landed.