IRM Mapping Errors on DGFT eBRC: Fixes for Each One

What a mapping is, and where it goes wrong

Since the November 2023 revamp, your bank reports each export payment to DGFT as an Inward Remittance Message, the IRM, and you generate the certificate yourself by linking that remittance to the export document it paid for: a shipping bill for goods, a Softex form for software, or an invoice for other services. That link is the mapping. The portal flow is written up step by step in how to generate an eBRC on the DGFT portal.

The values you supply for the mapping have rules, and DGFT applies them whether you file from the portal or from a workspace. The difference is when you hear about it. On the portal, some values are refused on the screen and others come back later on the status of the request. In a workspace that checks the form before it leaves, the same rules are applied while the values are still an edit. Either way the rule is the same, and so is the fix.

The errors, in the order they usually appear

1. The amount mapped is more than the remittance has available

The message reads like "mapped amount exceeds the available remittance", or names the excess: exceeds the available IRM amount by so much. It means the figure you typed as the amount to map is larger than what is genuinely left on that remittance. The available figure is not the gross amount the bank received: it is that amount less any outward remittance against it and less whatever earlier certificates have already used. DGFT's own form shows the same arithmetic as the IRM amount available to generate a fresh eBRC.

What to check: the available balance on the remittance record, which sits beside the gross amount. What to change: map the balance, or the part of it that belongs to this export, and leave the rest for the next certificate. In a spreadsheet, rows that carry the same IRM number are added together and the total is checked against the remittance, so three rows that each fit on their own can still fail together. A row whose remittance amount is blank or zero is also refused, because there is nothing to check the mapping against.

2. The deductions add up to more than the amount mapped

The message reads "deductions cannot exceed the mapped IRM amount", with both figures shown. Commission, discount, insurance, freight and other deductions are subtracted from the amount you mapped, not from the invoice value, so their total cannot be larger than that amount. A deduction that is negative, or not a number, is refused on the same check.

What to check: the deduction amounts are in the same currency as the remittance, and the column they sit in. DGFT keeps two columns for each deduction, one that reduces the net realised value and one that is recorded for information only; only the first is counted against the amount mapped. What to change: correct the figure, or move a charge the remittance never included into the information column. Which column is which is explained under step six of the portal guide.

3. The shipping bill number is not a shipping bill number

For a direct export the document number is the shipping bill number, which is digits only and not more than seven of them. The two ways this fails are a full reference pasted into the field, and a courier or invoice reference that contains letters. The message says so plainly: enter the shipping bill number on its own, not the full reference. The document number field itself takes at most twenty characters whatever the export type, and a Softex filing wants only the number, not the whole Softex reference.

A related refusal is a character DGFT does not accept. The document number, the bill or invoice number and the GST invoice number may contain letters, digits, a slash and a hyphen. A hash, a comma, an ampersand or a bracket in an invoice number is refused, and the message names the offending character. What to change: enter the number as it appears on the document, without the prefix, the year band or the punctuation your own system adds.

4. A date is not a real date, or not in a shape DGFT reads

The shipping bill date, the invoice date and the GST invoice date all have to be real calendar dates. A thirty first of February is refused however it is typed, and so is a year that cannot be right. In the wizard the date fields are pickers, so this mostly appears in a spreadsheet, where a cell can hold text that looks like a date. The template accepts a date written as DD/MM/YYYY, DD-MM-YYYY, DDMMYYYY or YYYY-MM-DD, or a genuine Excel date cell. What to change: retype the cell in one of those forms and check the day and month are not swapped.

5. The port code is not a DGFT port code

A port code is six characters: IN followed by four letters or digits, for example INDEL4 for Delhi Air Cargo. The common failure is a three letter airport or city code, DEL or BOM, typed where the six character code belongs. In the wizard the port is chosen from a list, so this is a spreadsheet error. What to change: pick the code from the list once and paste it, or take it off the shipping bill, where it is printed. A port code is needed on goods and deemed export filings; service filings do not carry one.

6. The currency code is not three letters

The currency of the shipping bill or invoice is its three letter code, USD or EUR or GBP. Anything longer or shorter is refused, and so is a symbol. What this is not: a mismatch between the document currency and the remittance currency. DGFT allows the two to differ, and the certificate is generated on the basis of the IRM currency. So a dollar remittance against a euro invoice is a valid mapping; what fails is a currency cell that says "US Dollar" or "$". Deductions, note, are always entered in the remittance's currency.

7. A service export is missing its invoice, SAC code or mode of export

A service export other than software has no shipping bill, so the document is the invoice, and the form asks for what an invoice carries: the invoice number and date, the currency and value, the SAC code and the mode of export of services. The message names the missing field: add the invoice number, add the SAC code. The mode of export must be one of the four DGFT lists; a spreadsheet cell with anything else is refused. DGFT publishes a purpose code to SAC mapping on its eBRC page, and it is worth using rather than guessing, because the portal shows only invoices whose SAC codes match the description of the same services. One more rule that reads like an error but is not: a service export is one remittance to one certificate, with no clubbing, so a second invoice against the same IRM is a second filing.

8. The GST fields contradict the GST answer

Every mapping answers one question, whether a GST invoice is available, with Y or N. Answer Y and the GST invoice number and the GST invoice date become mandatory, and the message says so: GST invoice number is required when GST is available. Answer N and both fields must be empty; a filing cannot decline GST and carry a GST invoice number at the same time. In a spreadsheet the answer itself must be Y or N and nothing else. The GST invoice number takes at most thirty characters. What to change: decide the answer first, then fill or clear the two fields to match. Why the answer matters for a refund claim is in eBRC for GST refund on exports.

9. The third-party and Vostro answers

Two questions on the basic details are yes or no. Is this a third-party export: answer yes when the money came from someone other than the buyer, so the certificate records that the payment was received from a third party. The remitter's name is on the remittance record in front of you. Is this a Vostro account transaction: answer yes and the Vostro type becomes mandatory, SVRA for a special Vostro realisation or NVRA for any other, and any other value is refused. In a spreadsheet both flags must be Y or N. Most filings answer no to both, which is why the wizard folds them away.

10. The spreadsheet as a whole is refused

Some errors belong to the file rather than a row. A file may contain only one type of eBRC; a sheet that mixes direct exports with service exports is refused with the instruction to split it. The upload type in the sheet has to match the type selected for the upload, and the type codes are 101 for Direct Export, 102 for Softex, 103 for Service Non-IT and 104 for Deemed Export; the short forms 1 to 4 are not accepted. Each row needs its own serial number. A file with more than 999 data rows is refused before anything is filed, so split it into smaller files and upload them one at a time. The file itself must be .xlsx or .xls and 5 MB or smaller, readable, not password protected, and must have data below the header row.

One habit prevents most of the rest. The columns that arrive pre-filled from your remittance ledger, the IRM number, the AD code, the purpose code, the IFSC and the remittance currency, have fixed widths, and an error that names one of them almost always means the cell was edited. Export a fresh template and add only the invoice columns. The whole loop is in filing eBRCs in bulk.

11. The shipping bill PDF did not fill the fields

Uploading the shipping bill PDF fills the shipping bill number and date, the port code, the invoice number, the currency and the value, and marks each filled field with a tick so you can see what came from the document. The upload takes a PDF of up to 10 MB. If the message says the document could not be read, try another copy of the bill, or fill the fields by hand; nothing else changes. Two things are always yours to check: that the values filled match the bill you meant, and the amount to map, which is the one field the document never fills. It is either the figure you enter or the whole remittance with one click.

Errors that come back from DGFT rather than before submit

A few rules are judged by DGFT on the remittance itself, so no form check can clear them. For an advance payment, purpose code P0103, the shipping bill or invoice date must be on or after the remittance date; the certificate waits for the shipment. Purpose codes P0101 and P0108 cannot generate an eBRC at all, and if the code on your remittance is simply wrong, only the bank can amend the IRM. Remittances combined into one certificate must share a currency, a bank account and a purpose code. And a shipping bill AD code that differs from the remittance AD code draws a warning, not a wall: DGFT's published position is that the certificate can still be generated. All of these are set out under the rules DGFT enforces in the portal guide, and the case where the remittance itself is missing or has changed status is in IRM not showing on DGFT and IRM shows Amended or Cancelled.

Fixing it once, not every time

Every rule above is the same rule on every filing, which is what makes a workspace worth having: it can apply the whole list before anything leaves. In the eBRC exporter app, the remittance card shows the available balance beside the gross amount, the mapping fields fill themselves from the uploaded shipping bill for you to confirm, deductions are checked against the amount mapped, and a spreadsheet comes back with every problem named by row and field before a single row is filed. Resubmitting a corrected file never creates a duplicate. The app does not choose the shipping bill for a remittance, and it does not need to; it takes the typing and the guessing out of the mapping you make. If the list above is one you recognise, start free and let the next filing be checked before it goes.

Frequently asked questions

What does "mapped amount exceeds the available remittance" mean on an eBRC?

The amount you are applying from the IRM is larger than what is left on it. The available figure is the gross remittance less any outward remittance against it and less what earlier certificates have already used. Map the balance or part of it; the rest stays available for the next certificate.

Why is my shipping bill number rejected for an eBRC?

For a direct export the shipping bill number is digits only and not more than seven of them. A full reference with a port prefix or a year band, or a number with punctuation in it, is refused. Enter the shipping bill number on its own, as printed on the bill.

Can the shipping bill currency be different from the IRM currency?

Yes. DGFT allows the document currency and the remittance currency to differ, and the eBRC is generated on the basis of the IRM currency. What is refused is a currency cell that is not the three letter code, such as a symbol or the currency's name.

Can I fix a mapping error after the eBRC is generated?

Partly. Deduction values can be updated on a certificate that has not been used for any benefit or incentive, from the repository on the DGFT portal. Anything else means cancelling the certificate, which an exporter can do within 120 days of generating it if it has not been used to claim anything, and generating it again against the corrected mapping.

Does eBRC catch these errors before filing?

Yes. In the eBRC exporter app the amount, the deductions, the number and date formats, the port code, the currency code, the GST fields and the export type's required fields are checked while the values are still an edit, and a bulk spreadsheet comes back with every problem named by row and field before anything is filed.