eBRC Full Form, Meaning and Status Check: The DGFT Process for Exporters (2026)

What is an eBRC?

Before the eBRC, exporters collected paper bank realisation certificates and physically submitted them for scheme claims. The electronic system replaced that with a digital record that flows from the bank to DGFT automatically, cutting paperwork and making realisation data available to the systems that grant benefits.

Conceptually the eBRC answers one question the authorities always ask: did the export actually earn foreign exchange for India? It is the closing entry on an export — the point at which a shipment stops being a promise and becomes realised value, with a certificate to prove it.

How an eBRC is generated

The chain begins with money, not paper. When the buyer's payment lands in your account, the bank records the inward remittance. That remittance then has to be attributed to the specific export invoices it settles — a payment may cover one invoice or several — and only once mapped does it become an eBRC that DGFT can read.

The shift toward exporter self-certification (often called eBRC 2.0) puts more of that mapping in your hands, which is efficient but demands accuracy. If a remittance is mapped to the wrong invoices, or left unmapped, the realisation record is wrong — and every benefit that reads from it inherits the error. Clean, per-invoice tracking is what makes self-certification safe.

eBRC generation flow from remittance to DGFT diagram — ExportCRM

How to check eBRC status on DGFT

Menu labels on the DGFT portal have changed more than once since the eBRC 2.0 self-certification system was introduced, so treat the path below as a guide and confirm the current labels on the portal.

1. Log in at dgft.gov.in with the user linked to your IEC.
2. Open My Dashboard → Repositories → Bills Repositories, and choose the eBRC bill type.
3. Filter by bank, date range or shipping bill number. Each row is one eBRC: number, date, bank, currency, amount realised and the matched shipping bill.
4. Under eBRC 2.0 (self-certification), your bank first pushes an Inward Remittance Message (IRM) to DGFT; you then match the IRM to the shipping bill(s) it pays for and self-certify the eBRC. If a remittance is sitting as an unmatched IRM, the eBRC has not been generated yet — complete the matching.
5. Download or print the eBRC for the record and for scheme applications. RoDTEP scrip generation and other DGFT benefits check for a matched eBRC against the shipping bill.

If an eBRC is missing, the usual causes are: the bank has not transmitted the IRM (ask the bank's trade-finance desk), the remittance was received in a different account or through a different AD bank than the one on the shipping bill, or the purpose code on the inward remittance was wrong and the bank did not treat it as export proceeds. Each of these is fixed at the bank, not on the DGFT portal.

Invoice realisation status tracker showing realised, due and overdue proceeds — ExportCRM

eBRC and the shipping bill: how the pieces connect

This is why realisation cannot be treated as a purely financial matter handled in isolation by accounts. The remittance that generates an eBRC has to be tied back to the specific shipping bills and invoices it settles, or the trade documents and the money will not line up. When they diverge, benefits that depend on the match are exposed.

Keeping the three connected from the start is far easier than reconstructing the links later. An export house that records the invoice, generates the shipping bill and then maps the incoming remittance against the same order has a clean, self-consistent set at every stage — which is exactly what a scheme claim or an audit needs to see.

Why the eBRC matters for incentives and compliance

Think of the eBRC as the receipt that validates everything upstream. RODTEP, drawback and other benefits are granted on the premise that a genuine export earned foreign exchange; if the proceeds are never realised or recorded, that premise fails and the benefit is exposed. The certificate is the thread that ties the money back to the shipment.

There is also a hard compliance side. Export proceeds are expected to be realised within RBI's prescribed timeline, and bills left outstanding beyond it draw scrutiny. Tracking which invoices are realised, which are due, and which are overdue is therefore not just good finance — it is how an export house stays clean with the regulator.

eBRC, foreign exchange and the RBI realisation timeline

The realisation timeline exists because an export is, in policy terms, meant to earn foreign exchange for the country. An invoice that ships but never gets paid — or gets paid but is never recorded as realised — leaves that obligation open. The bank tracks these outstanding bills, and persistent non-realisation can affect your standing and your access to benefits.

For most exporters the timeline is comfortable if payments are managed, but it becomes a problem when invoices are forgotten after dispatch. Knowing, at any moment, which bills are realised and which are approaching their realisation deadline turns a compliance risk into a routine follow-up — the same discipline that gets you paid on time also keeps you compliant.

Common eBRC problems and how to avoid them

Part-payments cause particular confusion: a buyer settles half an invoice now and half later, and unless both remittances are mapped, the invoice looks unrealised even though the money came in over two transfers. Multiply that across many buyers and currencies and the realisation picture drifts from reality — usually in the direction that hurts your claims.

Avoiding these problems is a matter of habit and system. When each remittance is attributed to the exact invoices it settles at the moment it arrives, the eBRC data stays true and self-certification is safe. A platform that holds invoices and their realisation together makes that reconciliation a quick, routine step instead of a forensic exercise months later.

Tracking realisation: closing the loop on every invoice

Most realisation problems are really visibility problems. When invoices are marked 'done' on dispatch and payments land weeks later in a separate bank statement, no single view shows which proceeds are actually in and which are still owed. The eBRC that should close the loop never gets checked against the invoice it belongs to.

Closing that loop is exactly what ExportCRM is built to do: each export invoice carries its payment terms, due date and realisation status, so getting paid, generating the eBRC and keeping benefits valid become one connected workflow. Realisation stops being an afterthought discovered at claim time and becomes a status you can see at any moment.

Frequently asked questions