The complete guide to e-BRC, EGM & export refunds

A goods export is really a story told in three official documents, filed at three different moments by three different parties. Get all three to line up and your refunds and incentives flow almost automatically; let any one of them go missing or mismatch, and the money quietly stops.

A service or software export has no shipping bill and no EGM — it never touches Customs — but it still ends in an e-BRC once payment arrives. We cover that difference in the goods-vs-services section below.

An e-BRC (Electronic Bank Realisation Certificate) is the digital certificate on DGFT that records that your overseas buyer's payment for an export has been realised in India. Under the system in force since November 2023, your Authorised Dealer (AD) bank reports each inward remittance to DGFT electronically as an Inward Remittance Message (IRM); you then generate the e-BRC yourself on the DGFT portal by matching those remittances to the relevant shipping bill, SOFTEX or invoice. It is a self-certification model — there is no per-certificate bank signature.

The certificate has evolved through three stages. Before 2012, an exporter collected a paper BRC from the bank for each realisation. From 2012, DGFT moved it online — banks transmitted realisation data electronically under digital signature. From November 2023, DGFT switched to self-certification: banks push inward-remittance data (IRMs) to DGFT, and the exporter creates and self-certifies the e-BRC by mapping IRMs to export documents — one e-BRC can group several IRMs, or one IRM can be split across several e-BRCs. (That mapping and generation is exactly what EximJinn's e-BRC Generation module automates.)

And it is not just for large manufacturers. Every exporter earns one — goods exporters, IT / ITeS and software firms, SaaS companies, freelancers and e-commerce sellers alike. If money comes in from abroad against an export, an e-BRC is how that payment becomes provable.

Under the current self-certification system you generate the e-BRC yourself on DGFT, from the remittance data your bank reports. Knowing the chain helps you see where an expected e-BRC is stuck:

1. 1Your buyer pays, and the proceeds are realised in India within the RBI-permitted period (currently 9 months from the date of export; the RBI can temporarily extend this from time to time).
2. 2Your bank reports the inward remittance to DGFT electronically as an Inward Remittance Message (IRM) (banks moved to API integration with the upgraded system in early 2024).
3. 3On DGFT you match the IRM(s) to the relevant shipping bill / SOFTEX / invoice — several IRMs can be grouped under one e-BRC, or one IRM split across several.
4. 4You self-certify, and DGFT generates the e-BRC (foreign-currency values converted to rupees at the notified reference rate). It is available immediately — no per-certificate bank signature.

When you generate an e-BRC (individually or in bulk) DGFT asks a few questions. They look technical but each has a simple, legal meaning. Here is what to pick and why.

Avail GSTIN benefit — Yes or No

This is whether you want the e-BRC linked to your GST tax invoices. Choose Yes if the e-BRC should tie to specific GST invoices — you then supply the GST invoice number and date, and DGFT records the realisation against them (useful where the export realisation needs to sit against your GST records). Choose No if you don't need that GST linkage; the e-BRC is still generated against the shipping bill and commercial invoice.

Payment realised in — regular account vs Vostro / SRVA

For a normal export realised in foreign currency into your own account, this is not a Vostro/SRVA case — leave it as the regular remittance (No). Choose a Rupee Vostro option only when the payment was settled in Indian rupees through a special banking arrangement:

• SRVA — Special Rupee Vostro Account: the RBI mechanism for settling international trade in INR (used, for example, for trade with countries under rupee-settlement arrangements). Pick this if your export proceeds came in via an SRVA.
• NVRA — Normal Vostro: payment realised through a normal (non-special) rupee vostro account.

If in doubt for a standard USD/EUR/GBP export, it is the regular option — SRVA/NVRA are the exceptions, not the rule.

Deductions & Net Realised Value

DGFT lets you record commission, discount, insurance, freight and other amounts in two columns: those that reduce the Net Realised Value (they lower the certified value and are printed on the e-BRC), and those for information only (recorded but not deducted). Bank charges — the small shortfall the bank keeps — are the usual reason the amount received is a little under the invoice value; record them so the invoice reconciles.

Individual vs bulk generation (and the IFSC)

Both routes create the same e-BRC. Generating one at a time on DGFT, the bank IFSC of the realisation account is filled in for you (read-only). In the bulk file you must supply that IFSC yourself, because DGFT's IRM download carries the AD code but not the IFSC. It is the same for every remittance received through that AD bank branch — so in EximJinn you set it once in Generation setup, and it fills every line.

On the DGFT portal, e-BRCs live in your Bills repository. The manual path is:

1. 1Log in to the DGFT portal with your IEC credentials.
2. 2Open My Dashboard → Repositories.
3. 3Under Bills Repositories, click Explore.
4. 4Choose Bank Realisations (e-BRC) from the dropdown.
5. 5Enter a date range (DGFT limits how wide a window you can pull at once) and search.
6. 6Open a Bank Realisation Number to view its details, then Print / Download the PDF.

That is fine for one or two certificates. The friction is scale and DGFT's per-request limits: pulling a full year means many small windows, one PDF at a time, then matching each back to a shipping bill by hand.

An EGM (Export General Manifest) is the list the carrier — the shipping line or airline — files with Customs after your goods have actually left the country. Each consignment gets a unique EGM number and date, tied back to your shipping bill. Under Section 41 of the Customs Act, 1962, the person-in-charge of the conveyance must file it (the Export Manifest for air cargo), listing everything loaded for export.

This matters because the shipping bill only shows you intended to export; the EGM confirms the carrier actually manifested and carried the cargo out. Courts and Customs treat EGM filing as the moment the export is legally complete. Its core jobs:

• Departure verification — evidence the goods physically left India.
• Customs closure — the trigger that lets Customs close the shipping bill.
• Refund processing — for exports on payment of IGST, a filed, error-free EGM is what releases the refund.
• Anti-fraud — it makes a benefit claim traceable to a real, manifested shipment.

An EGM “error” means the Customs system could not cleanly match the EGM to your shipping bill. Until it is corrected, the shipping bill stays open and any IGST refund, drawback scroll or EDPMS closure attached to it stalls. The most common causes:

• Shipping bill number / date not matching ICEGATE records
• Container number typos or duplication
• Let-Export-Order (LEO) date inconsistencies
• Short-shipment / shut-out status not updated
• Duplicate manifest entries
• Exporter IEC / GSTIN mapping failures
• Non-filing or delayed filing by the carrier
• Gateway-port misalignment in transhipment
• Incorrect vessel / voyage details

How they get resolved:

1. 1EGM amendment via ICEGATE with supporting documents — minor (clerical) amendments are straightforward; major ones (affecting revenue, classification or identity) may need officer adjudication.
2. 2Short-shipment / shut-out regularisation — with the shipping line's endorsement, so the cargo can be re-exported or re-filed.
3. 3Condonation for late / non-filing — carriers file within the prescribed window (typically 24 hours of departure); delays need a condonation request and late-filing charges.

Goods physically cross the border, so they go through Customs and generate a shipping bill, a port code and later an EGM. Services — software, IT / ITeS, consulting, design — have nothing physical to ship, so they never touch Customs. Instead they are declared on a SOFTEX, certified by STPI. The remittance is still reported to DGFT as an IRM, and you self-certify the e-BRC against the SOFTEX (rather than a shipping bill). So you always get an e-BRC, but only goods exports have a shipping bill and an EGM.

Practically: if you export services only, keep the EGM module off. There is no shipping bill for it to check. EximJinn validates the shipping bill and port code before it ever queries ICEGATE, and skips SOFTEX / service e-BRCs automatically, so a services account never chases a manifest that cannot exist.

How the IGST refund works. You can export goods on payment of IGST and claim that tax back. You do not file a separate application — your shipping bill is the application. The refund releases automatically once everything lines up:

1. 1GSTR-1 is filed with your export invoices in Table 6A (correct SB number, SB date and port code).
2. 2GSTR-3B is filed for the period, with the IGST in Table 3.1(b) at least equal to the IGST in Table 6A.
3. 3The GST portal transmits this to ICEGATE, which matches it against the shipping bill + EGM and credits the refund — usually with no manual intervention.

Three benefits, often confused:

• Duty drawback — gives back the customs duty embedded in the inputs of your exported goods.
• IGST refund — returns the GST you paid on the export itself.
• RoDTEP — remits other embedded central / state taxes and levies, issued as transferable scrips.

When a refund does not arrive, it is almost always one of a short list:

• The EGM is not filed, or is filed with an error that Customs could not match.
• A mismatch between the shipping bill and the GST return — wrong SB number, date or port code in Table 6A.
• GSTR-1 or GSTR-3B not filed for the period.
• Export proceeds not realised — no e-BRC — within the RBI timeline.

Best practice is boring but effective: monitor EGM status continuously, reconcile shipping bills against realisations after each sailing, keep sailing confirmations from your lines, raise amendments the moment a discrepancy shows, and keep a clean documentary trail. The hard part is doing it across hundreds of bills — which is where a tool earns its keep.

None of the above is conceptually hard for a single shipment. It becomes hard at volume: e-BRCs sitting in DGFT, EGMs in ICEGATE, remittances in the bank — three systems, per-request limits, and reconciliation that is manual, error-prone and easy to postpone until a refund is already late. Manual keying across systems is where invoice numbers, amounts and dates drift out of alignment.

EximJinn brings both government sources into one workspace and does the joining for you:

• Bulk e-BRC download from DGFT across any period, split into DGFT's allowed windows automatically.
• EGM, shipping-bill status & duty-drawback pulled from ICEGATE in one click, with missing / errored EGMs flagged.
• Transhipment handling — checks both origin and gateway ports for your EGM.
• Reconciliation — each shipping bill linked to all of its e-BRCs, with everything exportable to Excel.
• e-BRC Generation — pulls your inward remittances, maps them to shipping bills / invoices, and prepares bulk generation files for you to sign on DGFT.
• Services-aware — SOFTEX / service e-BRCs are kept out of the goods flow automatically.

EximJinn is organised into modules that each own one part of the export trail, all joined together so a shipping bill you upload once is understood everywhere. Here is what each module does and how to use it.

Provided for general understanding, not as legal or tax advice. Rates, timelines and forms change — confirm the current position for your case.