(A) Voluntary Closure of e-Way Bill
(B) Mandatory Ship-to GSTIN in Bill-to/Shipto Transactions
[Read with GSTN FAQs dated 01.07.2026 — changes effective from 1st August 2026]
1. Background
Vide the GSTN Advisory dated 2nd July 2026 published on the common portal, the Goods and Services Tax Network (GSTN) has informed stakeholders that the doubts, queries and representations received from taxpayers, trade, GST Suvidha Providers (GSPs) and other stakeholders — regarding the mandatory capture of the Ship-to field in e-Way Bills and the voluntary closure of e-Way Bills — have been examined, and that a comprehensive set of FAQs has been issued clarifying the applicable system validations, procedural requirements and manner of compliance.
Pursuant to the said GSTN Advisory dated 02.07.2026, two detailed sets of FAQs, both dated 1st July 2026, have been released, explaining the following changes to the e-Way Bill (EWB) ecosystem effective from 1st August 2026:
This Circular summarises both changes, their business impact, the API-level validations,
and the action points that clients should complete before the go-live date. Relevant
changes have already been released in the Sandbox environment for testing by ERP
vendors, GSPs, ASPs and API users.
| Sl | Change Introduced | Nature | Effective Date |
|---|---|---|---|
| 1 | Voluntary Closure of e-Way Bill after completion of delivery | Voluntary facility | 1st August 2026 |
| 2 | Capture of Ship-to GSTIN as a mandatory data element in Bill-to/Ship-to and Combination transactions | Mandatory validation | 1st August 2026 |
PART A — Voluntary Closure of e-Way Bill
2. What the facility is
The Voluntary e-Way Bill Closure facility enables the closure of an e-Way Bill after delivery of goods has been completed, so that the completion of movement is formally recorded in the system. Closure is entirely voluntary — there is no penal consequence for not closing an EWB. Closure is distinct from cancellation (used where the EWB was wrongly generated or movement did not take place) and from expiry (which operates automatically on the lapse of the validity period).
3. Key features at a glance
| Parameter | Position |
|---|---|
| Nature of facility | Voluntary — not mandatory |
| Effective date | 1st August 2026 (revised implementation date) |
| Who can close | Supplier, Recipient, Transporter, or Driver/Authorised person whose mobile number has been provided for closure |
| When to close | On the date of delivery or the immediately succeeding day (advisory); facility remains available up to one day after expiry of EWB validity |
| Date of closure | Must fall between the date of generation and the date of expiry of the EWB |
| Portal modes | EWB-wise closure or Date-wise (multiple EWBs) closure for logged-in users |
| Driver-based closure | Portal-based mobile number closure facility only (not available via API) |
| Closure remarks | Free text, up to 100 characters |
4. Modes of closure — who can do what
| Person | Mode Available | Remarks |
|---|---|---|
| Supplier | Portal login — EWB-wise or date-wise; API (if integrated) | Closure after completion of delivery |
| Recipient | Portal login — EWB-wise or date-wise; API (if integrated) | Closure after receipt of goods (inward) |
| Transporter | Portal login — EWB-wise or date-wise; API (if integrated) | Date-wise closure useful for multiple EWBs of a single date |
| Driver / Authorised person | Portal-based mobile number closure only | All active EWBs linked to the mobile number appear under the Search option; mobile number is optional and may be provided at the time of EWB generation or updated during vehicle updation, consolidated EWB operations, or validity extension. |
5. API impact — current position
| Issue | Current Position |
|---|---|
| API for closure of EWB | Available — requires EWB number, closure date, and remarks. |
| Date-wise bulk closure through API | Not supported currently. |
| API to retrieve closed EWBs (including date-wise) | Not available currently; may be considered after stabilisation. |
| Separate ‘Closed’ status in Get EWB Details API | Not introduced at present; proposed in due course. |
| Mobile number capture for driver closure via API | Not available — portal only. |
| ‘ClosedBy’ field in API response | Not available currently. |
| Closure date/remarks in EWB print | Not available currently. |
| Impact on e-Invoice API / IRN+EWB flow / EWB by IRN API | No impact; EWBs generated along with or using IRN can be closed. |
6. Status framework and post-closure behaviour
The existing status framework of Active, Cancelled and Discarded continues during the
initial stabilisation period; a separate “Closed” status is proposed to be introduced in due
course. Consequently, an EWB marked as closed may not immediately reflect a “Closed”
status, though closure details are captured in the system.
As a temporary relaxation, user actions such as Update Transporter, Vehicle Updation
and Extend Validity will continue to remain available even after closure. Once the system
stabilises, these post-closure actions will be suitably restricted. Clients should therefore
not treat closure as a system lock at this stage, and should build internal discipline
around it.
7. Closure vs. Cancellation vs. Expiry
| Aspect | Closure | Cancellation | Expiry |
|---|---|---|---|
| Trigger | User action after completion of delivery | EWB wrongly generated or movement did not take place | Automatic, on lapse of validity period |
| Voluntary? | Yes | Subject to applicable rules and time limits | Not a user action |
| Purpose | Records completion of movement | Nullifies an incorrect EWB | Ends the transportation validity |
| Who acts | Supplier / Recipient / Transporter / Driver | Generator of the EWB | System |
PART B — Mandatory Ship-to GSTIN in Bill-to/Ship-to Transactions
8. The change
In Bill-to/Ship-to and Combination transactions, the Ship-to GSTIN is required to be captured as a mandatory data element wherever the Ship-to party is registered. Where a GSTIN is not available, “URP” (not case-sensitive) may be entered, wherever applicable.
The stated objectives are improved traceability of goods movement, a stronger audit trail, and system-based verification by authorised officers. The requirement applies not only to standalone EWB generation but also to the Generate IRN + EWB together flow and the eWay Bill by IRN flow.
9. Transaction-type matrix
| Transaction Type | Example | Movement of Goods | Ship-to GSTIN Required? |
|---|---|---|---|
| Regular | A Ltd. sells to B Ltd.; goods move from A Ltd. to B Ltd. | Supplier to buyer | No — Ship-to GSTIN must NOT be sent (Error 616 in API). |
| Bill-to / Ship-to | A Ltd. bills B Ltd.; goods shipped to C Ltd. on B Ltd.’s instruction. | Supplier to third party | Yes — GSTIN of C Ltd. if registered; “URP” if unregistered. |
| Bill-from / Dispatch-from | A Ltd. bills B Ltd.; goods dispatched from C Ltd. to B Ltd. | Third party to buyer | No — Delivery is to the buyer who is already the Bill-to party (Error 864 if sent). |
| Combination | A Ltd. bills B Ltd.; goods move from C Ltd. to D Ltd. | Third party to fourth party | Yes — GSTIN of D Ltd. if registered; “URP” otherwise; Dispatch-from details of C Ltd. also required. |
10. Bill-to and Ship-to GSTIN cannot be the same
In a Bill-to/Ship-to transaction, the Bill-to party and the Ship-to party are expected to be
distinct persons. The same GSTIN cannot be entered in both fields (Error 618 / 2323).
Accordingly, where goods are supplied to a buyer and delivered to the buyer’s own
warehouse or additional place of business, the transaction should NOT be entered as Billto/Ship-to. It should be entered as a regular supply, with the actual delivery address
mentioned in the Bill-to address / place of delivery field
11. Confidentiality of Ship-to GSTIN
| Question | Position |
|---|---|
| Will Ship-to GSTIN be printed on the EWB? | No. |
| Will Ship-to GSTIN be returned in GET e-Way Bill APIs? | No; Ship-to Trade Name will also not be provided. |
| What remains visible on the EWB? | Ship-to address and PIN code, as per existing practice. |
| Who can view the Ship-to GSTIN? | Only authorised officers, for verification and enforcement. |
| Buyer does not wish to share Ship-to GSTIN with supplier/transporter? | Buyer may generate the EWB themselves (as an inward EWB) and enter the Ship-to GSTIN directly. |
12. Export and merchant-exporter scenarios
| Scenario | Treatment |
|---|---|
| Export — goods billed to overseas buyer, moved to port/airport/ICD/CFS/customs area/freight-forwarder/CHA-nominated location | Ship-to GSTIN to be entered as “URP” where the Ship-to location is export-linked and no domestic registered Ship-to GSTIN applies. |
| Effect of entering URP | Purely a system-level treatment for EWB generation; the export character of the supply continues to be determined by the export invoice, shipping bill, customs, and transport documents. |
| Ship-to address / PIN in export cases | Actual Indian destination — port, airport, ICD, CFS, customs area, freight-forwarder, or CHA-nominated location. |
| Merchant exporter | Bill-to GSTIN = merchant exporter’s GSTIN; Ship-to GSTIN is mandatory where the Ship-to location is registered, otherwise “URP”. |
13. API validations and error codes
(a) Standalone Generate EWB API
| Validation | Error Code / Treatment |
|---|---|
| Ship-to GSTIN mandatory in Ship-to and Combination transactions | 608 |
| Ship-to Trade Name | Optional |
| Ship-to GSTIN must not be sent in Regular transactions | 616 |
| Ship-to GSTIN must not be sent in Bill-from/Dispatch-from transactions | 864 |
| Bill-to GSTIN and Ship-to GSTIN must not be the same | 618 |
| Ship-to GSTIN must correspond to the State Code; PIN must correspond to the State Code | Validation applies |
| Bulk generation — record failing the new validation | Only that record fails; other valid requests proceed. |
(b) e-Invoice API — Generate IRN + EWB together
| Validation | Error Code |
|---|---|
| Ship-to GSTIN (ShipDtls.Gstin) mandatory if ship details are provided and EWB is required — field made conditionally mandatory | 5002 |
| Bill-to GSTIN and Ship-to GSTIN must not be the same if ship details are provided | 2323 |
| Ship-to State Code must match Ship-to GSTIN State Code | 2325 |
| Ship-to PIN Code must belong to Ship-to State Code | 3039 |
(c) e-Way Bill by IRN API
| Validation | Error Code / Treatment |
|---|---|
| GSTIN and Trade Name added in ExpShipDtls; GSTIN mandatory | 5001 |
| Export EWBs — ship details (including GSTIN) given at IRN stage can be replaced | Allowed |
| B2B and SEZ — ship details given at IRN stage cannot be replaced | 2324 |
| GSTIN not given at IRN stage can be provided at EWB-by-IRN stage | Allowed |
| Ship-to State Code must match Ship-to GSTIN State Code | 4074 |
| Ship-to PIN Code must belong to Ship-to State Code | 3039 |
14. Action Points for Clients before 1st August 2026
| Stakeholder | Action Required |
|---|---|
| All taxpayers | Identify Bill-to/Ship-to and Combination transactions in the order-to-delivery cycle; begin capturing Ship-to GSTIN / URP in sales and dispatch masters; establish an internal SOP for closing EWBs after delivery wherever the closure facility will be used. |
| Exporters / merchant exporters | Map export-linked Ship-to locations (ports, ICDs, CFS, CHA premises) where URP treatment applies; ensure correct destination address and PIN are maintained. |
| Buyers in triangular trades | Where the ultimate customer’s identity is commercially sensitive, plan to generate the EWB in-house (inward EWB) instead of sharing the Ship-to GSTIN with the supplier or transporter. |
| ERP / GSP / ASP / API users | Update payloads for standalone EWB, IRN+EWB, and EWB-by-IRN flows; implement the closure API (EWB number, closure date, remarks up to 100 characters); complete Sandbox testing before go-live. |
| Transporters | Familiarise operational teams with EWB-wise, date-wise, and driver mobile-number-based closure; coordinate with taxpayers for Ship-to details where the transporter generates the EWB. |
| Drivers / authorised persons | Use the portal-based mobile-number closure facility where the mobile number has been provided at generation or updated subsequently. |
| All stakeholders | Note that post-closure actions (vehicle update, transporter update, validity extension) are temporarily permitted during stabilisation but will be restricted later; do not build processes that depend on modifying closed EWBs. |
Disclaimer: This Circular is a summary of the GSTN Advisory dated 02.07.2026 and the GSTN FAQs dated 01.07.2026 on
Voluntary Closure of e-Way Bill and on Bill-to/Ship-to Transactions, prepared for the general guidance of clients. It is not a
substitute for professional advice on specific facts. Positions described as “current” reflect the initial stabilisation phase and
may change upon further system updates by GSTN.