eBRC Generation and Export Realisation: How Shipping Bill, Invoice and Remittance Need to Match

Your overseas buyer has paid.

The money is in India.

But the export transaction is not automatically complete.

For many exporters, the next questions are:

• Where is the inward remittance?
• How is it linked to the export invoice?
• How do I generate the eBRC?
• Why is the Shipping Bill or invoice not mapping correctly?

This is where eBRC becomes part of the export transaction.

What changed in the revamped eBRC system?

DGFT's revamped eBRC system shifted more of the generation workflow to exporters.

DGFT describes the system as based on electronic Inward Remittance Messages (IRMs) transmitted directly by banks.

Using those IRMs, exporters can self-certify eBRCs under the prescribed rules.

The DGFT services include:

• IRM / ORM Repository
• Generate eBRC
• View / Cancel eBRC
• IRM Utilization Report

That last item is particularly useful because it connects:

IRM → Shipping Bill / Invoice → eBRC

This is fundamentally a reconciliation trail.

What is an IRM?

IRM means Inward Remittance Message.

It represents the inward foreign-exchange remittance information transmitted by the bank into the DGFT framework.

For the exporter, the important checks are:

• Is the remittance visible?
• Is it under the correct PAN / IEC context?
• Is the amount correct?
• Is the remittance date correct?
• Is the currency correct?
• Can it be mapped to the intended export invoice / Shipping Bill?
• Has part of the IRM already been utilised?

A missing IRM and an incorrect invoice mapping are different problems.

Treat them separately.

How eBRC generation works in practical terms

DGFT's exporter manual describes the flow through the eBRC module after login.

At a high level:

Step 1: Find the inward remittance

Go to the IRM / ORM repository and identify the relevant remittance.

Step 2: Start Generate eBRC

The system allows generation for different export categories including physical exports of goods.

Step 3: Select / map the relevant export transaction

Connect the remittance to the relevant invoice / Shipping Bill information as required by the workflow.

Step 4: Confirm realisation values

Check the realised amount, currency and related details.

Step 5: Self-certify

Generate the eBRC only after confirming that the remittance genuinely relates to the declared export.

The exact screen sequence can change, so use the current DGFT manual for the live portal.

The key reconciliation: three records, one transaction

Consider this example.

Commercial Invoice

Invoice: INV-1482
Value: USD 48,000

Shipping Bill

Shipping Bill: 7421981
Invoice reference: INV-1482
FOB value: equivalent customs value

Bank remittance

IRM amount: USD 47,850

Does USD 47,850 mean the transaction is wrong?

Not necessarily.

The difference may reflect:

• bank charges
• permitted deductions
• commission
• short payment
• negotiated commercial adjustment
• partial realisation

The useful question is:

Can the difference be explained and correctly mapped under the applicable DGFT/RBI rules?

Do not force the numbers to match by changing records without understanding the reason.

Common eBRC problems exporters should investigate

1. IRM not visible

First ask whether the bank has transmitted the remittance correctly.

This is different from a Shipping Bill mapping issue.

2. Wrong invoice selected

The remittance exists, but it has been associated with the wrong export invoice.

3. Amount does not equal invoice value

There may be a valid commercial explanation.

Reconcile gross invoice value, realised amount and any accepted deductions.

4. Shipping Bill not available / not integrated

The export customs record may not yet be visible in the required downstream system.

Check Shipping Bill integration status rather than repeatedly editing eBRC data.

5. IRM already utilised

A remittance cannot simply be assigned again if it has already been consumed in another mapping.

Use the IRM Utilization Report to understand the existing linkage.

6. Currency / remittance detail inconsistency

Confirm the correct remittance and transaction instead of choosing the closest-looking IRM.

Example: one payment covers three invoices

An exporter receives:

USD 120,000

The buyer's remittance covers:

• Invoice A: USD 50,000
• Invoice B: USD 40,000
• Invoice C: USD 30,000

Operationally, this is not “one payment = one invoice”.

The exporter has to maintain a clear allocation trail.

The real control is:

Can we prove how this IRM was allocated across the export invoices and related Shipping Bills?

That matters for:

• eBRC generation
• realisation tracking
• internal receivables closure
• later regulatory / benefit use

Example: three payments against one invoice

The reverse also happens.

Invoice: USD 100,000

Buyer remits:

• USD 30,000
• USD 40,000
• USD 30,000

The export team should not treat each inward remittance as an unrelated transaction.

They are three pieces of the same receivable.

The eBRC / realisation workflow should preserve that connection.

What should your team reconcile before generating eBRC?

Export identity

- IEC / exporter
- buyer / remitter where relevant
- invoice reference

Shipment

- Shipping Bill number
- Shipping Bill date
- port / customs linkage where relevant

Commercial value

- invoice amount
- currency
- FOB / export value where applicable

Remittance

- IRM number
- inward remittance amount
- remittance currency
- remittance date
- available / utilised balance

Adjustment

- bank charges
- deductions
- short realisation
- partial receipts
- credit notes / commercial adjustments where legitimately applicable

Do not confuse eBRC with “the bank gave me payment proof”

The old mental model was often:

ask bank for BRC

The revamped DGFT process is more data-driven.

The bank provides the inward remittance message into the system.

The exporter uses that remittance data to generate the eBRC under DGFT's self-certification process.

That makes exporter-side data discipline more important.

If invoice, Shipping Bill and remittance references are poorly maintained, the problem appears later during mapping.

What to do when eBRC is not generating

Use this sequence:

1. Is the IRM present?

If not, investigate the bank/remittance transmission first.

2. Is the correct IRM unused / sufficiently available?

Check utilisation.

3. Is the Shipping Bill / invoice available?

If not, check integration.

4. Do amount and currency make sense?

Reconcile rather than forcing equality.

5. Is the allocation commercially explainable?

Document partial payments, deductions or multi-invoice allocation properly.

6. Is the problem portal-specific?

Use DGFT Helpdesk if the data is correct but the system is not behaving as expected.

The practical takeaway

eBRC is not a standalone certificate problem.

It is the final evidence layer of an earlier commercial transaction.

The cleanest workflow is:

Order → Invoice → Shipping Bill → Shipment → Buyer pays → IRM → eBRC

The more accurately those stages are connected from the beginning, the less reconciliation work is needed at realisation stage.

This guide is educational. DGFT and RBI processes change and transaction-specific rules may apply. Use the current DGFT eBRC manual, your bank records and professional advice for live transactions.

This guide is educational and does not replace examination of the specific credit, applicable ICC rules, international standard banking practice, contractual requirements or professional advice relevant to a particular transaction.