Amazon removes the old settlement reports on 11 November 2026

What exactly is being removed

Amazon's changelog names two report types. GET_V2_SETTLEMENT_REPORT_DATA_XML, listed in Seller Central as the XML Settlement Report, and GET_V2_SETTLEMENT_REPORT_DATA_FLAT_FILE, the Flat File Settlement Report. Both stop being produced on 11 November 2026, and the notice says the change applies to all marketplaces.

The naming is the first thing that confuses people, and it is worth slowing down on. Both of the reports being removed have V2 in their identifier. The report that replaces them is GET_V2_SETTLEMENT_REPORT_DATA_FLAT_FILE_V2, with V2 at the end as well. So you cannot tell old from new by looking for the string V2, which is exactly what a quick search of your own codebase will do. Match the full identifier, every character of it, or you will convince yourself you have already migrated.

The deprecation itself is not new. Amazon's deprecation schedule gives 17 March 2025 as the deprecation date for both reports, with removal on 11 November 2026. That is a twenty month warning, which is generous, and it is also long enough that whoever read the original notice has probably changed jobs.

The XML report has no replacement, and that is the expensive part

Amazon's wording leaves no room to hope here. The changelog says that an XML replacement report is not available. There is no new XML settlement feed coming, and no equivalent you can point an existing XML parser at.

If your accountant, your tool or your own script reads the XML settlement report, the work in front of you is not a field rename. It is moving from a nested document to a tab-delimited flat file, which is a different shape of data with different parsing, different type handling and different edge cases around empty values. Budget for it as a rewrite of that one integration rather than a configuration change.

This also catches people who did not know they were on XML. A reconciliation tool bought three years ago may well have chosen the XML feed because it was the richer format at the time. Ask the vendor which report type they call, by full identifier, and get the answer in writing.

Access narrows, which is the trap nobody schedules for

Amazon's report type reference lists the roles each settlement report needs. The old Flat File Settlement Report is readable with Inventory and Order Tracking, with Finance and Accounting, or with Amazon Fulfillment. The new Flat File V2 Settlement Report lists Finance and Accounting.

Read that as an operational problem rather than a documentation detail. Plenty of businesses give an operations person Inventory and Order Tracking so they can chase shipments, and that same person has been pulling the settlement file every fortnight for years. On 11 November the file they used stops existing, and the one that replaces it is not in their permission set. Nothing errors in a way that explains itself. The report is simply not there.

So the migration has a second task list beside the parsing one: work out who downloads settlements today, check what roles they hold, and grant Finance and Accounting to the ones who need to keep doing it. Do that before the date, because granting a finance role is the kind of request that sits in somebody's inbox.

You cannot request a settlement report, which limits how you test

Amazon's reference page states that settlement reports cannot be requested or scheduled, that Amazon schedules them automatically, and that you search for them using the getReports operation. That single sentence shapes the whole migration plan.

It means you cannot generate a fresh V2 file on demand to test against. You have to wait for Amazon to publish one on its own settlement cadence, then fetch it. If your settlement period is fortnightly, you have a small number of real files between now and 11 November, and each one is a test opportunity you do not want to waste.

The practical consequence is that the useful work is front-loaded. Pull the most recent Flat File V2 report that already exists in your account today, run your new parser over it, and compare the totals with what your old parser produced for the same period. The new report is available now, so this comparison does not need to wait for anything.

The check to run this week

Start by finding out what you actually consume. Search your own code, your scheduled jobs and your vendor documentation for the two full identifiers being removed. If either appears, that path has a deadline on it. Then search for the replacement identifier and confirm something already reads it, because an integration that mentions both is usually half-migrated rather than done.

Next, run both reports over the same settlement period and reconcile the totals to the rupee. If the two disagree, the difference is almost always consolidation rather than loss, because the new report condenses the price and fee columns. Find out which old rows collapsed into which new ones before you trust the new number.

Finally, check the roles. List every user who touches settlement data, confirm each holds Finance and Accounting, and request it for the ones who do not. That task has a human in the loop, so it is the one most likely to slip past the date.

If you reconcile across more than one marketplace, this is also a reasonable moment to stop doing it by hand. Robnu reads Amazon settlements alongside Meesho, AJIO, Flipkart and Myntra and matches each fee line back to the order that caused it, so a format change on one marketplace becomes our problem to absorb rather than yours to parse.

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:

• All 24 fields of the V2 settlement report, defined
• Mapping the old settlement columns to the new three
• How Amazon India settlements work
• When Amazon India actually pays you
• Reconciling Amazon India payments
• What reconciliation means, and why it is not bookkeeping
• What Robnu does on Amazon
• Settlement cycles across every marketplace

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.
• Amazon SP-API deprecation schedule the dated table. It gives 17 March 2025 as the deprecation date and 11 November 2026 as the removal date. 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.