← All posts

Anatomy of an Amazon settlement report — every field explained for EDPMS closure

By XPortKnock team · Published 2026-07-20 · 10 min read

The Amazon settlement report is where every reconciliation begins and where most reconciliations quietly go wrong. Sellers download it, glance at the "Net Total" line at the bottom, and try to make that number tie to their bank credit. It usually doesn't — because half of what's inside a settlement report is not proceeds against the current shipping bills.

This post walks through the settlement report field by field, transaction type by transaction type. When you've finished reading, you'll be able to look at any row in your settlement TXT file and know exactly how it should be treated for EDPMS purposes.

If you haven't read how to reconcile Amazon settlements with your bank credits yet, that post covers the reconciliation flow. This one covers the source data.

Where to download the report

The flat-file V2 format is a tab-separated text file with one header row and one row per transaction event. For any active FBA seller, a single settlement TXT can be tens of thousands of rows long. Never open it in Excel by default (Excel will drop leading zeros in order IDs and truncate large numeric fields). Open it in a proper text editor or import it as text into your reconciliation tool.

The header row — orientation

The first line of the flat file names 40+ columns. The ones you actually need for EDPMS reconciliation:

Every row will have some of these populated and others blank, depending on what kind of transaction it is.

Amazon settlement report anatomy Structural breakdown of an Amazon settlement report showing the header, the four categories of transaction rows (order events, refund events, non-order charges, reserved amount), and the net payable line. Amazon settlement TXT — what's inside Header row (40+ columns) settlement-id · start/end date · deposit-date · currency · transaction-type · sku · price-type · fee-type · ... Order events (positive proceeds) transaction-type = "Order" One row per (order, price-type, fee-type) Principal + Shipping + Tax − Commission − FBAFee = net Refund / Chargeback events transaction-type = "Refund" or "Chargeback" Reverses a prior order (may span settlements) Fees may or may not be refunded — check per row Non-order charges Storage · Subscription · Ads · Adjustments Not linked to a specific order/SKU Apportion pro-rata for EDPMS Reserved Amount transaction-type = "current-reserve-amount" Held funds — NOT realized proceeds Book as suspense; recognize on release "total-amount" row (net payable) Sum of all categories above = what wires to your bank (± FX conversion) The "Net Total" line at the bottom of the HTML summary hides all this structure. Always use the flat-file TXT for reconciliation.
Figure 1: A settlement TXT is not a bank statement. It's a bundle of four different categories of event that must be reconciled separately.

Category 1: Order events (positive proceeds)

Rows with transaction-type = "Order". Every consumer purchase generates multiple rows for the same order-id, one per line-item component:

Each of these can appear as a price-type on a separate row, all sharing the same order-id.

Amazon then deducts per-order fees on additional rows (same order-id):

To compute the net order contribution, you sum all positive price-amount rows and subtract all item-related-fee-amount rows for that order-id. That number is what the order actually contributes to your realized proceeds.

For EDPMS attribution: each order row references a specific SKU. Attribute the order's net contribution to whichever shipping bill your SKU-level FIFO says supplied the unit. See how to reconcile Amazon settlements for the FIFO mechanics.

Category 2: Refund and Chargeback events (negative proceeds)

Rows with transaction-type = "Refund" or "Chargeback". These reverse a prior order.

Two important things to know:

For EDPMS attribution: a refund reverses proceeds that were already attributed to a shipping bill in an earlier settlement. Your reconciliation engine has to reach back, find the original attribution, and back it out. This is why SKU-level attribution needs an idempotent recomputation model — a late refund can invalidate downstream attributions across months of settlements.

Category 3: Non-order charges

Rows with a transaction-type that is not tied to a specific order:

Sponsored Products, Sponsored Brands, and Sponsored Display charges are often deducted at the settlement level but can be tied to specific SKUs via the advertising reports (a separate download). If you have the advertising data, you can attribute ads directly; if not, apportion pro-rata.

For EDPMS attribution: none of these link to specific orders, and therefore none link natively to specific shipping bills. Apportion pro-rata by settlement contribution — every shipping bill that had realized proceeds in this settlement takes a share of the non-order charges proportional to its contribution.

Document the apportionment method in your reconciliation packet. Consistency matters more than the specific method chosen.

Category 4: Reserved Amount

Rows with transaction-type = "current-reserve-amount" or "previous-reserve-amount-balance":

The two work together across consecutive settlements. Settlement N withholds INR X. Settlement N+1 releases the previously-withheld INR X (from settlement N-1) and withholds a fresh amount for settlement N+1.

For EDPMS attribution: reserved amounts are not realized proceeds until released. Book the current reservation as a suspense credit. When the corresponding release row appears in a later settlement, recognize that row as realized proceeds against the shipping bills whose orders originally contributed to the reservation.

This is where sellers most commonly inflate their reconciliation numbers. Getting this right requires tracking reserved balances across settlements — another reason spreadsheet-based reconciliation struggles at any real trading volume.

Currency handling within the report

Every row's amount is in the settlement currency (USD for amazon.com, GBP for amazon.co.uk, etc.). There is one exception: rows related to VAT and tax-authority remittances may appear in the destination country's currency even if the settlement currency is different (rare, but worth watching for in EU marketplaces where VAT compliance is complex).

If your bank credit is in destination currency, the settlement's total-amount should match your bank credit (± the correspondent bank fee for cross-border wires). If your bank credit is in INR, apply Amazon's implied FX rate (from the corresponding total-amount-inr fields if present, or from a separate Amazon FX report) to derive the expected INR value — then reconcile the actual bank credit against that value, booking the difference as FX gain/loss.

Related supporting reports

The settlement TXT covers what money moved. Two adjacent reports give you the context to make attribution work:

Together, these three reports (settlement TXT, transaction CSV, advertising CSV) contain everything you need to reconcile Amazon FBA proceeds to EDPMS with defensible attribution.

The short version

Where XPortKnock automates this

XPortKnock parses Amazon settlement TXTs natively — every row, every event type, every fee subtype. It reconciles across settlements (so refunds attributed to prior settlements are handled correctly), tracks reserved-amount balances across time, and generates the SKU-level FIFO attribution automatically. The output is a reconciliation packet that satisfies every rejection pattern covered in why banks reject FBA EDPMS closures.

Bring one recent settlement TXT to a 14-day trial and see the parsed output the same day.