Invoice Number Formatting: How Tally and ICEGATE Disagree

Rule 46(b) of the CGST Rules, 2017 defines the lawful shape of a tax-invoice serial number: "a consecutive serial number not exceeding sixteen characters, in one or multiple series, containing alphabets or numerals or special characters- hyphen or dash and slash symbolised as '-' and '/' respectively, and any combination thereof, unique for a financial year." Four constraints follow: at most 16 characters; letters and digits; exactly two permitted special characters, hyphen and slash; and uniqueness within the financial year, which in practice means restarting or re-seriesing each 1 April.

Everything else commonly found in voucher formats sits outside the rule. Ampersands, hash signs, full stops, apostrophes, commas and spaces are not in the permitted set. A number longer than 16 characters — easily produced by a format like KLPL/EXP/2026-27/0042, which runs 21 — is not a valid serial number at all, and the GST portal's Table 6A entry rejects it, leaving the exporter unable to file the return consistently with the document already issued. For export invoices, the same rule adds the endorsement requirement — "SUPPLY MEANT FOR EXPORT/SUPPLY TO SEZ UNIT OR SEZ DEVELOPER FOR AUTHORISED OPERATIONS ON PAYMENT OF INTEGRATED TAX", or its without-payment-under-bond-or-LUT counterpart — which is how one invoice serves both the GST and the customs record.

Voucher-numbering conventions in Indian accounting software were designed for internal series control, not for cross-system string matching, and the divergence patterns are consistent. Prefix-and-suffix formats encode company, series and financial year around the sequence number — EXP/2026-27/042 — and every element is a chance to differ from what another system holds: the financial year written 2026-27 in one place and 26-27 in another, the sequence zero-padded to three digits in the ledger and four on the printed invoice, the prefix present in the accounting record and dropped at re-entry.

A second pattern is the domestic/export duality. Exporters commonly run one Tally series for GST-compliant domestic tax invoices and generate a separately numbered commercial invoice for the foreign buyer — the exact practice CBIC Circular 05/2018-Customs, para 2(ix), identifies as the root cause of invoice mismatch: "exporters are using two sets of invoices, one invoice for GST and another invoice for Customs." After GST, that duality has no legal basis; the DG Systems guide is explicit that the invoice declared in the Shipping Bill must be the GST-compliant invoice, since IGST is paid on the actual transaction value between exporter and consignee. But the duality persists operationally, because the commercial invoice carries buyer-facing formatting the tax series does not.

The Shipping Bill's invoice number is a re-keyed copy, and that is its vulnerability. The CHA's EDI software takes the invoice identifier from the commercial documents the exporter sends — frequently a PDF, sometimes a scan or a photographed copy — and a human operator or an import routine writes it into the draft Shipping Bill. The GST portal validates its string against Rule 46(b) at entry; the customs draft has no knowledge of what GSTR-1 will later say. Nothing in the filing path compares the two strings before the Let Export Order, unless someone deliberately performs that comparison at the draft-checklist stage.

That checklist moment is the single point where the error is still free to fix. The draft comes back from the CHA for approval; the invoice number on it either equals the tax-invoice string in the accounting system, character for character, or it does not. The GST Portal's own guidance states the standard — invoice numbers in Table 6A "are same as that given in Shipping Bill" — and the comparison takes seconds per invoice when it is actually performed against the issued invoice rather than against memory.