Ship-to GSTIN was going mandatory — GSTN just put it on hold

This was heading for a 1 August 2026 cutover. On 29 July 2026, GSTN quietly pulled it: Advisory No. 668 puts the mandatory Ship-to GSTIN validation in Bill-to/Ship-to e-Way Bill and e-Invoice API transactions "on hold until further notice" and withdraws the advisories and FAQs that built up to it. Nothing changed in production on 1 August. Here is exactly what GSTN said, what it had proposed, and what — if anything — to do now.

Where this actually stands, as of 14 August 2026

The rest of this article was written while the 1 August 2026 date was still live and is kept largely intact below, because the underlying design GSTN published is a reasonable preview of what a revived version will likely look like. But nothing in the sections that follow describes current, enforced behaviour on the e-Way Bill or e-Invoice APIs. Read it as "what was proposed, and what to have ready", not "what your ERP must do this week."

What GSTN had proposed, field by field

Three primary GSTN documents set out the design before the pause: the e-Way Bill portal advisory dated 9 June 2026, the Advisory on e-Invoice API and e-Way Bill by IRN API changes dated 17 June 2026, and the FAQs on Bill-to/Ship-to Transactions, Export Scenarios and API Impact dated 2 July 2026 — all three now withdrawn per Advisory 668. This was a GSTN/NIC API and portal change proposed by advisory, never an amendment to the Act or the Rules, which is consistent with how easily it was paused: nothing statutory needed to be undone. Note also what the design never claimed: it was never going to make Ship-to GSTIN mandatory on every e-invoice. In the e-Invoice API the field ShipDtls.Gstin was only to be conditionally mandatory — where ship details are provided and an e-way bill is required. An IRN generated without an accompanying e-way bill was never in scope.

Two design details worth remembering if this returns. First, GSTN's design let a missing Ship-to GSTIN at IRN generation be supplied later, at the e-Way Bill by IRN stage — so a gap would have been recoverable without a fresh invoice. Second, for B2B and SEZ transactions, ship details captured at IRN generation could not be replaced later (error 2324); only Export e-way bills allowed replacement. The proposal also kept Ship-to GSTIN backend-only: not printed on the e-way bill, not shown to taxpayers or transporters, not returned through the GET e-Way Bill APIs — visible only to authorised officers.

The dispatch patterns this design targeted

None of this is enforced today, but the taxonomy GSTN published is still the clearest way to think about Bill-to/Ship-to structures generally, and it is worth understanding before any revived version lands. There were four transaction types, and only two of them would have taken a Ship-to GSTIN at all.

Job work and delivery challans

GSTN's advisory and FAQs never addressed job-work movements or delivery challans expressly, and that remains true of the withdrawn material. On the taxonomy as published, a principal sending inputs to a job worker on a delivery challan under Rule 55 is not raising an invoice on a buyer at all, so it would not have been a Bill-to/Ship-to transaction — Ship-to GSTIN would not have applied. That reading follows from the transaction taxonomy rather than from any express GSTN statement on job work; it is moot for now, since none of this is enforced. The Section 143 / ITC-04 obligations on job-work movement are unaffected by any of this, live or paused.

Inter-state branch transfers: the correction worth keeping

Inter-state stock transfers under the same PAN were widely described, while this design was still live, as the pattern most exposed to it. On GSTN's own taxonomy they were not. When a Maharashtra plant transfers stock to a Karnataka depot, the Karnataka GSTIN is the recipient — it is the bill-to party. Goods move from supplier to buyer. That is a Regular transaction, and Ship-to GSTIN would not have been sent. This correction survives the deferral because it is about the transaction taxonomy, not about whether the validation is currently switched on.

The underlying tax treatment is unchanged and unaffected by any of this, live or paused, and is still worth stating. Under Schedule I, para 2 of the CGST Act read with Rule 28 of the CGST Rules, supplies between distinct or related persons — including inter-state branch and stock transfers under the same PAN — are taxable even without consideration, and where the recipient is eligible for full ITC the invoice value is deemed to be the open-market value. Both legs still have to reconcile: a tax invoice out of the sending GSTIN, matching credit at the receiving GSTIN.

What still matters right now, deferral or not

Nothing about this deferral changes existing law. Rule 48(4) of the CGST Rules already requires a notified taxpayer — currently anyone whose aggregate turnover has exceeded ₹5 crore in any financial year since 2017-18, under Notification 10/2023-Central Tax — to report each B2B invoice to the Invoice Registration Portal for an IRN and QR code, live and unaffected by Advisory 668. Rule 48(5) still means an invoice issued any other way "shall not be treated as an invoice", and Section 16(2)(a), CGST Act still means ITC needs a valid tax invoice. None of that turned on the Ship-to GSTIN change, and none of it went away with it.

What the deferral does remove, for now, is the specific new failure mode this design would have introduced: a stopped truck because a ship-to GSTIN field was missing or duplicated the bill-to GSTIN. That risk is paused along with the validation that would have created it.

A worked example (illustrative of the paused design, not current behaviour)

Kept here because it shows how the mechanics were meant to fit together — useful groundwork if a revived version lands, not a description of anything enforced today. A component manufacturer registered in Maharashtra dispatches to an OEM. The purchase order is raised by the OEM's Delhi head office; the goods go to the OEM's Pune plant, which holds its own Maharashtra GSTIN. Bill-to and ship-to are different GSTINs, so under the paused design this would have been a genuine Bill-to/Ship-to transaction requiring a Ship-to GSTIN.

The 18% rate is illustrative; substitute your own HSN rate. This example exists to show the shape of the risk the design would have created — a blocked e-way bill, not a broken credit, unless the pressure of a waiting truck led someone to ship on an invoice with no valid IRN, which is a live risk under Rule 48(4)/48(5) independent of Ship-to GSTIN entirely.

What to actually do now

• Don't change ERP config for this specific validation. There is nothing to implement; the fields and error codes above are not live.
• Keep any mapping work you already did. If you classified dispatch patterns into Regular / Bill-to/Ship-to / Bill-from/Dispatch-from / Combination while preparing for 1 August, that classification work is still correct and reusable groundwork — it just isn't graded by the portal yet.
• Kill the "copy the buyer's GSTIN into ship-to" habit anyway. It was the design's highest-volume failure case, and clean master data is good practice independent of whether GSTN is validating it this month.
• Watch for a fresh GSTN advisory rather than a fixed date. Advisory 668 gives no target; the next signal will be a new advisory, not a calendar date arriving.
• Keep enforcing what is actually live: valid IRNs on B2B invoices under Rule 48(4), and your GSTR-2B reconciliation — neither depends on this deferral.

Where Recoup fits

Recoup sits on the receiving side of this, deferral or not. It checks that vendor invoices carry valid IRNs before you book the credit — a supplier document that reaches you without a valid IRN cannot support your Section 16(2)(a) claim, and Recoup flags it before the credit is taken rather than after a notice. On the same run it reconciles your claimed ITC against your GSTR-2B and names the vendor behind every gap. None of that changes with Advisory 668 — it was never contingent on the Ship-to GSTIN validation going live, and it stays exactly as useful with it paused.

The honest framing: this was always a master-data and transaction-classification exercise before it was a tax problem, and for now it's on hold. Watch this page — we'll update it the moment GSTN issues a new advisory with a date.

Related guides