GST e-Invoice & e-Way Bill Changes 2026: API Validations & EWB Checks

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.

What changed from 1 August 2026?

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.

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.

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

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

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.

Frequently Asked Questions