Amazon settlement report V2: all 24 fields
Amazon publishes the field names and never publishes what the three columns carrying every charge can contain. Here is each field, what it is for, and the India lines no report splits for you.
The V2 settlement report has 24 fields. Amazon lists all of them publicly, then condenses every charge into three columns, amount-type, amount-description and amount, and never publishes the values those columns can hold. The old V1 reports are removed on 11 November 2026 with no mapping published, so anything reading them needs testing now.
- Twenty-four fields, listed on a public Amazon developer page that needs no Seller Central login.
- amount-description is the one that matters: it is where a referral fee, a closing fee and a reserve movement are told apart, and Amazon publishes no list of its values.
- V1 settlement reports are removed on 11 November 2026, deprecated since 17 March 2025, with no published field mapping to V2.
- Sales that look missing are usually in the next settlement, because a payout covers a window and funds release on their own schedule.
- Nothing in the file splits GST per fee line, which is the allocation an Indian seller has to do and a US tool never will.
Amazon tells you what the columns are called. It does not tell you what two of them can say, and those two are the ones that decide whether a payout was correct. That gap is why most reconciliation advice for Indian sellers stops at "download the report".
The one design decision that explains the whole file
Older settlement reports had a column per charge. V2 does not. Amazon's own documentation says the price columns are condensed into three general-purpose columns, amount-type, amount-description and amount, and that the first two hold the type of charge or fee incurred.
That is the right design for a format that has to survive new fees, and it moves all the meaning into free text. One row is no longer "referral fee: 101.50". It is three cells that have to be read together. Sum the amount column on its own and you will get a number that looks plausible and answers nothing, because you have added an item price to a fee to a tax line to a reserve movement.
And Amazon stops there. It names the columns and never enumerates the values. The practical consequence shows up on Amazon's own forums, where a seller listed the real amount-description values from his own file, could not find out what they meant, and said plainly that he had got his explanation out of a chatbot and did not know how accurate it was. That is not a careless seller. That is the only route left when the publisher of a format declines to document its contents.
amount-description values you find elsewhere was built the same way yours should be: by reading real files. The difference is that yours will match your categories, your fulfilment mix and your marketplace. Pull the distinct values across twelve months of settlements, map each one once, and treat a value you have never seen before as something to investigate rather than to bucket into "other".All 24 fields, grouped by the question they answer
The order below is Amazon's own. The grouping is ours, because reading the list flat hides that only three of the twenty-four carry money and the rest exist to tell you what that money was for.
The settlement itself
settlement-id- The identifier for the whole payout. Every row in one file shares it, and it is the key you reconcile a bank credit against.
settlement-start-date- Start of the period. Populated only on the first row of the file, which is why a spreadsheet filter can make it look missing.
settlement-end-date- End of the period. The boundary that decides which orders land in this payout and which wait for the next one.
deposit-date- When Amazon initiated the transfer. Not when it reached your bank, so a gap here is normal banking time, not a short payment.
total-amount- The net figure for the settlement. This is the number that should match your bank credit, and the only one that should.
currency- INR for an amazon.in settlement. Worth asserting in your reconciliation, because a global tool defaulting to USD is a silent error.
What kind of row this is
transaction-type- Separates an order row from an adjustment, a fee or a non-order event. Amazon does not publish the full value list, so read the distinct values in your own file rather than coding against a list from a blog.
What the row points at
order-id- Amazon's order identifier. Blank on rows that belong to no order, which is most of the fee and adjustment lines.
merchant-order-id- Your own order reference, if you set one. The join key if your books are keyed on your numbering rather than Amazon's.
adjustment-id- Present on adjustment rows. The handle to quote when you dispute one, and the field most reconciliation spreadsheets drop.
shipment-id- The shipment the row belongs to. One order can produce several, so a per-order sum that ignores this double counts nothing but confuses everything.
marketplace-name- Which Amazon store the row came from. Matters the moment you sell on more than one.
The three columns that carry the money
amount-type- The broad class of the amount: the item price, a fee, a promotion, a tax line. Amazon states this column holds the type and does not publish the set of types.
amount-description- The specific charge inside that class, and the single most important column in the file. This is where a referral fee, a closing fee, a weight handling fee and a reserve movement are told apart. Amazon publishes no list of the values it can hold.
amount- The signed figure. Negative is money leaving you. Summing this column without reading the two beside it is the commonest reconciliation mistake there is.
How it was fulfilled
fulfillment-id- Which fulfilment path produced the row, which is what makes an FBA line separable from an Easy Ship or self-ship line.
When it happened
posted-date- The date the transaction posted, as a date. This is the field to bucket by when you compare a month against your own books.
posted-date-time- The same event with a time. Convert to IST before you report on it, or an evening transaction drifts into the previous day.
Down to the item
order-item-code- Amazon's identifier for the line item, not the order. The level at which fees are actually charged.
merchant-order-item-id- Your own line-item reference, if you set one.
merchant-adjustment-item-id- Your reference on an adjustment line item. Almost always empty, and useful precisely because you can populate it.
sku- Your seller SKU. The join to your own cost data, and therefore to whether the order made money.
quantity-purchased- Units on the line. A per-unit fee reconciles against this, not against the order count.
promotion-id- The promotion that produced a discount row, so a coupon-funded discount can be separated from a price change you made.
The deadline nobody has written about
Amazon's public SP-API deprecations page lists GET_V2_SETTLEMENT_REPORT_DATA_FLAT_FILE and its XML sibling as deprecated on 17 March 2025, with a removal date of 11 November 2026. After that they stop being produced.
The part that costs time is what Amazon has not published: there is no field-by-field mapping from the old reports to the new one. If a spreadsheet, a script, an accountant's template or a tool you pay for reads the old format, the work of discovering what moved is yours, and it is much cheaper done against two files side by side now than against a missing file in November.
The honest test is small. Pull one V1 report and one V2 report covering the same settlement, and check that every figure your process depends on can still be produced. Where it cannot, the gap is almost always a charge that used to have its own column and now lives inside amount-description.
The three things that look like missing money and are not
1. Orders that fell into the next settlement
A payout covers a window, and an order enters it when its funds release rather than when it was bought. An order placed near the end of a period and delivered after it lands in the following file. On Amazon's own forums a seller reported seeing three sales against more than a thousand real orders for a six-day window, and the resolution was exactly this: bought on the 21st, delivered on the 25th, released on the 2nd, next settlement. Nothing was missing.
Before calling a gap a short payment, check the same orders against the next settlement. A period boundary and a genuine short payment look identical inside a single file, which is why reconciling one settlement in isolation is the habit that produces false alarms. The same discipline applies on every marketplace, which is why settlement cycles are worth knowing per channel rather than assumed.
2. Money held rather than taken
Reserve movements appear in the file as amounts like any other, so a reserve going up reads as money gone. It has not gone, it is held, and it returns on a later schedule. A reconciliation that treats a reserve line as a cost will under-report your margin every cycle and over-report it later.
3. Tax withheld that you can reclaim
TCS under GST section 52 and TDS under income tax section 194-O are cut from your payout and are both credits rather than costs. TCS is 0.5% of net taxable supplies, revised from 1% by notification 15/2024-Central Tax in July 2024, and the 1% figure still published widely is the statutory ceiling in section 52(1) rather than the notified rate. TDS under 194-O is 0.1%, reduced from 1% with effect from 1 October 2024.
Neither reaches you automatically. TCS lands in your electronic cash ledger, and only after you file the TDS and TCS Credit Received statement yourself, which is the step that quietly leaves money with the government. We cover the mechanics in claiming your TCS credit and the marketplace-side view in TCS and TDS refunds for sellers.
What the report will not do for an Indian seller
Two gaps are specific to selling on amazon.in, and no settlement report closes either.
Fees carry no GST split. Amazon's public fees page states that all fee types are displayed excluding GST and that 18% GST is applied to them. So the tax exists on every fee line and the file does not break it into IGST, CGST and SGST. If you want input credit traced to the fee that bore it, you allocate it, and that is work a tool built for a US seller has no concept of.
The fee invoice cannot be joined to an order. The monthly invoices do not print order identifiers against the fee lines. An Indian seller put it exactly on Amazon's own forum, asking for Order IDs against referral commission, closing fees, shipping charges and promotional rebates, and comparing an invoice without them to a document sent with no address. He got no reply. The settlement report is the route that does carry the join, which is why reconciliation starts there and not at the invoice, and why downloading invoices in bulk solves a filing problem rather than an accounting one.
Put together, that is the shape of the job: the settlement file is the only artefact that ties a charge to an order, and the two things an Indian seller most needs from it are the two Amazon leaves to you. Our wider method is in Amazon payment reconciliation for India and the per-channel view in how Amazon settlements work.
Start from the settlement, not the invoice
The invoice tells you what you were charged. Only the settlement tells you which order was charged for it. Build your working file from order-id, order-item-code, sku and the three amount columns, and keep adjustment-id, which most templates drop and every dispute needs.
Reconcile a window, never a file
Read two consecutive settlements together so a period boundary cannot masquerade as a short payment. The same rule is what makes payout reconciliation and reconciliation software worth the setup rather than a monthly scramble.
Where returns enter the picture
A return is not one row. It is a refund of the item price, a reversal or retention of fees depending on the fee type, and sometimes a separate reimbursement later. The three amount columns are what separate them, and a reconciliation that nets a return to a single figure loses the part you can act on.
Where a seller-fulfilled return comes back short, damaged or not at all, the claim route is SAFE-T, and its filing window is far shorter than most published guidance says. That is covered in Amazon SAFE-T claims, and the India-specific return-to-origin economics in Amazon RTO and returns in India.
Every Amazon payout, matched to the order that earned it
Robnu ingests Amazon settlements with their full line items, per seller and per account, so a short payment is visible the day it lands instead of at the end of the quarter.
Sources & further reading
- Amazon SP-API, settlement report type values lists the 24 fields of
GET_V2_SETTLEMENT_REPORT_DATA_FLAT_FILE_V2and carries Amazon's note about the three general-purpose amount columns. Public, no login. Read 6 October 2026. - Amazon SP-API deprecations records the V1 flat file and XML settlement reports as deprecated 17 March 2025 with removal on 11 November 2026. Read 6 October 2026.
- Amazon India fees and pricing states that fees are displayed excluding GST and that 18% GST applies to them. Read 6 October 2026.
- CBIC, section 52 of the CGST Act is the source for TCS being levied at a rate not exceeding one per cent of the net value of taxable supplies, which is the ceiling the widely published 1% figure comes from.
Not tax or legal advice. Rates and report formats change, and the two in this guide changed recently. Verify a figure against the primary source above before you file on it.
Questions sellers ask
Twenty-four. Amazon's own developer documentation lists them: settlement-id, settlement-start-date, settlement-end-date, deposit-date, total-amount, currency, transaction-type, order-id, merchant-order-id, adjustment-id, shipment-id, marketplace-name, amount-type, amount-description, amount, fulfillment-id, posted-date, posted-date-time, order-item-code, merchant-order-item-id, merchant-adjustment-item-id, sku, quantity-purchased and promotion-id. That page is public and needs no Seller Central login.
Amazon states that the price columns are condensed into three general-purpose columns, amount-type, amount-description and amount, and that the first two hold the type of charge or fee incurred. It then does not publish the set of values either column can take. So the honest method is to read the distinct values present in your own settlement files and build your mapping from those, rather than coding against a list published by a third party that cannot have got it from Amazon either.
Yes. Amazon's public SP-API deprecations page lists GET_V2_SETTLEMENT_REPORT_DATA_FLAT_FILE and the XML variant as deprecated on 17 March 2025 with a removal date of 11 November 2026. Amazon publishes no field-by-field mapping from the old reports to the new one, so anything of yours that reads the old format needs testing against the new one before that date rather than after.
Usually they are not missing, they are in the next settlement. A payout covers a window, and an order enters it on the date its funds are released rather than the date it was bought. An order placed near the end of a period and delivered after it therefore appears in the following file. Before treating a gap as a short payment, check the same orders against the next settlement and against the posted-date on the rows, because a period boundary and a missing payment look identical in a single file.
Because the monthly fee invoices do not carry order identifiers against the fee lines. Indian sellers raise this on Amazon's own forums, including a request to show Order IDs against referral commission, closing fees, shipping charges and promotional rebates, with the complaint that an invoice without them is like a document with no address. The settlement report is the route that does carry the join: the fee rows sit beside an order-id and an order-item-code, which is why reconciliation starts from the settlement file and not from the invoice.
Not as IGST, CGST and SGST columns, which is the gap Indian sellers feel most. Amazon's own public fees page states that all fees are displayed excluding GST and that 18% GST is applied to them, so the tax is real and has to be allocated by you if you want input credit traced to the fee that bore it. That allocation is the work no report does for you, and it is the reason an Indian reconciliation cannot be a US tool with the currency changed.
Related seller guides
More on the operations, money and claims that decide whether a marketplace catalogue actually makes money.
Meesho Negative Balance: Why Your Settlement Went Negative and How to Fix It
Meesho negative balance means deductions beat sales in that cycle. Why it happens, how Meesho recovers it, and which lines you can claim back.
How to Read the Meesho Payment Report, Column by Column (2026)
Read your Meesho payment report column by column: sale amount, shipping, GST, TCS, TDS and recoveries, to the bank settlement amount.
Meesho Next Payment Date: How to Check It (2026)
How to find your Meesho next payment date in the Supplier Panel, how the settlement window sets it, why a payout can look delayed, and what to do when a payment does not arrive.
Meesho Payment Deductions Explained Line by Line (2026)
Every deduction on a Meesho settlement explained: commission, shipping and logistics, return and RTO costs, penalties, TCS and TDS, and adjustments. What each line means, which ones are wrong most often, and how to spot an incorrect dedu...
Amazon India settlement reports explained
Referral fees, closing fees, shipping, refund reversals, reconcile order by order, spot the wrong-rate and duplicate errors, and find the refund reversals worth a SAFE-T claim.
Flipkart Settlement Reports Explained: Read Yours Line by Line
Every Flipkart settlement is order value minus a stack of deductions. Here is what each line means, which fees are wrong often enough to check, and how to reconcile a payout to the rupee.
Myntra Partner Payment Cycles Explained: Settlement Timing, Deductions & Reconciliation
How Myntra settlement works, the lead time from delivery to payout, every deduction that lands on a remittance, why payments get held, and how to reconcile a settlement against your orders.
Meesho payment cycle: when you actually get paid
The settlement timeline, every deduction applied before payout, and why your bank credit never matches your order value, plus how to tell a normal gap from a wrong one.