EDPMS

Why will my shipping bill not close in EDPMS, and how to fix it

The bill is filed, the money has arrived, the entry stays open. The causes in the order they occur, the check that isolates each, and who actually fixes it.

By Aaryan Kakani · · 15 min read

What has to be true before a bill can close?

EDPMS is a matching system, not a ledger you write to. It holds one record created from your shipping bill and one record created from each inward credit your Authorised Dealer bank receives, and it closes the first when the bank applies enough of the second against it. Nothing you do directly closes an entry. Your bank closes it, and it can only do so once three conditions hold at the same time.

  • The shipping bill exists in EDPMS. The record originates at customs and is transmitted to the system. If that transmission did not happen, there is nothing for your bank to close and no amount of correspondence with the bank will create it.
  • The export is recorded as having left. A filed shipping bill says goods were presented for export. The Export General Manifest, filed by the carrier after departure, is what records that they actually went.
  • An inward credit is available and applicable. The money must have arrived, must have been captured by your bank as an inward remittance record, and must be of a kind that can be applied against an export bill.

Every cause in this guide is one of those three conditions failing. That is why the diagnosis is worth doing in order: conditions one and two are settled at customs and by the carrier, condition three at your bank, and the two halves have no parties in common. An exporter who has not established which half they are in is writing to a party who cannot help.

Is the bill in EDPMS at all?

Ask this first, always. It costs one look at the pending report your bank can produce, and it splits the problem cleanly in two. If the shipping bill number does not appear, the entry cannot be closed because it does not exist, and the entire banking-side investigation (credits, IRMs, purpose codes, payers) is irrelevant until the record is created.

A bill missing from EDPMS is a transmission failure between the customs system and the monitoring system. The bill is real, it exists at ICEGATE, it has a number, and the exporter can see it on their own documents. Which is exactly why this cause is so often missed. Nothing in the exporter's own paperwork hints at it. The re-transmission is a defined request rather than a favour, and it is made to the customs side.

  • Where to look: the outstanding or pending shipping bill list your AD bank retrieves from EDPMS, searched by bill number rather than by scrolling for the buyer name.
  • What it settles: present means the break is on the banking side; absent means it is on the customs side, and the next step is a re-transmission request, not a letter to your bank.

The mechanics of getting a bill re-sent are covered separately in shipping bill re-transmission , and the wider behaviour of the customs portal in the ICEGATE guide .

Has the EGM been filed against the bill?

The Export General Manifest is filed by the shipping line or airline after the vessel or aircraft departs, and it is what converts a shipping bill from goods presented to goods exported. Until it is filed and matched to your bill, the export is incomplete in the customs record, and an incomplete export is not something the banking side can close against.

The operationally important point about this cause, and the reason it deserves its own place in the order, is who fixes it . You do not. Your bank does not. Your customs broker does not, except by chasing. The EGM is the carrier's filing, and an EGM error (unfiled, filed with a mismatched container or bill reference, filed against the wrong bill) is corrected by the carrier amending it. Exporters routinely lose weeks here by escalating with the wrong party, because every other cause on this list is fixed by somebody the exporter has a direct relationship with.

Has the bank created an IRM for the money?

This is where the exporter's certainty and the system's record diverge most sharply. An IRM (Inward Remittance Message) is your bank's structured record of one credit that arrived from abroad. Money can reach your account without one existing: the funds credit, your balance rises, your statement shows it, and the monitoring system knows nothing about it. Utilisation, the act of tying a bill to a credit, has nothing to draw on.

This happens most often where the credit did not arrive as a clean bank-to-bank transfer naming your export: consolidated payouts from a marketplace or a payment gateway, funds routed through an aggregator, or credits the bank booked under a domestic description because nothing on their face marked them as export proceeds. The remedy is to have the bank create the IRM against the underlying credit, evidenced with the settlement documentation showing the money came from abroad against your exports.

The three outcomes need three different people: no credit is a conversation with your buyer or platform; a credit with no IRM is a request to your bank with the settlement documents attached; and a credit with an IRM that still will not apply takes you to the next two sections. </> } />

Where an IRM does exist but the numbers will not reconcile against it, the arithmetic has its own guide: the over-utilised IRM .

Does the purpose code let the credit close an export?

Every inward remittance is booked against a purpose code describing what the money is for, and the code determines what the credit can be used for afterwards. A credit booked under a code that does not describe the export of goods cannot be applied to a goods shipping bill, however plainly the money is payment for that shipment. The entry stays open beside a correctly recorded credit of exactly the right amount, which makes this one of the most confusing causes to encounter and one of the easiest to fix once identified.

The code is assigned when the credit is booked, often from whatever the sender wrote in the payment reference, and neither the sender nor the exporter usually chose it deliberately. Marketplace and gateway settlements are the common offenders, because a consolidated payout does not describe itself as goods proceeds. The correction is a purpose code amendment made by the bank that booked the credit. A routine request, but one that has to name the correct code rather than ask the bank to work it out.

  • The check: read the purpose code on the IRM or the FIRA against what the shipment actually was. Goods, services, or a mixed order with both.
  • The fix: a purpose code amendment request to the booking bank, before you attempt utilisation rather than after, since an application made under the wrong code fails and has to be redone.

Which code applies to which kind of receipt, and the amendment procedure itself, are set out in RBI purpose codes , purpose codes for marketplace receipts and how to change a purpose code . Those pages carry the codes and their citations; this one deliberately does not restate them.

Did someone other than the buyer pay?

A bank matches an inward remittance to an export using the parties as well as the amount. When the name sending the money is not the name on your invoice, the credit may be perfectly genuine and still not attachable on its face. This is ordinary commercial reality rather than an irregularity: group treasuries pay for subsidiaries, purchasing agents pay for principals, marketplaces pay on behalf of the end customer, and freight forwarders occasionally settle for a consignee.

The remedy is documentary, and the distinction matters because exporters often try to fix this by amending something. There is nothing to amend. The credit is correct and the invoice is correct; what is missing is the evidence connecting the two. That is usually the buyer's written confirmation that the named entity paid on their behalf, together with the contract or purchase order naming the paying party, supplied to the bank as an attachment to the utilisation request.

An exporter ships to a buyer in Germany and invoices that buyer. The remittance arrives from the buyer's Netherlands-registered group treasury company, for the exact invoice amount, on time. The IRM is created, the purpose code is correct, the bill is in EDPMS and the EGM is filed. The entry will not close. </> } result= >

The diagnostic tell is that every quantitative check passes. Amount matches, date is sensible, code is right, balance is available. When the arithmetic is perfect and the entry still will not move, stop checking numbers and start checking names.

Is the realisation short, or only apparently short?

An amount arriving smaller than the invoice value is the most over-diagnosed cause on this list. Before treating it as short realisation, rebuild the deduction chain, because in the great majority of cases the gap is fees rather than a reduction in what the buyer owed.

  • Apparently short. Bank charges, correspondent-bank deductions, marketplace commissions, gateway fees, referral and fulfilment charges, currency conversion spreads. The buyer paid in full; intermediaries took their cut before the money reached you. The remedy is an explanation supported by the settlement statement showing each deduction.
  • Genuinely short. A negotiated discount, a quality claim, a short shipment, a rejected or returned consignment. What the buyer owed was reduced. The remedy depends on the size of the reduction and follows a defined route rather than an explanation.

The distinction decides which document pack you build, so it is worth settling before you write to anyone. Reconstructing a payout down to the individual shipment is covered in one payout, many shipping bills ; the case where the residue is structural rather than a shortfall at all is covered in utilisation running short on digital sales ; a short shipment against the filed bill is amended as described in short shipment amendment . Where the residual value is small, a simplified closure route exists and is set out with its citation in small-value EDPMS closure .

Is the entry already closed?

Worth thirty seconds before any of the work above. Pending reports are extracts taken at a moment in time, and an exporter working from a file downloaded weeks ago, or from a list the bank sent with a covering letter, can spend real effort investigating an entry that closed in the interim. Bank-side closure is not always notified to the exporter, so the absence of a confirmation is not evidence the entry is open.

  • Pull a fresh outstanding list before starting, not the one that prompted the question.
  • Check the bill number against the current extract rather than against your working file, which may carry rows the system no longer has.
  • Where you are working a batch, rebuild it against the fresh extract. Entries that closed since the batch was prepared will otherwise be submitted again and rejected.

In what order should I run these checks?

In the order below, because each check either resolves the question or eliminates a party, and running them out of order is what produces the three-week email threads. The ordering principle is cheapest and most decisive first: a check that splits the problem in half beats a check that confirms one hypothesis.

CheckWhat it rules outWho fixes it
Is the entry already closed?The whole investigationNobody. Done
Is the bill in EDPMS?Everything on the banking side, or everything on the customs sideCustoms, via re-transmission
Is the EGM filed and matched?A departure that never got recordedThe carrier, by amending
Is the credit in the statement?A matching problem. If absent, you are simply unpaidThe buyer or platform
Does an IRM exist for it?Money present, record absentThe AD bank, on evidence
Is the purpose code applicable?A correct credit that cannot be appliedThe booking bank, by amendment
Do the payer and the invoice match?A names problem masquerading as a numbers problemYou, with buyer confirmation
Is the gap fees or a genuine reduction?An explanation treated as a shortfallYou, with the settlement statement

Note what the third column does: four of the eight rows are fixed by somebody other than you and your bank. That is the practical value of running the list in order rather than opening with a letter to your relationship manager.

What do I send the bank?

Once the cause is identified, the closure request is a short document pack rather than an argument. Send the bank the chain, already assembled, so the reviewer can verify it rather than reconstruct it. A request that makes the reviewer do the reconstruction is a request that comes back with questions.

  • The shipping bill , with its number and date as they appear in EDPMS rather than as they appear on your copy.
  • The commercial invoice it was filed against, and the purchase order or contract where the payer question arises.
  • The credit. The FIRA or the bank advice for the inward remittance, with its reference and the purpose code visible.
  • The settlement statement where a marketplace or gateway sits in between, showing gross, each deduction, and the net that became the credit.
  • The arithmetic tying invoice to credit in one table, so the deduction chain is visible at a glance rather than implied across attachments.

Where the bank has written to you first asking why an export is unrealised, the reply has a conventional shape and its own guide: answering an export realisation pending letter . The documents each provider issues, and which of them your bank will accept, are compared in FIRA by payment provider .

What should I not do?

  • Do not open with a letter to your bank. Run the two customs-side checks first. Roughly half of stuck entries are not the bank's to fix, and the correspondence delay is pure loss.
  • Do not apply a credit under a purpose code you know is wrong in the hope it goes through. The application fails and has to be redone after the amendment anyway, having spent a cycle.
  • Do not write off a gap you have not reconstructed. Most gaps are fees. A write-off used as a rounding tool understates realisation and consumes a facility with real limits.
  • Do not let it sit because you have been paid. Being paid is not being closed, and the record that matters to your IEC is the one in EDPMS, not the one in your bank account.
  • Do not work from a stale extract. Rebuild against a fresh pending list, or you will investigate closed entries and resubmit rows the system has already retired.

What happens if entries accumulate unaddressed is set out in caution listing for marketplace sellers .

Which figures does this guide not state?

Deliberately, all of them. This page describes a matching chain and the order in which to test its links. Which is structural, verifiable against your own documents, and does not change when a circular is reissued. Every number that governs the surrounding obligations belongs to an instrument, and is left to the page that carries that instrument's citation.

If you arrived here wanting one of those numbers, follow the link rather than inferring it from anything on this page. A diagnosis that is right about the mechanism and wrong about a threshold is worse than no diagnosis, because it is actionable.

Frequently asked questions

Why does my shipping bill stay open in EDPMS when the money has already reached my account?

Because money reaching your account and money being matched to that bill are two different events, and only the second closes the entry. EDPMS holds one record per shipping bill and one record per inward credit, and the entry closes when your Authorised Dealer bank ties the second to the first. A credit that lands without anything identifying which shipment it pays is a credit the bank cannot attach, so the entry stays open next to a bank balance that has already gone up. This is the single most common reason an exporter is certain they have been paid while the system insists they have not: both are true, and the missing element is the link rather than the money.

How do I tell whether the problem is at customs or at my bank?

Look at whether the shipping bill appears in EDPMS at all. If the bill is not in the system, no bank action can close it and the break is on the customs side. Either the bill was never transmitted from ICEGATE to EDPMS, or the Export General Manifest has not been filed against it, so the export is not yet recorded as having departed. If the bill is in the system and shows an outstanding amount, the break is on the banking side: the credit has not arrived, has arrived without an IRM, or has an IRM that cannot be applied. Establishing which half you are in takes one look at the pending report and saves writing to the wrong party, which is how these cases lose weeks.

My buyer paid from a different company name than the one on my invoice. Does that block closure?

It can, and it is one of the harder causes to spot because nothing about the credit looks wrong. Banks match an inward remittance to an export by the parties as well as the amount, so a payment from a group treasury entity, a purchasing agent, a marketplace operator or a freight forwarder settling on the buyer's behalf may not be recognisable as payment for your invoice. The credit exists and the funds are yours, but the bank has no basis on its face for attaching it to that shipping bill. The remedy is documentary rather than corrective: you evidence the relationship between the payer and the buyer named on the invoice, usually with the buyer's written confirmation and the contract or purchase order naming the paying entity.

The amount realised is a little less than the invoice value. Will the bill ever close?

Usually yes, but first establish whether it is genuinely short or only apparently short, because the two have different remedies and the apparent case is far more common. Bank charges, correspondent-bank deductions, marketplace commissions and payment-gateway fees are all taken from the gross before the credit reaches you, so the amount arriving is expected to be smaller than the invoice and that gap is not a shortfall in the regulatory sense. Genuine short realisation is a reduction in what the buyer owed. A negotiated discount, a quality claim, a rejected consignment. Reconstruct the deduction chain from the settlement statement before treating anything as short: an apparent shortfall that resolves to fees needs an explanation to the bank, while a genuine one needs the route appropriate to its size.

Can I just ignore an open EDPMS entry if I have been paid?

No, and the cost of ignoring it arrives later and in a form that is harder to fix. An outstanding entry is the bank's record that an export has not been realised, and entries left open accumulate against your Importer Exporter Code: they drive the follow-up correspondence your bank is obliged to send, they can put the exporter on the caution list, and while the record shows unrealised exports they interfere with matters that have nothing to do with the shipment in question, including incentive claims and refunds that read the same data. An entry that is genuinely closeable is closed with a document pack you already hold, and the effort of doing it now is a fraction of the effort of doing it under a caution-listing notice.

Update history

  • First published.