Mapping the old Amazon settlement columns to the new three
The old report spread charges across price and fee columns. The new one condenses them into amount-type, amount-description and amount. Amazon publishes the pairings, and one line in that table explains why your totals will not match row for row.
Amazon's removal changelog carries a mapping table. price type name and fee type name become amount-type. price amount and fee amount become amount. price type and fee type become amount-description. transaction-type stays transaction-type or becomes amount-description. The table also warns that disjointed amounts may be consolidated, which is why row counts drop.
- A mapping does exist. It is in Amazon's removal changelog rather than in the report documentation, which is why it is widely reported as unpublished.
- The old price and fee column pairs collapse into three general-purpose columns: amount-type, amount-description and amount.
- Amounts now always land in a single amount column, so you stop scanning several columns to find the number on a row.
- Amazon warns that disjointed amounts may be consolidated. Expect fewer rows for the same money, and reconcile on totals rather than on row counts.
- Amounts print in local currency format, so a European file can read 95,00 where you expect 95.00. Parse the separator, do not assume a full stop.
The common advice on this migration is that you are on your own, because Amazon never published a field mapping. That was a reasonable reading of the report documentation, which does not contain one. It is wrong about the changelog, which does. The mapping lives in the same notice that announces the removal, a few paragraphs below the date everybody stopped reading at, and it answers most of the questions people have been reverse engineering from sample files.
The mapping Amazon actually publishes
The old report described a charge using a pair of columns, one naming the kind of thing and one carrying the money, and it had a separate pair for prices and for fees. The new report drops that symmetry in favour of three general-purpose columns that describe any charge.
The pairings Amazon gives are these. price type name and fee type name both become amount-type. price amount and fee amount both become amount. price type and fee type both become amount-description. transaction-type maps either to transaction-type, which survives under its own name, or to amount-description depending on the row.
Read down that list and the design becomes obvious. Where the old report asked you to know in advance whether you were looking at a price or a fee, and to read a different column accordingly, the new one asks you what kind of amount this is, what it was for, and how much. The same information, asked in a more uniform way, which is what Amazon means when it says the same information in fewer columns and streamlined formatting.
One amount column, which simplifies every parser
Amazon's reference page makes a point worth quoting on its own terms: amount values always populate in a single amount column, so there is no need to parse the rows to find a number.
Anyone who has written against the old report will recognise what that removes. The old shape forced a parser to look in one place for a price and another for a fee, and to decide which on the basis of other columns on the row. Every one of those branches is a place where an unexpected row type produced a silently wrong total rather than an error.
So the new report is genuinely easier to consume, and the migration is not purely a cost. If you are rewriting the parser anyway, this is the part that gets shorter.
The consolidation warning, and why your totals move
There is one line in Amazon's mapping table that matters more than the pairings, and it is easy to skim. Amazon notes that disjointed amounts may be consolidated.
In practice that means a charge which occupied several rows in the old report can arrive as one row in the new one. The money is the same. The row count is not. If you reconcile the two reports by comparing how many lines each produced, or by matching line to line, you will find differences that look like missing data and are not.
Reconcile on totals instead, and reconcile per settlement period. Take one period, sum the money in the old report, sum the money in the new one, and confirm they agree. Then, where you care about the breakdown, work out which old rows collapsed into which new row before you build anything that depends on the granularity. Some of it is simply no longer there, and finding that out now is cheaper than finding out in a tax filing.
Local currency formatting, the bug that waits for your first European file
Amazon's reference page states that amounts are displayed in local currency formats, giving the example of 95,00 for the EU instead of 95.00.
For an India-only seller this is a detail you can note and move past, because rupee amounts use a full stop as the decimal separator. For anyone selling in Europe as well, it is a defect waiting in your parser. A naive conversion of 95,00 to a number returns 9500 in some languages, zero in others, and an error in the better ones. None of those are what you want in a settlement total.
Handle the separator explicitly rather than trusting a default number parse, and test it against a real file from the marketplace in question rather than one you typed yourself.
Every charge, described the same way
amount-type says what kind, amount-description says what for, amount carries the money
A migration order that does not waste your remaining files
Because Amazon schedules settlement reports and you cannot request one, the number of real V2 files you can test against before 11 November 2026 is fixed by your settlement cadence. Treat them as a limited resource.
Work in this order. Pull the most recent Flat File V2 report already published in your account and read it with fresh eyes against the field list. Write the new parser against that file. Then reconcile its totals against what your old parser reports for the identical period, which is the test that actually proves the migration. Only after the totals agree should you switch anything that feeds your books.
Keep the old report's output for the overlap period rather than deleting it the day you cut over. It is the only thing you can compare against if a number looks wrong in December, and after 11 November you cannot regenerate it.
If you would rather not own this at all, it is the kind of work Robnu absorbs. We read Amazon settlements next to Meesho, AJIO, Flipkart and Myntra, match each fee line back to the order behind it, and keep the format change on our side of the line.
The part of this Robnu does for you
Robnu reads your Amazon account and reconciles every settlement line back to the order that caused it, so a wrong deduction is visible the day it lands.
- Orders, returns, payouts and inventory synced
- Every settlement line matched to its order
- FBA units Amazon has not made good, listed
Where this sits in the rest of your Amazon operation
On Amazon, Robnu syncs your orders, returns, payouts and inventory, reconciles every settlement line back to the order that caused it, lists the FBA units Amazon's own ledger has not made good, flags a return that never came back before the SAFE-T window closes, and scans returns in at your dock. It reads your Amazon account rather than writing to it, so accepting orders and making labels run on AJIO and Meesho today. Related reading:
Sources & further reading
- Amazon SP-API changelog, settlement report removal Amazon's own notice. It carries the 11 November 2026 date, the two report identifiers being removed, the sentence "An XML replacement report is not available", and the field mapping table. Read 2 November 2026.
- Amazon SP-API settlement report type values the reference page for all three settlement reports. It states the role each one needs, that settlement reports cannot be requested or scheduled, and the three-column condensation. Read 2 November 2026.
Not legal or tax advice. Amazon changes fees, windows and policies without notice, and the detailed style guides and account-health thresholds sit behind a Seller Central login, so any figure quoted here as convention is not Amazon-published. Check anything you plan to act on against your own Seller Central account first.
Questions sellers ask
Yes, in the removal changelog rather than in the report documentation. It pairs price type name and fee type name with amount-type, price amount and fee amount with amount, price type and fee type with amount-description, and transaction-type with either transaction-type or amount-description. The report reference page itself does not carry the table, which is why it is often said to be unpublished.
Because of consolidation. Amazon's mapping table notes that disjointed amounts may be consolidated, so a charge spread over several rows in the old report can arrive as a single row in the new one. The totals should still agree. Reconcile on the money rather than on the row count.
In one column. Amazon's reference states that amount values always populate in a single amount column, so there is no need to parse the rows to find a number. That replaces the old arrangement where a price and a fee carried their money in different columns.
They are the two descriptive columns that replace the old price and fee type pairs. amount-type takes what used to be price type name or fee type name, and amount-description takes what used to be price type or fee type, and sometimes what used to be transaction-type. Amazon condenses the price columns into these three general-purpose columns and does not publish the full set of values either descriptive column can contain, so build your own mapping from the distinct values in your own files.
No, but know why the question matters. Amazon states that amounts are displayed in local currency formats, with 95,00 for the EU instead of 95.00. Indian rupee amounts use a full stop, so an India-only seller is unaffected. If you also sell in Europe, parse the separator explicitly rather than relying on a default number conversion.
However many Amazon publishes on your settlement cadence between now and 11 November 2026. You cannot create more, because Amazon states that settlement reports cannot be requested or scheduled and that you search for them with getReports. The Flat File V2 report is available now, so start with the files already sitting in your account.
Related seller guides
More on the operations, money and claims that decide whether a marketplace catalogue actually makes money.
Amazon Removes The Old Settlement Reports On 11 Nov 2026
On 11 November 2026 Amazon removes the XML and Flat File settlement reports in every marketplace. There is no XML replacement, the new report needs a different Seller Central role, and anything of yours that reads the old format stops working that day.
Amazon order defect rate, what counts and what does not
ODR is three separate things counted as one, and sellers usually watch the wrong one. What feeds it, the lag that makes it look wrong, and why the threshold is not publicly citable.
Amazon Reconciliation: What It Is, And What It Is Not
Reconciliation is not bookkeeping. It is proving that what Amazon paid you matches what Amazon owed you, line by line, and finding the gap when it does not. Here is the method, the eight places money goes missing, and what to automate.
Receive Returns By Sending Codes In A WhatsApp Chat
Say return scan, then send AWB after AWB as the parcels come off the van. Each one is marked received the moment it lands, and shows up everywhere a scan from the web dock does, reports included.
Amazon cancellation rate, only your cancellations count
A buyer cancelling does not hurt you; you cancelling does. Why the metric is almost always a stock accuracy problem, and the two habits that quietly generate it.
Amazon listing uploaded with no error and showing nowhere
A clean processing report does not mean a live listing. The six states an uploaded listing sits in while buyers cannot see it, and how to tell them apart.
Amazon error 5461, not approved to create new ASINs
Error 5461 means the category is gated for your account, so no file edit clears it. What gating is, and the two legitimate routes past it.
Unicommerce Alternatives in India: Honest Options by Seller Shape (2026)
What Unicommerce is genuinely good at, why sellers look elsewhere, and the real alternatives by seller shape. Only three order management products in this market publish a price you can compute.