The 8 reasons AD Banks reject FBA EDPMS closures — and how to fix each one

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

When your AD Bank rejects an EDPMS reconciliation, the rejection notice rarely explains the root cause. You get a curt line — "figures do not tally, please resubmit" — and a follow-up email that repeats the same words. The actual failure is one of a small set of patterns, and once you learn to recognize them, you can pre-empt most of them before submitting.

This post enumerates the eight most common rejection reasons for FBA sellers and gives the specific fix for each. For the underlying reconciliation methodology this all sits on top of, read how to reconcile Amazon settlements with your bank credits.

Figure 1: The eight rejection patterns group into arithmetic, structural, and documentary categories.

1. The realized value doesn't tally to the FOB value

What the bank says: "Realization value INR X does not match shipping bill FOB value INR Y. Please clarify."

What's actually happening: For an FBA shipment, realized proceeds will always be lower than the FOB value declared at customs. Amazon deducts referral fees (typically 15%), fulfillment fees, storage fees, and advertising costs before wiring you the net. The FBA seller's realized foreign exchange, after all Amazon deductions, is typically 60-75% of FOB.

The bank's system flags any realization below 100% of FOB. For traditional B2B, this flag is legitimate. For FBA, it's a false positive.

The fix:

Educate the bank up-front, in writing, with an explanatory annexure that shows Amazon's fee structure and the expected realization range as a percentage of FOB
Cite RBI's post-2015 clarification that recognizes "netted proceeds" for marketplace-based exports
File a "part realization + write-off" application if the shortfall exceeds RBI's tolerance for small differences (currently 5% or USD 25,000, whichever is lower)

The write-off pathway is the correct legal instrument for the Amazon fee gap. Most banks accept it once the pattern is documented.

2. FX rate mismatch forced into the reconciliation

What the bank says: "Amount in bank credit does not match settlement value at RBI reference rate."

What's actually happening: The bank's system computes an expected INR value by applying the RBI reference rate to the settlement's foreign-currency amount. Your actual bank credit is at either Amazon's internal rate (if Amazon converted) or your bank's own conversion rate (if you received foreign currency directly). Both differ from the RBI reference rate.

The fix:

Use the actual conversion rate — Amazon's or your bank's — in your reconciliation
Book the gap between actual and reference as an FX conversion gain/loss line, clearly labelled, in a separate section of your packet
Do not try to force the numbers to match a hypothetical rate — the bank's own credit narration is the source of truth for INR realization

If your bank insists on the RBI reference rate, that is a legitimate compliance position — but the gap still gets booked as FX gain/loss, not eliminated.

3. Reserved amount treated as realized proceeds

What the bank says: "Realization value exceeds actual bank credit. Please reconcile."

What's actually happening: You added Amazon's Reserved Amount to your realized-proceeds column. But Reserved Amount is money Amazon withheld — it has not landed at your bank yet. Booking it as realized inflates your total by 5-10% and creates an unexplainable gap.

The fix:

Move Reserved Amount to a suspense line in your reconciliation, not the realization line
When the reserved amount is released in a later settlement, book that row as realized (not the original reservation row)
Show both rows in your packet — reservation and release — so the auditor can trace the flow

This is one of the most common rejections and one of the easiest to fix. See the anatomy of an Amazon settlement report for how to identify reserved-amount rows in the raw data.

4. Wrong shipping bill referenced (FIFO by payment date)

What the bank says: "Realization value against Shipping Bill SB/XXXXX does not correspond to the goods declared in that bill."

What's actually happening: You (or your CA) knocked off the oldest open shipping bill first, based on payment date, rather than doing SKU-level attribution. On a random pull audit, the bank's team compared your realization narrative against the actual goods in SB/XXXXX and found the units that "generated" the payment weren't even from that shipping bill.

The fix:

Do SKU-level FIFO attribution across shipping bills — for every order in the settlement, deduct the sold units from the oldest shipping bill that still has stock of that SKU
Rebuild your reconciliation from raw Amazon transaction data (order-level, not settlement-summary-level)
If you don't have the tooling for this, use XPortKnock or a comparable reconciliation engine — this is the reconciliation approach the bank actually needs, and it cannot be done in Excel at any real trading volume

Payment-date FIFO is the fastest way to a rejection once your bank starts sampling. It also violates the spirit of EDPMS, even if the arithmetic tallies at the top level.

5. Non-order charges lumped in without an apportionment method

What the bank says: "Deductions totalling INR X applied to Shipping Bill SB/XXXXX cannot be linked to the export."

What's actually happening: You subtracted Amazon's monthly Seller Central subscription, cross-SKU ads, and storage fees from a specific shipping bill's realization without explaining how those charges were apportioned. The bank sees an unexplained deduction and rejects.

The fix:

Choose an apportionment method — pro-rata by settlement contribution is the most defensible
Document the method in a one-paragraph note at the top of your reconciliation packet
Show the apportionment math for each shipping bill affected (a small table is enough)

Auditors are not looking for perfection — they're looking for a defensible, consistently applied method. Any of pro-rata, activity-based, or direct-attribution works as long as you apply it consistently across all reconciliations.

6. Multiple realizations not filed correctly on the bank side

What the bank says: "Shipping Bill SB/XXXXX has three prior realizations. This is the fourth. Please provide consolidated realization certificate."

What's actually happening: Your AD Bank has been recording each realization separately in EDPMS, but their internal system requires a consolidated realization certificate after N partial realizations. Some banks cap at 5, some at 10, some have no cap. The RBI framework has permitted unlimited partial realizations since 2015 — but many bank IT systems have not caught up.

The fix:

Ask your AD Bank's relationship manager for a consolidated eBRC / consolidated EDPMS closure statement rather than N individual ones
If the bank refuses, cite RBI Master Direction on Export of Goods and Services and specifically the FED Master Direction paragraph permitting unlimited partial realizations for legitimate export patterns
Escalate to the bank's Trade Finance operations team, not the branch — this is a system limitation, not a compliance question

7. UTR trace missing from the packet

What the bank says: "Bank credit reference not linked to declared settlement."

What's actually happening: Your reconciliation packet has the settlement details and the invoice details but not the bank credit UTR that ties them together. The bank team cannot verify that the money you're claiming as realized actually landed in your account.

The fix:

For every settlement in the packet, include the corresponding bank credit's UTR, date, sender name, and amount
If the same settlement was split across multiple credits, list all of them
For foreign-currency inward remittance where the UTR reference is generated at the correspondent bank, include the nostro reference as well

The UTR trace is often the shortest section of the packet and the one most frequently missing. Make it a checklist item.

8. Underlying settlement report not attached

What the bank says: "Executive summary received. Please provide supporting settlement documentation."

What's actually happening: You handed the bank a clean per-shipping-bill summary — which is the top layer of the packet — but not the raw Amazon settlement TXT files or the invoice PDFs. The bank cannot audit your arithmetic without the source data.

The fix:

Package the raw Amazon settlement TXT files (one per settlement in the reconciliation window) alongside the executive summary
Include the corresponding customs invoice PDFs
If the total data set is large, use a zipped folder or a shared drive link (banks vary on how they prefer to receive supporting docs)

A complete packet is: executive summary + per-shipping-bill detail + UTR trace + raw settlement files + invoice PDFs. Missing any of these five layers is a rejection risk.

The bigger point

Every rejection reason above traces to one of two root causes: either the reconciliation method is wrong (FIFO by payment, reserved-amount counting, non-order-charge lumping) or the packet is incomplete (missing UTR trace, missing raw files, missing apportionment note).

Method issues are fixed by adopting the correct reconciliation approach — see how to reconcile Amazon settlements.

Packet issues are fixed by using a checklist. Ours:

Executive summary (one page per SB)
Per-SB detail (SKU-level attribution)
UTR trace (every credit to every settlement)
Raw Amazon settlement files (all in the window)
Invoice PDFs (all referenced SBs)
Apportionment method note (one paragraph)
FX gap disclosure (booked as gain/loss, not eliminated)
Reserved-amount suspense reconciliation (open vs released)

Meet all eight and rejections drop to near zero. Miss any and the pattern repeats.

Where XPortKnock helps

XPortKnock produces a bank-ready packet that satisfies all eight checklist items automatically. SKU-level FIFO, reserved-amount handling, apportionment with documented method, FX gap disclosed cleanly, UTR trace attached — all generated in one export from the source data. What used to be a rejection loop becomes a one-shot submission.

If you want to see the packet output on your own data, start a 14-day trial and bring one settlement. We'll show you the fully-formed packet the same day.