Proposed E-Invoice and E-Way Bill API Changes (Ship-to GSTIN): What GSTN Proposed and Why It Is on Hold

On 17 June 2026, the Goods and Services Tax Network (GSTN) issued an advisory (GST portal Advisory No. 664) detailing structural changes to the E-Invoice API and the E-Way Bill by IRN API that would make the Ship-to GSTIN mandatory whenever Ship-to details are provided and an e-Way Bill is required. The changes, first announced on 20 May 2026 for roll-out on 15 June 2026 and then deferred to 1 August 2026, were ultimately not implemented: on 29 July 2026, GSTN announced (Advisory No. 668) that the proposed e-Way Bill API Changes have been kept on hold until further notice, and that the related advisories and FAQs would be withdrawn from the GST portal.

Had they gone live, the changes would have transformed e-Way Bill generation from a routine compliance formality into a more stringent, data-driven process. For businesses running integrated billing, ERP and logistics software, understanding what was proposed remains essential: it shows the direction in which GST compliance is heading, and it is the best guide to the API validation failures that could disrupt the movement of goods if and when the changes are revived.

Introduction

The Goods and Services Tax (GST) framework in India continues to evolve, with the Government consistently introducing measures aimed at strengthening compliance, plugging revenue leakages, enhancing transparency and streamlining the movement of goods.

Businesses involved in complex logistics arrangements, third-party deliveries or e-commerce fulfilment should understand the proposed changes so that they are prepared if and when GSTN decides to implement them. Organisations should review their existing GST compliance processes, ERP configurations, customer master data and API integrations.

Businesses engaged in Bill-to/Ship-to transactions were set to witness an important change in the e-Way Bill rules. The sequence of events was as follows:

• 20 May 2026 (Advisory No. 661): GSTN announced enhancements to the e-Way Bill portal, making the Ship-to GSTIN a mandatory data element in Bill-to/Ship-to transactions and introducing a voluntary e-Way Bill closure facility, for deployment by 15 June 2026.
• 9 June 2026 (Advisory No. 663): following representations from trade and industry citing the need for system changes, testing, API and ERP readiness and master-data updation, implementation was deferred to 1 August 2026.
• 17 June 2026 (Advisory No. 664): GSTN released the detailed API-level changes to the e-Invoice and e-Way Bill by IRN APIs, with the revised specifications made available in the sandbox environment.
• 1 July 2026: GSTN released detailed FAQs on Bill-to/Ship-to transactions, export scenarios and API impact.
• 29 July 2026 (Advisory No. 668): implementation of the proposed enhancements was kept on hold until further notice. GSTN clarified that no changes are required in the production environment and that the related advisories and FAQs would be withdrawn from the GST portal.

As of the date of this article, no revised implementation date has been announced. Even so, businesses that rely on automated GST compliance services, GST APIs or third-party GST technology platforms should understand the effect the changes would have, since the proposal introduces stricter structural and validation requirements for GST invoice, e-Invoice and e-Way Bill API  changes.

The Core Change: Strengthening Traceability and Combating Fake Billing

For years, businesses engaged in Bill-to/Ship-to transactions have enjoyed a degree of operational flexibility. A typical arrangement involves a GST invoice being billed to a corporate head office while the goods are physically delivered to a regional warehouse, branch or third-party distributor. Under the CGST Rules, only one e-Way Bill is required for such a movement, and it may be generated by either the supplier or the party who orders the goods.

Under the proposed framework, this flexibility would be subjected to stricter reporting requirements wherever the shipping destination differs from the billing destination. The GSTIN of the actual Ship-to party would have to be transmitted through the API, wherever applicable.

GSTN’s objective is to strengthen supply-chain traceability and curb fraudulent or fictitious billing. By linking the physical movement of goods to a specific and verifiable GST registration, tax authorities would obtain greater visibility into the movement and destination of goods.

Where the Ship-to party is unregistered and does not possess a GST registration, the value “URP” (Unregistered Person) would be entered in the Ship-to GSTIN field. This would allow the reporting of B2C and other transactions involving unregistered recipients.

API-Level Enhancements

To understand the impact of the proposed mandate, it is important to examine how the requirements would affect the specific GST API interfaces through which ERP systems, billing software and other applications communicate with the GST ecosystem.

E-Way Bill Generation together with e-Invoice (IRN) Generation

When an Invoice Reference Number (IRN) and an e-Way Bill are generated simultaneously, the ShipDtls.Gstin field in the Generate IRN payload was proposed to become conditionally mandatory. If the software sends a Ship-to legal name and a Ship-to address and requests an e-Way Bill in the same API call, the Ship-to GSTIN would have to be provided. Failure to provide it would result in API validation failure (proposed error code 5002) and rejection of the request. Businesses using an automated GST e-invoicing solution should therefore ensure that the relevant API fields are correctly mapped and validated before an invoice is submitted.

E-Way Bill Generation through the e-Way Bill by IRN API

Many businesses first generate the IRN and subsequently generate the e-Way Bill once dispatch details, such as the vehicle number, become available. For this subsequent generation, GSTN proposed a new mandatory Gstin field under ExpShipDtls (proposed error code 5001 where it is missing). A TrdNm (Trade Name) field was also proposed, as an optional field.

These changes, if implemented, would require businesses and technology providers to review their existing GST API mappings and ensure that the revised data structure is correctly implemented.

New Validations and Error Codes

GSTN proposed stringent system validations to ensure that the information submitted is not merely complete but also internally consistent and accurate.

• Distinct Parties Rule (Error 2323): In a genuine Bill-to/Ship-to transaction, the Bill-to and Ship-to parties must be distinct. The system would flag the transaction if the same GSTIN were reported in both fields. Businesses should therefore review legacy ERP configurations that automatically populate the Ship-to GSTIN with the buyer’s GSTIN, since such default mappings would result in validation failures during e-Invoice generation.
• State Code Consistency (Error 2325): The first two digits of the Ship-to GSTIN must correspond to the State indicated in the Ship-to address. Incorrect, outdated or manually entered master data would produce a mismatch between the GSTIN and the State code, causing the transaction to fail validation.
• PIN-to-State Mapping (Error 3039): The API would also validate the destination PIN code against the State associated with the Ship-to GSTIN. Data-entry errors or incorrect destination PIN codes would therefore prevent successful e-Invoice or e-Way Bill generation and could delay the movement of goods.

Modification Rules: B2B/SEZ versus Export Transactions

The proposed framework distinguishes between domestic B2B/SEZ supplies and export transactions, recognising the different operational requirements associated with international shipments.

• B2B and SEZ Supplies: For B2B and SEZ supplies, the Ship-to details recorded at the time of IRN generation would be treated as final. The Ship-to GSTIN could not subsequently be altered or replaced when the e-Way Bill is generated, and any attempt to overwrite it would trigger Error 2324. Businesses would therefore have to ensure that Ship-to details are accurately captured and validated before generating the IRN.
• Export Transactions: Export transactions would be treated differently, since overseas consignee details and port-related information may change during the logistics process. Ship-to details, including the GSTIN where applicable, could be replaced at the e-Way Bill generation stage. Where there is no domestic registered Ship-to GSTIN for the export movement, the “URP” designation would be used.

Voluntary E-Way Bill Closure Facility

Alongside the stricter compliance requirements, GSTN also proposed a potentially useful operational facility: voluntary closure of an e-Way Bill.

At present, an e-Way Bill generally remains active until its validity period expires, even where the goods have already been delivered. Under the proposed facility, the portal and the associated APIs would allow stakeholders to close an E-Way Bill voluntarily immediately after the movement has been completed, on the day of delivery or the following day. Closure could be initiated by:

• the supplier who dispatched the goods;
• the recipient who accepted delivery;
• the transporter responsible for the movement; or
• the driver or other authorised person whose mobile number was provided at the time of E-Way Bill generation or vehicle updation, through a mobile-number-based facility on the portal (the closure API for system integrators did not, at the proposal stage, provide for driver closure).

A separate “Closed” status was proposed to be introduced in due course. Voluntary closure would provide a system-generated audit trail confirming that the movement of goods has been completed, reduce ambiguity during transit-related verification, and support more effective inventory and logistics reconciliation. Like the Ship-to GSTIN mandate, this facility is covered by the hold advisory.

Practical Preparedness Checklist (for Any Future Implementation)

Since the changes are currently on hold, no production changes are required. The following steps nonetheless remain useful for master-data hygiene and for readiness if GSTN re-notifies the requirements:

1. Conduct a Master Data Audit

Review customer, vendor, ERP, CRM and logistics master data to ensure that each delivery location has accurate and up-to-date GSTIN information. Unregistered Ship-to locations should be appropriately identified so that the system can apply “URP” wherever applicable.

2. Coordinate with Your ERP Provider or GST Consultant

Businesses should engage with their ERP provider, billing software provider, Application Service Provider (ASP), GST Suvidha Provider (GSP) or a qualified GST consultant to understand the system updates that would be required. Particular attention should be given to the correct mapping and transmission of the ShipDtls.Gstin field.

A professional GST consultant can also assist businesses in reviewing their transaction structures, identifying potential compliance gaps and aligning internal processes.

3. Use the Sandbox Environment

The revised API specifications were released in the GSTN sandbox environment for taxpayers, ERP vendors, GSPs, ASPs, private IRPs and other system integrators. Businesses and technology providers can continue to test the revised e-Invoice API, e-Way Bill by IRN API and e-Way Bill closure functionality as a readiness exercise, but production deployment should await a fresh advisory.

4. Review Internal Workflows

Businesses should avoid relying on default system configurations that automatically copy billing-party information into Ship-to fields. Instead, the actual destination and consignee details should be captured, verified and validated at the appropriate stage of the order-to-dispatch process.

Conclusion

The proposed mandatory reporting of the Ship-to GSTIN was intended as a significant step towards a more transparent and data-driven GST compliance ecosystem. While the changes have been kept on hold until further notice, they illustrate the direction in which GSTN is likely to move. Businesses that maintain accurate customer and logistics master data and keep their ERP and API mappings flexible will be better placed to adapt quickly if and when the requirements are reintroduced.

With appropriate system readiness, accurate master data, robust validation controls and timely coordination with ERP providers, GST consultants and GST compliance service providers, businesses will be able to minimise transaction failures and ensure uninterrupted compliance with the e-Invoice and e-Way Bill framework, whatever form it finally takes.

Note: Stakeholders are advised to monitor official GSTN communications and to make no production changes until a fresh advisory is issued.

References

1. Goods and Services Tax Network (GSTN), Advisory to Taxpayers and Stakeholders: Enhancements in the e-Way Bill (EWB) Portal, dated 20 May 2026 (GST portal Advisory No. 661): gst.gov.in
2. GSTN, Extension of timeline for implementation of mandatory ‘Ship To GSTIN’ and Voluntary Closure of e-Way Bill functionalities, dated 9 June 2026 (GST portal Advisory No. 663).
3. GSTN, Advisory on e-Invoice API and e-Way Bill by IRN API changes for mandatory capture of Ship-to GSTIN and Voluntary Closure of eWay Bill, dated 17 June 2026 (GST portal Advisory No. 664): gst.gov.in
4. GSTN, FAQs on Bill-to/Ship-to Transactions, Export Scenarios and API Impact, dated 1 July 2026: gst.gov.in
5. GSTN, Advisory on Keeping on Hold the Proposed e-Way Bill Enhancements, dated 29 July 2026 (GST portal Advisory No. 668): ewaybillgst.gov.in
6. Ministry of Finance, Press Release dated 23 April 2018, “Issues regarding ‘Bill To Ship To’ for e-Way Bill under CGST Rules, 2017”; Rule 138 of the Central Goods and Services Tax Rules, 2017.
7. GST e-Invoice portal, e-Invoice and IRN-related guidance and validation rules for e-Invoicing.