Through June and July 2026, dispatch teams across Indian factories were told to prepare for a hard cutover. The ship to GSTIN e-way bill field was going to become mandatory and validated, and any Bill-To/Ship-To consignment missing it would fail at generation. ERP teams rewrote address masters, GSPs published migration notes, and finance heads booked sandbox windows for late July. Days before the deadline, the package was pulled. If your project stopped mid-way and nobody has told you whether to resume, freeze, or roll back, this is what changed and what still needs fixing.
What actually happened between May and July 2026
The sequence matters, because most content still ranking on this topic was published before the final turn and has not been updated since.
| Date | Development |
|---|---|
| 20 May 2026 | Ship-To GSTIN proposed as a mandatory data element in Bill-To/Ship-To e-way bills |
| 10 June 2026 | Rollout deferred from 15 June to 1 August 2026 |
| 17 June 2026 | Requirement extended to the e-Invoice API and e-Way Bill by IRN API |
| 1 July 2026 | FAQs published covering Bill-to/Ship-to, exports and API impact |
| 29 July 2026 | Enhancements kept on hold until further notice |
The base document was GSTN's advisory dated 20 May 2026, which stated that in Bill-to/Ship-to transactions the Ship-To GSTIN field would be captured as a mandatory data element during e-Way Bill generation, with the value "URP" entered where the consignee is unregistered. The original 15 June date was pushed back by six weeks after ERP vendors, GSPs and transporters said they needed more time to update systems.
Then it stopped entirely. On 29 July 2026, GSTN issued an advisory placing the proposed e-Way Bill enhancements on hold until further notice, suspending the changes communicated through the June advisories and the July FAQs, and clarifying that taxpayers, transporters, ERP providers and GSPs are not required to implement any system changes in the production environment. GSTN also advised businesses not to modify their systems based on the earlier advisories and confirmed that the related advisories and FAQs would be withdrawn from the GST portal.
This is the second deferral of the same package inside seven weeks. With the e-way bill enhancements on hold and the source documents being withdrawn, the specification your team downloaded in July may now be the only copy available to you. That advisory, circulating as GSTN advisory 668, is worth archiving locally before it disappears.
The rule as it was written, and why it matters to factories
A Bill-To/Ship-To dispatch is one where the party you invoice and the party who physically receives the goods are different entities. For a trading company this is a single, predictable pattern. For a manufacturer it multiplies across the operation:
- Job-work triangulation: a principal sends material to a job worker, who ships finished output directly to the OEM
- Merchant export: a merchant exporter buys ex-works and nominates an ICD or port as the delivery point
- Intra-group movement: one group GSTIN raises the invoice, a plant under a different GSTIN receives the goods
- Direct-to-site delivery: a project customer bills from head office and takes delivery at a site in another state
- Multi-stage job work: material moves from one job worker to a second for a further operation without returning
Under the proposed rule, all of these Bill-To/Ship-To transactions would have required the actual consignee's GSTIN in a field that had been optional since 2018.
The proposal also addressed cases where no GSTIN exists. Where the consignee is unregistered, URP unregistered person was to be entered in place of a GSTIN. For goods dispatched to an Indian port or ICD for onward export, the guidance was to enter URP as the Ship-To GSTIN while recording the actual destination address and PIN code of the port or export location. For any manufacturer with export exposure, these are routine weekly dispatches rather than edge cases.
Why ERP-integrated plants faced more work than portal users
A company generating e-way bills by logging into the portal was facing a training problem. A company generating them from ERP was facing a software release. GSTN's API advisory made clear that the change applied to the e-Invoice API and e-Way Bill by IRN flows as well, meaning any ERP that auto-generates an e-invoice together with an e-way bill would need to push Ship-To GSTIN correctly wherever Bill-To and Ship-To differed.
The e-invoice API changes were narrower than most coverage suggested, and the distinction is worth holding on to:
| API surface | What was proposed |
|---|---|
| e-Way Bill portal / API | Ship-To GSTIN mandatory in Bill-To/Ship-To cases |
| e-Invoice API | Ship-details GSTIN only conditionally mandatory — where ship details are provided and an e-way bill is required |
| e-Way Bill by IRN API | Missing Ship-To GSTIN could still be supplied at this stage, making it recoverable without a fresh invoice |
Three surfaces, three behaviours. Teams that read them as one change built considerably more validation than the rule ever asked for — which is precisely what now has to be unwound.
Where ship-to data actually lives in ERPNext
Before deciding what to build, establish what your system already holds. In ERPNext the GSTIN sits on the Address doctype, and an address connects to a Customer through Dynamic Link. A Sales Invoice references a Customer Address for billing and a Shipping Address for delivery; the Delivery Note carries the same pair plus Transporter Info.
| Record | Field | Role in the e-way bill |
|---|---|---|
| Address (billing) | GSTIN | Drives tax calculation — almost always populated |
| Address (shipping) | GSTIN | Would have become the Ship-To GSTIN — frequently blank |
| Address (shipping) | PIN / State | Feeds destination validation |
| Delivery Note | Transporter Info | Vehicle, transporter ID, distance |
| GST Settings | e-Waybill config | Controls JSON assembly and API credentials |
When you trigger ERPNext e-way bill generation through the India Compliance app, the e-Waybill JSON is assembled from these linked records rather than from anything typed at dispatch time.
The failure point is structural, not technical. Billing addresses carry clean GSTINs because tax calculation depends on them. Shipping addresses are often created in a hurry during order entry with a street, city and PIN but no GSTIN and no link back to the receiving entity. E-way bills have generated correctly for years because the field was optional, so nobody flagged it. Under the proposed rule, each of those addresses becomes a blocked dispatch. Confirming your exposure takes one report: list every Address record used as a shipping address in the last six months and count the blanks.
Three data problems the deferral does not solve
Incomplete shipping-address records
Missing consignee GSTIN master data costs nothing today and everything on the day the rule returns. It is also the slowest item to fix, because it depends on collecting GSTINs from customers and job workers rather than on configuring software. Start now and it is a background task; start at cutover and it is a phone-call marathon run by your dispatch clerk.
Misclassified same-GSTIN deliveries
This is the trap most likely to produce rejections even after a clean data cleanup. Deliveries to a buyer's own warehouse or additional place of business under the same GSTIN were to be sent as a Regular transaction with the delivery address in the bill-to address field — not as a Bill-to/Ship-to transaction at all. Many ERPNext instances record these as ship-to variants simply because the physical address differs. The data is not wrong; the transaction type is. Correcting it is a review of how order entry uses shipping addresses.
Internal inconsistency on the address record
A GSTIN beginning with 24 attached to an address carrying a Maharashtra PIN passes ERPNext validation and fails API validation. These records are already generating quiet reconciliation noise in GSTR-1 and are worth cleaning regardless of what GSTN does next.
Subcontracting and job work: the highest-risk pattern
For job work dispatch compliance, the exposure concentrates in movements where goods never return to your plant. The straightforward case is contained: you raise a Subcontracting Order, issue material through a Stock Entry of type Send to Subcontractor, and the job worker is both consignee and known supplier.
The difficulty appears in the three-party flows:
- Principal issues material to Job Worker A under a delivery challan
- Job Worker A completes the operation and ships directly to the OEM, or to Job Worker B for a second operation
- The invoice runs principal-to-OEM while the physical movement runs job worker-to-OEM
- The Ship-To party may be an entity your ERP holds no GSTIN for, because they are neither your customer nor your supplier
These dispatches also have the least tolerance for delay. A rejected e-way bill on a finished-goods sale is an irritation; a rejected one on a job-work leg stalls a work order with downstream operations queued behind it. If you audit only one transaction category before the rule returns, audit this one.
What to freeze and what to keep
Freeze immediately:
- Any client-side validation already making Ship-To GSTIN mandatory. A mandatory field the portal does not require will stop you billing customers whose consignee GSTIN you do not hold, and the resulting failures land on your support desk rather than on GSTN's.
- Any release scheduled for the 1 August cutover — roll it back or put it behind a feature flag
- Vendor-pushed changes: confirm in writing that enforcement has been reverted
Keep and document:
- The shipping-address to GSTIN mapping
- The transaction-type classification review
- Sandbox test cases and error codes captured in July
- Any workflow built for the e-way bill closure facility, which was part of the same suspended package
Two deferrals in seven weeks indicate flexibility on timing. Nothing in the July advisory suggests the architectural direction has changed. Teams that treat a deferral as permission to abandon the work end up running the same project twice under worse time pressure.
8. A 30-day readiness plan that pays off either way
| Week | Action | Output |
|---|---|---|
| 1 | Audit shipping addresses for missing or inconsistent GSTINs | Ranked list by dispatch volume |
| 2 | Classify six months of dispatches by pattern | Volume count per category |
| 3 | Collect missing GSTINs, starting with your top 20 ship-to destinations | Updated Address records |
| 4 | Name a rejection owner and document the manual fallback | Escalation path with portal access |
None of this depends on the advisory returning. Cleaner address records improve GSTR-1 reconciliation, reduce input-credit disputes with customers, and cut the manual corrections your accounts team makes at month-end. That is the workable version of GST compliance for manufacturers: build the data quality that turns the next mandate into a configuration change rather than a project. Where dispatch, subcontracting and quality records already sit inside one ERPNext instance, as they do in a SigzenMFG deployment, most of this audit is a report rather than a data-collection exercise.
9. Frequently asked questions
Is Ship-To GSTIN mandatory on e-way bills right now? No. GSTN's advisory dated 29 July 2026 kept the proposed enhancements on hold until further notice and confirmed that no production system changes are required. The e-way bill portal and APIs continue to accept Bill-To/Ship-To consignments with the Ship-To GSTIN field left blank, exactly as they did before the May advisory.
Has the requirement been cancelled or only deferred? Deferred. The advisory uses the language of a hold rather than a withdrawal of intent, and this is the second postponement of the same package in seven weeks. GSTN has advised businesses not to modify their systems based on the earlier advisories and to wait for further communication, which leaves the door open to reissue.
Do I need to change my ERPNext setup today? No production change is required, and if your team already deployed a mandatory Ship-To GSTIN validation, revert it to optional. A client-side rule stricter than the portal's will block invoicing for customers whose consignee GSTIN you do not yet hold. Keep the master-data work in a tested branch instead of discarding it.
What should I enter when the consignee is unregistered? Under the proposed specification, the value "URP" was to be entered in the Ship-To GSTIN field where the consignee is an unregistered person. The same applied to goods sent to a port or ICD for export, with the actual destination address and PIN code of that location recorded alongside. Neither is enforced at present.
Does this apply to job work and subcontracting dispatches? Yes, wherever the invoiced party and the receiving party differ for example when a job worker ships completed output directly to your customer. Single-leg movements from principal to job worker under a delivery challan are simpler, since the consignee is a known supplier whose GSTIN is already in your master data.
What is the e-way bill closure facility? It was a proposed voluntary feature allowing suppliers, recipients and transporters to formally confirm delivery and close an e-way bill on the portal, replacing the current position where a bill simply lapses. It formed the second half of the same July package and is on hold alongside the Ship-To GSTIN change.
