How to reconcile Amazon settlement reports with your Indian bank credits

Every fortnight, an Amazon settlement lands in your Indian bank account. Your CA asks: "Which shipping bills does this credit close?" You open the settlement report from Seller Central, open your bank statement, open your invoice ledger — and stare at three files that don't visibly align.

This post walks through exactly how the reconciliation is supposed to work. Six steps, in order, with every gotcha we've hit in production called out. If you sell on Amazon Global Selling via FBA and you have ever felt like you were guessing your way through EDPMS closure, this is the map.

If you haven't read the complete guide to EDPMS closure yet, start there — it explains why the reconciliation is hard. This post explains how to actually do it.

The three data sources you're reconciling

Everything in FBA reconciliation is a three-way match between:

1. The Amazon settlement report — from Seller Central → Reports → Payments → Statement View. This is the source of truth for what Amazon actually earned on your behalf and what it deducted.
2. The bank credit(s) — the INR (or foreign-currency) amount that hit your account, with the bank's own UTR reference.
3. Your invoice ledger and shipping bills — the goods that generated the sales, filed at customs and mapped to specific consignments.

Every reconciliation is: settlement → bank credit → invoices → shipping bills. The direction matters. Money flows backwards through this chain, but attribution flows forwards. You need both directions to close a shipping bill defensibly.

Step 1: Match each settlement to a specific bank credit

Amazon publishes a settlement in Seller Central. A few days later, a corresponding credit lands in your bank account. Your first job is to prove which settlement produced which credit.

The UTR is the bridge

Every domestic wire credit in India carries a UTR (Unique Transaction Reference). Your bank statement shows it. Amazon's payout narration sometimes references it, sometimes doesn't. When it does, matching is trivial. When it doesn't — which is often, especially for foreign-currency inward remittance — you match by:

• Date proximity (settlement close date + 2 to 5 business days = credit date)
• Amount (the settlement's net payable, minus FX spread if the bank did the conversion)
• Sender ("AMAZON PAYMENTS" / "AMAZON SERVICES" / a nostro correspondent for foreign wires)

If you receive in destination-marketplace currency (USD, GBP, EUR, AUD) rather than INR, expect the bank's rate to differ from Amazon's internal rate by 0.3-1.5%. That gap is legitimate and must be accounted for in the reconciliation, not treated as an unmatched difference.

Gotcha: partial or split settlements

A single Amazon settlement occasionally arrives as two bank credits (split for cross-border cash-management reasons on Amazon's side). Both credits share the settlement's start/end dates but each carries a distinct UTR. Treat the settlement as reconciled only when the sum of matched credits equals the settlement's net payable.

Step 2: Decompose the settlement into event categories

Once you know which credit came from which settlement, open the settlement report. It is a flat file with thousands of rows and one transaction-type column that tells you what each row is.

The event categories that matter for EDPMS:

• Order — a consumer sale. Positive gross amount, minus per-order fees, equals the row's net contribution to the settlement.
• Refund — a returned or cancelled order. Negative amount. Reduces realized proceeds for the SKU it refers to.
• Chargeback — bank-initiated reversal. Same effect as a refund but has separate legal treatment.
• Reserved Amount — Amazon holding a portion of receivables against future refunds. Not proceeds until released. Treat as a suspense entry.
• FBA Storage Fee — inventory-holding cost. Non-order charge.
• Subscription Fee — Seller Central monthly. Non-order charge.
• Sponsored Products / Sponsored Brands — advertising deduction. Non-order charge in the settlement-report sense (though it can be linked to campaigns).
• Adjustment / Miscellaneous — Amazon's catch-all for retroactive corrections.

Every row falls into one of these. Group the settlement by event category before you go further — the reconciliation approach for orders is fundamentally different from the approach for non-order charges.

Step 3: SKU-level attribution against shipping bills

This is where FBA reconciliation stops being arithmetic and starts being an actual reconciliation exercise.

For every Order row in the settlement, you have an SKU and a quantity. For every one of your shipping bills, you have SKUs and quantities. But an SKU appears in multiple shipping bills — that's what makes this hard.

The correct method is SKU-level FIFO across shipping bills:

• Maintain a running per-SKU inventory ledger, split by shipping bill of origin
• For each order event, deduct the sold quantity from the oldest shipping bill that still has stock of that SKU
• If the order draws from multiple shipping bills (bill A had only 3 units left, order is for 7), split the row: 3 units against bill A, 4 units against bill B
• Attribute the order's net contribution (gross minus per-order fees) to those specific shipping bills, proportionally to units

Do this correctly and each order event flows back to one or more specific shipping bills, with a defensible per-unit realization number attached.

The reason this is impossible in Excel: you have to maintain that running per-SKU-per-shipping-bill ledger across every settlement, all year, for hundreds of SKUs. One late refund three months into the ledger can invalidate a chain of downstream attributions. Purpose-built software handles this with idempotent recomputation; a spreadsheet does not.

Step 4: Reconcile FX at the settlement level, not the order level

Amazon converts consumer sales to your settlement currency at rates that shift constantly through the settlement period. Then a second conversion happens — either Amazon converts to INR before wiring, or your bank converts on arrival.

Rule: apply FX at the settlement level, not per-order. Amazon's own report has one blended rate per settlement (or per settlement-currency-block). Use that rate for the entire settlement's INR realization. Attempting to re-derive per-order FX from RBI reference rates will introduce artificial differences that break your top-to-bottom reconciliation.

If you receive in foreign currency and your bank does the conversion, the bank's rate is what ultimately determines your INR realization. Reconcile the settlement's foreign-currency net payable to the foreign-currency credit at the bank, then let the bank's INR conversion be the final realized number for EDPMS.

The gap between "Amazon's implied rate × settlement net" and "actual INR credit" is your FX conversion gain/loss. This is a normal accounting entry — do NOT force it into the reconciliation.

Step 5: Apportion non-order charges honestly

The five categories of non-order charge — subscription, ads, storage, long-term storage, adjustments — cannot be attributed to specific orders because they aren't caused by specific orders.

Two defensible apportionment methods:

• Pro-rata by settlement net — split the non-order charge across all shipping bills that had realized proceeds in the same settlement, in proportion to each bill's contribution. Simple. Defensible. What most auditors accept.
• Direct-attribution where possible — Sponsored Products spend can sometimes be tied to specific ASINs (and therefore SKUs, and therefore shipping bills). For all other non-order charges, fall back to pro-rata.

Whichever you choose, document the method in a note that accompanies your bank data packet. Auditors are looking for consistency and defensibility, not perfection.

Step 6: Handle reserved amounts as suspense entries

Amazon's Reserved Amount is money Amazon holds back for a rolling window (typically 7-14 days) to cover potential refunds and chargebacks. It appears as a negative row in the current settlement and a positive row in a later settlement (when released).

Do not treat reserved amounts as realized proceeds at the point of reservation. Book them as a suspense entry. Match the release row in a later settlement back to the original reservation. Only the released portion counts as EDPMS realization for the shipping bills whose orders contributed to the reserved pool.

This is one of the top three reasons banks reject reconciliations — sellers include reserved amounts as realized proceeds, and the total per-shipping-bill number ends up inflated by 5-10%.

What to actually hand your bank

A defensible EDPMS reconciliation packet has three parts:

1. An executive summary — one page per shipping bill. Shipping bill number, filing date, invoice value, realized-to-date INR, remaining unrealized, list of contributing settlement IDs.
2. A per-shipping-bill detail — every SKU in the shipping bill, units shipped, units sold as of the reconciliation date, realized INR per SKU, contributing settlement IDs, refunds netted, non-order charges apportioned.
3. A bank credit trace — every bank credit in the reconciliation window, matched to a settlement, matched to a foreign-currency (if applicable) → INR conversion, matched forward to the shipping bills that received proceeds.

The bank's reconciliation team should be able to walk from any row in your bank statement to a specific shipping bill's realized-proceeds line without asking follow-up questions. If they can, you're done. If they can't, you have a rejection risk — see the 8 reasons AD Banks reject FBA closures for the common failure modes.

Where XPortKnock automates this

Everything in this post is what XPortKnock does automatically. Upload your invoices, upload your Amazon settlement reports (raw TXT from Seller Central), and upload your bank statement. The system runs SKU-level FIFO attribution across shipping bills, handles FX at the settlement level, apportions non-order charges pro-rata (or by direct-attribution when possible), quarantines reserved amounts as suspense, and generates a bank-ready data packet with all three sections above.

What used to take a competent CA a full weekend per settlement now takes a few minutes. And because the recomputation is idempotent, a late refund or a corrected shipping bill triggers a clean rebuild — not a spreadsheet-wide search-and-replace.

If you want to see this end-to-end, start a 14-day trial. No card required. Bring one recent settlement report, one bank credit that landed in the window, and the corresponding invoices. We'll show you a reconciliation packet the same day.

The short version

• Match settlement to bank credit using UTR + date + amount
• Group settlement rows by event category (order / refund / reserved / non-order)
• Attribute order events to shipping bills using SKU-level FIFO
• Apply FX at the settlement level, not per-order
• Apportion non-order charges pro-rata (or by direct-attribution)
• Treat reserved amounts as suspense, not proceeds
• Ship the bank a three-part packet: summary + per-bill detail + credit trace

Do all six steps for every settlement and you'll close shipping bills on the strength of the numbers, not on the strength of your bank relationship. Which is the whole point of EDPMS.