A complete guide to EDPMS closure for Amazon FBA exporters in India

You made the sale. Amazon has settled the payment. The money has landed in your account.

Two weeks later, an email arrives from your bank: "Kindly note the following shipping bill is pending realization. Please submit reconciliation."

You look at your bank statement. You look at your Amazon settlement report. You look at the shipping bills your customs broker filed months ago. There is no obvious way to tell the bank which rupee in your account belongs to which shipping bill.

That is the EDPMS closure problem for FBA exporters. It's not that anyone is doing anything wrong. The Indian export monitoring system was designed for a world where one shipment equals one buyer equals one payment. Amazon Global Selling via the FBA model works nothing like that. And nobody in the chain — not the bank, not your CA, not the customs broker — actually understands the mismatch.

This is a long post. It has to be, because the topic is genuinely complex. But read to the end and you will understand exactly why EDPMS closure feels impossible when you sell FBA, and exactly what has to happen to actually close a shipping bill by the book.

What EDPMS is, and why it exists

EDPMS stands for Export Data Processing and Monitoring System. It's an RBI-run system that tracks whether Indian exporters actually bring back the foreign-exchange proceeds from every export they declare.

The logic is simple in its intent:

• You export goods. Customs generates a Shipping Bill.
• The Shipping Bill enters EDPMS as an open (unrealized) entry.
• You receive foreign payment. Your AD Bank closes the Shipping Bill against that payment in EDPMS.
• If you don't close within the RBI-mandated window — currently 9 months from date of shipment, extendable in specific cases — you enter the RBI caution list.
• Being on the caution list means no new export shipping bills can be filed under your IEC. Your export business freezes.

The system exists to prevent one specific thing: capital flight via fake exports. If you could declare an export on paper and never bring the money back, you could legally send rupees out of India under the cover of "goods shipped abroad." EDPMS forces every rupee to be traceable to a specific shipping bill, and every shipping bill to be traceable to received foreign exchange.

For roughly 90% of Indian exports — the traditional B2B world — EDPMS works fine. For the remaining 10% and growing — the marketplace-driven B2B2C world — it does not.

The world EDPMS was designed for: B2B

For a traditional B2B exporter, the EDPMS flow is clean. Here's how it looks:

1. Your buyer in Germany places an order for 500 units of your product.
2. You raise one commercial invoice for €50,000.
3. Your customs broker files one shipping bill referencing that invoice.
4. The container ships out.
5. Your buyer wires €50,000 to your Indian bank account, either in one shot or on an agreed tranche schedule.
6. Your bank receives the SWIFT credit. The invoice number appears in the message.
7. Bank closes the shipping bill against that payment in EDPMS. Done.

One invoice. One shipping bill. One payment. Clean 1:1 mapping. Your CA reconciles it in five minutes. Your bank closes it in ten. Everyone goes home.

This is the world every AD Bank reconciliation team, every CA, and every compliance software vendor was trained on. Most of them have never seen an export work any other way.

Enter the FBA model

Amazon Global Selling with Fulfilled by Amazon (FBA) is a completely different animal:

1. You ship (say) 500 units of your product to an Amazon warehouse in the USA.
2. Your customs broker files one shipping bill for that consignment.
3. Amazon receives the goods, verifies them, and lists them for sale.
4. Over the next six months, individual consumers in the destination country buy your product — one unit at a time.
5. Amazon groups those consumer sales into 14-day settlement periods.
6. At the end of each settlement period, Amazon adds up all units sold, subtracts a long list of fees, and wires the net to your Indian bank account. Every 14 days. For as long as inventory remains. Depending on how you have set up your Seller Central account, the credit can land in either INR (Amazon does the FX conversion at their rate before wiring) or in the destination marketplace's currency — USD, GBP, EUR, AUD, and so on — with your AD Bank doing the FX conversion at their rate on arrival. Some sellers deliberately opt to receive in destination currency to hold FX exposure and gain from currency arbitrage; either way, the EDPMS closure obligation is identical.
7. You get a bank credit that reads something like "AMAZON SERVICES — SETTLEMENT XXXXXX — USD nnn,nnn" with no reference to any invoice or shipping bill.

Here's the fee list Amazon subtracts at each settlement:

• Referral fees (~15% of consumer sale value)
• FBA fulfillment fees (pick, pack, ship)
• FBA storage fees (monthly + long-term)
• Advertising fees (Sponsored Products, Sponsored Brands)
• Chargebacks and refunds from consumer returns
• Currency conversion spread applied at settlement level (whether Amazon does it before wiring INR, or your AD Bank does it on arrival of a foreign-currency credit)

The net amount lands in your account — as INR if you have opted for that, or as destination-currency (USD / GBP / EUR / AUD) if you receive foreign inward remittance directly. Either way, there is no per-invoice or per-shipping-bill breakdown in the bank credit. Amazon has bundled 20+ transactions across potentially 10+ different shipping bills into one aggregate settlement, minus their fees.

And the payments never stop coming for that one shipping bill. As long as there is inventory from your original consignment sitting in the Amazon warehouse, every 14 days another partial payment lands. A single 500-unit shipment might generate 15 to 25 different partial settlement payments over six to nine months.

Why the mapping breaks

Here's the specific place where B2B logic breaks down:

Your bank cannot tell which rupee of your credit corresponds to which shipping bill. Neither can you, without a system that tracks every unit sold and rolls it up to the original shipment.

This is the core problem. It is not small. For an active FBA seller, there could be 50 or more open shipping bills at any moment, and every settlement adds partial closures to a rolling subset of them.

The parties involved — and why none of them understand

Every EDPMS closure discussion for an FBA exporter involves multiple parties. Understanding why each one struggles is critical to understanding why the system stays broken.

The exporter — you

You know what you shipped, you can feel the weight of every "shipping bill pending" reminder, and you can see the money hitting your bank account. What you don't have is the tooling to slice Amazon's settlement report by original consignment. You spend your evenings in Excel trying, and it never quite adds up.

Amazon Global Selling

Amazon's system is world-class at running the marketplace and processing consumer transactions. It is not designed to produce EDPMS-compliant reconciliation reports for Indian AD Banks.

Amazon gives you a settlement report grouped by 14-day period. It gives you a transaction report showing individual consumer orders with fees itemized. It does not give you a "here's which shipping bill this payment closes" report — because from Amazon's perspective, shipping bills are your problem, not theirs.

Your AD Bank

Your Authorised Dealer Bank is trained on B2B closure patterns. Ninety percent of the export credits they process fit the one-invoice-one-payment model. When your FBA settlement credit lands, the bank's system flags it as "payment received, please match to shipping bill."

Your bank's relationship manager knows exports as they were taught. SWIFT messages, buyer references, letter-of-credit patterns. They do not — cannot — understand:

• Why the payment doesn't match any single invoice value
• Why the same shipping bill takes 15 payments to close
• Why the FX doesn't reconcile at line-item level
• Why Amazon's fees are deducted at settlement, not per-invoice
• Why a single settlement credit maps to 20+ different shipping bills

Their instruction to you: "Sir, please provide reconciliation showing which shipping bill each rupee closes."

That is a request for information that does not exist in any single place. You have to construct it. And the construction requires software that nobody in the chain has built.

Your CA or tax consultant

Your CA is trained in Indian accounting standards (Ind-AS / GAAP). They book revenue at invoice-raise time. In their mental model, revenue equals invoice value.

But Amazon recognizes revenue at unit-sale time, not invoice-raise time. And it releases funds to you at settlement-period time, not unit-sale time. Three completely different clocks, none of which align with Indian accounting convention.

Faced with the FBA reconciliation problem, most CAs will suggest one of a small set of workarounds. Every one is widely used. Every one is technically non-compliant. And every one is what the entire Indian FBA industry currently runs on because there is no genuinely correct manual option.

Your customs broker

Your customs broker's job ends when the shipping bill is filed and the container leaves the port. They can help you look up shipping bill status in ICEGATE. They know EDPMS closure exists. They don't touch payment reconciliation. Not their scope, not their skill.

ICEGATE, DGFT, and RBI — the government stack

• ICEGATE is where all your shipping bills live. Customs electronic gateway. Data flows into EDPMS. Your CA logs in to see the status of each shipping bill: open / part-closed / closed. ICEGATE knows nothing about payments.
• DGFT (Directorate General of Foreign Trade) issues your IEC. If your shipping bills stay unrealized past the RBI window, RBI notifies DGFT and DGFT enforces the caution list.
• RBI runs EDPMS, sets the rules, and monitors realization patterns. RBI is technically the only party that can rewrite the rules to explicitly accommodate FBA — and while it has partially done so (see below), the tooling gap on the bank side has not caught up.

The workarounds Indian FBA exporters actually use — and why none of them hold up

The Indian FBA industry currently runs on one of three workarounds. Every one exists because the reconciliation is genuinely intractable by hand. Every one is legally shaky. And every CA who suggests them is doing so not out of ignorance but out of a lack of any better option.

Workaround 1: Under-invoicing to a "guesstimated" net

The most widely-recommended workaround. The CA tells the exporter: don't raise the commercial invoice at the full expected export value. Raise it at whatever amount is supposed to eventually land in the bank account after Amazon has taken all its deductions. On paper, this makes the reconciliation "match" — the invoice value approximates the settlement value, the bank sees a clean incoming credit, closure gets stamped.

The problem is right there in the word supposed. Nobody — not the exporter, not the CA, not the Amazon account manager, not a single soul on this planet — can accurately predict what Amazon will actually pay out for a given consignment. Every one of the following is variable, and every one of them only becomes knowable after the fact:

• Amazon's commission structure can change mid-cycle. Category-level fee revisions, rebate programs, promotional adjustments — none announced with enough lead time to reprice an in-flight invoice.
• Fulfillment cost varies with delivery distance. A unit that ships from a New York FBA warehouse to a New York buyer costs Amazon less to fulfill than the same unit going from New York to San Francisco. That cost delta hits your settlement. You didn't know at invoice-raise time which buyer would place the order or where they lived.
• Advertising deductions are campaign-driven, not unit-driven. Sponsored Products or Sponsored Brands spend for one campaign can wipe out the "expected" margin on a batch of units. Different consignments carry different ad loads at different times.
• Storage fees compound with slow-moving inventory. Long-term storage fees can turn a profitable unit into a break-even one. You don't know inventory velocity at invoice-raise time.
• Amazon holds a reserved amount. Marketplaces retain a rolling reserve to cover potential refunds and chargebacks. This delays and reshapes what actually settles per period, and the reserve itself changes without notice.
• Chargebacks and returns are stochastic. You can model them; you cannot predict them for any specific batch of goods.
• Non-order charges get deducted from the same settlement pot. Monthly Seller Central subscription. Long-term storage fees applied on a fixed monthly date. Standalone advertising invoices. These are account-level charges — not per-unit, not per-invoice — but Amazon deducts them from the same settlement that pays you for unit sales. How is a seller supposed to apportion "₹2,500 of last month's ad spend" or "the Seller Central monthly subscription" across 12 different in-flight shipping bills? There is no defensible manual answer, because there is no one-to-one link between those charges and specific goods.

The consequence: any invoice value raised on a "supposed to be received" basis is a guess. It will always end up either too high (bank sees unrealized proceeds and starts asking questions) or too low (bank sees "excess" credit that doesn't match any invoice — even more awkward to explain, and just as unresolvable). The exporter and the CA then spend the rest of the quarter making informal "adjustments" to force the numbers together, which is exactly the kind of pattern that FEMA audits and income-tax scrutinies single out.

And on top of the practical mess, under-invoicing at any layer:

• Misrepresents the actual export value → violates FEMA export-valuation norms
• Creates GST / customs valuation exposure → customs can reassess with penalties on the basis that the declared value is below arm's-length
• Short-changes RBI's realization tracking → the actual foreign exchange being generated is more than what EDPMS ends up recording
• Undermines any future dispute — with Amazon, with insurance, with buyers — because your legal record of what was exported no longer reflects reality

Workaround 2: FIFO knock-off at shipping-bill level

The bank (or the CA, on the bank's behalf) sees each settlement credit land and knocks off the oldest open shipping bill first, up to that credit's value. Then moves to the next-oldest. Repeat.

On the surface, it works. Shipping bills eventually close. Bank reminders stop.

It is not real reconciliation. The payment that just landed had nothing to do with the goods in the oldest shipping bill — those goods may still be sitting in Amazon's warehouse, three months from being sold. FIFO chronology of payments is not the same as attribution of proceeds.

And FIFO at the shipping-bill level is the easy version. The genuinely correct method is FIFO at the SKU level — for every SKU, track which units in which shipping bill sold first (based on Amazon's actual sell-through order), then attribute each unit-of-sale's realized proceeds back to that specific shipping bill.

Try to picture doing this by hand:

• Every settlement report has thousands of rows — one per consumer order, with SKU, quantity, price, fees, currency, timestamp
• Every shipping bill contains tens of SKUs, each with a specific unit count
• SKU-level FIFO requires a running ledger — "SKU X has 500 units across shipping bills SB/1, SB/2, SB/3. Amazon just sold 27 of them at these prices. Which shipping bill's inventory did the 27 come from? Now update the ledger. Now move to the next SKU."
• Repeat this thousands of times per settlement, dozens of settlements per year, across your full SKU catalog
• Now apportion Amazon's non-order deductions (subscription, cross-SKU advertising, long-term storage) across shipping bills using some documented method
• Now reconcile every bank credit — INR or foreign currency, including partial credits, cancelled credits, and FX-converted credits — back to a specific rolled-up realized-per-shipping-bill number
• Now generate a bank-facing packet showing all of this line by line, with amounts that reconcile top-to-bottom

A single seller cannot do this by hand in any realistic amount of time. Not for one settlement, and certainly not for a rolling year's worth of them. The rare few who genuinely try burn full weekends every fortnight and still submit reconciliations the bank has to re-question. SKU-level FIFO done properly is a nightmare. It is the correct method. It is also the reason every seller who tries it drops back to shipping-bill-level FIFO or under-invoicing — because doing the right thing by hand simply cannot happen at any real trading volume.

This is exactly why XPortKnock exists. Not because we thought "reconciliation software would be nice." Because a founder who exports on Amazon FBA burned hands on this system, month after month, for years — until it became unmissable that the correct behavior is implementable in software, and that no software vendor had built it.

XPortKnock does SKU-level FIFO attribution across shipping bills automatically. It reconciles every settlement event to a specific invoice line. It apportions non-order Amazon charges using a documented, defensible method. It maps every bank credit — INR or destination-marketplace currency — to a specific set of settlement events, and rolls them up per shipping bill. What used to burn a weekend now takes a few clicks. The output is a data packet you can hand your bank without a follow-up email.

There is one more thing no CA will tell you: once the mapping is done accurately, the "deficit / excess" per shipping bill becomes visible for the first time. You can see which shipments actually made money after all Amazon costs, and which quietly bled you. This changes how you buy inventory, how you price, and how you negotiate with Amazon. The reconciliation stops being only a compliance chore. Done properly, it becomes the sharpest management-accounting tool an FBA exporter can have.

Workaround 3: Deferring and paying penalties

Some exporters simply don't close within the 9-month window, accept the caution-list trigger, negotiate extensions, pay penalties, and eventually get their IEC restored. This is the most common outcome for exporters who tried the first two workarounds and gave up.

The paperwork conversation that actually happens

If you're a new FBA exporter, this is how your first EDPMS conversation with the bank plays out. Almost word for word.

Bank: "Sir, your shipping bill SB/2024/00XXX dated 15-Jan is pending closure. It's been eight months. Please submit reconciliation."

You: "Amazon has sent me payments. I have the credits in my account."

Bank: "Which payment closes this shipping bill?"

You: "It's not one payment. It's parts of multiple settlement credits, spread over six months."

Bank: (long pause) "Sir, that's not how it works. Please give us a statement showing which payment closes this shipping bill."

You: "But every settlement credit is a mix of proceeds from 30+ shipping bills, minus Amazon's fees, converted to INR at Amazon's FX rate. There's no clean way to say 'this specific rupee belongs to this specific shipping bill.'"

Bank: (longer pause) "Please provide an Excel with the mapping."

You then spend three weekends in Excel. You email the Excel. The bank replies:

Bank: "This total doesn't add up. Amazon's fees are missing. Please redo."

Repeat.

This is the reconciliation loop every FBA exporter enters. It is why every FBA exporter eventually gives up on doing the reconciliation properly and adopts one of the workarounds above. Not because they want to be non-compliant, but because compliance is genuinely intractable without the right tooling.

What RBI has already done — and what still needs to happen

RBI is aware the world has changed. Since 2015, RBI has explicitly permitted:

• Multiple realizations against one shipping bill. You can close a single shipping bill against 20+ separate payments. The old five-realization ceiling is gone for legitimate cases.
• Partial closures. You do not have to close a shipping bill in one shot.
• Deferred payment arrangements are recognized for cross-border business models.
• Netting of certain fees against export proceeds is permitted with adequate documentation.

The rules technically accommodate FBA. What doesn't accommodate FBA is the tooling: your bank's software, your CA's software, the compliance workflow. All of it still assumes B2B patterns because the people who built it were trained on B2B.

What actually needs to happen for a clean, defensible closure

To close an FBA shipping bill by the book, you need to answer, for each shipping bill:

1. Which specific units in this shipping bill were sold, in which settlement period, at what consumer sale price, minus which Amazon fees?
2. What was the INR realization for each of those units, applying the specific FX rate Amazon used for that settlement?
3. Roll all those unit-level realizations up. This is the total realized INR for this shipping bill.
4. Match those rupees back to your bank credits — which credits, in which order, contain the rolled-up realizations for this specific shipping bill.
5. When the sum of realized proceeds equals the shipping bill's invoice value (or exceeds it, net of Amazon's fees and FX), the shipping bill can be marked closed in EDPMS with a full audit trail.

Every step above requires data from a different source:

• Shipping bill data → ICEGATE / your customs broker
• Invoice-to-shipping-bill mapping → your own records
• Unit-level sales data → Amazon Seller Central transaction reports
• Settlement-level payment data → Amazon Global Selling settlement reports
• Bank credits → your bank statement
• FX rates and Amazon fees → embedded in the settlement report per settlement

All of it has to reconcile end to end, with a defensible audit trail. Without a tool that ingests every source and rolls them up, this is not a task a human can do in Excel at scale. It's not that it's hard. It's that the sheer number of line items — for an FBA seller doing a few hundred consumer orders a day, that's thousands of transaction rows per settlement — makes manual reconciliation genuinely intractable.

Where this is all going

Indian FBA exporters number in the tens of thousands and growing. Amazon Global Selling is one of the fastest-growing export channels for Indian D2C brands. Every one of these exporters faces the EDPMS-closure problem we've described here.

Three things need to change:

1. Software. Someone has to build the reconciliation layer that maps Amazon's settlement events back to original shipping bills, unit by unit. This is what XPortKnock does.
2. Bank awareness. AD Bank teams have to learn how FBA settlements actually work, so the conversation isn't a 20-round Excel exchange. This will happen slowly as more exporters push back with well-prepared reconciliation packets and force the industry to catch up.
3. RBI clarification. The rules technically permit FBA closure patterns, but explicit RBI guidance for the marketplace model — with worked examples — would end the interpretation gap. This has been raised at industry forums; it takes time.

None of these three change overnight. But the growing FBA exporter base is going to force all of them.

The bottom line

If you're an Indian exporter selling on Amazon Global Selling via FBA, here's the short version:

• EDPMS closure isn't optional. Miss the window and you're caution-listed. Caution-listed means no new exports can be filed under your IEC. Business freeze.
• Traditional B2B reconciliation logic doesn't apply. Don't let your CA under-invoice or FIFO your way through it — both workarounds are technically non-compliant and both will blow up in an audit.
• You need to do the actual unit-level mapping. It's intractable in Excel. It is perfectly tractable in software.
• The paperwork conversation with your bank will get easier as your bank's team learns the FBA pattern — and faster if you walk in with the reconciliation already complete and defensible.

XPortKnock exists to do this reconciliation for you. Upload your invoices. Upload your Amazon settlement reports. Get a clean, bank-ready data packet mapped shipment by shipment, unit by unit, settlement by settlement. See how it works or start a 14-day trial.

Or don't — but at least you now know why the current system is failing you, and what to ask your CA and your bank to look at next.