TaxTMI Login
TaxTMI 
Login
Loading...
Press 'Enter' to add multiple search terms. Rules for Better Search
of 3381 
Press 'Enter' after typing page number.
of 3381 Press 'Enter' after typing page number.
No Folders have been created
Are you sure you want to delete "My most important" ?
NOTE:
of 3381 Press 'Enter' after typing page number.
of 3381 Press 'Enter' after typing page number.
All News
of 3381 Press 'Enter' after typing page number.
All News
Note
Bookmark
Share
"Dear Stakeholders,
It is informed that various doubts, queries and representations received from taxpayers, trade, GST Suvidha Providers (GSPs) and other stakeholders regarding the mandatory capture of the Ship-to field in E-Way Bills and the voluntary closure of E-Way Bills have been examined. Accordingly, a comprehensive set of Frequently Asked Questions (FAQs) has been prepared to provide necessary clarifications on the applicable system validations, procedural requirements and manner of compliance. The stakeholders are requested to go through the FAQs for familiarisation with the applicable requirements, system validations and procedure to be followed.
GOODS AND SERVICES TAX NETWORK
(A Government Enterprise)
4th Floor, World Mark-1, East Wing, Asset 11, Hospitality
District, Aerocity, New Delhi 110037
Tel: 011-49111200, Fax: 011-49111210
E-Mail: [email protected], www.gstn.org.in
CIN: U72200DL2013NPL249988
FAQs on Bill-to/Ship-to Transactions, Export Scenarios and API Impact
(FAQs for stakeholder guidance and system readiness.)
Date: 01.07.2026
1. Scope and Implementation
Q1. What is the purpose of these FAQs?
These FAQs explain the proposed treatment of Ship-to GSTIN in Bill-to/Ship-to transactions, including different business scenarios, impact in e-Way Bill API, e-Invoice API and e-Way Bill by IRN flows. The FAQs are intended to help taxpayers, transporters, ERP vendors, GSPs, ASPs, private IRPs and other system integrators plan system readiness.
Q2. What is the main change being introduced?
In Bill-to/Ship-to and combination transactions, Ship-to GSTIN is required to be captured as a mandatory data element wherever the Ship-to party is registered. Where GSTIN is not available, “URP” may be entered, wherever applicable.
Q3. What is the revised date of implementation?
The revised date of implementation is 1st August, 2026.
Q4. Are the changes available in Sandbox?
The relevant changes have been released in Sandbox for testing. Taxpayers, ERP vendors, GSPs, ASPs, private IRPs and other system integrators are advised to complete testing and readiness before production implementation.
Q5. Why is Ship-to GSTIN being captured?
Ship-to GSTIN is being captured to improve traceability of goods movement, strengthen the audit trail in Bill-to/Ship-to transactions, and enable system-based verification by authorised officers.
2. Business Transaction Types
| Sl. No. | Transaction Type | Billing Flow | Movement of Goods | Ship-to GSTIN Treatment |
| 1 | Regular | Between supplier and buyer | From supplier to buyer | No. Ship-to GSTIN is not applicable to regular transactions |
| 2 | Bill-to/Ship-to | Between supplier and buyer | From supplier to third party as instructed by buyer | Mandatory where Ship-to party is registered. URP may be entered for supply to Unregistered persons. |
| 3 | Bill-from/Dispatch-from | Between supplier and buyer | From third party to buyer | Ship-to GSTIN is not required, since the delivery is being made to the buyer himself, who has already been declared as the Bill-to party. |
| 4 | Combination | Between supplier and buyer | From third party to fourth party | Mandatory where Ship-to party is registered. URP may be entered where GSTIN is not available. |
Q6. What is a Regular transaction?
A Regular transaction is a normal transaction where billing and movement of goods take place between the same two parties. For example, A Ltd. sells goods to B Ltd. and the goods move directly from A Ltd. to B Ltd.
Q7. What is a Bill-to/Ship-to transaction?
A Bill-to/Ship-to transaction is one where the invoice is issued to the buyer, but the goods are delivered to a third party as per the instruction of the buyer. For example, A Ltd. bills B Ltd., but ships the goods to C Ltd. on the instruction of B Ltd.
Q8. What is a Bill-from/Dispatch-from transaction?
A Bill-from/Dispatch-from transaction is one where billing is between the supplier and the buyer, but goods are dispatched from a third-party location. For example, A Ltd. bills B Ltd., but goods are dispatched from C Ltd. to B Ltd.
Q9. What is a Combination transaction?
A Combination transaction involves both Bill-to/Ship-to and Bill-from/Dispatch-from features. Billing is between the supplier and buyer, but goods are dispatched from a third party and delivered to a fourth party. For example, A Ltd. bills B Ltd., but goods move from C Ltd. to D Ltd. on the instruction of B Ltd.
Q10. Can Bill-to GSTIN and Ship-to GSTIN be the same in a Bill-to/Ship-to transaction?
No. In a Bill-to/Ship-to transaction, the Bill-to party and Ship-to party are expected to be distinct persons. Accordingly, the same GSTIN as mentioned in the Bill-to field should not be entered in the Ship-to GSTIN field.
Example 1 — Correct Bill-to/Ship-to case
A Ltd., Chennai sells goods to B Ltd., Bengaluru, but B Ltd. directs A Ltd. to deliver the goods directly to C Ltd., Mysuru.
Here, Bill-to and Ship-to are different persons, so Bill-to/Ship-to option can be used.
Example 2 — Not a Bill-to/Ship-to case
A Ltd., Chennai sells goods to B Ltd., Bengaluru, and goods are delivered to B Ltd.’s own warehouse/additional place of business.
Here, Bill-to GSTIN and Ship-to GSTIN are the same. Hence, it should not be treated as a Bill-to/Ship-to transaction.
How to do it in the system
Where goods are supplied to the buyer and delivered to the buyer’s own premises/additional place of business: Do not select Bill-to/Ship-to transaction.
The transaction may be entered as a regular supply transaction, and the actual delivery address may be mentioned in the Bill To address/place of delivery field, as applicable.
3. Confidentiality and Display of Ship-to GSTIN
Q11. Will Ship-to GSTIN be printed on the e-Way Bill?
No. Ship-to GSTIN shall not be printed on the e-Way Bill generated on the e-Way Bill portal.
Q12. Will Ship-to GSTIN be provided through GET e-Way Bill APIs?
No. Ship-to GSTIN shall not be provided through the GET e-Way Bill APIs.
Q13. What will continue to be visible on the e-Way Bill?
The relevant Ship-to address and PIN code shall continue to be shown as per the existing practice.
Q14. Who will be able to view the Ship-to GSTIN?
Ship-to GSTIN will be captured in the system for official purposes. It will be visible only to authorised officers for verification and enforcement purposes.
Q15. How is trade secrecy protected?
Trade secrecy is protected by ensuring that Ship-to GSTIN is captured in the system backend but is not printed on the e-Way Bill, is not displayed to taxpayers or transporters, and is not shared through GET e-Way Bill APIs.
4. Role-wise Generation Scenarios
Q16. If the supplier generates the EWB, how will Ship-to GSTIN be entered?
Where the supplier generates the EWB in a Bill-to/Ship-to transaction, Ship-to GSTIN may be entered by the supplier if the buyer provides the Ship-to GSTIN to the supplier.
Q17. What if the buyer does not want to share Ship-to GSTIN with the supplier?
If the buyer chooses not to share the Ship-to GSTIN with the supplier due to confidentiality concerns, the buyer may generate the e-Way Bill themselves and directly enter the Ship-to GSTIN in the system (as an inward e-Way Bill).
Q18. Can the transporter generate the EWB?
Yes. The transporter may generate the EWB if the required details are provided. However, where the buyer does not wish to disclose the Ship-to GSTIN to the transporter, the buyer may generate the EWB.
Q19. Can the Ship-to party see the details of the original purchaser or supplier?
The system design is intended to protect commercially sensitive information. Ship-to GSTIN is not printed in the taxpayer/transporter-facing EWB and is visible only to authorised officers.
5. Export and Merchant Exporter Scenarios
Q20. How does Bill-to/Ship-to arise in export transactions?
In export transactions, the goods may be billed to an overseas buyer, while the goods are physically moved from the supplier’s premises in India to a port, airport, ICD, CFS, customs area, freight forwarder location, CHA-nominated premises, or any other export-linked location.
Q21. What should be entered as Ship-to GSTIN in export Bill-to/Ship-to cases?
In export sub-supply type involving Bill-to/Ship-to transactions, Ship-to GSTIN is proposed to be entered as “URP”, where the Ship-to location is export-linked and no domestic registered Ship-to GSTIN is applicable.
Q22. Does entering URP mean that the transaction is treated as a domestic supply to an unregistered person?
No. Entry of URP is a system-level treatment for EWB generation in export-related movement. The nature of export shall be determined based on export invoice, shipping bill, customs documents, transport documents and other applicable records.
Q23. What should be entered as Ship-to address and PIN code in export cases?
The actual destination address and PIN code in India should be entered, such as the port, airport, ICD, CFS, customs area, freight forwarder location, CHA-nominated location or other export-linked location.
Q24. How should merchant exporter scenarios be handled?
Where goods are billed to a registered merchant exporter and moved directly to a port, airport, ICD, CFS, customs area or export-linked location for export, the Bill-to GSTIN would be the GSTIN of the merchant exporter and Ship-to GSTIN is required to be captured as a mandatory data element wherever the Ship-to location is registered. Where GSTIN is not available, “URP” may be entered, wherever applicable.
6. Impact in Standalone e-Way Bill API
Q25. What is the change in standalone Generate EWB API?
Ship-to GSTIN has been made mandatory in Ship-to and Combination transactions.
| Sl. No. | Validation / Requirement | System Treatment / Error Code |
| 1 | Ship-to GSTIN mandatory in Ship-to and Combination transactions | Error Code: 608 |
| 2 | Ship-to Trade Name | May be sent but optional |
| 3 | Ship-to GSTIN should not be sent in Regular transactions | Error Code: 616 |
| 4 | Ship-to GSTIN should not be sent in Bill-from/Dispatch-from transactions | Error Code: 864 |
| 5 | Bill-to GSTIN and Ship-to GSTIN should not be same in Ship-to and Combination transactions | Error Code: 618 |
Q26. Will Ship-to GSTIN field be rejected in Regular transactions?
Yes. Ship-to GSTIN should not be sent in Regular transactions. Error Code 616 is applicable.
Q27. Will Ship-to GSTIN field be rejected in Bill-from/Dispatch-from transactions?
Yes. Ship-to GSTIN should not be sent in Bill-from/Dispatch-from transactions. Error Code 864 is applicable.
Q28. Is Ship-to Trade Name mandatory in standalone EWB API?
No. Ship-to Trade Name may be sent but it is optional.
Q29. Does the PIN-State or State-GSTIN validation apply to standalone EWB API?
Yes. If Ship-to GSTIN is entered, it should correspond to the respective State as mentioned in State Code and PIN code should also correspond to the State Code mentioned.
Q30. How will bulk EWB generation behave if one record fails due to missing Ship-to GSTIN?
The existing behaviour shall continue. If there are errors due to newly introduced changes, only the respective request will fail and other valid requests will continue to generate the e-Way Bills.
7. Impact in e-Invoice API: Generate IRN and EWB Together
Q31. Is Ship-to GSTIN mandatory in IRN + EWB combined flow?
Yes. Ship-to GSTIN has been made mandatory if ship details are provided and e-Way Bill is required.
| Sl. No. | Validation / Requirement | System Treatment / Error Code |
| 1 | Ship-to GSTIN mandatory if ship details are provided | Error Code: 5002, with JSON parameter display name |
| 2 | Bill-to GSTIN and Ship-to GSTIN should not be same if ship details are provided | Error Code: 2323 |
| 3 | Ship-to State Code should match SHIP TO GSTIN State Code | Error Code: 2325 |
| 4 | Ship-to PIN Code should belong to Ship-to State Code | Error Code: 3039 |
Q32. Which e-Invoice field is proposed to be made conditionally mandatory?
In the Generate IRN payload schema, “ShipDtls.Gstin” shall be made conditionally mandatory where e-Way Bill generation is required.
Q33. What is the treatment where Ship-to GSTIN is not available in IRN + EWB flow?
Where GSTIN is not available, “URP” may be provided, wherever applicable.
Q34. Can the same GSTIN be entered in Bill-to and Ship-to fields in IRN + EWB flow?
No. If ship details are provided, Bill-to GSTIN and Ship-to GSTIN should not be the same.
8. Impact in e-Way Bill by IRN API
Q35. What is the change in e-Way Bill by IRN API?
GSTIN and Trade Name have been added in ExpShipDtls, and GSTIN has been made mandatory.
| Sl. No. | Validation / Requirement | System Treatment / Error Code |
| 1 | GSTIN and Trade Name added in ExpShipDtls; GSTIN mandatory | Error Code: 5001, with JSON parameter display name |
| 2 | For Export EWBs, ship details including GSTIN provided during IRN generation can be replaced | Allowed |
| 3 | For B2B and SEZ transactions, ship details provided during IRN generation cannot be replaced | Error Code: 2324 |
| 4 | If GSTIN was not provided during IRN generation, it can be provided during EWB by IRN | Allowed |
| 5 | Ship-to State Code should match SHIP TO GSTIN State Code | Error Code: 4074 |
| 6 | Ship-to PIN Code should belong to Ship-to State Code | Error Code: 3039 |
Q36. Can ship details be replaced while generating EWB by IRN?
For Export EWBs, ship details including GSTIN provided during IRN generation can be replaced. For B2B and SEZ transactions, ship details provided during IRN generation cannot be replaced.
Q37. If Ship-to GSTIN was not provided at IRN generation stage, can it be provided during EWB by IRN?
Yes. If GSTIN is not provided during IRN generation, it can be provided during e-Way Bill by IRN.
Q38. Will Ship-to GSTIN be printed in EWB generated through IRN?
No. Ship-to GSTIN shall not be printed in the EWB and shall not be provided through GET EWB APIs.
9. Common Questions Raised by Stakeholders
Q39. Is the mandatory Ship-to GSTIN requirement applicable only to standalone EWB generation?
No. The requirement is also being extended to IRN-related flows, namely Generate IRN and EWB together and e-Way Bill by IRN, as per the respective API changes.
Q40. When will the e-Invoice API changes be implemented in production?
The proposed date of implementation is 1st August, 2026.
Q41. Will Ship-to GSTIN and Ship-to Trade Name be available in Get EWB Details API?
Ship-to GSTIN shall not be provided through GET e-Way Bill APIs.
Ship-To Trade name will also not be provided in E Way Bill details.
Q42. Will a revised EWB PDF specimen be provided showing Ship-to GSTIN and Ship-to Trade Name?
Ship-to GSTIN shall not be printed on the EWB.
Q43. Is “URP” case-sensitive?
No, the value “URP” is not case-sensitive.
Q44. What should be done by taxpayers before implementation?
Taxpayers should update ERP/master data, capture Ship-to GSTIN wherever applicable, map third-party ship-to locations, complete API testing in Sandbox, and align operational teams before 1st August, 2026.
10. Quick Readiness Checklist
| Sl. No. | Stakeholder | Action Required |
| 1 | Taxpayers | Identify Bill-to/Ship-to and Combination transactions and start capturing Ship-to GSTIN/URP. |
| 2 | ERP/GSP/ASP/IRP | Update API payloads for standalone EWB, IRN + EWB and EWB by IRN flows. |
| 3 | Business users | Ensure Ship-to address and PIN code are correctly maintained. |
| 4 | Exporters / merchant exporters | Identify export-linked Ship-to locations where URP treatment may apply. |
| 5 | Transporters | Coordinate with taxpayers for required details, especially where EWB is generated by transporter. |
| 6 | All stakeholders | Complete Sandbox testing before 1st August, 2026. |
11. Business Transaction scenarios:
| Q. No. | Transaction Type | Description | Example | Whether "Ship-To GSTIN" is Required? |
| Q6 | Regular | A transaction where the invoice is issued to the buyer (Bill-to), and the goods are delivered to a Same person. | A Ltd. sells goods to B Ltd. and the goods move directly from A Ltd. to B Ltd. | No. This is not treated as a Bill to Ship to transaction. |
| Q7 | Bill-to / Ship-to Transaction | A transaction where the invoice is issued to the buyer (Bill-to), but the goods are delivered to a third party(Ship-to) as per the buyer's instructions. | A Ltd. raises the invoice on B Ltd., but ships the goods directly to C Ltd. on the instruction of B Ltd. | Yes. The GSTIN of C Ltd. (Ship-To party) should be entered in the Ship-To GSTIN field, where the consignee is a registered person. If the consignee is unregistered, “URP” should be entered. |
| Q8 | Bill-from / Dispatch-from Transaction | A transaction where the supplier raises the invoice to the buyer, but the goods are dispatched from a third-party location instead of the supplier's own premises. | A Ltd. raises the invoice on B Ltd., but the goods are dispatched from C Ltd. directly to B Ltd. | No. Since the goods are delivered to the buyer (B Ltd.), who is already the Bill-To party, there is no separate Ship-To GSTIN to be entered. Only the Dispatch-From details are required. |
| Q9 | Combination Transaction (Bill-to/Ship-to + Bill-from/Dispatch-from) | A transaction where both concepts are involved. The invoice is issued by the supplier to the buyer, the goods are dispatched from a third-party location, and delivered to another party as instructed by the buyer. | A Ltd. raises the invoice on B Ltd., the goods are dispatched from C Ltd., and delivered to D Ltd. on the instruction of B Ltd. | Yes. The GSTIN of D Ltd. (Ship-To party) should be entered in the Ship-To GSTIN field, where D Ltd. is a registered person. The Dispatch-From details should also be provided for C Ltd. |
FAQs on Voluntary Closure of e-Way Bill: Business Scenarios, API Impact and Portal Behaviour
(FAQs for stakeholder guidance and system readiness)
Date: 01.07.2026
1. Scope and Implementation
Q1. What is the Voluntary e-Way Bill Closure facility?
The Voluntary e-Way Bill Closure facility enables closure of an e-Way Bill after delivery of goods has been completed. It is intended to record completion of movement in the system.
Q2. Is closure of EWB mandatory?
No. Closure of EWB is voluntary in nature.
Q3. What is the revised implementation date?
The revised date of implementation is 1st August, 2026.
Q4. When can an EWB be closed?
An E-Way Bill may be closed after completion of delivery of goods. It is advised that such closure should be carried out on the date of delivery or on the immediately succeeding day.
However, the closure functionality shall remain available up to one day after the expiry of validity of the E-Way Bill. The date of closure, i.e. the date of receipt/delivery of goods, should fall between the date of generation and the date of expiry of the E-Way Bill.
For example, where an E-Way Bill is generated on 20.06.2026 and its validity expires on 30.06.2026, the date of closure may be any date between 20.06.2026 and 30.06.2026, depending upon the actual date of receipt of goods. If the goods are received on 25.06.2026, the E-Way Bill may be closed from 25.06.2026 up to 01.07.2026, i.e. one day after the expiry of validity.
Q5. Who can close an EWB?
An EWB may be closed by the supplier, recipient, transporter involved in the transaction, or driver/authorised person whose mobile number has been provided for closure.
2. Portal-based Closure
Q6. Where is the closure option available for supplier, recipient and transporter?
For suppliers, recipients and transporters, the closure option is available after login under the e-Way Bill section of the portal.
Q7. What are the portal modes for closure?
Closure can be performed EWB-wise or date-wise for logged-in users.
Q8. What is EWB-wise closure?
EWB-wise closure means that a specific e-Way Bill number is selected and closed after delivery is completed.
Q9. What is date-wise closure?
Date-wise closure allows the logged-in user to view EWBs for a particular date and close eligible EWBs after delivery.
Q10. Can multiple EWBs be closed through date-wise closure on the portal?
Yes, the option is available.
Q11. Can a driver or authorised person close an EWB?
Yes. A driver or authorised person can close an EWB through the portal-based mobile number closure facility, where the mobile number has been provided for closure purposes.
Q12. How does mobile number-based closure work?
All active EWBs linked to the concerned mobile number are displayed under the Search option on the EWB Common Portal, enabling closure by the authorised person after delivery.
Q13. Is mobile number entry mandatory?
No. Providing the mobile number is optional. However, if closure by driver or authorised person is intended, the relevant mobile number should be provided.
Q14. When can the mobile number be provided or updated?
The mobile number may be provided at the time of EWB generation. If required, it can also be updated during vehicle updation, consolidated EWB operations or extension of validity, wherever applicable in the system.
3. EWB API Impact
Q15. Is an API available for EWB closure?
Yes. An API has been provided for system integrators and API users for closure of EWBs.
Q16. What details are required for closure through API?
For closure through API, the EWB number, closure date and remarks are required to be transmitted.
Q17. Does the closure API support date-wise bulk closure?
No, the current API does not support date-wise bulk closure.
Q18. Is there any API to retrieve EWBs marked as closed, including date-wise retrieval?
No. Currently, no separate API has been introduced to retrieve EWBs that have been marked as closed, including date-wise retrieval of closed EWBs. Such functionality may be considered in future after the closure module is stabilised and based on operational requirements emerging from field usage.
Q19. Will Get EWB Details API show a separate Closed status or closed date?
At present, no separate provision has been introduced in the Get EWB Details API to return a Closed status or Closed Date. For the initial stabilisation period, the existing status framework is being continued. A separate status of “Closed” is proposed to be introduced in due course.
Q20. Can APIs capture the mobile number for closure by driver or authorised person?
No. At present, there is no provision in the APIs to capture or specify the mobile number for closure by driver or authorised person.
Q21. Can a driver or authorised person close EWB through API?
No. As per the current implementation, closure by driver or authorised person through mobile number-based access can be carried out only through the portal.
Q22. What is the character limit for closure remarks?
Closure remarks may be entered up to a maximum of 100 characters.
Q23. Does any API response indicate who closed the EWB?
As of now, the API response does not contain any field indicating the person who closed the e-Way Bill(EWB).
4. Status and Post-Closure Behaviour
Q24. Will a separate status of “Closed” be introduced?
Yes. A separate status of “Closed” is proposed to be introduced in due course for EWBs that have been marked as closed after completion of delivery.
Q25. What is the current EWB status framework?
Currently, the EWB status is reflected as Active, Cancelled or Discarded. For the initial stabilisation period, this existing status framework is being continued so that trade and system users are not adversely impacted during the transition phase.
Q26. If an EWB is marked as closed, will it immediately show as “Closed”?
During the initial stabilisation period, a separate “Closed” status may not be reflected in the existing status framework. However, closure details will be captured in the system.
Q27. Can user actions be performed after an EWB is marked as closed?
Yes. As of now, user actions such as Update Transporter, Extend Validity, Vehicle Updation and other permitted modifications will continue to remain available even after the EWB has been marked as closed.
Q28. Why are post-closure actions allowed initially?
This relaxation is being provided for the benefit of users during the initial stabilisation period.
Q29. Will post-closure actions be restricted later?
Yes. Once the system is stabilised, necessary restrictions will be introduced and post-closure actions will be suitably curtailed.
Q30. Can transporter details be updated after closure?
Yes. During the initial stabilisation period, updating transporter details will continue to be available even after the EWB has been marked as closed. Suitable restrictions may be introduced after stabilisation.
Q31. Can vehicle details be updated after closure?
Yes. Vehicle update will continue to remain available even after the EWB has been marked as closed during the initial stabilisation period. After stabilisation, such post-closure actions may be suitably restricted.
Q32. Can validity be extended after closure?
As of now, the option to extend validity will continue to remain available even after the EWB has been marked as closed. This is a temporary relaxation for the initial stabilisation period.
Q33. Is closure the same as cancellation?
No. Cancellation is used where EWB was wrongly generated or movement did not take place, subject to applicable rules. Closure is used after delivery of goods has been completed.
Q34. Is closure the same as expiry of EWB?
No. Expiry is based on the validity period of the EWB, whereas closure is a user action to record completion of delivery.
5. Impact in e-Invoice API and e-Way Bill by IRN
Q35. Is there any impact of voluntary closure on e-Invoice API?
The e-Invoice API facilitates only the generation of the e-Way Bill. After generation, all further operations relating to the e-Way Bill are handled exclusively through the EWB APIs. Accordingly, no impact is envisaged on the e-Invoice API.
Q36. Is there any impact of voluntary closure on Generate IRN and EWB together flow?
There is no impact.
Q37. Is there any impact of voluntary closure on e-Way Bill by IRN API?
There is no impact.
Q38. Can an EWB generated along with IRN be closed?
Yes, it can be closed.
Q39. Can an EWB generated using IRN be closed?
Yes, it can be closed.
6. Business Scenarios
Scenario 1: Supplier closes EWB after delivery
A supplier generates an EWB for goods dispatched from Chennai to Bengaluru. After goods are delivered, the supplier logs in and closes the EWB on the same day of delivery or on the immediately succeeding day.
Scenario 2: Recipient closes EWB after receipt
A recipient receives goods against an EWB generated by the supplier. After receipt, the recipient closes the EWB to record completion of movement.
Scenario 3: Transporter closes EWB after delivery
A transporter carries goods from Pune to Hyderabad. After delivery, the transporter closes the EWB through portal login.
Scenario 4: Driver closes EWB using mobile number
The driver’s mobile number is provided for closure. After delivery, the driver accesses the portal-based mobile number closure facility, views the active EWBs linked to the mobile number, and closes the relevant EWB.
Scenario 5: Mobile number updated during vehicle updation
An incorrect or missing mobile number is corrected during vehicle updation. The driver or authorised person may then close the EWB through the portal-based mobile number closure facility.
Scenario 6: Closure through API by ERP-integrated taxpayer
An ERP-integrated taxpayer closes EWBs through API after delivery by transmitting the EWB number, closure date and remarks.
Scenario 7: Date-wise closure by transporter
A transporter handles multiple EWBs generated on a single date. After delivery of goods, the transporter uses date-wise closure on the portal to identify and close eligible EWBs.
Scenario 8: EWB marked as closed but vehicle update attempted
During the initial stabilisation period, vehicle updation and other permitted actions will continue to remain available even after closure. After stabilisation, such post-closure actions may be suitably restricted.
Scenario 9: API user wants date-wise list of closed EWBs
At present, no separate API has been introduced for date-wise retrieval of closed EWBs. Such functionality may be considered in future after stabilisation and based on field requirements.
7. Consolidated Position Matrix
| Sl. No. | Issue | Current Position / Reply |
| 1 | Nature of closure facility | Voluntary |
| 2 | Who can close EWB | Supplier, recipient, transporter, driver/authorised person |
| 3 | Closure timing | Same day of delivery or immediately succeeding day |
| 4 | Portal closure modes | EWB-wise or date-wise |
| 5 | API for closure | Available using EWB number, closure date and remarks |
| 6 | API for date-wise retrieval of closed EWBs | Not available currently; may be considered in future |
| 7 | Separate Closed status | Proposed to be introduced in due course |
| 8 | Existing status framework during initial period | Active, Cancelled and Discarded will continue |
| 9 | Post-closure actions | Allowed during initial stabilisation period |
| 10 | API mobile number capture for driver/authorised person closure | Not available currently |
| 11 | Driver/authorised person closure through API | Not available currently; portal only |
| 12 | Remarks character limit / fixed reason code | Upto 100 characters |
| 13 | ClosedBy in API / Get Details response | Not available currently |
| 14 | Closure date and remarks in EWB print | Not available currently |
8. Action Required from Stakeholders
| Sl. No. | Stakeholder | Action Required |
| 1 | Taxpayers | Create internal process to close EWB after delivery wherever the facility is used. |
| 2 | Transporters | Familiarise operational teams with EWB-wise/date-wise closure and driver-based closure. |
| 3 | Drivers / authorised persons | Use portal-based mobile number closure where mobile number has been provided. |
| 4 | ERP/GSP/ASP/API users | Implement closure API using EWB number, closure date and remarks. |
| 5 | All stakeholders | Note that post-closure actions are temporarily allowed during initial stabilisation period but may be restricted later. |
Thank you,
Team GSTN
