e-BRC Self-Certification: From Bank Realization to Refund Document

Not every inward remittance can become an e-BRC, and the gate is the RBI purpose code the bank attached to the IRM. The DGFT exporter manual is specific: an e-BRC "cannot" be generated for P0101 and P0108; for goods, only P0102, P0103, P0104 and P0109 are allowed; P0103 (advance receipt against exports) "can be used standalone" and "can be clubbed with any other purpose codes for inward remittance"; services-IT e-BRCs run on P0802, P0803, P0807 (plus P0103); and P1505 is reserved for deemed exports.

The operational meaning sits at the bank counter, months before anyone thinks about certificates: the purpose code is declared when the remittance is received, usually by whoever answers the bank's disposal query. A receipt coded outside the permitted set leaves the exporter with realized money that the platform will not certify against a shipping bill — a defect discoverable only at e-BRC time and correctable only through the bank's re-coding process. The prevention is a standing instruction: every export receipt's purpose code is checked against the permitted set on the credit advice, the day it lands.

A goods e-BRC is a linkage record, and the manual names its matching keys: shipping bill number, invoice number, shipping bill date, and port code. Anyone who has read this library's customs cluster will recognise the list — these are the same identity fields whose exact-string mismatches produce the SB001/SB005 refund blocks on the IGST side. The realization pipeline re-runs the identity test: an invoice number that diverged between the accounting system and the Shipping Bill at filing time resurfaces here as an IRM that will not sit cleanly against its bill.

Three mapping situations cover most real cases. One IRM, one bill is trivial. One IRM, many bills (a consolidated buyer payment) is split across bills, with the exporter certifying the allocation. Advance receipts ride P0103 and are clubbed with the final-payment codes when the shipment follows. In each case the platform's Risk Management System can flag the generated e-BRC "Under Review" (manual, Section 9) — self-certification is post-audited, not unexamined, and the GSTIN fields the goods flow captures ("GSTIN of Branch, GST Invoice No. and GST Invoice Date" become mandatory when GST benefit is claimed) are exactly the fields a cross-regulator verification would test.

The workable cadence is monthly, in three passes: reconcile new IRMs against open shipping bills (flagging purpose-code defects for bank correction while they are fresh); generate e-BRCs for cleanly matched pairs, with the GST fields completed wherever refund linkage is claimed; and review anything the RMS has flagged, with the underlying bank advice and invoice at hand. Exporters who batch this annually — typically when an incentive return forces it — inherit a year of coding defects and drifted identifiers at the worst possible time.

TradeWatch carries the e-BRC layer inside its readiness intelligence: purpose-code checks on receipt, IRM-to-bill matching proposals keyed on the same four identity fields it reconciles pre-shipment, and RMS-flag tracking, each anchored to the DGFT manual's rules. Kanan Labs prepares evidence and readiness; the self-certification itself is the exporter's declaration, and the underlying realization records remain the AD bank's. It does not file Shipping Bills and holds no customs credentials — your licensed CHA files.