Ship-to GSTIN is now mandatory on e-way bills: what cross-border sellers need to fix.

From 1 August 2026, GSTN requires a Ship-to GSTIN on every e-way bill that carries ship-to details — miss it and your invoice or e-way bill can be rejected at generation.

A change that GSTN first flagged for 15 June 2026 and then deferred after industry pushback finally went live on 1 August 2026: the Ship-to GSTIN field is now mandatory across the e-Invoice API, the e-Way Bill-by-IRN API, and the EWB Closure API, wherever ship-to details are present and an e-way bill is required. For any Indian company invoicing into a different delivery location than the buyer's registered address — a common pattern for cross-border groups, GCC captives, and multi-warehouse D2C operations — this is a live system dependency, not a compliance-calendar footnote.

What changed

Wherever a Bill-to/Ship-to transaction generates an e-way bill, the ShipDtls.Gstin field in the Generate IRN payload is now conditionally mandatory: it must be populated whenever a Ship-to Legal Name and Ship-to Address are present in the e-invoice schema and an e-way bill is requested in the same call. Where the consignee is unregistered or no GSTIN applies, the value URP is entered instead. As reported by multiple GST-compliance outlets, an integration that doesn't supply this field correctly risks having the invoice or e-way bill rejected at generation — which means goods do not move until it's fixed.

The one piece of good news

Alongside the mandate, GSTN introduced a voluntary e-way bill closure facility on the same three APIs: suppliers, recipients, transporters or drivers can now mark an e-way bill as closed once goods are delivered. It is explicitly optional, not a new obligation — but it gives businesses a cleaner audit trail for delivery confirmation than letting e-way bills simply expire.

Why this lands harder on cross-border and multi-entity sellers

Groups with an Indian subsidiary invoicing a group entity abroad, or shipping to a third-party warehouse or a client's designated consignee, are exactly the pattern this field targets. A GCC or India-entry structure with intercompany dispatch flows, a company drop-shipping to a customer's freight forwarder, or an exporter routing goods through a bonded warehouse before final dispatch — all of these involve a ship-to party that differs from the billed party, which is precisely where this field now bites. If your ERP, GST Suvidha Provider, or e-invoicing middleware hasn't been updated to populate ShipDtls.Gstin (or URP for unregistered consignees), the next affected shipment is the one that gets stuck.

What to check before your next shipment

• Confirm with your ERP or GST Suvidha Provider that Ship-to GSTIN capture is live in production, not just tested in sandbox.
• Audit your consignee master data — unregistered ship-to parties need a clean URP mapping, not a blank field.
• If you route through a bonded warehouse, C&F agent, or third-party logistics partner, confirm their GSTIN (or URP status) is captured correctly at the point of dispatch, not backfilled later.

How Advisory Monks Consulting helps

Our Global Outsourcing & Virtual CFO and India Entry practices work with founders and finance teams to keep GST, e-invoicing and cross-border dispatch documentation aligned as the compliance layer changes underneath them. See our Global Outsourcing & Virtual CFO practice or India Entry & Foreign Company Advisory for how we set this up end-to-end.

General information, not tax or compliance advice. Details are as reported by GST-compliance publications as of publication date; confirm current API specifications and your obligations with your GSP/ERP provider and a qualified GST practitioner before your next filing.

This note is general guidance, not tax or legal advice. Positions depend on your specific facts — speak with a partner before acting.