Bank Realisation Certificate (eBRC): 2026 Exporter Guide

A bank realisation certificate (eBRC) is proof that an exporter has received payment from an overseas buyer for goods or services exported from India. It confirms the foreign-exchange proceeds were credited to the exporter's account and matched to a specific shipment or invoice.

In short:

• What it is: an electronic Bank Realisation Certificate generated on the DGFT portal, evidencing that export proceeds were realised in India.
• What it authenticates: the inward foreign remittance credited against a shipping bill or export invoice, under your Importer Exporter Code (IEC).
• Why it matters: it is the proof of realisation you need to claim export incentives (Duty Drawback, RoDTEP, EPCG, Advance Authorisation), close export obligations, and support GST refunds on zero-rated supplies.
• Who it is for: goods exporters, and software exporters filing SOFTEX, chiefly for incentive and DGFT-facing claims.

The manual paper BRC was replaced by the eBRC on the DGFT portal in 2012. Since 2024 you self-certify it by mapping bank-uploaded remittance data to your invoices. For the underlying rule on how long you have to bring the money home, see realisation and repatriation of export proceeds.

eBRC stands for electronic Bank Realisation Certificate. BRC is simply the older term for the same document in its manual form. In export and banking contexts the two are used interchangeably, but the current, DGFT-recognised version is the electronic one.

The certificate sits inside the DGFT (Directorate General of Foreign Trade) ecosystem. Your Authorised Dealer Category-1 (AD-1) bank reports the inward remittance to DGFT, and you convert that data into an eBRC linked to your IEC.

The eBRC is the single evidence most Indian export benefits are built on. Without it, incentive and refund claims stall. It is required to:

• Claim export incentives: Duty Drawback, RoDTEP, EPCG authorisation closure, Advance Authorisation, and other DGFT schemes all ask for proof of realisation.
• Meet FEMA and forex-compliance rules: it evidences that proceeds were realised within the permitted window and repatriated to India.
• Close export obligations: it feeds Export Obligation Discharge Certificate (EODC) applications under schemes tied to your IEC.
• Support GST refunds: for zero-rated supplies, the eBRC or an equivalent realisation proof backs your refund claim.

Frame it as relief rather than red tape. Once the remittance data is clean and your invoices map correctly, the certificate is a short self-service step, not a bank-counter chase.

These are the two documents exporters most often confuse. They prove different things and are used in different places. Keep the distinction crisp and use the right one for the right claim.

The short version: the eBRC is DGFT-facing proof of realisation for goods (and SOFTEX software) exports, while the FIRC or FIRA is bank proof that an inward remittance landed. For the full side-by-side, read BRC vs FIRC; for the certificate-versus-advice nuance, see BRC vs FIRA. We will not restate those comparisons here.

Since the DGFT moved to a bank-data-driven model, you no longer request an eBRC from your bank. Your AD-1 bank uploads an Inward Remittance Message (IRM) to DGFT, and you self-certify by mapping it to your export documents.

The steps on the DGFT portal:

Step 1: Log in to the DGFT portal

Log in to dgft.gov.in with your IEC and linked credentials.

Step 2: Open the IRM / ORM Repository

Open the IRM / ORM Repository and search for the inward remittance your bank has reported.

Step 3: Generate the eBRC

Generate eBRC by mapping the IRM to the relevant shipping bill(s) or export invoice(s).

Step 4: Enter the realisation details

Enter details such as the realised value, purpose code, and, for services, the Mode of Export of Services field.

Step 5: Self-certify and submit

Self-certify and submit; you can then view, download, or cancel the eBRC as needed.

Clubbing rules to know: you can combine multiple remittances into one eBRC only where they share the same currency and the same bank. Some purpose codes, notably P0101 (export bills negotiated) and P0108, are excluded from certain eBRC mappings, so check your code before you start. See rbi purpose code for inward remittance for how codes are assigned.

A generated eBRC ties three identifiers together. Reading them stops most reconciliation errors.

• IRM (Inward Remittance Message): the record your AD-1 bank pushes to DGFT for each inward payment. No IRM means no eBRC.
• Realisation date: the date the proceeds were actually credited and realised. When a shipping bill shows a BRC realisation date, it is confirming when payment for that shipment landed, not the shipment date.
• Realised value vs invoice value: these can differ after bank charges or partial payment, which is where short realisation comes in.

Two updates matter, and most competitor pages still print the old rules. Date both when you cite them.

• Realisation window extended to 15 months. As of RBI's amendment in November 2025, the period to realise and repatriate export proceeds was extended from 9 months to 15 months from the date of export. Many guides still say 9 months. Confirm the current position with your AD bank or a CA before relying on it.
• Mode of Export of Services field. Effective 1 May 2025, the eBRC format for service exports requires a mandatory Mode of Export of Services field. Service exporters must select the correct mode when self-certifying.

If your claim depends on the timing, read export incentives alongside this so you sequence realisation and incentive filing correctly.

Say you export software services and raise an invoice for USD 10,000. At an illustrative USD/INR of ₹95, the invoice is worth ₹9,50,000.

• Invoice value: USD 10,000 (₹9,50,000 illustrative).
• Amount realised: the buyer's bank and intermediaries deduct USD 40 in charges, so USD 9,960 lands.
• Realised value on the eBRC: USD 9,960, mapped to that invoice.

The USD 40 shortfall is a short realisation. Small charge-related gaps are generally acceptable, but you should be able to explain them, and large or unexplained shortfalls can hold up incentive claims. This is exactly why clean, correctly coded remittance records matter before you self-certify.

This is the most common blocker, and the sequence is fixed: no IRM in the repository means you cannot generate the eBRC, because the certificate is built from bank-reported data.

Work through it in order:

Step 1: Confirm the remittance landed

Confirm the money actually landed in your account and was booked as an inward foreign remittance.

Step 2: Ask your bank to report the IRM

Ask your AD-1 bank to report the IRM to DGFT. The bank must upload it first; DGFT does not create it for you.

Step 3: Check the purpose code

Check the purpose code your bank used. A wrong or excluded code (for example P0101/P0108) can stop the mapping.

Step 4: Allow processing time and re-search

Allow processing time after the bank confirms upload, then re-search the repository.

If the remittance came through cleanly with the right purpose code from the start, this whole problem disappears. That is a reconciliation and data-quality issue at the receiving stage, not a DGFT one.

Not always, and this is where services exporters and freelancers get stuck. The eBRC is DGFT-facing proof, so you need it when you are making a claim that DGFT or an incentive scheme requires it for.

• You likely need an eBRC if you file SOFTEX for software exports, claim export incentives, or bid for tenders that ask for proof of realisation.
• A FIRC or FIRA often suffices for many non-software services exporters and freelancers, for ITR reporting and GST-refund evidence, where no DGFT incentive is being claimed.

If your work sits in the services lane, the practical proof you rely on day to day is usually the foreign inward remittance certificate, not the eBRC. Software exporters should also check SOFTEX filing, since SOFTEX is what brings software services into the eBRC net.

Note on fees: downloading and self-certifying the eBRC on the DGFT portal is free of cost. A bank may still charge for its own remittance-processing or documentation service, but that is separate from the DGFT step.

Refund officers sometimes ask for realisation proof before releasing a GST refund on export of services. The Karnataka High Court has held that a GST refund on export of services cannot be denied where the exporter has submitted eBRC or FIRC evidence of realisation.

Practically, this means keeping clean realisation proof is your strongest position in a refund dispute. For how that proof supports a claim, see export of services under GST and, for the refund workflow specifically, FIRC for GST refund.

Xflow does not issue your eBRC. DGFT does, from data your bank reports. What Xflow does is make that upstream data clean.

Xflow's receiving accounts settle export proceeds to your AD-1 bank with correctly purpose-coded remittance records and auto-issued eFIRA, so the IRM your bank reports to DGFT is accurate and your self-certified eBRC maps to invoices without guesswork. For most services exporters and freelancers, the everyday proof is the eFIRA that arrives with each payment, while the eBRC comes into play for SOFTEX and incentive claims. Xflow holds final PA-CB (Payment Aggregator – Cross Border) authorisation from the RBI for exports and imports, as of February 2026, and settles on the next business day (T+1).

None of this is tax or legal advice. Confirm the current realisation window and your specific documentation with your AD bank or a CA.