SB001–SB006: The ICEGATE Shipping Bill Error Codes, Explained

The validation compares a fixed set of identity parameters between the GSTN transmission and the customs record: GSTIN, Shipping Bill number, and invoice number, with taxable value and IGST paid carried alongside. Before any of that runs, GSTN applies its own five gate conditions — GSTR-1 and GSTR-3B filed; export invoices present in Table 6A; complete Shipping Bill number, date and port code against each invoice; IGST reported in Table 3.1(b) of GSTR-3B and not 3.1(a) or 3.1(c); and Table 3.1(b) equal to or greater than the total IGST in Tables 6A and 6B of GSTR-1.

The two-stage design means a refund can fail before ICES ever sees it. Records that fail GSTN's validations are not transmitted to customs at all, produce no SB-series code, and are invisible in ICEGATE — CBIC's 2018 analysis found only about 32% of GSTR-1/Table 6A records were being transmitted. An exporter whose Shipping Bill appears in no ICEGATE status report should check the GSTN side first.

SB000 means the invoice validated — not that money moves. The DG Systems guide lists four conditions under which a successfully validated Shipping Bill still produces a scroll amount of zero: the export was made under bond or LUT (no IGST was paid, so nothing refunds); the Shipping Bill covers multiple invoices and at least one is stuck in another error; drawback was claimed at the higher rate, making the Shipping Bill ineligible; or the IGST claim is below ₹1,000.

Two further gates sit between the temporary and final scroll. A Shipping Bill enters the temporary scroll but drops from the final scroll if the exporter's bank account has not been validated by PFMS, or if there is an alert or suspension on the IEC in ICES — for arrears, pending e-BRC, or similar. Both are visible in ICES reports and both are fixable (furnish correct account details; clear the suspension), but neither announces itself to the exporter.

SB001 means the Shipping Bill number or date furnished in GSTR-1 Table 6A does not match any customs record — almost always a clerical error made while filing the GST return, and fixable entirely on the GST side. The exporter amends the export invoice through Form 9A (Table 9A of a subsequent period's GSTR-1, available since 15.12.2017) with the correct Shipping Bill number, date and port code. Once GSTN retransmits, the validation reruns. No customs procedure is involved, and the CHA has nothing to correct: the filed Shipping Bill was never wrong.

SB002 means the Export General Manifest that would prove the goods left India has not been filed electronically by the carrier, so the Rule 96 precondition for treating the Shipping Bill as a refund application is unmet. The rectification is to press the shipping line to file the EGM in ICES. Where an EGM is filed but errors out, CBIC Circular 06/2018-Customs (para 6) and the DG Systems guide's Annexure B catalogue the mismatch flags — M (incorrect gateway port code), C (container number mismatch between Shipping Bill and EGM), N (number of containers), T (nature of cargo), P (number of packets), L (LEO date later than sailing date) — each with its amendment route through the service centre and proper officer. Several of these flags are themselves downstream document-reconciliation failures, which is why they recur in the pre-LEO reconciliation note.

SB003 means the GSTIN declared on the Shipping Bill is not the GSTIN that filed the corresponding GST returns — a common outcome for exporters with multiple state registrations, where the factory files the return and the head office's GSTIN reached the Shipping Bill. The published fix is a GSTR-1 amendment through Form 9A, with the caveat the Chennai Customs procedure states directly: no amendment can be made to the Shipping Bill once the EGM has been filed. Where the return-side GSTIN is the correct one, the amendment route resolves it; where the Shipping Bill's GSTIN is simply wrong, the case converges on the same post-EGM rigidity that governs SB005.

SB004 is the one benign code: GSTN transmitted the same Shipping-Bill-invoice record twice, and ICES had already validated the earlier transmission for refund. No action is required from anyone; the duplicate is ignored. Its only operational significance is diagnostic — an SB004 against an unpaid refund means the payment blocker is elsewhere (typically a scroll-stage gate such as PFMS validation), not in the invoice matching.

SB005 means the invoice number in the Shipping Bill's invoice table does not exactly match the invoice number in GSTR-1 for the same supply — the most common and the most consequential code, because neither record can simply be amended into agreement after EGM. Its two causes, per CBIC: a typographical error at data entry, or the exporter's use of two invoice sets, one for GST and one for customs. Its fix is unique among the codes: a Concordance Table (Annexure A) submitted to the Assistant Commissioner (IGST Refunds) and verified through a permanent officer interface, at ₹1,000 per Shipping Bill under Circular 05/2021-Customs. The full mechanics — including the Rule 96 proviso that shifts the refund's deemed filing date until the mismatch is rectified — are in SB005: Why Your IGST Refund Blocks After EGM and How to Clear It, and the formatting divergence that typically causes it is dissected in Invoice Number Formatting: How Tally and ICEGATE Disagree.

SB006 is the inland container depot (ICD) variant of the manifest failure: the local EGM exists, but the gateway port's electronic EGM is missing or stuck in error, so ICES cannot confirm the goods left India. A manually filed gateway EGM does not suffice — the EGM must be filed in ICES at the gateway port. The published rectification has three parts: file the train/truck summary immediately after cargo leaves the ICD; have the shipping line include the ICD Shipping Bill in its gateway-port EGM along with the transference copy; and clear residual errors through service- centre amendment approved by the proper officer. Exporters shipping through ICDs see SB006 chronically, because it depends on two handoffs neither the exporter nor the CHA controls.