e-Way Bills Are About to Get Stricter —Ship-to GSTIN Becomes Mandatory from 1 August 2026

For a Lucknow manufacturer or trader that ships goods to a job-worker, a branch office, or a buyer's separate delivery address, one small data field is about to become the difference between an e-way bill that generates cleanly and one that gets rejected at the point of dispatch. The Goods and Services Tax Network (GSTN) has issued an advisory, dated 17 June 2026, making the "Ship-to GSTIN" field mandatory across a wide range of e-Invoice and e-Way Bill API transactions with effect from 1 August 2026 — alongside a new, voluntary facility to formally close an e-way bill once delivery is complete. Neither change amends a provision of the CGST Act; both are systems-level changes. But for any Uttar Pradesh business generating e-invoices or e-way bills through an ERP, GST Suvidha Provider (GSP), or Application Service Provider (ASP), this is the kind of change that causes real disruption if it is discovered only in the last week of July.

What the advisory actually says

GSTN's earlier advisory of 20 May 2026 had first flagged that the Ship-to GSTIN would be mandatorily captured in Bill-to/Ship-to transactions, with the value "URP" (Unregistered Person) to be entered where the consignee is unregistered. Trade bodies, ERP vendors, GSPs, ASPs and private Invoice Registration Portals then sought clarification on how this requirement applies where an e-way bill is generated together with the e-invoice, or later using the Invoice Reference Number (IRN). GSTN's follow-up advisory dated 17 June 2026 answers that question, and simultaneously introduces the voluntary e-way bill closure facility described below. Both sets of changes were released in the Sandbox environment for testing from mid-June, and go live in Production on 1 August 2026.

Where the mandatory Ship-to GSTIN applies

The requirement is not limited to one screen or one API. GSTN's advisory lists five specific flows where it bites: generating an IRN and e-way bill together; generating an e-way bill later using an existing IRN; genuine Bill-to/Ship-to transactions (where the buyer and the consignee are different persons); "combination" transactions that involve both Bill-to/Ship-to and Bill-from/Dispatch-from; and, separately, the new voluntary closure of an e-way bill after delivery.

• Generate IRN and e-way bill together: the field ShipDtls.Gstin becomes conditionally mandatory whenever a Ship-to legal name and address are provided and e-way bill generation is also requested.
• Generate e-way bill using an existing IRN: a new field, Gstin, has been added under ExpShipDtls in this API and is now mandatory. An optional Trade Name field, TrdNm, has also been added.
• Where no GSTIN applies: the value "URP" may still be entered wherever the Ship-to party is unregistered, or GSTIN genuinely does not apply to the transaction.

The validations that can now reject a bill outright

Alongside the mandatory field, GSTN has built in validations that a compliance team should know before 1 August. In a genuine Bill-to/Ship-to transaction, the Ship-to GSTIN cannot be the same as the Bill-to GSTIN — the two are meant to be distinct persons, and the system will reject an entry that repeats the Bill-to GSTIN in the Ship-to field. The system also checks that a valid GSTIN has been entered, that the Ship-to state code matches the GSTIN, and that the Ship-to PIN code belongs to that state. The Sandbox environment lists indicative error codes for these checks — for example, a missing Ship-to GSTIN where ship details are provided, a repeated Bill-to/Ship-to GSTIN, and state-code or PIN-code mismatches — so a rejected e-way bill during dispatch is very likely to trace back to one of these fields.

Two carve-outs worth knowing: exports, and B2B/SEZ

The advisory treats exports and B2B/SEZ transactions differently, and the difference matters operationally. For export e-way bills, the ship details — including GSTIN — given at the IRN stage may still be replaced when the e-way bill is later generated using that IRN, and "URP" is permitted where no domestic registered Ship-to GSTIN applies to the export scenario. For B2B and SEZ transactions, the position is reversed: ship details fixed at the IRN stage cannot be replaced later at the e-way-bill-by-IRN stage — though if a GSTIN was left blank at the IRN stage, it can still be added when the e-way bill is generated, subject to the usual validations. GSTN has also clarified that an older IRN generated with the same GSTIN in both the Bill-to and Ship-to fields will continue to generate a regular e-way bill without being caught by the new "must be distinct" validation.

A Ship-to field that used to be optional paperwork is about to become a hard validation — the difference between an e-way bill that generates and goods held up at dispatch.

A new — but still optional — way to close an e-way bill

The second, unrelated change is a Voluntary Closure facility for e-way bills, meant to record that a delivery has actually been completed. It may be used by the supplier, the recipient, the transporter involved in the movement, or the driver/authorised person whose mobile number was captured for this purpose. Closure can be done e-way-bill-wise or date-wise, either through the GST portal after login, or through a new closure API that requires the e-way bill number, the closure date, and remarks — useful for businesses that want to integrate this into their own ERP or logistics systems.

Two practical points for now: first, there is no separate "Closed" status yet — the existing statuses (Active, Cancelled, Discarded) continue to apply during this stabilisation period, so a closed e-way bill does not visibly change state in the system. Second, actions such as updating the transporter, extending validity, or updating the vehicle remain possible even after an e-way bill has been marked closed — GSTN has described this as a temporary relaxation that will be tightened once the system stabilises. There is also no API yet to capture a driver's mobile number for closure purposes (that remains portal-only for now), and no API to retrieve which bills have already been marked closed.

What to do before 1 August 2026