e-BRC for Indian service exporters — what it is, why you need it, how to get one

If you're an Indian service exporter — a freelancer billing US clients in USD, or an agency running cross-border SaaS retainers — there's a three-letter acronym quietly blocking your working capital: e-BRC.

Your CA mentions it once a quarter. Your payment rail hasn't mentioned it at all. You hear it in passing when someone asks why your GST refund hasn't landed. And then you go back to shipping client work, and it waits.

Here's a short-and-specific guide to what an e-BRC actually is, how to self-certify one, why it gets stuck, and what changes under the Oct 1, 2026 FEMA rollout. We wrote this because the cross-rail picture isn't covered: Skydo has written a useful explainer, and rails like Karbon and Winvesta surface own-rail support in places, but no public product appears to manage e-BRCs across Skydo, Wise / Payoneer / PayPal, direct SWIFT, DGFT, GST, and EDPMS in one workspace. That cross-rail seam is where most service exporters actually live.

01 · What is an e-BRC?

e-BRC stands for electronic Bank Realisation Certificate. It's a DGFT-generated document that confirms one or more foreign- exchange inward remittances were received against an export from India.

Two things most guides get wrong:

• You generate it yourself. Current DGFT policy (the IRM/ORM Repository flow) is exporter self-certification. You log in to DGFT, pick the inward remittances (IRMs) your Authorized Dealer bank has transmitted, and click generate. Your AD Cat-I bank's job is to push those IRMs upstream to DGFT. Issuance sits with you.
• One e-BRC can cover multiple IRMs. DGFT supports clubbing — if a single export invoice was settled in three tranches, you can self-certify a single e-BRC against all three IRMs. Equally, a single e-BRC can sit against one IRM. The shape is flexible; the match just has to be honest.

Before 2012 this was a paper form called BRC, issued by the bank. DGFT moved it electronic and, as of the current flow, handed generation to the exporter. The "e" stuck; the authority moved.

02 · Why it matters: GST refund depends on it

Here's the high-stakes part most guides skip. If you're an exporter of services under a Letter of Undertaking (LUT), you're exporting without paying IGST. The government owes you a refund on any input GST you paid while producing that export — cloud bills, AWS, tooling, SaaS subscriptions, office rent input credit.

That refund is claimed via GST RFD-01. RFD-01 is the form. The evidence attached to it is typically:

• The export invoice you raised.
• The FIRA / FIRC confirming you received the foreign exchange.
• The e-BRC (or equivalent BRC / realization evidence) tying the remittance to the invoice.

CBIC refund rules frame this as "relevant BRC/FIRC evidence" rather than e-BRC-only — but in practice, for service exports, the e-BRC is the most common and cleanest artifact. Missing the remittance-evidence trail (e-BRC, BRC, or FIRC) and the GST officer will issue a deficiency memo and stall the refund until you close the gap. Your working capital sits in the input-credit limbo. Agencies with ₹50L+ annual input GST tell us this stalls ₹2-4 lakh in refunds at any given time.

Same story for many non-GST schemes: EPCG closure, SEIS claims (where still applicable), Advance Authorization proofs. The e-BRC is the match artifact that keeps showing up in every scheme's evidence list.

03 · The workflow: bank → DGFT repository → you self-certify

The current DGFT flow has five beats. The mental model to hold is: bank transmits, you generate.

1. Inward remittance arrives. SWIFT wire, Payoneer payout, Wise transfer, Skydo settlement — whatever the rail, INR lands in your AD Cat-I bank account.
2. Bank tags it with a purpose code + IRM reference. The bank assigns an RBI purpose code (P0802 for software, P1006 for business / management consultancy, P0801 for hardware consultancy, etc.), generates an Inward Remittance Message (IRM), and pushes it to DGFT's IRM/ORM Repository. Some banks auto-tag Skydo / Payoneer / Wise payouts; for direct SWIFT, you usually fill an FIRC request form triggering the IRM creation.
3. IRM appears in your DGFT repository.You log into DGFT, open the IRM/ORM Repository for your IEC, and your bank's transmission lands there. Elapsed time between the remittance landing and the IRM appearing can be anywhere from 48 hours to 6 weeks — that depends on how fast your bank batches upload.
4. You self-certify the e-BRC.Pick an IRM (or club multiple IRMs that close the same invoice / group of invoices), link to the corresponding export invoice(s), confirm values, and generate. The certificate is issued in your name, by you, to DGFT's record.
5. Attach to the claim.Download the e-BRC PDF / reference, attach to your GST RFD-01, or to the scheme claim (EPCG / SEIS / Advance Authorization) that needs it. You can also view, cancel, or track utilization of e-BRCs you've generated.

The brittle step is #3. Banks batch IRM uploads, and nobody tells you when yours has gone through. You check DGFT a week after the remittance, nothing's there; two weeks, still nothing. There's no rejection — the IRM is just absent from your repository. Most exporters find out during the quarterly RFD-01 filing, which means a 4-6 week gap between money received and refund claimable. For service exporters who live on quarterly refund timing, that gap is expensive.

04 · The fields that actually matter

The IRM record (transmitted by the bank) plus the e-BRC record (generated by you) together carry ~20 fields. Five of them are where downstream problems happen — either the IRM won't validate during self-certification, or the GST officer kicks back the RFD-01:

• Shipping Bill / Invoice reference.For goods exporters this is the Shipping Bill number. For service exporters, it's the invoice number you submitted to your bank at the time of purpose-code declaration. If this doesn't match what you claim on RFD-01, the GST officer kicks it back.
• IEC (Importer-Exporter Code).Your DGFT-issued 10-character code. Freelancers often skip this because they think they don't need an IEC for services — but you'll need one to claim a single export-scheme benefit. Get one. DGFT's IEC application fee is nominal (₹500 as of the current fee schedule), and it's a one-time setup.
• Purpose code.P0802 (software), P1006 (business / management consultancy), P0801 (hardware consultancy), and so on — the full RBI purpose-code list is structured by service category. The wrong purpose code can invalidate the e-BRC's use as proof of service export against a specific invoice category. For SEO and digital marketing receipts, use the SEO services purpose-code guide as a narrower checklist.
• Realized value in foreign currency.The bank logs what came in. If this doesn't match your invoice (remember: client-side bank fees, FX conversion loss, rail markup), the e-BRC shows a shortfall — and your claim has to reconcile it.
• Date of realization. Starts the FEMA realization clock. Foreign-currency exports must be realized within 15 months; INR-denominated within 18. This is the timestamp that binds your invoice to those windows.

05 · Why e-BRCs get stuck (and feel like rejections)

Under exporter self-certification there's no single "your e-BRC was rejected" event. Things stall at one of three gates — the IRM never appears, the self-certification fails validation, or the downstream GST claim gets kicked back. Top five causes, in rough order of frequency:

• Batch processing delay (IRM absent).Not a rejection, but reads like one. You check DGFT a week after the remittance, the IRM isn't there. Two weeks, still nothing. Your bank hasn't batched it to DGFT yet, and there's no status indicator telling you that's what's happening.
• Invoice number mismatch. You filed an invoice as INV-2026-014 on the GST portal. You told your bank INV-14/2026for the IRM, and self-certified the e-BRC with that string. The GST officer matches on exact string during RFD-01 scrutiny. No match = deficiency memo. The e-BRC itself was validly generated — it just doesn't match your GST records.
• Purpose code misuse. You bill business consultancy (P1006) but the bank tagged the IRM as P0802 (software). Self-cert technically works — until the GST officer cross-checks against your invoice line items and flags the category mismatch.
• Partial realization unexplained. Client paid $9,750 on a $10,000 invoice (client-side bank shaved $250 in wire fees). Your IRM shows $9,750. Your invoice shows $10,000. You can still self-certify the e-BRC, but the GST officer asks for a reconciliation statement. Most people give up and write off the refund on the $250.
• Missing or wrong IEC.Bank tags the IRM against a name or PAN, not an IEC. DGFT has no IEC-level entity to attach your e-BRC to. Effectively orphaned — you'll see the IRM but the repository won't let you generate against it.

06 · What changes from Oct 1, 2026

The RBI's FEMA Notification 23(R)/2026-RB (Jan 13, 2026) retires the SOFTEX regime and makes the Export Declaration Form (EDF) the default instrument for every export — goods and services, freelancer to agency.

For e-BRC specifically, three practical shifts to watch (language hedged because implementation detail is still being published):

• EDF comes with its own timing window.Public summaries of the notified framework describe service-export EDFs as due within 30 days from the end of the invoice month, with non-software services allowed on or before payment receipt. Keeping the EDF filing cadence ahead of bank matching can reduce invoice-string mismatches at self-cert time — though the actual sequencing still depends on the monthly / non-software filing window and the bank's IRM flow. A conditional win, contingent on the EDF ledger staying clean.
• EDPMS as the closure source of truth.e-BRC stays the match artifact but EDPMS becomes the overarching closure view. You'll likely see EDPMS status + e-BRC status side-by-side in the DGFT portal, with open/closed/ written-off as the closure state.
• Tighter realization clock enforcement. Bank-side and RBI-side monitoring of the 15-month / 18-month realization window is expected to tighten. That's where FEMA's 3× penalty multiplier actually bites — not at e-BRC generation, but at unrealized-and-unresolved invoices after the window closes.

In other words: Oct 1, 2026 doesn't change the exporter-self-certifies-against-bank-IRMs mechanic. It changes the cost of not staying on top of it.

07 · What a real e-BRC screen should do

Skydo, Karbon, and Winvesta each have public support content around e-BRC / FIRC flows for money they receive on their own rail. What doesn't exist today is a single service-exporter workspace that manages e-BRCs across every rail you use — Skydo plus Payoneer plus Wise plus direct SWIFT — alongside GST, DGFT, and EDPMS in one view. Your CA does that reconciliation by spreadsheet, quarterly, for a fee.

Here's the screen we're building at NiryatBox:

• A per-invoice e-BRC status pill. Awaiting remittance · Remittance received · IRM in DGFT repository · e-BRC self-certified · Utilized (on RFD-01 / scheme). Colored. Sortable. Filterable by client and by quarter.
• Bank-side nudge.7 days after the remittance lands, if the IRM still isn't in your DGFT repository, we auto-draft an email to your bank's trade-services desk with the specifics — invoice, purpose code, amount, date. One click, you just approve. Most banks move when asked by name.
• Self-cert helper. When the IRM lands, we pre-fill the self-certification form with matched invoice references, flag clubbing opportunities (multiple IRMs against one invoice, one IRM against multiple invoices), and validate the match before you generate. Less portal clicking, fewer string-match errors.
• RFD-01 ready bundle.When you're ready to claim GST refund, one click assembles invoice + FIRA + e-BRC per remittance, in the format your CA files directly.
• Cross-rail coverage.We pull inward remittance data from every rail you use, not just one. Skydo is a rail. So is Payoneer. So is direct SWIFT. e-BRC management shouldn't care which.