GST e-Invoice & e-Way Bill Changes from 1 August 2026: API Validations, Ship-To GSTIN & EWB Closure
Answer first: GSTN introduced production changes from 1 August 2026 affecting the e-Invoice API, e-Way Bill by IRN API and a new voluntary e-Way Bill closure facility. Businesses using ERP/API integrations should review Ship-To GSTIN handling, export shipping validations, Bill-To vs Ship-To controls and post-delivery e-Way Bill closure workflows. These are primarily system/API changes; they should not be confused with a fresh statutory e-invoicing turnover threshold.
Effective date: 1 August 2026 | Area: e-Invoice and e-Way Bill system/API | Stakeholders: taxpayers, ERP teams, GSPs, ASPs, private IRPs and system integrators | Primary source: GSTN advisory | Last reviewed: 26 August 2026
What changed from 1 August 2026?
| Area | Change | Practical impact |
|---|---|---|
| Generate IRN + EWB | ShipDtls.Gstin becomes conditionally mandatory where Ship details are provided and EWB is required | ERP payload logic must populate GSTIN correctly when applicable |
| EWB by IRN | GSTIN field added under ExpShipDtls and made mandatory; TrdNm added as optional | Export shipping payloads need revised mapping |
| URP | URP permitted where Ship-To GSTIN is not available, wherever applicable | ERP should not force a GSTIN where the business case legitimately has none |
| Validations | GSTIN, Bill-To/Ship-To distinction, State Code and PIN validations strengthened | Bad master data may now trigger API rejection |
| Export EWB | Ship details may be replaced in Export EWB by IRN cases | Export logistics flows get limited flexibility |
| B2B / SEZ | Ship details sent during IRN generation cannot be replaced | Accuracy at IRN stage becomes more important |
| Voluntary EWB closure | Closure facility introduced after delivery | Businesses can mark completed movement operationally |
Legal framework vs system change
The GSTN advisory describes technology and validation changes in the e-Invoice/e-Way Bill ecosystem. It does not, by itself, create a new GST levy, new tax rate or new e-invoice turnover threshold. Finance and tax teams should therefore separate three layers: the CGST Act/Rules governing invoice and e-Way Bill obligations; notifications determining e-invoicing applicability; and GSTN/NIC system advisories defining how the portal/API validates and processes data.
| Layer | What it controls |
|---|---|
| CGST Act / Rules | Underlying statutory compliance |
| Notifications | Applicability, exemptions and effective conditions |
| GSTN/NIC advisory/API specification | Technical fields, validations, system behaviour and integration readiness |
1. Ship-To GSTIN becomes more important
Where shipping details are supplied and an e-Way Bill is required along with IRN generation, GSTN's revised API makes the relevant Ship-To GSTIN field conditionally mandatory. This means ERP logic should distinguish between a genuine registered Ship-To location and cases where a GSTIN is not available.
A common ERP mistake is to copy the Bill-To GSTIN blindly into Ship-To. The new validations make such shortcuts riskier because the system can test GSTIN validity and whether Bill-To and Ship-To values are appropriately distinct.
2. Export shipping validations
For e-Way Bill generation by IRN, the advisory adds a GSTIN field under ExpShipDtls and makes it mandatory, while TrdNm is optional. Export flows should be tested separately because the permitted replacement of shipping details differs from B2B/SEZ transactions.
For Export EWB by IRN cases, shipping details may be replaced. For B2B and SEZ transactions, shipping details already provided during IRN generation cannot be replaced. This is an important control distinction for dispatch teams.
3. URP where Ship-To GSTIN is unavailable
The advisory allows URP where the Ship-To GSTIN is unavailable, wherever applicable. ERP developers should therefore build rule-based handling instead of inventing a GSTIN or populating an unrelated registration merely to pass validation.
4. Voluntary closure of e-Way Bill
GSTN has introduced a voluntary closure mechanism intended for completion of movement after delivery. The closure API uses the e-Way Bill number, closure date and remarks. This is an operational status tool and should not be confused with cancellation.
| Action | Purpose |
|---|---|
| Cancel EWB | Used where an e-Way Bill needs cancellation within the permitted rules/system window |
| Close EWB | Operationally marks movement as completed after delivery |
| Extend validity | Used where movement continues and permitted extension conditions are met |
Initial stabilisation period: an important caveat
GSTN states that a separate visible status of “Closed” is proposed to be introduced in due course. During the initial stabilisation period, the existing Active, Cancelled and Discarded status framework continues. GSTN also states that actions such as transporter update, validity extension and vehicle update may continue to remain available even after an EWB has been marked closed during this transition period.
Therefore, businesses should not design permanent controls on the assumption that post-closure actions will always remain possible. GSTN has clearly indicated that restrictions may be introduced once the system stabilises.
Worked examples
Example 1: Bill-To and Ship-To are different GST registrations
A supplier invoices the Delhi GSTIN of a customer but ships goods to the customer's Haryana registered location. The ERP should populate the correct Bill-To and Ship-To registrations and state/PIN information rather than copying one GSTIN into both fields.
Example 2: Export dispatch
An exporter generates an IRN and later generates the e-Way Bill using the IRN. The revised export shipping fields and GSTIN/URP logic should be mapped in the ERP before the API call is made.
Example 3: Delivery completed
A transporter completes delivery and the business wants its e-Way Bill dashboard/API records to reflect completion. The voluntary closure facility can be used, subject to the live system behaviour and GSTN's transition-stage limitations.
Example 4: B2B ship detail entered wrongly at IRN stage
Because GSTN says ship details provided for B2B/SEZ IRN generation cannot be replaced through the EWB-by-IRN route, finance/logistics teams should validate these fields before IRN creation rather than expecting later correction.
ERP and accounting control checklist
- Update the API schema used by your ERP/GSP/ASP.
- Map Bill-To and Ship-To GSTIN separately.
- Validate GSTIN status in customer/location masters.
- Validate State Code and PIN Code combinations.
- Build URP handling only for legitimate cases.
- Separate export, SEZ and domestic B2B payload rules.
- Add pre-IRN checks for shipping details that cannot later be replaced.
- Log API rejection codes for root-cause analysis.
- Create user rights for voluntary EWB closure.
- Retain closure date and remarks in the ERP audit trail.
- Test post-closure actions periodically because GSTN may tighten them later.
Month-end / audit review
| Control | Evidence |
|---|---|
| Rejected API requests | Error log + corrected master/payload |
| Bill-To/Ship-To mismatches | Customer master and dispatch record |
| Export EWB cases | IRN JSON + shipping documents |
| Closed EWBs | Closure API response / system log |
| Open EWBs after completed deliveries | Logistics ageing report |
Common mistakes
- Treating this advisory as a new statutory e-invoicing threshold.
- Using Bill-To GSTIN as Ship-To GSTIN by default.
- Ignoring PIN/State Code master-data quality.
- Assuming B2B shipping details can always be corrected later.
- Confusing EWB closure with cancellation.
- Assuming the current transition-stage post-closure flexibility is permanent.
- Updating the ERP only in production without sandbox testing.
Risk matrix
| Risk | Impact | Control |
|---|---|---|
| Incorrect Ship-To GSTIN | API rejection / dispatch delay | Location-master validation |
| Wrong export payload | EWB generation failure | Separate export mapping and testing |
| Incorrect B2B ship details | Limited correction flexibility | Pre-IRN approval/check |
| Improper closure | Operational record mismatch | Role-based closure and audit trail |
| Outdated integration | High-volume transaction failures | Sandbox regression testing |
Frequently Asked Questions
When did the changes go live?
GSTN stated that the production implementation date is 1 August 2026.
Is this a new e-invoice turnover threshold?
No. The advisory deals with API/system changes, not a fresh threshold notification.
Is Ship-To GSTIN always mandatory?
No. GSTN describes it as conditionally mandatory where Ship details are provided and an EWB is required.
Can URP be used?
Yes, where Ship-To GSTIN is unavailable and URP is applicable.
What changed for e-Way Bill by IRN?
A GSTIN field was added under ExpShipDtls and made mandatory, with TrdNm as an optional field.
Are GSTIN validations stricter?
The advisory specifically lists GSTIN, Bill-To/Ship-To, State Code and PIN Code validations.
Can export shipping details be replaced?
GSTN states that ship details may be replaced in Export EWB by IRN cases.
Can B2B shipping details be replaced?
GSTN states that B2B/SEZ ship details provided during IRN generation cannot be replaced through this flow.
What is voluntary EWB closure?
It is a new facility to mark the movement as completed after delivery.
Is closure the same as cancellation?
No. Cancellation and closure serve different purposes.
What data does the closure API use?
The GSTN advisory refers to EWB number, closure date and remarks.
Will “Closed” immediately appear as a separate status?
GSTN says a separate Closed status is proposed in due course; the existing status framework continues during initial stabilisation.
Can transporter or vehicle details still be changed after closure?
During the initial stabilisation period GSTN says certain post-closure actions continue, but it plans to curtail them later.
Who needs to act on the advisory?
Taxpayers, ERP vendors, GSPs, ASPs, private IRPs and other system integrators using these APIs.
Should ERP teams test before deployment?
Yes. GSTN specifically advised stakeholders to test revised specifications in the Sandbox.
Does this change GSTR-1 law?
The advisory itself is an e-Invoice/e-Way Bill system advisory; GSTR-1 obligations remain governed by the applicable GST law and portal functionality.
Do manual portal users need to care?
Yes to the extent the underlying portal validations/closure workflow affect their transactions, though API integration work mainly concerns ERP/GSP/ASP users.
What should finance teams do first?
Confirm the ERP/GSP version supports the revised fields and run Bill-To/Ship-To, export and closure test cases.
Official References
- GSTN Advisory on Changes Introduced in e-Invoice API, e-Way Bill by IRN API and Voluntary Closure of e-Way Bill
- GSTN-authorised IRP core API documentation
Last reviewed: 26 August 2026.
Join the conversation