8 GSTN validations went live on 1 August 2026: the ship-to GSTIN changes your ERP must ship

Summary. On 17 June 2026 the Goods and Services Tax Network published an advisory making the ShipDtls.Gstin field conditionally mandatory in the Generate IRN payload and adding a mandatory Gstin field under ExpShipDtls in the e-Way Bill by IRN API. Both went into production on 1 August 2026, two days ago, after being released to Sandbox first. The advisory lists eight indicative validations across the two flows, including error 5002 when ship-to details are supplied without a GSTIN and error 2323 when the bill-to and ship-to GSTINs are identical. It also introduced a voluntary e-way bill closure facility with an API that takes three fields. E-invoicing itself applies to GST-registered businesses whose aggregate annual turnover has crossed ₹5 crore in any financial year since 2017-18, so this touches a very large share of Indian B2B sellers.

If your dispatch volume runs through an ERP or a GST Suvidha Provider, the failure mode is not a tax notice. It is a rejected IRN at 9am with a truck waiting at the gate.

What GSTN actually changed

The 17 June 2026 advisory refers back to an earlier GSTN advisory dated 20 May 2026, which first announced that ship-to GSTIN would be mandatorily captured in bill-to/ship-to transactions. Trade bodies, ERP vendors, GSPs, ASPs and private IRPs asked for clarification on how that applied when the e-way bill is generated alongside an e-invoice or from an IRN. The June advisory is the answer, and it is specific about which flows are affected.

Flow	Applies when	What changed
Generate IRN and e-way bill together	E-way bill is generated along with the IRN	ShipDtls.Gstin becomes conditionally mandatory wherever ship-to details are provided
Generate e-way bill using IRN	E-way bill is generated subsequently from an IRN	New Gstin field under ExpShipDtls, mandatory; optional TrdNm field added
Bill-to/ship-to transactions	Ship-to details are provided and an e-way bill is required	Ship-to GSTIN must be transmitted, or URP where none applies
Combination transactions	Both bill-to/ship-to and bill-from/dispatch-from are involved	Same requirement, on the more complex payload
Voluntary closure of e-way bill	After delivery of goods is complete	New closure facility and API

The conditional trigger matters more than the word "mandatory". GSTN's wording is that where ship-to legal name and ship-to address are provided in the e-invoice schema and e-way bill generation is requested, ship-to GSTIN is also required. If you never populate ship-to details, nothing changes for you. If you populate them sometimes, you now have a branch in your payload builder that has to be right every time.

The eight validations, and what each one costs you

The advisory publishes indicative error codes for the two flows. These are the ones your integration will actually hit.

Flow	Validation	Error code	The data problem behind it
Generate IRN + EWB	Ship-to GSTIN is mandatory if ship details are provided	5002	Delivery addresses stored without a linked GSTIN
Generate IRN + EWB	Bill-to and ship-to GSTIN must not be the same	2323	Ship-to auto-populated from bill-to as a default
Generate IRN + EWB	Ship-to state code must match the GSTIN state code	2325	Free-text state fields, or a GSTIN attached to the wrong branch
Generate IRN + EWB	Ship-to PIN code must belong to the ship-to state code	3039	Stale PIN-to-state mapping in the customer master
EWB by IRN	Gstin under ExpShipDtls is mandatory	5001	Two-step flows that only collected ship-to at invoice time
EWB by IRN	For B2B and SEZ, ship details from IRN generation cannot be replaced	2324	Warehouse teams correcting the delivery address after invoicing
EWB by IRN	Ship-to state code must match the GSTIN state code	4074	Same as 2325, on the second call
EWB by IRN	Ship-to PIN code must belong to the ship-to state code	3039	Same as above

Read the right-hand column again. Only two of those eight are code changes. The other six are master-data problems that were invisible until GSTN started validating them, which is why teams that treated this as a schema patch are the ones firefighting this week.

The 2323 rule deserves its own paragraph. GSTN states that in bill-to/ship-to transactions, the bill-to party and ship-to party are expected to be distinct persons, and the same GSTIN in both fields is not permitted. A great many ERPs default ship-to to bill-to when the user leaves the delivery address blank. That default is now a hard rejection. The fix is to detect the identical case before you call the IRP and send it as a regular transaction rather than a bill-to/ship-to one.

There is a transitional mercy for historical data. The advisory states that for old IRNs generated with the same GSTIN as both bill-to and ship-to, the e-Way Bill by IRN API will generate a regular e-way bill. So invoices already registered before 1 August 2026 will not strand.

URP, exports and the SEZ trap

Where a ship-to GSTIN is not available, GSTN allows the literal value URP in the field, wherever applicable. The advisory names two situations: the ship-to party is unregistered, or a GSTIN is not applicable to the transaction scenario. That covers direct-to-consumer deliveries, job-work movements to unregistered parties, and export legs.

Exports and domestic B2B behave in opposite ways, which is the single most likely source of a production incident:

• For export e-way bills, ship details including GSTIN provided during IRN generation may be replaced when generating the e-way bill using the IRN. Where no domestic registered ship-to GSTIN applies, URP may be entered.
• For B2B and SEZ transactions, ship details provided during IRN generation cannot be replaced at e-way bill time. Error 2324 is the enforcement. The one concession is that if GSTIN was not provided at IRN generation, it may be supplied during e-way bill by IRN, subject to the same validations.

If your dispatch process routinely corrects the consignee address between invoicing and gate-out, that process now has to move upstream of IRN generation for B2B and SEZ. This is a workflow change in the warehouse, not a change in the integration layer, and it is the part that takes longest to land.

Voluntary e-way bill closure: useful, and deliberately incomplete

GSTN has added a facility to close an e-way bill after delivery is complete. It is voluntary. Four parties may close one: the supplier, the recipient, the transporter involved in the transaction, and the driver or authorised person whose mobile number was provided for closure. Closure can be done e-way-bill-wise or date-wise.

For API users the closure call takes three fields:

POST  EWB Closure API
{
  "ewbNo":       "<e-way bill number>",
  "closureDate": "<date of closure>",
  "remarks":     "<free text>"
}

Three things about closure are not built yet, and the advisory says so plainly:

• There is no API provision to capture or specify the mobile number for driver-based closure. That path is portal-only today.
• There is no API to retrieve closed e-way bills, including date-wise retrieval. GSTN says this may be considered once the closure module stabilises.
• A separate Closed status is proposed but not live. The existing Active, Cancelled and Discarded framework continues during stabilisation, so a closed e-way bill will not look closed in your status field.

There is a corollary that will surprise auditors. During the stabilisation period, actions such as update transporter, extend validity and vehicle updation remain available even after an e-way bill has been marked closed. GSTN states these restrictions will be introduced once the system stabilises. So closure today is a record of intent, not a lock. Build your reconciliation on your own delivery-proof timestamp and treat the GSTN closure as a secondary signal until the Closed status ships.

The engineering work, in the order it should be done

A tax technology expert at Cygnet One, quoted by CFOtech India on 30 June 2026, framed the run-up like this:

"The revised implementation date should not be viewed as a delay in compliance, but as a readiness window. The real question for enterprises is whether their invoice data, dispatch data, ERP workflows, ASP integrations, and Bill APIs are aligned before the go-live date."

That is the right order of operations, and it is worth being concrete about what each layer means.

1. Audit the customer and ship-to master first. Before touching code, run three queries against your existing data: ship-to records with an address but no GSTIN, ship-to records whose GSTIN state code disagrees with the state field, and ship-to records whose PIN code does not belong to the state. Those three queries predict errors 5002, 2325 and 3039 exactly. Fix the data and most of the incident volume disappears.

2. Make ship-to GSTIN a first-class field, not a note. In a lot of Indian ERPs the delivery location lives as free text on the sales order. It needs to become a validated attribute of a ship-to party record with a GSTIN, a state code derived from the first two digits of that GSTIN, and a PIN code validated against the state. Derive the state code from the GSTIN rather than storing it separately, and two of the eight validations become structurally impossible to fail.

3. Branch the payload builder explicitly. Three cases, decided before the call: ship-to present and different from bill-to (send the GSTIN), ship-to present and unregistered or not applicable (send URP), ship-to identical to bill-to (do not send it as a bill-to/ship-to transaction at all).

4. Make the calls idempotent. IRN generation is not naturally idempotent from the client side, and a retry after a timeout can leave you unsure whether an IRN exists. Key every attempt on your own document number, persist the request and the response, and use the IRP's get-IRN-by-document-details call to resolve ambiguity rather than blindly retrying. A rejected call with error 5002 is safe to retry after fixing the payload. A timeout is not.

5. Classify errors into two buckets. Codes 5001 and 5002 are payload defects and can be auto-corrected if the master data has the answer. Codes 2323, 2324, 2325, 3039 and 4074 are data or process defects that need a human. Routing them to the same queue is how a compliance change turns into a support backlog.

6. Test in Sandbox, then reconcile in production. GSTN released these changes to Sandbox before production precisely so integrators could test. Post-go-live, reconcile three ways daily: invoices in the ERP, IRNs registered at the IRP, and e-way bills generated. Any invoice with an IRN and no e-way bill on a dispatch day is an exception worth alerting on.

Where the integration actually sits

Indian GST integration has three common shapes, and the amount of work in front of you depends on which one you have.

Integration shape	Who changes the payload	Effort for this change	Risk
Direct to a private IRP or the NIC API	Your engineering team	Highest: schema, validation, error handling, retries	You control the fix, and you own every edge case
Through a GST Suvidha Provider or ASP	The GSP updates the API; you update what you send it	Medium: field mapping and master data	You depend on the GSP's release date, which you do not control
Desktop accounting software with a connector	The vendor, on their release cycle	Lowest for code, highest for data	Batch and file-based connectors give you no real-time error surface

The third row is where most Indian small and mid-sized businesses sit, and it is the one that ages worst. Desktop accounting products that expose no documented REST API force integration through file exports, ODBC or third-party connectors, so a validation failure surfaces hours later in a rejected batch rather than at the moment of invoicing. If you are running high-volume dispatch on that shape, the ship-to GSTIN mandate is a reasonable trigger to move invoice generation behind a service you can instrument.

India-specific considerations

E-invoicing under GST applies where aggregate annual turnover has exceeded ₹5 crore in any financial year from 2017-18 onwards, and that test is historical, so a business whose current-year turnover has fallen below the threshold remains covered. Separately, taxpayers with aggregate annual turnover of ₹10 crore or more have been subject to a 30-day limit for reporting invoices to the Invoice Registration Portal since 1 April 2025. Stack those two rules against the new validations and the operational picture is clear: an invoice that fails ship-to GSTIN validation cannot simply be parked, because the reporting clock is already running.

Data governance is the quieter half of this. Ship-to records now hold a verified tax identifier tied to a delivery address, which for D2C and last-mile scenarios sits close to personal data. Design the ship-to master with the Digital Personal Data Protection Act 2023 in mind: minimise what you keep against the consignment, keep the retention period defensible, and log access. Our DPDP Act engineering playbook covers the controls, and the DPDP compliance cost breakdown covers what the work is worth budgeting.

For distribution and B2B businesses, this change usually lands alongside a wider ordering-system question. If your dealers still place orders by WhatsApp and email, the ship-to data problem starts there, and a B2B distributor ordering portal is where it gets fixed at source. Warehouse and dispatch teams tend to need the same discipline on the movement side, which is the territory of logistics and supply chain applications, and the connective work between ERP, IRP and e-way bill sits squarely in API integration and modernisation.

What good looks like by the end of August

A team that has this under control can answer five questions with a number, not an opinion: how many ship-to records currently lack a valid GSTIN, how many invoices in the last week triggered any of the eight error codes, how many of those were auto-corrected against master data, how many dispatches were delayed as a result, and how many e-way bills from the last 30 days remain open with delivery already confirmed.

If those five numbers do not exist yet, that dashboard is the highest-value thing to build this month. The engineering judgement, stated plainly: compliance mandates rarely break systems that already have clean master data and observable integrations. They just expose the ones that do not.

FAQ

What exactly became mandatory on 1 August 2026?

GSTN made the ShipDtls.Gstin field conditionally mandatory in the Generate IRN payload wherever ship-to details are provided and an e-way bill is required. It also added a mandatory Gstin field under ExpShipDtls in the e-Way Bill by IRN API, plus an optional TrdNm trade name field, effective in production from that date.

What do I send when the consignee has no GSTIN?

GSTN allows the literal value URP in the ship-to GSTIN field wherever applicable. The advisory names two situations for it: the ship-to party is an unregistered person, or a GSTIN is not applicable to the transaction scenario. Export legs with no domestic registered ship-to party may also use URP.

Why is my IRN rejected with error 2323?

Error 2323 fires when the bill-to GSTIN and the ship-to GSTIN are the same in a bill-to/ship-to transaction. GSTN treats those two parties as distinct persons, so the same GSTIN in both fields is not permitted. Detect that case before the call and submit it as a regular transaction instead.

Can I still correct the delivery address after generating the IRN?

Not for B2B and SEZ transactions. GSTN states that ship details provided during IRN generation cannot be replaced when generating the e-way bill from the IRN, enforced by error 2324. Export e-way bills are the exception, where ship details including GSTIN may be replaced at that stage.

Is the voluntary e-way bill closure facility mandatory?

No. GSTN describes the facility as voluntary in nature. It may be used by the supplier, the recipient, the transporter involved in the transaction, or the driver or authorised person whose mobile number was provided. Closure may be performed either e-way-bill-wise or date-wise after delivery is complete.

Which fields does the closure API take?

Three: the e-way bill number, the closure date, and remarks. GSTN notes that there is currently no API provision to capture the mobile number used for driver-based closure, and no API to retrieve closed e-way bills. Both paths remain portal-based or unavailable while the module stabilises.

Will a closed e-way bill show a closed status?

Not yet. GSTN says a separate Closed status is proposed to be introduced in due course, but during the initial stabilisation period the existing Active, Cancelled and Discarded framework continues. Actions such as update transporter, extend validity and vehicle updation also remain available after closure for now.

Who does GST e-invoicing apply to in 2026?

E-invoicing applies to GST-registered businesses whose aggregate annual turnover has crossed ₹5 crore in any financial year from 2017-18 onwards, and the test is historical rather than current-year. Taxpayers with turnover of ₹10 crore or more have also faced a 30-day limit for reporting invoices to the IRP since 1 April 2025.

How eCorpIT can help

eCorpIT is a Gurugram-based technology consultancy founded in 2021, with senior-led engineering teams building commerce, ERP-integration and logistics systems for Indian businesses. For this change we typically start with a master-data audit that predicts which of the eight error codes your data will hit, then rebuild the payload branch, error routing and three-way reconciliation between ERP, IRP and e-way bill so failures surface at invoicing rather than at the gate. We are CMMI Level 5 appraised, MSME certified and ISO 27001:2022 certified, and we design systems aligned with DPDP Act 2023 requirements for consignee and customer data. If dispatches are being held up by validation failures this week, talk to our engineering team and we will scope the fix against your actual rejection log.

References

1. 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, Goods and Services Tax Network, 17 June 2026
2. GSTN e-Way Bill changes push firms to prep systems, CFOtech India, 30 June 2026
3. GSTN issues advisory on e-Invoice API and e-Way Bill by IRN API changes effective from 1st August 2026, CAclubindia
4. GSTN's e-Invoice API and e-Way Bill by IRN changes from 1st August 2026: a step-by-step compliance checklist, CAclubindia
5. E-Way Bill changes from 1st August 2026: mandatory Ship-To GSTIN and new EWB closure facility, ClearTax
6. Mandatory Ship-To GSTIN and voluntary closures: a legal guide to the August 2026 e-Way Bill update, LiveLaw
7. GSTN mandates Ship-to GSTIN in e-Invoice and e-Way Bill APIs; introduces voluntary e-Way Bill closure facility from August 1, 2026, JurisHour
8. GSTN system enhancements: new e-Invoice and e-Way Bill API changes effective 1 August 2026, TaxO
9. Mandatory Ship-to GSTIN from 1 August 2026: what every business must know, Tally Solutions
10. E-invoicing rules in India: 2026 guidelines explained, Tally Solutions
11. GST e-Way Bill closure and bill-to ship-to GSTIN mandate 2026, CMA Knowledge
12. E-invoice bill-to ship-to data entry checklist, GimBooks
13. New GST rules effective from 1 August 2026: changes to e-invoicing and e-way bill provisions, Trade Brains

Last updated: 3 August 2026.