The electronic bank realisation certificate, end to end

An eBRC is the electronic record that an exporter has been paid. DGFT's own frequently asked questions on self-generation of the eBRC, version 1.0 of March 2024, define it as a certificate issued by DGFT as confirmation that the exporter has received payment from the buyer against the export of goods or services. That single sentence carries the change most guidance has not caught up with: the certificate is issued by DGFT off data the bank supplies, and since the revamp it is generated by the exporter rather than by the bank.

Who generates an eBRC now, and since when?

DGFT Trade Notice 33/2023-24 dated 10-11-2023 announced the upgraded system. It records that the directorate has implemented an enhanced eBRC system based on electronic inward remittance messages to be transmitted directly by banks to DGFT, and that based on the messages received, the exporters shall self-certify their eBRCs. The trade notice set a soft launch from 15-11-2023, with each bank setting its own cut-off date after user acceptance testing, and required all banks to complete application programming interface integration by 31-01-2024.

The transition was deliberately overlapping, which is why both arrangements are still described in the wild. The same trade notice provides that for remittance messages generated before a bank's cut-off date, the bank generates the eBRC under the legacy process, and that both the upgraded and legacy systems operate simultaneously until all banks have transitioned. DGFT's frequently asked questions add that after a bank's successful integration, generation from the bank's side is discontinued for messages dated on or after the cut-off, and that the ownership of the eBRC system lies with DGFT, making its instructions the primary guidance.

What is an inward remittance message, and why does it govern everything?

An inward remittance message is the bank's electronic record of a payment arriving, and it is the only thing an eBRC can be built from. DGFT's frequently asked questions define it as a reference number assigned by the bank to an inward remittance transaction, used to identify the transaction and link it to the exporter's account, and answer the obvious question directly: an exporter cannot generate the eBRC without a message. Trade Notice 33/2023-24 restricts what banks push, requiring them to send messages pertaining to the trade account only, meaning remittances for goods or services exports, and not capital account remittances.

Because inward remittance messages are keyed to the exporter's permanent account number, and importer exporter codes are linked to that number, the trade notice provides that only the concerned importer exporter code holder has visibility of their own messages on the DGFT website. The practical consequence for an exporter chasing a certificate is that the first question is never about the certificate. It is whether the message exists, because until the bank has pushed it there is nothing to certify against.

How is an eBRC actually created?

By matching. Trade Notice 33/2023-24 provides that the exporter will create eBRCs by matching an inward remittance message with the relevant shipping bill, SOFTEX or invoice details, and that multiple messages may be grouped under one eBRC, or one message split across several eBRCs. That many to many relationship is the part exporters underestimate. A single shipping bill paid in two instalments through two banks produces two eBRCs, one against each payment, per DGFT's frequently asked questions, and a single large remittance covering four shipments is split rather than duplicated.

The certification is validated rather than free text. The trade notice states that the Reserve Bank purpose code and other fields in the remittance message are used to validate the eBRC fields being certified by the exporter, and DGFT's frequently asked questions record that for deemed exports the purpose code P1505 is the only code permitted for eBRC creation. They also confirm that the shipping bill currency may differ from the remittance currency, and that where a shipping bill is not available in the export monitoring system, the exporter can add shipping bill metadata and generate the eBRC on that basis.

What does the bank still do?

More than the phrase self-certification suggests. The bank supplies the remittance message, and it retains oversight of what is built on it. Trade Notice 33/2023-24 provides that banks have access to all eBRCs created from the messages they input, and that they may flag any eBRC for further examination or request input from the exporter concerned. DGFT's frequently asked questions add that banks can flag an eBRC through a risk based management system and can cancel one, that flagging does not by itself affect validity, and that where a purpose code on a message is wrong it is the bank that amends the message.

The division of cancellation rights is worth knowing before you need it. DGFT's guidance states that an exporter can cancel eBRCs issued through DGFT, but cannot cancel eBRCs that were issued by banks under the legacy process. An exporter carrying certificates from both eras therefore has two different correction routes on one book, and the older ones go back through the bank.

Why does an eBRC not close your bank's EDPMS entry?

This is the single most expensive misunderstanding in the area, and DGFT states the position in the plainest terms available. Asked how an eBRC is obtained where inward payments are netted off, its frequently asked questions answer that it is important to note that the export monitoring system and the eBRC operate as distinct systems, and repeat the point when asked about shipping bills not present in that system. Generating an eBRC on the DGFT portal does not, of itself, close the entry your authorised dealer bank is watching.

The reason is that the two artefacts answer to different regulators for different purposes. The Reserve Bank's FED Master Direction No. 16/2015-16 on Export of Goods and Services deals with issuance of the eBRC at paragraph C.30 and records that authorised dealer banks are required to update the export monitoring system with data of export proceeds on an as and when realised basis, and, with effect from 16-10-2017, to generate the eBRC only from the data available in that system. That direction was written for banks issuing certificates. DGFT's own guidance acknowledges the point, noting that under the new workflow the exporter declares eBRCs directly and they remain available to banks for reconciliation. Why your shipping bill is still showing as open in EDPMS covers the other half of that loop.

What consumes an eBRC downstream?

Scheme and authorisation work. DGFT's frequently asked questions describe the bills repository where a generated eBRC is found, and the search parameters it exposes are the tell: bank realisation number, issue date range, the date the amount was realised in the bank, free on board value, shipping bill number, date and port, bill identifier, authorisation number and utilisation status. A certificate carrying an authorisation number and a utilisation status is an artefact designed to be consumed against something, and partly consumed at that.

What it is not needed for is the refund of integrated tax on exported goods. Paragraph 48 of CBIC Circular No. 125/44/2019-GST dated 18-11-2019 clarifies that realisation of consideration is a condition for export of services but not a pre-condition for export of goods, and that insistence on proof of realisation for processing refund claims on export of goods was not envisaged. We do not name the Handbook of Procedures paragraphs that require an eBRC against particular schemes, because we could not confirm the current text of those paragraphs against an official source at the time of writing.

Where does the eBRC go wrong?

Four places, and only one of them is the certificate itself.

• The message never arrived. No inward remittance message, no eBRC, per DGFT's frequently asked questions. Where a rupee payment arrives through another bank, the exporter's own bank has to report it before it reaches DGFT.
• The purpose code is wrong. The code validates the certified fields, and DGFT's guidance directs the exporter to the bank to have the message amended. It is not editable at the DGFT end.
• The certificate exists and the bank entry does not close. The two systems are distinct, so a complete set of eBRCs is not evidence that anything is reconciled at the bank.
• The split is wrong. Grouping several messages under one certificate, or splitting one across several, is a decision the exporter makes and later scheme utilisation is measured against, so it is worth making deliberately rather than in the order remittances happened to land.

Where to go from here

The eBRC sits at the join between the shipment file, the bank's monitoring obligation and the schemes that pay out against it, so each of those has its own clock.

• The bank's side of the same shipment. Why your shipping bill is still showing as open in EDPMS explains what actually closes an entry, and what does not.
• The deadline the realisation itself runs to. The realisation clock changes on 01-10-2026 sets out the window a shipment is judged against and the change coming to it.
• The money the certificate unlocks. The two clocks on every RoDTEP claim covers the scheme dates that run after the money is home.
• The tax side of the same export. GST refund on exports: the two routes shows where realisation matters to a refund and where it does not.

Purser holds the shipment record that the shipping bill number, the invoice and the realised amount all belong to, so a remittance can be placed against the shipments it actually paid for before anything is certified. Purser never submits to a government portal and it never sends an outbound message without a recorded human approval event, so the certification stays yours, on your login, at the moment you choose. What changes is that the matching was worked out against one record instead of a bank statement and a folder. Purser Outbound is where the record lives.

Frequently asked questions

Who issues the eBRC now, the bank or the exporter?

The exporter generates it and DGFT issues it. DGFT Trade Notice 33/2023-24 dated 10-11-2023 provides that banks transmit electronic inward remittance messages directly to DGFT and that exporters shall self-certify their eBRCs from those messages. Banks continued to generate certificates under the legacy process for messages dated before each bank's own cut-off date, so an exporter's book can contain certificates from both arrangements.

Can an eBRC be generated without an inward remittance message?

No. DGFT's frequently asked questions on self-generation of the eBRC state plainly that an exporter cannot generate the eBRC without an inward remittance message. Where a rupee payment reaches the exporter through a different bank, the exporter's own bank has to report the message before it becomes visible on the DGFT portal, so the first check on a missing certificate is always whether the message exists.

Does generating an eBRC close my EDPMS entry?

No. DGFT's frequently asked questions state that the export monitoring system and the eBRC operate as distinct systems. The certificate records that DGFT accepts the exporter has been paid; the entry your authorised dealer bank holds is a separate obligation under the Reserve Bank's FED Master Direction No. 16/2015-16, and it is closed at the bank rather than by anything done on the DGFT portal.

Can one eBRC cover several shipping bills?

Yes, in both directions. DGFT Trade Notice 33/2023-24 provides that multiple inward remittance messages may be grouped under one eBRC, or one message split across several eBRCs. Where part payments against a single shipping bill arrive at two different banks, DGFT's frequently asked questions direct the exporter to generate a separate eBRC against each payment.

Is an eBRC needed to claim a GST refund on exported goods?

Not for goods. Paragraph 48 of CBIC Circular No. 125/44/2019-GST dated 18-11-2019 clarifies that realisation of consideration is one of the conditions for export of services but not a pre-condition for export of goods, and that insistence on proof of realisation for processing refund claims related to export of goods was not envisaged. A bank realisation or foreign inward remittance certificate is required for the export of services.