Bulk eBRC Generation on the DGFT Portal from Excel

When bulk generation is the right tool

DGFT opened the bulk route with Trade Notice 12/2024-25 of 14 August 2024, effective 20 August 2024, alongside the exporter API. The notice puts it plainly: exporters can generate multiple eBRCs concurrently by uploading a spreadsheet that carries the IRM mapping together with the shipping bill and invoice details, and they are to follow the rules set out in the spreadsheet template itself. Nothing about the certificate changes. A bulk row is the same mapping you would make on the Generate e-BRC form, one inward remittance applied to one export, and the same rules decide whether it is issued.

So the question is not whether bulk is better. It is whether you have a batch. A backlog of remittances from a busy quarter, a month of invoices on a services desk that is paid on every one, a run of shipping bills settled in instalments: those are batches, and typing them one form at a time is where the transcription errors come from. For one or two certificates, generating an eBRC on the DGFT portal form by form is quicker than preparing a file.

The path: Services, eBRC, Bulk Generate eBRC

Sign in at dgft.gov.in with the account linked to your IEC, open Services, then eBRC, and click the Bulk Generate eBRC tile. DGFT's User Guide on Bulk Generation of eBRC and the current FAQ on self-generation of eBRC (question 86) give the same path, and the tile is listed on the public DGFT eBRC page with the caption "Self-Certify and Generate eBRC in Bulk".

Inside the tile there is a button of the same name, Bulk Generate eBRC, and that is what opens the upload screen. The first thing on it is the type of eBRC you want to generate, and you choose it before you upload anything. That order matters: the type is fixed for the file, so a goods batch and a services batch are two files, not one. The validations DGFT prints under its template speak of four kinds, goods, deemed exports, services IT and services non-IT, and the rules that follow differ for each, which is why the type comes first.

Download Sample Excel: the columns that identify the remittance

On the upload screen is Download Sample Excel. Use it every time rather than a file kept from a previous month, because the sheet has grown since August 2024 (the new columns are below). DGFT does not host the sample on a public URL; it comes from inside the portal, after sign in.

The field table in the bulk guide, and the fuller one in section 10 of the exporter manual, version 1.2, name each column, whether it is mandatory, and its length. Every row is one remittance mapped to one export, and the first half of the row says which remittance. These columns are mandatory:

• Serial number. Unique within the file, starting from 1 and running to 999.
• Branch code, the IEC branch the certificate is generated for.
• IFSC code and AD code of the bank, as they appear on the IRM the bank sent to DGFT.
• IRM number, IRM date, IRM foreign currency code and purpose code, again exactly as the bank reported them.
• Remittance amount available in the foreign currency: the total IRM amount less any outward remittance against it, as DGFT's record shows it.

Every one of these has to agree with the IRM the bank sent to DGFT, and the guide says so on the IFSC, the IRM date and the purpose code in as many words. Open the IRM repository and copy from it; do not work from the bank's advice, which can differ in a date or a code.

The columns that identify the export and the mapping

The second half of the row says what the money paid for and how much of it you are applying. Mandatory again:

• Shipping bill, SOFTEX or invoice number and its date: the shipping bill for a direct export, the SOFTEX for software, the invoice for any other service.
• Port code, which must come from DGFT's master data.
• Bill number, the invoice the IRM is mapped against. For a service other than software it can be the same as the invoice number.
• IRM amount mapped, the part of the remittance applied to this export. Across the rows for one IRM the mapped total cannot exceed the amount available.
• Vostro payment, Y or N, with the Vostro type, SVRA or NVRA, when it is Y.
• SAC code 1, mandatory for services IT and non-IT. SAC code 2 is optional.

The optional columns cover the ORM amount mapped, a third party export flag, and the deductions. Two formats catch people: dates are dd-mmm-yyyy, so 15-Jul-2025 rather than 15/07/2025, and the serial number is typed as a number.

Deductions: a column to deduct and a column for information

Commission, discount, insurance, freight and other deductions each appear twice in the template. The "to be deducted" column reduces the net realised value on the certificate; the "for info" column records the figure without deducting it. DGFT's FAQ (question 75) states the principle for every eBRC: separate columns for items to be deducted and items not to be deducted. Put a charge in the wrong column and the net value on the certificate is wrong, and that is the figure an incentive claim or an auditor reads. It is the same split as the single-certificate form, only laid out sideways.

The columns added since August 2024

The standalone bulk guide is dated August 2024 and its table stops at the SAC codes. The exporter manual's version of the same table carries three more columns and one more mandatory field:

• Whether you want to avail GST benefits?, Y or N, mandatory.
• GST invoice number and GST invoice date, mandatory when the answer above is Y.
• Mode of Export, mandatory for services IT and non-IT.

The mode column follows Trade Notice 02/2025-26 of 21 April 2025, which introduced the Mode of Export of Services field for every eBRC generated on or after 1 May 2025. The current FAQ (question 91) confirms the column is already in the bulk upload sheet, and adds a rule worth knowing if you had a file in flight that week: a file uploaded before 1 May 2025 that failed for any reason, with the response arriving after that date, has to be uploaded again with the new field filled in. And a single IRM that covers more than one mode of service needs a separate eBRC for each mode (question 96).

Upload, Save, then sign and submit

With the type chosen, upload the file. DGFT checks the fields at this point, and the guide is blunt about what happens: if any field in any row has an error, the errors are shown during the upload and the upload fails. The whole file, not the row. A batch with one date in the wrong format goes nowhere until that date is fixed, so it pays to read the sample's instruction sheet before filling two hundred rows.

A clean upload opens a status screen with the file's status, the number of records uploaded, the success records, the number of eBRCs generated, the failed records, who uploaded it and when. Click Save. Then sign and submit. The guide names the status a saved file sits at until that is done, Success-Pending Signature, and notes that the link into the file's records is available only at that status, so that the file can be uploaded again. What the guide does not say is which signing method the bulk screen uses. It says "sign and submit" and no more, and this guide will not guess for it.

What comes back, and how long it takes

After submission the file can be searched from the same screen. Once processing is done, the Failed or Processed status link opens the rows, and for each processed row you see the eBRC number generated, the eBRC date, the total realised value and the net realised value. Each failed row carries its own message saying why. That is the payoff of the bulk route over the form: the answer arrives row by row, and one failed row does not hold the others back.

In the eBRC exporter app every row is checked before anything is filed, errors come back row by row so you know exactly what to fix, and resubmitting never creates a duplicate filing.

Reckon on about two hours. DGFT's own note on the last page of the bulk guide puts it as a range: allow 30 to 180 minutes of processing for any bulk upload file. The certificates then sit where every eBRC sits, under My Dashboard, Repositories, Bills Repository with e-BRC as the bill type, and downloading and printing an eBRC from the DGFT portal walks that search, including the one week rule on its date range.

The rules DGFT checks in bulk

The validations printed under the template are the rules the file is judged by. They are the general eBRC rules with a few lines specific to bulk, and they turn on the type:

• Services, IT and non-IT: clubbing is not allowed. One IRM generates one eBRC.
• Goods and deemed exports: clubbing is allowed and one eBRC can carry several IRMs, provided every clubbed IRM shares the same currency and the same bank, and the branch is the same for all of them and active.
• Purpose codes: no eBRC at all for P0101 or P0108. Services IT may use P0103, P0802, P0803 and P0807, and P0807 and P0802 cannot be clubbed together. Goods are limited to P0102, P0103, P0104 and P0109. Deemed exports take P1505 and P0103, and P1505 is used nowhere else. Services non-IT cannot use P0102, P0104 or P0109. IRMs with different purpose codes cannot be clubbed, except P0103.
• Amounts: the IRM amount mapped across the rows for one remittance cannot exceed the remittance amount available.

What each code means, and the currency codes the sheet expects, is in the purpose codes and currency codes guide. Read the purpose code off the IRM before you pick the eBRC type for the file, because a services row carrying P0102 or a goods row carrying P0802 fails on that line alone.

Bulk Download Request: getting the certificates out

Bulk generation has a sibling tile for the other direction. From Services, then eBRC, click Bulk Download Request, set the request type to eBRC, enter a From date and a To date, and click Submit. The request is not instant: when its status changes to Processed, a link appears on the same screen and the file downloads from there. The same screen serves inward and outward remittances, IRM or ORM, with the request type switched. DGFT's FAQ (question 53) confirms that exporters can download in bulk the eBRCs generated through the DGFT system.

What DGFT has not published

Three things the upload screen does settle, because DGFT prints them in its notes there: the file must be .xlsx, only one attachment of up to 500 kb is accepted per upload, and the sample downloads under a name in the form IEC_GENeBRC_DDMMYYHHMMSS, which you may change before uploading. Two things nothing published settles: how many rows a single file may carry beyond the serial numbers 1 to 999 the sheet allows, and whether the signature at submission is a digital signature certificate or Aadhaar e-Sign. The screen says sign and submit and no more, so this guide says the same.

The same batch without the portal

Both routes produce the same DGFT issued certificates from the same remittances. What differs is the work between the spreadsheet and the certificate.

• On the DGFT portal: one file per eBRC type, the sample Excel filled by hand, an .xlsx of up to 500 kb, Save, then sign and submit, then 30 to 180 minutes before each row shows its certificate number or its failure.
• In the eBRC exporter app: a template pre-filled with the remittances that have already arrived, every row checked before anything is filed, errors returned row by row, no duplicate on resubmission, and the certificates usually back in about two hours in the same ledger as everything else.

It is free at any volume, with no certificate limit and no card at sign-up. Create an account, or start with the bulk spreadsheet workflow.

Frequently asked questions

How do I generate eBRCs in bulk on the DGFT portal?

Sign in, open Services, then eBRC, then Bulk Generate eBRC. Choose the eBRC type, click Download Sample Excel, fill one row per remittance mapping, upload the file, click Save, then sign and submit. The file shows Success-Pending Signature until it is signed, and after processing each row carries its eBRC number and date or a failure message.

What format does the DGFT bulk eBRC template use?

An Excel file, downloaded from inside the portal with Download Sample Excel. Dates are dd-mmm-yyyy, serial numbers run from 1 to 999, the port code comes from DGFT master data, and the IRM fields must match what the bank reported. Since 1 May 2025 the sheet also carries Mode of Export of Services, mandatory for a services eBRC.

How long does DGFT take to process a bulk eBRC upload?

DGFT's bulk guide asks you to allow 30 to 180 minutes for any bulk upload file, so reckon on about two hours. When the file's status turns to Processed, each row shows the eBRC number, eBRC date, total realised value and net realised value; each failed row shows its own message.

Can several IRMs be clubbed into one eBRC in a bulk upload?

For goods and deemed exports, yes: one eBRC can carry several IRMs if they share the same currency, the same bank and the same active branch, and the same purpose code, with P0103 as the one exception. For services, IT and non-IT, no: one IRM produces one eBRC.

Why did my bulk eBRC file fail on upload?

A field error in any row fails the whole upload, and the errors are shown during the upload. Check the mandatory columns, the dd-mmm-yyyy dates, the port code against DGFT master data and the SAC code on services rows, then upload again. In the eBRC exporter app on ebrc.in every row is checked before anything is filed and the failing row is named with its field.