Ship-to GSTIN becomes mandatory — and the trap is the field your ERP already fills in

This is a schema change, not a tax change — which is exactly why it gets ignored until dispatch stops. From 1 August 2026 the Ship-to GSTIN is a mandatory, validated field in Bill-to/Ship-to and Combination transactions. The surprise is not only the blanks: copying the buyer's own GSTIN into the ship-to field, which is what most ERPs do today, is now an explicit rejection.

Do this first

Before you read the reasoning, three actions, in order. They are all ERP-side and none of them need a tax opinion.

1. Classify your dispatch patterns before you fix any master data. The new validations are driven by transaction type, not by whether you happen to know a GSTIN. Ship-to GSTIN is mandatory in Bill-to/Ship-to and Combination transactions — and is rejected if you send it in Regular or Bill-from/Dispatch-from transactions. Getting the classification wrong now fails in both directions.
2. Find every case where your ERP copies the buyer's GSTIN into the ship-to field. This is the single most common ERP default and it becomes a hard error: Bill-to GSTIN and Ship-to GSTIN must not be the same. Deliveries to the buyer's own warehouse or additional place of business under the same GSTIN must be sent as a Regular transaction with the delivery address in the bill-to address field — not as Bill-to/Ship-to.
3. Test in the Sandbox and name an owner for rejections. The changes are already live in the NIC/GSTN Sandbox; production cutover is 1 August 2026. Push your awkward patterns through and see which come back with error codes. Then decide who fixes a rejection at 6pm on a dispatch day — no e-way bill means the truck waits.

What actually changed, field by field

Three separate API surfaces, three separate changes. Most write-ups merge them; the error codes do not.

Two operational details worth knowing before you panic. First, if Ship-to GSTIN was not provided at IRN generation, GSTN confirms it can be supplied at the e-Way Bill by IRN stage — so a missing GSTIN is often recoverable without a fresh invoice. Second, for B2B and SEZ transactions ship details captured at IRN generation cannot be replaced later (error 2324); only Export e-way bills allow replacement. Get it right at IRN time or you are cancelling and re-issuing.

Ship-to GSTIN is captured in the backend only. GSTN confirms it will not be printed on the e-way bill, will not be shown to taxpayers or transporters, and will not be returned through the GET e-Way Bill APIs — it is visible to authorised officers for verification and enforcement. If your buyer refuses to disclose a ship-to GSTIN on confidentiality grounds, the buyer can generate the e-way bill themselves as an inward e-way bill.

The dispatch patterns that break

The taxonomy in GSTN's FAQ is the thing to internalise. There are four transaction types, and only two of them take a Ship-to GSTIN at all.

Job work and delivery challans

GSTN's advisory and FAQs do not address job-work movements or delivery challans expressly. On the taxonomy they publish, 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 is not a Bill-to/Ship-to transaction — which means Ship-to GSTIN should not be sent, and sending it would attract error 616 on the standalone EWB API. That reading follows from the transaction taxonomy rather than from any express GSTN statement on job work, so test it in the Sandbox before you hard-code it. The Section 143 / ITC-04 obligations on job-work movement are unaffected by any of this.

Your own inter-state branch transfers: the correction most write-ups get wrong

Inter-state stock transfers under the same PAN are widely being described as the pattern most exposed to this change. On GSTN's own taxonomy they are not. When your Maharashtra plant transfers stock to your 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 must not be sent. The exposure is the opposite of the one usually described: an ERP that helpfully populates a ship-to block on a branch transfer will now be rejected for doing so.

The underlying tax treatment is unchanged and still worth stating, because it is what makes the dispatch matter. 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. A rejected e-way bill stops that movement; it just does not stop it for the reason most people are being told.

How a rejection becomes a tax problem — and how it usually doesn't

Nothing in the Act changed. The honest chain is shorter and narrower than the alarming version, so here it is in both directions.

The usual consequence is operational, not fiscal. A validation failure blocks the e-way bill. If you were generating IRN and e-way bill together, the whole call fails and you get neither. If you generate the IRN first and the e-way bill separately, the IRN stands — and GSTN expressly allows the missing Ship-to GSTIN to be supplied at the e-Way Bill by IRN stage. In most failures you have a valid invoice and a stopped truck, not a broken credit.

The fiscal consequence arrives only if you ship anyway. Under Rule 48(4) of the CGST Rules 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 — must report each B2B invoice to the Invoice Registration Portal for an IRN and QR code. Rule 48(5) is the limb that bites: an invoice issued by such a person in any manner other than that specified in Rule 48(4) "shall not be treated as an invoice". Then Section 16(2)(a), CGST Act does the damage — ITC is available only if the recipient is in possession of a tax invoice or debit note issued by a registered supplier. Your customer is holding a document that is not one.

There is a second, slower failure. Under Section 16(2)(aa), CGST Act, ITC can be claimed only if the invoice has been furnished by the supplier in GSTR-1 and communicated to the recipient. IRN data auto-populates GSTR-1, so an invoice that never got an IRN has to be added to GSTR-1 manually — and if nobody does, it never reaches your customer's GSTR-2B. They will chase you for it in the month they are trying to file.

So: a schema rejection is a dispatch problem. It becomes a credit problem only when the pressure of a waiting truck produces an invoice with no IRN behind it. That is the decision to govern.

A worked example

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 this is a genuine Bill-to/Ship-to transaction and Ship-to GSTIN is mandatory.

The 18% rate is assumed for illustration; substitute your own HSN rate. Scale the second consequence and it gets uncomfortable — a plant running 40 such dispatches in a month that responds to repeated rejections by shipping without an IRN would put roughly ₹1.32 crore of counterparty credit at risk in a single month. The commercial consequence lands before the tax one: a customer whose credit you broke raises a debit note or withholds the tax portion of your payment. That is a contractual remedy between two businesses, not a withholding of tax from the government.

What good looks like before the cutover

• Fix transaction-type classification before master data. Every dispatch must resolve to exactly one of Regular, Bill-to/Ship-to, Bill-from/Dispatch-from or Combination. Two of those four must not carry a Ship-to GSTIN at all.
• Kill the "copy the buyer's GSTIN into ship-to" default. It is the highest-volume failure waiting to happen, and it fails as a hard error, not a warning.
• Treat ship-to GSTIN as a mandatory master field for genuine third-party deliveries, with URP as an explicit, reasoned option rather than a blank.
• Validate state code and PIN together. Three of the new error codes are state/PIN consistency checks, not missing-field checks. A GSTIN that exists but does not match the ship-to state or PIN fails the same way a blank one does — and is harder to spot.
• Get ship details right at IRN time for B2B and SEZ. They cannot be replaced at the e-way bill stage.
• Keep a rejection log by error code. The distribution of 608/616/618/864/5001/5002 tells you immediately whether your problem is missing data or wrong classification.

Where Recoup fits

Recoup sits on the receiving side of this problem. 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 — so a supplier whose dispatches started failing in August shows up as a named exception at month-end, not an unexplained shortfall.

The honest framing: this is a master-data and transaction-classification problem before it is a tax problem, and the fix is in your ERP. Reconciliation gives you the early warning on the other side of the transaction — the suppliers who did not fix theirs.

Related guides