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

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

• Seller Central → Reports → Payments → Statement View
• Choose the settlement you want, click "Download flat file V2" (tab-separated TXT)
• The default view (HTML summary) is not enough for reconciliation — always pull the TXT

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:

• settlement-id — Amazon's unique ID for this settlement bundle
• settlement-start-date, settlement-end-date — the 14-day window
• deposit-date — when Amazon actually wired the net (this is what matches your bank credit date, ± 2-5 business days)
• total-amount — the net payable for this settlement in settlement currency
• currency — the settlement currency (USD for amazon.com, GBP for amazon.co.uk, EUR for amazon.de/fr, AUD for amazon.com.au, and so on)
• transaction-type — the category of each row (Order, Refund, Chargeback, StorageFee, etc.)
• order-id — the customer-facing Amazon Order ID (for Order and Refund rows)
• sku — the SKU that generated the transaction (blank for non-order rows)
• quantity-purchased — number of units in the transaction
• price-type, price-amount — the gross line-item components (Principal, Shipping, Tax, GiftWrap)
• item-related-fee-type, item-related-fee-amount — the per-order deductions (Commission, FBA Fees, VAT)
• promotion-amount — coupon or promotional discounts (negative)
• posted-date — the date Amazon recognized the transaction

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

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:

• Principal — the SKU's list price × quantity
• Shipping — Amazon-charged shipping (kept by Amazon in most cases; passthrough for the seller)
• Tax — VAT/GST/sales tax collected on the sale (passthrough to the tax authority in the destination country)
• GiftWrap — optional gift wrapping charge
• PromotionAmount — negative; discounts and coupons

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):

• Commission — the marketplace referral fee (typically 15% of principal + shipping)
• FBAPerUnitFulfillmentFee — pick, pack, and ship
• VATOfCommission — VAT on Amazon's commission (destination-country tax)

Each row's contribution to the order-level net depends on the combination of price-amount and item-related-fee-amount fields on all rows sharing the same order-id. Reconstructing the true net-per-order requires walking the whole group.

For EDPMS attribution: each order row references a specific SKU, and every unit of that SKU came from a specific shipping bill. Tying the two together is what a purpose-built reconciliation engine handles for you.

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:

• A refund can be in a different settlement from the original order. A June sale can generate a July refund. Your reconciliation must connect them back to the same order-id.
• Not all order fees are refunded. Amazon typically refunds the Principal and Tax but often keeps a portion of the Commission and the FBAFee. Check each refund row's item-related-fee-amount and item-related-refund-fee-amount to see what was refunded and what was retained.

For EDPMS attribution: a refund reverses proceeds that were already attributed to a shipping bill in an earlier settlement. Getting this right across months of settlements is a well-known limitation of spreadsheet-based reconciliation — it's the kind of state-management problem that needs purpose-built tooling.

Category 3: Non-order charges

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

• FBAStorageFee — monthly warehouse fee, charged mid-month
• FBALongTermStorageFee — for inventory sitting more than 180 days (or 365 days, depending on the marketplace)
• Subscription — Seller Central Professional plan monthly ($39.99 for amazon.com; equivalent for other marketplaces)
• CouponRedemptionFee — Amazon's platform fee for processing coupons
• AdjustmentItem / AdjustmentTax — Amazon's catch-all for retroactive corrections (SAFE-T reimbursements, lost inventory reimbursements, dispute settlements)
• CS_ErrorItem — customer service concession
• RunLightningDealFee — Lightning Deal participation fees

Sponsored Products, Sponsored Brands, and Sponsored Display charges are often deducted at the settlement level. Some marketplaces expose additional advertising reports that add SKU-level context, but the settlement report itself doesn't.

For EDPMS attribution: none of these link to specific orders, and therefore none link natively to specific shipping bills. A defensible reconciliation packet documents its apportionment method so the AD bank has something consistent to audit against. Consistency matters more than the specific method chosen.

Category 4: Reserved Amount

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

• current-reserve-amount — how much of this settlement's positive contributions Amazon is withholding for the reserve period (typically 7-14 days)
• previous-reserve-amount-balance — the amount that was reserved in the previous settlement and is now being released into this settlement

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. Handling this correctly means tracking held balances across settlements and only recognizing the release event as realization — again, a state-management problem that spreadsheet-based reconciliation struggles with at any real trading volume.

This is where sellers most commonly inflate their reconciliation numbers. Getting it right takes purpose-built tooling.

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:

• Transaction report — Seller Central → Reports → Payments → Transaction View → download date-range CSV. Order-level detail with per-order fee breakdowns. Cross-reference against the settlement report when you need to explain a specific order.
• Advertising report — Seller Central → Advertising → Reports. Campaign-level ad spend, tied to specific ASINs. Use for direct-attribution of ads to shipping bills when the settlement's ad charge is high enough to matter.

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

• Always use the flat-file TXT (V2), not the HTML summary
• Rows fall into four categories: Order events, Refund/Chargeback events, Non-order charges, Reserved Amount
• Order events attribute back to specific SKUs and the shipping bill each unit came from
• Refunds can span settlements — they must reconcile against the original order-id
• Non-order charges need a documented apportionment method
• Reserved Amount is not realized until released
• Currency handling depends on whether you receive INR or destination currency

Where XPortKnock automates this

XPortKnock parses Amazon settlement TXTs natively — every row, every event type, every fee subtype. It handles cross-settlement refunds, held reserves, and per-shipment attribution automatically. The output is a reconciliation packet designed to pass first-submission review at your AD bank — the rejection patterns covered in why banks reject FBA EDPMS closures don't fire.

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