Last reviewed: September 2, 2026
The settlement report is the only document that explains, line by line, the money Amazon actually moved to your bank. It is also the report with no public glossary: Amazon's own article about the fields sits behind a Seller Central login, and most of what is written about the format online is documentation for somebody's importer.
This page describes the file itself. Which download to take, what each column holds, how the older layout differs, the one arithmetic check it performs on itself, and what it cannot answer.
In Seller Central, click the Reports menu, then Payments, then the All Statements tab. Pick the settlement period and click Download. Amazon documents that navigation on a public page: https://pay.amazon.com/help/202070210. The Seller Central version of the article, the one that lists the fields, needs a seller account, which is why the format has no authoritative public reference.
Three downloads are offered for a settled statement: XML, Flat File, and Flat File V2. Take Flat File V2. XML holds the same data in a shape no spreadsheet will open, and plain Flat File is the older layout described in section 5. Both are tab separated text.
Pulling statements through the Selling Partner API instead, the report type identifier for the same file is GET_V2_SETTLEMENT_REPORT_DATA_FLAT_FILE_V2.
Flat File V2 gives every amount its own row. An order that sold for one price, paid one referral fee and paid one fulfilment fee is three rows, not one row with three columns. Each row states what kind of amount it is with an amount-type and an amount-description, and the money sits in amount.
| Column | What it holds |
|---|---|
settlement-id | Amazon's identifier for this statement, repeated on every row. The natural journal reference back to the file. |
transaction-type | The event that produced the row: Order, Refund, Transfer. Blank on the summary row. |
order-id | The order the money belongs to. Empty on every account-level line, see section 7. |
sku | Your seller SKU. Also empty on account-level lines. |
quantity-purchased | Units on the order line. Blank on fee rows that are not per unit. |
amount-type | The family the amount belongs to, for example ItemPrice, ItemFees or Promotion. |
amount-description | The line type inside that family, for example Principal or Commission. It decides which account the money belongs in. |
amount | The signed value. Revenue positive, fees and withholdings negative, a reversal opposite to what it reverses. |
posted-date | When Amazon posted the movement. Not the order date, not the deposit date. |
currency | The settlement currency, stated on the summary row and repeated below. |
The file also carries settlement-start-date, settlement-end-date, deposit-date and total-amount, filled in only on the first row.
These two columns look interchangeable and are not. transaction-type describes the event: Order, Refund, Transfer, Chargeback Refund. amount-type and amount-description describe the money: ItemPrice with a description of Principal, ItemFees with Commission.
The trap is a rule that reads Refund off the transaction and reroutes everything on it into a refunds account. A refunded Principal is still product revenue with a negative sign, and moving it out of sales leaves the sales figure gross rather than net. The safe rule reads the amount, not the event: a reversal of X folds back into X's own account with its own sign. Both versions balance, which is why the error is hard to spot. That failure mode has its own page: a balanced entry can still be split wrongly.
The first data row is a summary row. No transaction, no order, no amount type. It carries settlement-id, the start and end dates, the deposit date, the currency, and total-amount, Amazon's own figure for what this statement paid out.
That number is the most useful thing in the report: a check you can run before your books enter the picture. Sum the amount column across every detail row. If the total does not equal total-amount, your reading of the file is wrong, and agreement with your bank statement will not rescue it. Every other check needs a second source. This one is inside the file.
The plain Flat File download uses an older layout that opens with the same first six column names as V2, which is how it gets mistaken for it. V1 does not give each amount its own row. It spreads amounts across one row in type and amount column pairs, so a single order row can carry a price, an item fee, a shipment fee and a promotion at once.
| V1 column pair | Carries |
|---|---|
price-type and price-amount | What the buyer paid: the V2 ItemPrice family. |
item-related-fee-type and item-related-fee-amount | Per item fees: referral, fulfilment and the rest of the ItemFees family. |
shipment-fee-type and shipment-fee-amount | Fees charged per shipment. |
order-fee-type and order-fee-amount | Fees charged per order rather than per item. |
promotion-type and promotion-amount | Seller funded discounts. |
direct-payment-type and direct-payment-amount | Payments taken outside the normal settlement flow, for example cash on delivery. |
other-fee-reason-description and other-fee-amount | Anything with no dedicated pair, with the reason spelled out in words. |
misc-fee-amount and other-amount | Two amount columns with no type column beside them. Their meaning lives in transaction-type, which is how account-level events such as REVERSAL_REIMBURSEMENT and WAREHOUSE_LOST arrive in this layout. |
Now the failure mode. Open a V1 file in a tool that expects V2 and there is no amount column, so the tool picks the most amount-looking column it can see, which is total-amount. There is no amount-description either, so every line falls into one unclassified pile. The result is a journal that balances perfectly, holds a single enormous Other row, and is entirely wrong. Nothing warns anybody, because nothing was violated.
The conversion is simple once the pairs are known: emit one V2 shaped line for every populated amount column, taking the description from the type column beside it, or from transaction-type where there is none. Measured on a real 4,341 row UK export, that produced 3,677 V2 shaped lines: 1,534 price lines, 2,014 item fee lines, 100 promotion lines and 29 account-level lines. They summed to 4,103.32 against the 4,103.32 Amazon stated in total-amount. That tie is the only reason to trust the conversion, and one that does not tie should be refused rather than rounded into agreement.
Revenue. Principal is what the buyer paid for the product, with Shipping and GiftWrap as separate revenue lines beside it. Their chargebacks claw the same money back on FBA orders, set out in the product revenue section of the fee glossary.
Tax. Tax and ShippingTax are collected from the buyer, while the marketplace facilitator lines are tax Amazon withholds and remits for you. The two usually net close to zero, and the UK, EU, Canadian and Indian variants are in the taxes section of the fee glossary.
Selling fees. Commission is the referral fee, Amazon's percentage of each sale, and RefundCommission is what Amazon keeps for processing a refund. Both are referral family charges that net in one account, as explained in the selling fees section of the fee glossary.
Fulfilment. The FBA fee family covers picking, packing and shipping, charged per unit, per order, by weight or by size tier. Every code in the family is listed in the fulfilment section of the fee glossary.
Storage and services. These are recurring charges tied to no single sale: monthly and long term storage, the Professional selling plan subscription, removals and disposals. They are the lines most often blamed on a product that had nothing to do with them, catalogued in the storage and services section of the fee glossary.
Reserves and transfers. Reserve, disbursement and currency conversion lines move money without being income or expense, so they never belong in a profit figure. The labels and their homes are in the reserves and transfers section of the fee glossary.
A large share of a settlement has an empty order-id and an empty sku. Subscription fees, storage, advertising billed inside the settlement, reserves, currency conversion and rounding are account-level events. Amazon did not attribute them to a product because they do not belong to one.
Any tool that spreads those amounts across SKUs, by revenue share or unit count, is inventing a number and presenting it as measurement. Keeping them in their own accounts makes the profit and loss right and leaves per-SKU margin free of amounts nobody can attribute. Reserves are the most commonly mishandled: reserve balances in QuickBooks.
Take a statement whose total-amount is 4,103.32. Group every detail row by what its amount-description means and you get a handful of subtotals: product, shipping and gift wrap revenue positive, tax collected positive with the facilitator withholding negative beside it, referral fees, FBA fees, storage, subscription and promotions negative, reimbursements positive, reserve movements either way.
Add the subtotals and the result is the payout figure, because they are the same rows counted twice. The deposit in your bank is that figure on the deposit date, less anything Amazon holds back. When the bank line and the statement disagree the cause is usually timing or a reserve rather than a missing transaction, and the checks are on the page about why your deposit does not match. For the same subtotals as a double-entry posting, see the journal entry it becomes.
What your goods cost. The settlement knows what a product sold for and what Amazon charged you, and nothing about what you paid your supplier. Any profit built from the settlement alone is a contribution figure before cost of goods, and calling it profit is how a loss-making SKU looks healthy for a year.
Advertising billed to a card. Ad spend appears in the settlement only when Amazon deducts it from your payout balance. When the balance will not cover it Amazon charges the card on file instead, and that spend is invisible here. Reconciling ads from settlements alone understates them.
Which period a sale belongs to. A refund settles in a later statement than the sale it reverses, so a statement can show negative revenue for an item sold two months earlier. One statement will not tie to one month of sales, and the mismatch is not an error.
Everything above is doable by hand. Sort by amount-description, subtotal the groups, check them against total-amount, post the result. Worth doing once, to know what the file contains.
SkuSum is that work automated. It reads the file locally in your browser, with nothing uploaded and no Amazon login, classifies every line into the accounts described above, checks the total against Amazon's own total-amount, converts a V1 file only when the conversion ties, and flags a line type it does not recognise instead of guessing. The classification is validated against 161,344 real settlement lines from US, UK, German and Indian sellers, with every line classified. Run your own file, or read the mapping first in the fee types glossary.