Amazon settlement report explained: reconcile payouts and migrate to V2

A sales dashboard, settlement statement and bank account answer different questions. Sales show business activity; a settlement records financial postings; the bank confirms cash received. Comparing their totals without aligning dates, transaction status and scope can create an apparent shortage.

This guide sets out a seller-run reconciliation and migration method. Start with one completed disbursement, preserve its source files and investigate differences before treating them as claims.

Act before the 11 November 2026 report change

Amazon's SP-API announcement dated 9 March 2026 says two report types will be removed on 11 November 2026:

• XML Settlement Report: GET_V2_SETTLEMENT_REPORT_DATA_XML; and
• original Flat File Settlement Report: GET_V2_SETTLEMENT_REPORT_DATA_FLAT_FILE.

Amazon identifies GET_V2_SETTLEMENT_REPORT_DATA_FLAT_FILE_V2 as the replacement across all marketplaces. It also states that no XML replacement is available.

This is an integration change, not the removal of settlement reporting. A seller downloading reports manually should inspect the format actually available in the account; a developer, agency or software provider using SP-API should confirm the report type in its code, scheduled jobs and stored configuration.

A five-minute dependency check

Ask the person responsible for each accounting, reconciliation or data-import workflow to provide:

1. the exact report-type identifier requested;
2. the last successful import timestamp;
3. a sample V2 file from the same seller account and marketplace;
4. the importer version or mapping used for V2; and
5. the signed settlement total produced after import.

Do not accept “the file still downloads” as migration evidence. The control is whether the V2 data imports completely and reproduces a known settlement and bank match.

1. Collect the records for one completed payment

Download the settlement statement available in your Amazon India seller account. Record the seller account, marketplace, settlement identifier, currency, period and export time. Keep the original file unchanged and do the analysis in a separate working copy.

Collect the corresponding bank entry and the supporting order, refund, fee-invoice and adjustment records. Add inventory or reimbursement records when those transactions appear. If a payment has not reached the bank, keep it in a pending-transfer register rather than marking it as reconciled.

Use the payment pages and report names visible in your account. Menu labels and export options can change; identify the statement, transaction detail and transfer reference actually attached to that payment.

Check the file before importing

Amazon's current Settlement Reports documentation describes Flat File V2 as a tab-delimited report. Treating it as a comma-delimited CSV can shift columns or combine fields without an obvious error.

Before importing:

• preserve identifiers as text so leading zeros and long references are not altered;
• retain the original currency and signs;
• verify the delimiter and character encoding;
• count source rows before filters or joins;
• keep rows without an order ID; and
• quarantine, rather than discard, descriptions the importer does not recognise.

Amazon notes that local currency formats can differ, such as comma decimals in some marketplaces. A parser should use the marketplace and currency context rather than applying one global number format.

2. Understand the Flat File V2 schema

Flat File V2 condenses legacy price and fee columns into three general-purpose fields:

• amount-type: the broader amount grouping;
• amount-description: the specific charge, fee or transaction description; and
• amount: the signed value.

Amazon's migration mapping says legacy price-type and fee-type names move to amount-type, their values move to amount-description, and price or fee amounts move to amount. It also warns that formerly separate amounts may be consolidated in the V2 description structure.

That means a safe migration is not only a header rename. Any logic that assumes a fixed set of fee columns, drops unfamiliar descriptions or locates numbers by column position needs to be tested.

Write an explicit import contract

For each V2 field used downstream, document:

• source header;
• target field;
• data type and null handling;
• sign convention;
• currency parsing rule;
• identifier treatment;
• duplicate key or row-grain rule; and
• response when an unseen amount-description appears.

The last rule should preserve the row and raise a review exception. New descriptions should not silently become zero or disappear from the settlement total.

3. Rebuild the settlement total, then match the bank

First reconcile the statement to itself. Group signed transaction amounts by the descriptions in the file. Keep settlement-level opening, reserve or balance movements separate from order lines, and follow the statement's own presentation.

Build a bridge showing the starting balance where applicable, credits, debits, reserve movements where shown, and the resulting transfer. Do not add a summary total to detailed rows that already produce that total.

Then match the transfer to the bank using the available reference, amount, currency and dates together. Record the actual credit date separately from the statement's deposit date. A similar amount alone is weak evidence of a match.

Illustrative arithmetic, not a marketplace rate card

Suppose a simplified statement contains ₹20,000 of credits, ₹4,000 of fee debits, ₹2,000 of refund debits and a ₹500 adjustment credit, with no other balance movements.

The signed total is ₹20,000 − ₹4,000 − ₹2,000 + ₹500 = ₹14,500. If the linked bank credit is ₹14,500, the transfer matches. This does not establish that each fee or refund is correct.

These amounts are illustrative and invented solely to demonstrate arithmetic. Real statements can contain additional movements, taxes and transactions. Use every relevant line in the seller's own statement.

4. Separate deferred money from unexplained differences

Amazon's India announcement on deferred transactions explains that reserved proceeds can appear as deferred transactions, with the reason and estimated release date available in the payment view and downloadable report. It says the duration depends on the seller's STEP level, while some older transactions or other holds can remain in account-level reserves.

Use the release information displayed for the account instead of assuming every order follows a universal payout timetable. Keep a dated register of deferred transactions, reasons, expected release dates and later releases.

Classify each difference as:

• Pending or deferred: the record shows a hold, release date or transfer still in progress.
• Explained timing: the financial posting belongs to another period.
• Matched: the amount and supporting identifiers reconcile.
• Unexplained: the available records do not yet account for the difference.
• Disputed: evidence has been submitted and a case is open.

When money is released, remove it from the deferred register and match the resulting posting. Do not count the same amount as both outstanding and paid.

5. Check transaction lines against applicable terms

Once the transfer is reconciled, test the underlying charges. Amazon India's fees guidance separates referral, closing, weight-handling and other applicable fees. Their basis varies by category, price, fulfilment and shipment characteristics; the page records a closing-fee update effective 7 September 2026.

For each selected charge, save the terms applicable to the transaction date and the product attributes used in the calculation. Comparing an older charge with today's rate card can produce a false exception.

Fees, refunds and reimbursements need separate checks

Trace a fee to its transaction, category, fulfilment route and recorded weight or dimensions where relevant. Compare expected and charged amounts on the same tax basis.

For a refund, follow the original order, refund posting and any related fee credits or debits. Do not assume every original charge reverses in full. If the applicable treatment cannot be verified, record that uncertainty before raising a dispute.

Inventory adjustments and reimbursement postings need their own supporting records. A lost or damaged item does not by itself establish eligibility, claim value or a filing deadline. Check the current policy applying to the event and preserve the evidence.

6. Prove V2 parity before cutover

Use a completed settlement whose bank credit and transaction bridge have already been verified. Import the same economic period through the old and V2 workflows while both are available, then compare:

1. settlement ID, marketplace and currency;
2. source and imported row counts;
3. minimum and maximum posting dates;
4. total positive amounts and total negative amounts;
5. net settlement total;
6. counts and totals by amount-type;
7. unmapped or blank amount-description values;
8. duplicate identifiers or duplicated rows; and
9. the final bank-credit match.

Investigate every difference before approval. A matching net total is necessary but not sufficient: equal and opposite omissions can cancel out while transaction detail remains wrong.

Define acceptance and rollback evidence

Record the test file hashes or filenames, importer version, run timestamp, reviewer and explained differences. Keep the previous mapping read-only until the V2 process has completed an agreed number of successful reconciliations.

If V2 fails after the legacy reports are removed, rollback may mean restoring the previous application release while keeping the V2 report—not requesting a removed report type. The recovery plan should therefore cover parser changes, quarantined rows and manual reconciliation, not depend on legacy availability after 11 November.

7. Keep an exception ledger another person can reproduce

Use one row per investigated difference, with:

• seller account, marketplace and settlement ID;
• order, shipment or adjustment identifier where available;
• transaction description, posting date and currency;
• expected amount, actual amount and signed difference;
• calculation basis and applicable source date;
• source filenames and supporting evidence;
• classification, owner, next action and review date; and
• case reference, decision and any later adjustment or bank credit.

A sample is a prioritisation method, not proof that the account is correct. Matching selected orders cannot clear untested storage charges, reimbursements or account-level adjustments.

Only describe a recovery as received after the relevant adjustment and cash movement have been verified. A submitted case, accepted request and completed payment are separate stages.

8. Close the review without erasing open items

A useful close records four results separately:

• whether the settlement rebuilt to its stated transfer;
• whether the bank credit matched;
• which underlying charges were tested; and
• which exceptions remain open.

Carry unresolved items forward with their evidence and next action. Do not erase them when a new settlement arrives or when the V2 importer is approved.

This review explains payouts. It does not replace a profitability calculation, accounting close or tax reconciliation. Keep operational matches and accounting classifications connected, with the appropriate finance review where needed.

Our team at Steps Ecommerce works from seller-owned exports and documented transaction evidence. The practical starting point is one reproducible payment reconciliation, followed by a written scope for the work the account needs.

Primary sources rechecked on 28 October 2026. Amazon's report-removal announcement is dated 9 March 2026; the settlement documentation and India deferred-transactions announcement should be rechecked when the account or integration is changed.