GSTN's e-Invoice API and e-Way Bill by IRN Changes from 1st August 2026: A Step-by-Step Compliance Checklist for Businesses

If your business raises e-invoices through an ERP, a GSP/ASP, or any API-based system, the e-Invoice and e-Way Bill flows you rely on every day are about to change. On 17 June 2026, GSTN issued an advisory that introduces two structural changes: mandatory capture of the Ship-to GSTIN and a Voluntary Closure facility for e-Way Bills across the e-Invoice API, the e-Way Bill by IRN API, and the EWB Closure API. These go live in Production on 1 August 2026, a date that is itself a deferral from the originally notified 15 June 2026, pushed back after industry representations sought more time for system changes and the revised specifications are already available in the Sandbox for testing.

The catch is that this is not a portal cosmetic update. It is a payload-and-validation change. If your IRP/EWB integration is not updated before the cutover, your e-invoices and e-way bills can be rejected at generation, which means goods do not move. This article breaks down exactly what changes, what each error code means, and a two-column action plan to get ready before 1 August.

The 60-Second Summary

Change 1: Ship-to GSTIN Becomes Mandatory

Until now, in a Bill-to/Ship-to transaction you could generate an e-way bill by furnishing only the consignee's address. From 1 August 2026, wherever Ship-to details are present and an e-way bill is required, the Ship-to GSTIN must also be transmitted. Where the ship-to party is unregistered or no GSTIN applies to the scenario, the value URP is entered instead.

This change touches two distinct API flows, and the field is different in each:

A. Generate IRN and e-Way Bill together

In the Generate IRN payload, the field ShipDtls.Gstin is now conditionally mandatory, it must be provided whenever Ship-to Legal Name and Ship-to Address are furnished in the e-invoice schema and e-way bill generation is requested in the same call. If GSTIN is not available, URP may be used wherever applicable.

B. e-Way Bill by IRN (generated subsequently)

In the API that generates an e-way bill later, using an existing IRN, GSTN has added a new field Gstin under the ExpShipDtls section, and made it mandatory. A new optional field TrdNm (Trade Name) has also been added to capture the consignee's trade name.

The practical takeaway for your developers: this is not one field in one place. Map both ShipDtls.Gstin (combined IRN+EWB) and ExpShipDtls.Gstin (EWB-by-IRN) in your integration.

The Validation Rules and the Error Codes You Will See

This is where most failures will happen on day one. GSTN has prescribed strict validations, and the Sandbox already returns specific error codes. Keep this table handy for your testing log:

Generate IRN and e-Way Bill together

Three rules deserve special attention because they trip up real-world data:

1. Bill-to and Ship-to must be distinct parties. In a genuine Bill-to/Ship-to transaction, the same GSTIN cannot appear in both fields. If your master data defaults the buyer's GSTIN into both, every such invoice will fail (error 2323).
2. State Code consistency. The first two digits of the Ship-to GSTIN must match the state implied by the address. Stale or mismatched address masters are the usual culprit.
3. PIN-to-State mapping. The Ship-to PIN code must genuinely belong to the Ship-to state (error 3039). Copy-paste errors in delivery addresses will now be caught at generation.

Export vs B2B/SEZ: The Crucial Difference

GSTN has deliberately treated export logistics differently from domestic B2B/SEZ movement.

• B2B and SEZ: Ship details provided at the time of IRN generation cannot be replaced when you later generate the e-way bill by IRN (error 2324 if attempted). If the GSTIN was simply omitted at IRN stage, it can be supplied at the EWB-by-IRN stage, subject to validations.
• Export: Ship details, including GSTIN, may be replaced at the e-way bill stage, recognising that export consignee/destination details often firm up later. Where no domestic registered ship-to GSTIN applies, URP may be used.
• Old IRNs: IRNs already generated with the same GSTIN in Bill-to and Ship-to will continue to generate a regular e-way bill without disruption so historical data is not invalidated.

Change 2: Voluntary Closure of e-Way Bills

GSTN has introduced a Voluntary Closure facility to formally mark an e-way bill as completed once goods are delivered. It is optional, and can be exercised EWB-wise or date-wise .

Who can close an EWB: the Supplier, the Recipient, the Transporter, or the Driver / authorised person whose mobile number was provided for closure.

Through the portal: Suppliers, recipients and transporters get a closure option after login under the e-Way Bill section. Drivers/authorised persons can close via their registered mobile number, which surfaces the active EWBs linked to that number.

Through the API: A closure API is available for system integrators. It requires just three inputs:

Important caveats during the stabilisation period do not get caught out:

• There is currently no API provision to capture the mobile number for driver/authorised-person closure. That route works through the portal only for now.
• There is currently no API to retrieve closed EWBs (including date-wise). Build your own log of what you have closed.
• A separate "Closed" status is only proposed for a future release. For now the system continues with Active, Cancelled and Discarded so existing integrations are not broken.
• Crucially, post-closure actions (Update Transporter, Extend Validity, Vehicle Updation) still remain available during stabilisation. Do not assume "closed" means "locked." Once the system stabilises, GSTN has signalled these will be curtailed.

The "Before 1 August" Action Plan

Use this as a two-column working checklist with your IT/ERP team and your GSP/ASP.

Common Mistakes That Will Cause Failures

1. Leaving the ERP sandbox un-updated until late July. ERP release cycles, GSP coordination and UAT take weeks, not days. A last-minute push risks failed invoicing on 1 August. Start testing against the Sandbox now.
2. Mapping only one of the two GSTIN fields. Teams often patch ShipDtls.Gstin for the combined flow but forget ExpShipDtls.Gstin for EWB-by-IRN (error 5001). Map both.
3. Same GSTIN in Bill-to and Ship-to. A surprisingly common master-data default that now hard-fails (2323).
4. Assuming Ship-to can be corrected later for B2B/SEZ. It cannot once the IRN is generated (2324). Accuracy must move upstream to invoice creation.
5. Treating Voluntary Closure as a lock. During stabilisation, closed EWBs can still be modified — and there is no API yet to retrieve closed EWBs. Plan your records accordingly.
6. Ignoring URP logic for unregistered consignees , leading to mandatory-field rejections.

What Non-Compliance Actually Costs You

Be precise about the risk, because it is operational, not theoretical. If your integration is not ready:

• e-Invoices or e-Way Bills get rejected at generation due to validation failure — which means the consignment cannot legally move .
• Goods moving without a valid e-way bill expose the consignment to detention, seizure and penalty under Section 129/130 of the CGST Act , plus business disruption and demurrage.
• Mismatches between IRN/e-invoice data and the e-way bill create reconciliation gaps that surface later in GSTR-1 vs e-invoice vs EWB reviews and in departmental scrutiny.

The exposure here is a stopped supply chain and downstream reconciliation pain , not an automatic input tax credit reversal — but for any business moving goods daily, a halted dispatch is the more immediate and expensive problem.

FAQ

1. Is manual / portal-based e-way bill generation still available after 1 August 2026?

Yes. The portal route to generate an e-way bill continues to exist. What changes is that the Ship-to GSTIN field is now mandatory for Bill-to/Ship-to transactions across both the portal and the APIs — so the portal is not a way to avoid the new requirement. It remains a sensible manual fallback for the first few days if your API integration hits issues.

2. We only do B2C / single-location supplies. Does this affect us?

The Ship-to GSTIN requirement bites specifically where Ship-to details are furnished in a Bill-to/Ship-to scenario. If your transactions have no separate ship-to party, the new conditional field generally does not trigger but you should still update your system to the latest API specs to avoid version-mismatch rejections.

 3. What is the difference between ShipDtls.Gstin and ExpShipDtls.Gstin?

 ShipDtls.Gstin lives in the Generate IRN payload (when you create the IRN and e-way bill together). ExpShipDtls.Gstin is the new field in the e-Way Bill by IRN API (when you generate the e-way bill later from an existing IRN). They serve the same purpose in two different flows — map both.

4. Can we fix a wrong Ship-to GSTIN after the IRN is generated?

For B2B and SEZ , no - Ship-to details from the IRN cannot be replaced at the e-way bill stage (error 2324).

For exports, yes - they may be replaced. If the GSTIN was simply left blank at IRN stage in a B2B/SEZ case, it can be supplied at the EWB-by-IRN stage, subject to validation.

5. Is Voluntary Closure mandatory?

No. It is optional. It exists to create a clean system record that delivery is complete. During the initial stabilisation period there is no separate "Closed" status and post-closure modifications remain possible.

6. The advisory mentioned a Sandbox. Do we have to test there?

Strongly advised. The revised specifications are live in the Sandbox specifically so that ERP vendors, GSPs, ASPs, private IRPs and in-house teams can validate their changes and clear the new error codes before 1 August. Treat a clean Sandbox run as a go-live gate.

This article is for general guidance based on the GSTN Advisory dated 17 June 2026. Field names, error codes and validations are reproduced from the published Sandbox specifications and should be re-verified against the latest GSTN/NIC API documentation before deployment. 

Authored by the GST practice at Patron Accounting LLP - a chartered accountancy and company secretarial firm advising businesses on e-invoicing, GST returns and reconciliation across ERP, SAP, Tally and Zoho integrations.