Voluntary Closure of e-Way Bill: What GSTN's New FAQ Means for Taxpayers, Transporters, and API Users

The Goods and Services Tax Network (GSTN) has issued a detailed FAQ, dated 1st July 2026, explaining a new facility called Voluntary Closure of e-Way Bill. This facility is set to go live on 1st August 2026 (a revised date from what was originally planned). Since the change touches everyone who deals with e-Way Bills, from suppliers and recipients to transporters, drivers, and ERP-integrated businesses, it is worth understanding in full. Below is a complete breakdown of what the facility does, how it works on the portal and through APIs, and what stakeholders need to prepare for.

What Is Voluntary Closure of e-Way Bill?

At its core, this facility lets a taxpayer or transporter formally mark an e-Way Bill (EWB) as closed once the goods it covers have actually been delivered. It is a way of telling the system "this movement is complete," rather than simply letting the EWB run out its validity period and fade into the background.

Importantly, this is not mandatory. Businesses can continue operating exactly as they do today, and nothing changes if they choose not to use the facility. It exists purely as an optional tool to keep records accurate.

Timing: When Should an EWB Be Closed?

The recommended practice is to close an EWB on the same day the goods are delivered, or on the day immediately after. That said, the system builds in some flexibility. The closure option remains usable for up to one day after the EWB's validity period expires.

There is one firm rule underneath this flexibility: the closure date (that is, the actual date of receipt or delivery of goods) must fall somewhere between the date the EWB was generated and its expiry date, extended by that one extra day.

An example from the FAQ makes this concrete. Suppose an EWB is generated on 20 June 2026, and its validity runs out on 30 June 2026. If the goods are actually delivered on 25 June 2026, the business has a window running from 25 June all the way to 1 July 2026 (one day past expiry) to formally close that EWB.

Who Is Allowed to Close an EWB?

Closure is not restricted to a single party in the transaction. It can be carried out by any of the following, depending on who is best placed to confirm delivery:

• The supplier
• The recipient
• The transporter handling the movement
• The driver or another authorised person, provided their mobile number was registered for this purpose

How Closure Works on the Portal:

For suppliers, recipients, and transporters, the closure option sits inside the e-Way Bill section of the portal, available once they log in. From there, two modes of closing EWBs are supported.

The first is EWB-wise closure, where a user picks out one specific e-Way Bill number and closes it individually after confirming delivery. The second is date-wise closure, which is more convenient for anyone managing volume: a logged-in user can pull up all EWBs tied to a particular date and close the eligible ones together. Multiple EWBs can indeed be closed in a single date-wise action, which should save considerable time for transporters or businesses handling many shipments.

There is also a separate path built specifically for drivers. A driver or other authorised person can close an EWB through a portal-based facility tied to their mobile number. Once logged in, all active EWBs linked to that number appear under the portal's Search option, and the driver can close any of them after delivery is complete.

It is worth noting that providing a mobile number is entirely optional. It only becomes necessary if the business wants the driver or an authorised person to have the ability to close EWBs directly. This number can be entered at the time the EWB is first generated, or added later during related actions such as vehicle updation, consolidated EWB handling, or validity extension, wherever those options are available in the system.

Impact on APIs and System Integrators:

Businesses that rely on ERP systems or other API-based integrations have not been left out. GSTN has confirmed that an API is available specifically for closing EWBs. To use it, three pieces of information need to be transmitted: the EWB number, the closure date, and a remarks field.

That remarks field does have a limit. Entries can run up to a maximum of 100 characters.

That said, the current API has some notable gaps that businesses should plan around:

• It does not support date-wise bulk closure. Each closure through the API is handled individually.
• There is no API to retrieve a list of EWBs that have already been marked closed, whether for a specific date or otherwise. GSTN has indicated this could be considered later, once the closure module has stabilised and real-world usage patterns become clearer.
• The Get EWB Details API will not, at least for now, show a distinct "Closed" status or a closed date. The existing status structure continues unchanged during this initial period, though a dedicated "Closed" status is planned for the future.
• APIs cannot currently capture or record a mobile number for driver or authorised-person closure. That functionality is portal-only for now, meaning a driver cannot close an EWB via API even if their number is on file.
• The API response does not currently identify who closed a particular EWB.

How Statuses and Post-Closure Actions Will Behave:

One of the more practical questions in the FAQ concerns what happens to an EWB's status once it is closed, and whether anything else can still be done to it afterward.

For now, the EWB status framework remains exactly as it is today: Active, Cancelled, or Discarded. Even after an EWB is closed, this framework stays in place during what GSTN calls the "initial stabilisation period." Closure details are still recorded in the system, but they are not yet reflected as a separate visible status. A dedicated "Closed" status is planned for introduction later, once things settle.

More notably, several actions remain available even after an EWB has been marked closed, at least for now. These include updating the transporter, extending validity, and updating vehicle details. GSTN describes this as a deliberate relaxation meant to benefit users while the new facility beds in. It will not last indefinitely, though. Once the system stabilises, these post-closure actions are expected to be curtailed, meaning businesses should not assume this flexibility is permanent.

Closure Is Not the Same as Cancellation or Expiry:

The FAQ is careful to draw a clear line between three concepts that might otherwise get confused.

Cancellation applies when an EWB was generated incorrectly, or when the intended movement of goods never actually happened, subject to the usual rules governing cancellation. Closure, by contrast, is used specifically when delivery has genuinely been completed; it is a positive confirmation of a transaction that did occur.

Expiry is different again. It is simply a function of the EWB's validity period running out over time. Closure, meanwhile, is an active step taken by a user to record that delivery has happened, regardless of where the EWB sits in its validity window.

Effect on e-Invoice and IRN-Linked EWBs:

Businesses using the e-Invoice system or generating EWBs alongside an Invoice Reference Number (IRN) will be relieved to know this change does not disrupt those processes. The e-Invoice API is only ever used to generate the e-Way Bill in the first place; everything that happens afterward, including closure, runs through the separate EWB APIs. So there is no knock-on impact on e-Invoice API, on the combined "Generate IRN and EWB together" flow, or on the "e-Way Bill by IRN" API.

Practically, this also means an EWB generated together with an IRN, or one generated using an IRN, can be closed just like any other EWB.

Business Scenarios Illustrating the Facility:

The FAQ walks through several everyday situations to show how this would play out:

• A supplier ships goods from Chennai to Bengaluru, and after delivery, logs in to close the EWB on the day of delivery or the next day.
• A recipient who receives goods against a supplier-generated EWB closes it themselves after receipt, to mark the movement as complete.
• A transporter carrying goods from Pune to Hyderabad closes the EWB through the portal once delivery is done.
• A driver whose mobile number was registered for closure uses the portal-based mobile facility to view and close the relevant EWB after delivery.
• Where a mobile number was missing or entered incorrectly, it gets corrected during vehicle updation, after which the driver or authorised person can proceed to close the EWB.
• An ERP-integrated taxpayer closes EWBs by calling the API and passing the EWB number, closure date, and remarks.
• A transporter managing several EWBs generated on the same date uses date-wise closure on the portal to handle them together.
• Even after an EWB is marked closed, a business might still need to update vehicle details, something the system currently permits during this stabilisation period, though this could change later.
• An API user looking for a date-wise list of closed EWBs will find this is not yet available, though GSTN has left the door open for it in future.

Consolidated Position at a Glance:

Pulling together the key facts from across the FAQ:

• The closure facility is voluntary, not mandatory.
• It can be used by the supplier, recipient, transporter, or driver/authorised person.
• Closure should ideally happen on the day of delivery or the day after, though the system allows it up to one day past expiry.
• The portal supports both EWB-wise and date-wise closure.
• An API is available for closure, requiring the EWB number, closure date, and remarks.
• There is currently no API for retrieving lists of closed EWBs, date-wise or otherwise; this may come later.
• A separate "Closed" status is planned but not yet live.
• During the initial stabilisation period, the existing Active/Cancelled/Discarded framework continues, and several post-closure actions remain permitted.
• APIs cannot currently capture a mobile number for driver-based closure, and drivers cannot close EWBs through the API, only through the portal.
• Remarks are capped at 100 characters.
• Neither the API response nor the EWB print currently shows who closed the EWB, or the closure date and remarks, on the printed document.

What Stakeholders Should Do Now:

GSTN has laid out fairly specific expectations for different groups ahead of the 1st August 2026 rollout:

Taxpayers should build an internal process for closing EWBs after delivery, wherever they intend to use this facility.

Transporters should get their operational teams familiar with both EWB-wise and date-wise closure, as well as how driver-based closure works.

Drivers and authorised persons should use the portal's mobile number-based closure option wherever their number has already been registered for this purpose.

ERP, GSP, ASP, and other API users should begin implementing the closure API, using the EWB number, closure date, and remarks fields as required.

All stakeholders should keep in mind that the relaxed post-closure actions available today (like updating transporter or vehicle details after closure) are temporary conveniences tied to the stabilisation period. They should not be treated as permanent features, since restrictions are expected once the system settles down.

Conclusion:

This facility does not change any compliance obligation around e-Way Bills; it simply gives businesses a cleaner way to signal that a shipment has actually reached its destination. For large transporters and ERP-driven businesses handling high volumes of EWBs, the date-wise closure option and the closure API could meaningfully cut down on manual tracking. For smaller taxpayers, it is entirely optional and can be adopted at whatever pace suits their operations.

Given that several elements (the API for retrieving closed EWBs, the dedicated "Closed" status, and the eventual restriction of post-closure actions) are all still evolving, businesses would do well to keep an eye on further updates from GSTN as the 1st August 2026 implementation date approaches and the system moves past its initial stabilisation phase.

By

Expert Team of Complytax Intelligent Solutions Private Limited