Vehicle Tracking And OTP Verification In e-Way Bill Compliance

Introduction

An e-way bill is only as reliable as the data inside it. A document that carries the wrong vehicle number, a stale Part B with an outdated transporter assigned, a consignment value that does not match the linked invoice, or a GSTIN that has been blocked for return non-compliance – any of these makes the e-way bill non-compliant even if it has a valid EWB number. The goods traveling under it are exposed to detention, seizure, and penalties that can significantly exceed the value of any tax involved.

For enterprise shippers managing hundreds of active e-way bills simultaneously, the ability to detect these compliance mismatches before goods move – and to monitor them continuously during transit – is not a convenience feature. It is the difference between smooth logistics operations and vehicles stopped at check posts with goods detained, drivers holding documentation that contradicts reality, and tax notices arriving weeks after delivery based on FASTag-EWB mismatch data that the GST analytics wing has already flagged.

This blog covers the full picture of pre-transit mismatch detection, vehicle tracking, Part B update compliance, OTP-based delivery verification, RFID-FASTag enforcement, recipient acceptance workflows, and transit alert management – explaining what the platform checks, when it checks it, how it alerts the right people, and what delivery proof capabilities protect the business at the point of receipt.

The Compliance Risk Landscape for Goods in Transit

India’s e-way bill enforcement has matured significantly since the system’s introduction. The compliance risks for shippers have expanded in step with this maturation, and the types of mismatches that attract enforcement action have broadened.

The Pre-Transit Risk Window

Most e-way bill compliance problems are preventable before the vehicle departs. A vehicle number entered incorrectly at dispatch, a GSTIN that has been suspended overnight due to return non-compliance, a consignment value that has been manually adjusted after the e-way bill was generated, or a Part B entry that references a vehicle that is not in the Vahan database – all of these are detectable before the truck gate opens. The cost of catching them before departure is a corrected document and a five-minute delay. The cost of discovering them at a check post is detention of goods, a detention notice under Section 129 of the CGST Act, and a penalty of up to Rs. 10,000 or the tax evaded, whichever is higher.

The In-Transit Risk Window

Once goods are on the road, compliance risks shift from data quality to temporal validity. A e-way bill With accurate data at departure may expire mid-journey if the vehicle is delayed. A vehicle substitution at a transshipment point that is not reflected in Part B creates a mismatch between the vehicle carrying the goods and the vehicle recorded in the portal.

A consignment that passes a toll plaza without a valid e-way bill – or with an expired one – now generates an automated enforcement alert through the RFID-FASTag integration at national highway check points.

The Post-Transit Risk Window

Even after delivery, compliance risks persist. If the recipient does not accept or reject the e-way bill within 72 hours of generation (or before actual delivery, whichever is earlier), the portal treats the consignment as deemed accepted. But if the recipient has a valid reason to dispute – wrong goods, short supply, damaged consignment – and misses the 72-hour window, the acceptance is locked and the dispute mechanism becomes more complex.

On the supplier’s side, e-way bill data that does not reconcile with GSTR-1 outward supply declarations attracts system-generated scrutiny notices from the GST analytics wing, which correlates EWB data with return data, e-invoice data, and FASTag toll records.

Pre-Transit Mismatch Detection – What the System Checks Before Dispatch

The platform runs a multi-layer pre-transit compliance check on every e-way bill before the dispatch confirmation is recorded. These checks are not a substitute for the portal’s own validation – they run before the portal submission, catching errors that would either fail at the portal or, worse, pass the portal and create a compliant-looking document with incorrect data.

Vehicle Number Validation Against the Vahan Database

The vehicle registration number entered in Part B is validated against the Vahan database maintained by the Ministry of Road Transport and Highways. The Vahan database holds records of all registered motor vehicles in India. A vehicle number that does not exist in Vahan – because it has been mistyped, because the vehicle was recently registered and has not yet been indexed, or because a temporary registration number has been used – will be rejected by the e-way bill portal. The platform pre-validates against Vahan before the portal submission, returning the specific failure reason to the logistics team for correction.

The Vahan validation also reveals vehicle registration status. A vehicle whose registration has expired or been suspended cannot legally carry goods in interstate commerce. When the Vahan check returns an inactive or suspended status, the platform flags the vehicle and prompts the logistics team to assign a compliant vehicle before the dispatch proceeds.

GSTIN Status Check for Supplier, Recipient, and Transporter

E-way bill generation is blocked by the portal when the supplier’s GSTIN is suspended, provisional, inactive, or cancelled. It is also blocked when the supplier’s GSTIN has been flagged for non-filing of two or more consecutive GSTR-3B returns. The platform checks all relevant GSTIN statuses in real time against the GSTN database before processing any e-way bill requests. If a supplier GSTIN is blocked, the platform surfaces the blocking reason and estimated unblocking timeline (typically the next day after returns is filed) so the dispatch team can plan accordingly.

The recipient’s GSTIN is checked separately. If the recipient of GSTIN is active or suspended, the e-way bill can still be generated. But if it is cancelled, inactive, or provisional, the portal blocks generation. The platform flags these cases before submission, prompting verification of the recipient’s current GST registration status – particularly important for consignments to long-standing customers whose registration status may have changed without the supplier’s knowledge.

Consignment Value Discrepancy Detection

A consignment value mismatch occurs when the value recorded in the e-way bill differs from the value in the linked invoice, delivery challan, or e-invoice. This discrepancy may arise because the invoice value was updated after the e-way bill was generated, because a line item was added or removed at the loading bay, or because the e-way bill was generated from a draft invoice that was subsequently finalized with a different value.

 The platform cross-checks the e-way bill consignment value against the source document value at the point of dispatch confirmation.

Part B Completeness Check

An e-way bill with only Part A completed has no validity period. The e-way bill number exists, but the goods cannot legally move until Part B – vehicle number and transporter details – is entered. The platform tracks Part B completion status for every generated e-way bill. Any e-way bill that approaches its dispatch schedule without a completed Part B generates an alert to both the logistics team and the transporter’s contact, prompting urgent completion before the vehicle loads.

The platform also checks that the vehicle number in Part B matches the vehicle that is scheduled for the dispatch. In operations where vehicles are pooled and allocated dynamically, it is common for a Part B to be entered with one vehicle and the goods then loaded onto a different vehicle. The platform compares the Part B vehicle against the logistics system’s vehicle allocation record and flags any mismatch before the vehicle departs.

Document Date Age Validation

Since January 2025, e-way bills cannot be generated for invoices dated more than 180 days before the generation date. The platform validates the document date at the point of e-way bill initiation and blocks generation for any invoice or delivery challan that is older than 180 days. This is particularly relevant for shipments of slow-moving goods where inventory has been invoiced in advance of dispatch, and for cases where a delivery was returned and is being re-dispatched against the original invoice.

Duplicate E-Way Bill Detection

The portal prevents duplicate e-way bills for the same invoice number and date. The platform tracks all active and cancelled e-way bills against their source documents and alerts the user if an attempt is made to generate an e-way bill for an invoice that already has one. This prevents situations where a transporter or dispatcher generates an e-way bill unaware that one already exists for the same consignment, which would have resulted in a portal rejection and confusion about which document is valid.

HSN Goods Presence Validation

E-way bills can only be generated for invoices containing at least one line item classified under a goods HSN code. Invoices that cover only services do not qualify. The platform checks HSN Classification in the invoice line items at the point of e-way bill initiation and surfaces this condition if the invoice covers only services, preventing a portal submission that would be rejected. For mixed invoices covering both goods and services, the platform confirms that the goods component exceeds the applicable threshold before initiating e-way bill generation.

Part B Update and Vehicle Change Management During Transit

One of the most frequent compliance events during an active shipment is a vehicle change. A truck breaks down on the highway, and the goods are transferred to a replacement vehicle. A transshipment hub moves the consignment from a long-haul truck to a last-mile delivery van. A rail booking is changed, and the goods move from one rake to another. Each of these events must be reflected in the e-way bill of Part B before the goods resume movement in the new vehicle.

The Part B Update Rule

Part B of an e-way bill can be updated multiple times within its validity period. The vehicle number field specifically exists to accommodate mid-transit vehicle changes. Each update to the vehicle number in Part B is recorded with a timestamp in the portal audit trail. Crucially, a Part B update does not reset or extend the e-way bill’s validity – validity is calculated from the first Part B entry and is fixed for the distance declared at that point. A vehicle change does not grant more time.

The only exception to the rule that Part B cannot extend validity is when the reason for the vehicle change is a breakdown or other exceptional circumstance, in which case the transporter may also apply for a validity extension simultaneously with the vehicle update. The extension request requires selecting the reason from a defined list and updating the current location details.

Platform-Managed Part B Updates

For enterprise logistics operations, Part B updates are managed through the platform’s logistics event tracking rather than through individual portal logins. When the logistics management system records a vehicle substitution event – the dispatcher confirms that cargo has been transferred from Vehicle A to Vehicle B at a transshipment point – the platform automatically generates a Part B update request for the affected e-way bills, submits it to the portal, and confirms the update. The event is logged in the consignment’s transit history alongside the timestamp and reason code.

Bulk Part B updates are supported for operations managing multiple simultaneous vehicle changes – as happens at large cross-docking facilities where dozens of consignments may be re-sorted and re-loaded in a single shift. The platform aggregates all vehicle change events from the shift, prepares the update file, submits it to the portal in a single batch, and confirms each update against the affected e-way bill records.

Multi-Vehicle Consignments

A single consignment that cannot fit in one vehicle may be split across multiple vehicles, each requiring its own e-way bill. When a multi-vehicle dispatch is planned, the platform generates separate e-way bills for each vehicle portion of the consignment, links them in the system under the same source invoice and tracks their combined delivery status. If one vehicle’s portion is delivered while another is delayed, the delivery tracking accurately reflects the partial delivery and maintains the open e-way bill for the remaining portion.

OTP Verification in E-Way Bill Compliance

OTP (One-Time Password) mechanisms appear at multiple points in the e-way bill compliance lifecycle. Understanding what each OTP mechanism covers and how it interacts with the platform’s workflow is important for compliance teams managing the full transit cycle.

Portal Login MFA – The Access Security Layer

All e-way bill portal logins – whether through the main portal at ewaybillgst.gov.in or the parallel portal at ewaybill2.gst.gov.in launched in July 2025 – require multi-factor authentication for all taxpayers from April 1, 2025. The MFA uses an OTP sent to the registered mobile number associated with the GSTIN, typically through SMS or the Sandes app. This OTP gates access to every portal action – generation, update, cancellation, and extension.

For enterprise API integrations managed through the platform, this portal MFA is handled at the API credential level. The API authentication uses encrypted credentials and registered API keys that satisfy the MFA requirement at the session level, rather than requiring a human to receive and enter an OTP for each action. Sub-users of a GSTIN each have their own authentication credentials and OTP mechanism based on their individually registered mobile numbers in the e-way bill and e-invoice systems.

Recipient Delivery Confirmation – The Delivery OTP Mechanism

A distinct OTP mechanism that operates at the point of delivery serves as a proof-of-delivery tool in logistics operations linked to the e-way bill system. When goods arrive at the delivery address, the platform generates a delivery of OTP tied to the specific e-way bill and consignment.

The delivery of OTP is shared with the recipient’s designated contact through the platform or through the transporter’s delivery management system. The delivery driver obtains confirmation that the OTP has been received and verified by the recipient’s team – confirming that the goods have arrived at the correct destination and been received by an authorized person.

This delivery of OTP confirmation does two things simultaneously. It provides the supplier and transporter with documented proof that the consignment was delivered to the correct recipient – important for managing disputes over non-delivery claims and for triggering payment milestones in contracts tied to delivery confirmation. And it timestamps the delivery in the platform’s consignment record, linking the delivery event to the e-way bill, the invoice, and the transport document in a single auditable history.

Portal’s Recipient Acceptance and Rejection – The 72-Hour Window

The e-way bill portal provides a separate formal mechanism for recipient acceptance and rejection, independent of the delivery of OTP. When an e-way bill is generated against a recipient’s GSTIN, the recipient can view it on the portal and formally communicate acceptance or rejection within 72 hours of generation or before the actual delivery of goods, whichever occurs first.

If the recipient takes no action within 72 hours, the portal treats the consignment as deemed accepted. This deemed acceptance is binding from the portal perspective, even if the goods are later disputed, because the 72-hour window has closed without formal rejection.

The platform manages this 72-hour window proactively. For every incoming e-way bill generated against the business’s GSTINs as recipient, the platform tracks the acceptance window and alerts the receiving team when the window is approaching expiry without a decision. For consignments that are in transit and expected to arrive near the 72-hour mark, the alert is escalated to ensure that a responsible person reviews the e-way bill details and makes an informed acceptance or rejection decision before the deemed acceptance locks in.

Transit Validity Monitoring and Expiry Alert Management

Once goods are in transit, the e-way bill validity is the primary compliance parameter to monitor. Validity is not extended automatically for any reason. It expires on a fixed schedule based on distance, and the only way to extend it is through a manual action on the portal – which can only be initiated in a narrow 8-hour window before or after expiry.

Real-Time Validity Dashboard

The platform’s transit monitoring dashboard displays all active e-way bills sorted by time remaining to expire. Color-coded status indicators give the logistics team an immediate visual overview: green for bills with more than 24 hours remaining, amber for bills between 6 and 24 hours from expiry, and red for bills within 6 hours of expiry or already in the extension window. Clicking on any record shows the full consignment details, the dispatch time, the expected delivery time from the transport booking, and the gap between the expected delivery and the validity of expiry.

Configurable Alert Thresholds

The platform supports configurable alert thresholds calibrated to the business’s operational rhythm. A manufacturer of shipping on fixed overnight routes may configure alerts at 6 hours remaining – sufficient time to initiate an extension if a vehicle is delayed. A logistics company managing long-haul interstate freight with variable transit times may configure alerts at 24 hours remaining and a follow-up at 6 hours. The alert recipients are also configurable: the generating GSTIN’s compliance team, the assigned transporter’s contact, and an escalation contact for high-value consignments.

The Extension Initiation Workflow

When an expiry alert triggers an extension requirement, the platform guides the compliance team through the extension workflow. The extension requires selecting a reason from the portal’s approved list – vehicle breakdown, natural calamity, law and order issues, transshipment delay, accident of conveyance – and updating the current location and remaining distance. The platform pre-fills the current location from the logistics system’s last recorded vehicle position and calculates the remaining distance to destination, reducing the data entry required from the compliance team.

The extension cap of 360 days from the original generation date means that severely delayed consignments eventually reach a point where extension is no longer possible. The platform tracks cumulative extension history for every e-way bill and alerts the team when an active bill is approaching the 360-day cap, prompting them to either expedite delivery or plan for a new e-way bill under an amended or reissued invoice.

RFID and FASTag Integration – Government-Side Tracking

The GST enforcement landscape changed significantly with the operationalization of RFID-FASTag integration at national highway toll plazas. This integration cross-references the e-way bill portal data against real-time vehicle movement data captured at toll plazas – creating an enforcement mechanism that operates without any physical interception.

How the Integration Works

RFID readers installed at toll plazas read the FASTag embedded in vehicles passing through. The toll data – vehicle registration number, timestamp, toll plaza location – is transmitted to a central system. The GSTN’s analytics wing cross-references this toll data against the e-way bill portal to verify that every vehicle carrying goods above the threshold has a valid active e-way bill at the time of passing each toll point.

Where a vehicle passes a toll without a valid e-way bill – because the e-way bill was never generated, because it expired before the vehicle reached that point, or because the vehicle number in the e-way bill does not match the FASTag vehicle number – the system generates an automated compliance alert. This alert is forwarded to the enforcement wing and can result in a show-cause notice being issued to the supplier, the recipient, and the transporter – sometimes weeks after the goods have already been delivered.

The Vehicle Number Match Requirement

The FASTag integration makes the accuracy of the vehicle number in Part B of the e-way bill critically important in a way that was less pressing before automated toll checks. The FASTag is associated with the vehicle’s registration number. If the e-way bill lists a different vehicle number – because Part B was not updated after a vehicle substitution at a transshipment point, or because the vehicle number was entered with a transcription error – the FASTag data and the e-way bill record will not match at the toll plaza. The mismatch is recorded and can generate a compliance notice.

The platform addresses this by making Part B updates easy and mandatory. When the logistics system records a vehicle change event, the platform integration immediately initiates the Part B update on the portal. The compliance record is maintained in real time throughout the journey, not as a retrospective correction. This keeps the FASTag vehicle number and the EWB Part B vehicle number synchronized throughout the transit chain.

RFID Tags for Transporters with Large Fleets

For registered transporters operating more than 20 vehicles, RFID tags issued by the GST department – separate from FASTag – are mandatory and must be affixed to each vehicle. These are Class 1 Gen 2 RFID tags mapped to the e-way bills carried by that vehicle. When the vehicle passes an RFID reader at a designated check post, the system reads the tag and verifies that the associated e-way bills are valid. This mechanism allows remote verification of multiple consignments on the same vehicle simultaneously, without requiring the driver to present documentation physically.

The platform maintains the mapping between vehicle-specific RFID tags, and the e-way bills assigned to those vehicles. As e-way bills are generated and assigned to vehicles, the platform updates the tag mapping in real time. This ensures the enforcement system always has current data about which consignments are on which vehicles.

E-Way Bill and GSTR-1 Reconciliation – Closing the Loop

Transit compliance does not end at delivery. The GST analytics wing actively correlates e-way bill data with GSTR-1 outward supply data, e-invoice data, and FASTag toll records to identify patterns that suggest tax evasion or documentation inconsistency. A supplier whose e-way bill data consistently shows different consignment values from their GSTR-1 declarations, or whose e-way bills show interstate movement that does not appear in their return’s inter-state supply column, is generating a compliance risk that the system will eventually surface.

What the Reconciliation Checks

The platform’s post-delivery reconciliation module matches the e-way bill to register against the GSTR-1 outward supply data for each filing period. The reconciliation looks for three types of gaps. First, e-way bills generated in the period that do not appear as outward supplies in GSTR-1 – indicating either a missed entry or a supply that was dispatched but not invoiced.

Second, outward supplies declared in GSTR-1 above the e-way bill threshold that do not have a corresponding e-way bill – indicating a potential compliance gap. Third, value mismatches where the e-way bill consignment value and the GSTR-1 taxable value for the same transaction differ beyond a de minimis threshold.

Each identified gap is surfaced in the reconciliation dashboard with the specific e-way bill or GSTR-1 entry involved, the nature of the discrepancy, and a suggested resolution. Gaps that have benign explanations – a consignment that was cancelled and the e-way bill and invoice were both cancelled, or a transaction value corrected by a credit note – are resolved through the supporting documentation link in the platform. Unexplained gaps are escalated to the tax team for investigation before the return is filed.

The Consequence of Unresolved Mismatches

Unresolved mismatches between e-way bill data and GSTR-1 data are a known source of scrutiny notices under Section 61 of the CGST Act. The GST analytics wing’s automated processing of EWB, e-invoice, and return data means that mismatches are identified systematically, not just during departmental audits. A business with persistent EWB-GSTR-1 mismatches will receive system-generated notices requiring explanation, potentially opening the door to a broader audit. The platform reconciliation module is designed to identify and resolve these gaps at the point of return preparation, before they become a compliance conversation with the department.

Delivery Proof Capabilities and Transit Documentation

Delivery proof serves multiple functions in the e-way bill compliance lifecycle. It confirms that goods reached the correct destination within the validity period. It supports the supplier’s case if the recipient raises a non-delivery claim. It timestamps the delivery event in relation to the e-way bill validity period. And it creates the evidentiary record that demonstrates compliance if the transaction is later scrutinized by the department.

Electronic Proof of Delivery

The platform supports electronic proof of delivery (ePOD) capture at the point of receipt. The delivery driver opens the consignment in the platform’s mobile interface, confirms the e-way bill number and the delivery address, and the recipient’s authorized representative signs electronically on the delivery app screen. The signed delivery confirmation is timestamped, geotagged if permitted by the recipient, and linked to the e-way bill record in the platform.

Alongside the electronic signature, the platform supports photo capture at delivery: a photograph of the goods at the delivery point, a photograph of the delivery location, and if there is a discrepancy, a photograph of the specific items in question. This visual evidence is stored against the consignment record and is retrievable alongside the e-way bill history if a dispute arises.

Consignment Discrepancy Documentation at Delivery

When goods arrive in a condition different from the e-way bill’s description – short quantity, wrong items, damaged packaging, or goods that do not match the HSN code on the bill – the delivery driver documents the discrepancy through the platform’s discrepancy reporting interface. The driver records the nature of the discrepancy; the quantity or items affected and photographs the evidence. This creates a contemporaneous record of the delivery condition that is date and time stamped at the point of receipt.

The discrepancy report triggers an automatic alert to the supplier’s logistics team and the customer service contact. It initiates the rejection or partial acceptance workflow in the platform, which feeds into the 72-hour acceptance/rejection window on the e-way bill portal. The documentation created at this point becomes the evidentiary basis for any subsequent dispute resolution, credit note issuance, or insurance claim.

Form GST EWB-04 for Detention Reporting

If a vehicle carrying goods is intercepted, stopped, or detained by a GST officer for more than 30 minutes, the transporter has the right to upload information about the detention in Form GST EWB-04 on the common portal. This creates a formal record of the detention event that is visible to the supplier, the recipient, and the department. The platform tracks EWB-04 uploads against active consignments and alerts the compliance team when a detention is reported, allowing them to respond proactively – whether by providing additional documentation, arranging for legal representation, or initiating the resolution process for any error that triggered the detention.

Inspection Records Under Rule 138C

When a GST officer conducts a physical inspection of goods in transit, the inspection summary must be recorded online in Part A of Form GST EWB-03 within 24 hours of the inspection, and the final report must be submitted in Part B of EWB-03 within 3 days. Goods may only be inspected once during a journey under normal circumstances. The platform tracks inspection events against active e-way bills and maintains a record of each inspection against the consignment history, providing the compliance team with complete documentation if follow-up queries arise.

FAQs