My bank says the IRM is over-utilised. What do I do now?

What does over-utilised actually mean?

An IRM (an Inward Remittance Message) is your Authorised Dealer bank's record of one inward credit that reached your account from abroad. It carries a reference, a currency, an amount, a remittance date and a purpose. It is a record of money, not of a shipment, and on its own it settles nothing.

Utilisation is the act of tying that credit to a specific export. You tell the bank that a stated portion of a stated IRM is the realisation of a stated shipping bill, and the bank marks it against the bill in EDPMS. Once enough utilisation has been marked against a bill to account for its declared value, the bill can close. That is the whole mechanism: bills are closed by allocating credits to them, one linkage at a time.

Over-utilisation is the failure of the one constraint that governs the exercise:

For every IRM: sum of all utilisation marked against it, across every batch ever submitted, must not exceed that IRM's outstanding balance.

When your bank returns a file saying an IRM is over-utilised, it has evaluated that sum against its own record of the credit and found your side larger. Nothing about your export has been questioned. No view has been taken on whether the goods left, on whether the buyer paid, or on whether the pricing was right. One number in your file exceeds one number in the bank's, and the task is to find out which of the two is wrong and why.

It is almost always yours, and that is good news, because a defect in an allocation file is corrected in an afternoon. The causes below are ordered by how often they turn out to be the answer, so working down the list in order is the fastest route to the one that applies to you.

Why is there no tolerance in the over direction?

Because the two directions are not symmetrical, even though a spreadsheet treats them as though they were.

An IRM that is under -utilised is in an entirely ordinary state. It means part of a credit has not yet been allocated to a bill. Usually because the shipments it relates to are still to be submitted, sometimes because it covers a period that straddles two batches. The unallocated balance sits there and remains available. Nothing is wrong, nothing needs explaining, and in a healthy ledger a good number of IRMs are in exactly this condition at any moment.

An IRM that is over -utilised is a different kind of statement. Every unit above the outstanding balance is an assertion that the remittance contained money it did not contain. The bank cannot accept it, not as a matter of strictness but because it has no record to post it against. There is no pool of funds behind the ceiling to draw on.

The practical consequence is a rule of thumb for every allocation you build: when a figure cannot be made to land exactly, land it short . A residue left on an IRM is recoverable in the next batch. An overage is not recoverable at all. It is a rejection.

Did I draw from the outstanding balance or from the gross amount?

This is the first thing to check and, in practice, the answer more often than every other cause combined.

An EDPMS pending report gives you more than one amount per IRM. One is the gross value of the credit as it arrived. The total amount received. Another is the portion still available to be allocated against bills, after everything previously submitted has been deducted. These are different numbers with similar labels, sitting in adjacent columns, and the wrong one is very easy to pick up. The exact captions differ between banks and between report versions, so identify the two by what they do rather than by the words above them.

The reason this cause is so persistent is that it hides itself perfectly on a first submission. On a first batch nothing has been consumed yet, so gross and outstanding are the same figure and a file built from either passes. Nothing tells you the method is wrong. It only becomes visible from the second batch onward, at which point it looks like a new problem that has just appeared. And it is instead a method that was wrong from the beginning and has only now had something to be wrong about.

If you are investigating your first ever over-utilisation and the exporter has submitted before, start here and expect to find it.

Did an earlier batch already consume part of this IRM?

This is the same failure approached from the other side, and it catches people who are using the right column but a stale copy of it.

An outstanding balance is only correct as at the moment the report was generated. If you downloaded a pending report, submitted a batch from it, and then built the next batch from the same download, every balance in your working file is overstated by exactly what the first batch consumed. The arithmetic inside your file is flawless. It is measured against a ceiling that has since come down.

Two habits remove this permanently:

• Re-download the pending report at the start of every batch, and build from that download only. Never carry balances forward from a previous working file, however recent. The download is the only figure the bank will agree with.
• Keep a running IRM utilisation ledger of your own, separate from the submission file. One row per IRM, showing opening balance, what earlier batches consumed, what this batch draws, and the closing balance. It is what lets you catch a double-spend before the bank does, and it is also the attachment that settles a dispute later. See section 9.
• Exclude bills that have already been submitted, not just IRMs that have already been consumed. A resubmitted bill draws a second time against a credit that already paid for it once, which produces an over-utilisation whose cause looks like it is on the IRM side when it is on the bill side.

Is the overage an FX rounding artefact?

If the amount by which the IRM is over is very small relative to the credit (a unit or two in the last decimal place) you are probably looking at a conversion that could not land exactly rather than a real error of allocation.

This happens whenever a value has to be expressed at a precision the rate cannot reach. A conversion carried at two decimal places will sometimes land a fraction either side of the figure you are trying to match, and if it lands on the high side, the allocation exceeds the balance by that fraction and the row rejects. The overage is meaningless in substance and fatal in processing.

The remedy is the rule from section 2 applied at the last decimal place: when the conversion cannot land exactly, clamp it downward. A residue a fraction short of the balance is safe and is picked up in a later batch. A fraction over is an outright rejection of the row. The asymmetry in the constraint has to be reproduced in the rounding.

Did one credit arrive as several rows. Or did one bill?

Two different shapes produce over-utilisation, they look alike in a spreadsheet, and they are routinely confused with each other and with genuine duplication. Separating them is worth doing carefully because the remedies are opposite.

One credit, fragmented across several rows

A single bank credit sometimes appears in a gateway or bank export as two or three rows carrying the same reference with differing partial amounts. This is one remittance presented in pieces, not several remittances. Treat it as one IRM at the single true bank-sourced amount. Not as the sum of the fragments, and not as multiple partial rows each available to be drawn on.

Get this wrong in the direction of keeping the fragments and you create phantom capacity: three rows each look like a credit you can allocate against, so bills get tied to all three, and the total drawn is a multiple of the money that actually arrived.

Note the contrast with a genuine repeat. A reference appearing more than once is entirely legitimate when one remittance covers several bills. That is the ordinary case and nothing needs collapsing. It is a defect only when the amount and date repeat in a way that double-counts the same credit.

One bill, split across several IRMs

The mirror image, and the more expensive of the two. When a bill is large enough to need more than one credit to fill it, it appears on several rows. One per IRM it draws from. On every one of those rows the bill value is the same figure, because the bill value is a property of the bill and does not change according to which credit is paying for it. What differs per row is the utilisation: the portion being drawn from that particular IRM.

Put the bill value into the utilisation column of every row and you have drawn the whole bill from each IRM separately. The file over-utilises by a multiple, and because each row looks individually sensible, nothing about it reads as wrong until the bank sums by IRM.

The discipline that follows from this is to tie out at bill level and never at row level , and to sum every one of a bill's rows before accepting any shortfall flag against it. Reviewers on both sides flag individual line items without summing them first, and a severe apparent shortfall that sits exactly on an IRM boundary is far more often a missing continuation row than a missing payment.

Am I sure it is even the right shipping bill?

An over-utilisation can be caused by a bill that should never have been on the IRM at all, and the usual route in is matching on the bill number alone.

Shipping bill numbers are reused across unrelated shipments. Matching on the number by itself (and especially on a truncated form of it, such as the last few digits, which collides constantly) will happily attach a credit to a shipment it has nothing to do with. The allocation then sits against the wrong bill, the right bill stays open, and the IRM is drawn down for a shipment that was already accounted for elsewhere.

• Match on bill number together with bill date and bill value, never on the number alone. Three fields agreeing is a match; one field agreeing is a coincidence waiting to happen.
• Normalise both sides before comparing where the formats differ. Where one system zero-pads the number and the other does not, reduce both to the same form before matching, or identical bills will read as different ones and different bills as identical.
• Add a same-party check where the same bill could appear in two channels' files. A bill paid partly through one gateway and partly through another appears in both exports. Each file read on its own shows a false under-utilisation for the other channel's share, and correcting that apparent shortfall by drawing more is how the over-utilisation is created.

Does this IRM still exist?

An IRM that appeared on an earlier pending list may simply not be on the current one. It has been fully consumed and closed in the period between your two downloads. Any allocation you have built against it is void rather than merely too large, and rebuilding from a fresh download is the only remedy.

This is worth checking explicitly rather than assuming, because the proportion of a working list that has gone stale can be much higher than intuition suggests when a gap of some weeks separates the two downloads. It also presents confusingly: to the exporter it looks like an over-utilisation, because both conditions produce an allocation the bank will not accept, but the fix is different. An over-utilisation is corrected by reducing the draw. A vanished IRM cannot be reduced into existence. The bill has to be tied to a credit that is actually available.

There is a related constraint that no amount of arithmetic will solve, and it is worth knowing before you spend an afternoon trying: an IRM issued through one AD bank cannot be linked against a bill under a different bank's arrangements. If the money arrived at a bank other than the one holding the bill, the answer is not a better allocation. It is a conversation with both banks about where the export is to be closed.

In the great majority of cases one of the first three steps ends the investigation, and the remedy is to rebuild the batch from a fresh pending report using the outstanding balance column. Work them in order rather than starting with the interesting ones. </> } />

An exporter receives a single remittance of

USD 40,000

covering several shipments. In their first batch they allocate two bills against it. Six weeks later they build a second batch from the same saved copy of the pending report and add a third bill. The bank rejects the second batch for over-utilisation. All figures below are invented for illustration. </> } result={ <> The second batch drew

USD 4,000

more than existed. Nothing was wrong with the third bill or with the money. The batch was measured against a ceiling that had already come down by USD 27,000. Rebuilding from a fresh pending report gives an outstanding balance of USD 13,000, and the third bill is allocated USD 13,000 with USD 3,000 of it left open for a later credit. </> } >

The exporter built Bill C's allocation against the USD 40,000 gross figure they still had on screen, saw that 15,000 plus 12,000 plus 17,000 came to 44,000, assumed the excess was a fee difference, and submitted. The number that mattered was not on that screen.

How do I prove the balance back to the bank?

With one attachment that shows the arithmetic, rather than an email asserting a conclusion. The exchange that takes three rounds is the one where each side states a figure; the exchange that takes one is the one where you show how your figure was reached, so the reviewer can see immediately which line they disagree with.

Build an IRM utilisation status view. One row per contested IRM, with the movement laid out left to right:

Alongside it, attach the bill-level tie-out for any bill that is split across IRMs: the bill, its value, each row's utilisation, and the sum. That is the document that answers a line-item shortfall flag without an argument, because it shows the missing amount is on another row rather than missing.

Where the correspondence needs a formal letter rather than a working, the bank regulatory deviation letter and the export realisation pending letter cover the formats banks expect.

What if the draw is genuinely more than I have?

Sometimes none of the causes above applies. The file is right, the report is fresh, the matching is sound, and the bills you need to close really do require more than the credits you hold. At that point the over-utilisation has done its job: it has told you that you have a genuine gap, and the question changes from arithmetic to what to do about a shortfall.

The options, in the order worth trying them:

• Reallocate unused balance sitting inside IRMs you already hold. This is the first move and the one most often skipped. Closing a gap from an existing unallocated balance is a valid route and it is far quicker than having new IRMs created. It requires the ledger from section 4 to be visible.
• Reduce this batch's draw to the balance and leave the bill part-open. A partly utilised bill is a normal state. It waits for the next credit. Forcing it closed now is what creates the rejected file.
• Check whether the missing money is a deduction rather than a shortfall. A gap that recurs at a similar size across unrelated bills is usually something deducted before the credit reached you rather than money that failed to arrive, and it is treated differently. Our guide to one payout against many shipping bills works the fee chain through.
• Check whether part of the revenue was never goods revenue at all. If the settlement blends physical and digital or services lines, only the goods share can ever fill a shipping bill, and the residue is not a shortfall. See why EDPMS utilisation runs short on digital sales .
• Where the shipment itself was short or amended, correct the bill rather than the allocation. A bill whose declared value overstates what actually shipped is fixed at the bill, through a short shipment amendment , not by finding more money to pour into it.

Only once those are exhausted is the remaining gap a genuine unrealised amount, with its own routes and its own conditions. The write-off and reduction provisions, their limits and the conditions attached to each are set out with their citations on the RBI caution list guide . This page states none of those figures itself, for the reason given in section 12.

What should I not do?

Every item here is something that makes the file pass and the position worse. They share a shape: applying a rule bluntly to make a number close, instead of resolving why it did not.

• Do not delete the offending rows. Dropping whatever a rule flags is how genuine realisation gets discarded. Rows excluded by a blanket filter regularly turn out to be real money against real bills. Surface the blocker with the amount at stake and decide deliberately.
• Do not apply a tolerance band in the over direction. It does not make the allocation acceptable; it makes the rejection arrive later and in bulk.
• Do not convert at spot to force a fit. It disguises a currency mismatch rather than resolving it, and the allocation will not tie out against either side afterwards.
• Do not write off to make the arithmetic close. Where the cause is missing or mis-entered shipment data (which, after the causes above, it usually is) the remedy is to correct the data. A write-off used as a rounding tool surrenders a real claim to fix a clerical fault, and it is not reversible once granted.
• Do not add a totals row or restructure the bank's template to make the working visible. Bank-facing submission files are data rows only. Put the working in the separate attachment described in section 9, where it helps rather than causing the file itself to be returned.

Which figures does this guide deliberately not state?

This guide states no rate, no threshold, no deadline, no purpose code and no notification number of its own, and that is a design decision rather than an omission. Everything above is either structural (what an IRM is, what utilisation does, which record each act creates) or arithmetic over your own documents. It holds whatever the current regulatory figures are, and it would still hold if they changed tomorrow. Figures that go stale silently are the failure mode this page is built to avoid.

Two things follow that are worth saying explicitly. The diagnostic habits described here (clamping a conversion downward, treating a residue as a missing linkage rather than a loss, summing a bill's rows before believing a shortfall flag) come from reconciliation practice. They are ways of finding an error, not entitlements anyone grants you, and no circular prescribes them. And where a genuine regulatory figure is needed, take it from the instrument or from the page here that carries it with its citation:

Frequently asked questions

What does it mean when a bank says an IRM is over-utilised?

It means the amounts you have marked against one inward remittance add up to more than that remittance has left to give. An IRM is your AD bank's record of a single inward credit; utilisation is the act of tying a shipping bill, or part of one, to that credit so the bill can close in EDPMS. The constraint is one line of arithmetic: the sum of everything allocated against an IRM cannot exceed that IRM's outstanding balance. Over-utilisation is that sum failing. It is not a finding that your export was improper, that the money did not arrive, or that you have done something that needs explaining. In the overwhelming majority of cases the error is in the allocation file rather than in the money, and it is fixed by correcting the file.

Why will the bank not accept a small tolerance above 100%?

Because an IRM records money that actually arrived, so there is nothing above it to draw from. Under-utilisation is an ordinary state. It simply means more shipments are still to be allocated against that credit, and the balance sits there until they are. Over-utilisation is different in kind: it asserts the existence of funds the remittance never contained, and every rupee above the balance is a claim the bank cannot evidence against its own record of the credit. A tolerance band that is symmetrical in both directions is a defect in whatever produced the file. Short is safe and normal; over rejects.

What is the single most common cause of over-utilisation?

Drawing from the wrong column. An EDPMS pending report typically carries both the gross amount of the remittance and the amount still available for bill submission against it. Allocations must be built from the outstanding balance, never from the gross figure, because the gross has not been reduced by what earlier submissions already consumed. This is invisible on a first batch, where the two figures are equal, and it surfaces from the second batch onward. Which is why it is so often diagnosed as a new problem when it is a method that was wrong from the start and only just became visible.

My shipping bill is split across several IRMs. Does the full bill value go on every row?

The bill value repeats on every row by design, but only the utilisation splits, and confusing the two is a common way to over-draw by a multiple. The bill value is a property of the bill, so it is the same figure wherever the bill appears. The utilisation is the portion of that bill being drawn from the particular IRM on that row, and those portions are what must sum to the bill value. Tie out at bill level rather than row level: add up every row belonging to one bill before deciding whether anything is short. Bank reviewers do flag line items without summing them first, and a severe apparent shortfall sitting exactly on an IRM boundary usually means a continuation row is missing rather than that money is.

The IRM I allocated against is not in this month's pending list. What happened?

It has most likely been consumed and closed since the export you were working from was generated, and an allocation against an IRM that is no longer pending is void rather than merely wrong. This is why allocations should be rebuilt against a freshly downloaded pending report at the start of each batch rather than carried forward from a working file. The failure is easy to mistake for over-utilisation, because both produce an allocation the bank cannot accept, but the remedy differs: over-utilisation is corrected by reducing the draw, while a vanished IRM has to be replaced by a different credit that is actually available.

Update history

• 2026-09-12 First published.