India E-Way Bill System: Rules, Thresholds, Part A & B

India's e-way bill system is the GST-linked process used to track the movement of goods. In practice, businesses usually start paying attention to it when an inter-state consignment exceeds Rs 50,000, but that is only the first checkpoint. Some intra-state movements also need an e-way bill based on state-specific rules, and the operational burden is split between Part A, which captures the document and supply details, and Part B, which completes the transport side of the record. Key 2025 controls now block generation from invoices or challans older than 180 days, require MFA for taxpayers using the system, and cap extensions at 360 days from the original generation date.

That distinction matters because dispatch failures usually start upstream. If the invoice or delivery challan details are wrong, Part A is wrong. If the vehicle or transporter update is wrong, Part B is wrong. Either way, the shipment can be stopped even when the commercial transaction itself is genuine.

The current rule environment is also stricter than many older explainers suggest. For dispatch and compliance teams, the India e-way bill system is no longer just a tax checkbox. It is a live workflow that links GST records, source-document quality, transport updates, and timing controls before goods move.

This guide is built around that workflow. Instead of treating the e-way bill as a standalone portal form, it shows how threshold checks, Part A data, Part B updates, e-invoice integration, validity rules, exemptions, and penalty risks fit together in the same operating process.

When an E-Way Bill Is Mandatory and How the Rs 50,000 Threshold Really Works

The baseline rule is straightforward: when a registered person causes the inter-state movement of goods and the consignment value exceeds Rs 50,000, an e-way bill is generally required before movement starts. That is the rule most teams remember, but it should not be treated as the whole decision tree.

First, the movement may be tied to different base documents. In many cases that document is the tax invoice. In others it may be a bill of supply or a delivery challan, such as stock transfers, goods sent for job work, or other movements that are not a normal taxable outward sale. If the source document is a GST tax invoice, this Rule 46 checklist for India GST invoices helps confirm the record has the mandatory fields before it feeds the transport workflow. If your movement is backed by a challan rather than a standard invoice, the same document-control thinking covered in delivery note fields and shipment handoff basics becomes relevant because the e-way bill is only as strong as the source document behind it.

Where the underlying purchase also shifts GST liability to the recipient, teams may need to align dispatch checks with India GST reverse charge and self-invoice rules so the transport trail and tax-document trail stay consistent.

Second, intra-state movement is where teams often get caught out. The national system gives you the framework, but states can notify their own position for intra-state thresholds and requirements. That means a dispatch team should not assume that an inter-state rule summary automatically answers an intra-state movement within the same state. If the shipment is time-sensitive, check the current state notification before the truck leaves.

Third, responsibility changes with the movement model. A supplier moving goods in its own vehicle may complete the process directly. If the goods are handed to a transporter and no valid e-way bill has yet been generated, the transporter may have to generate it based on the invoice, bill of supply, or delivery challan. That is why threshold checks should sit in the dispatch workflow, not only with the tax team.

One more practical point: businesses can generate an e-way bill voluntarily even below the Rs 50,000 threshold. That does not turn the threshold into a mandatory rule for every shipment, but it does mean teams can use the system for control and traceability where a customer, transporter, or internal SOP expects it.

Part A vs Part B: Which Data Comes From the Invoice and Which Comes From Transport

The cleanest way to understand the e-way bill workflow is to separate document data from movement data.

Part A is the document side. It is where the system captures the details that already exist in the commercial or stock-movement record: recipient GSTIN, place of delivery, invoice or challan number, invoice or challan date, consignment value, HSN information, and the reason for transportation. In practice, this is the part that depends on your finance, ERP, or dispatch documentation being right before the vehicle is loaded.

Part B is the movement side. For road transport, it is the point where the actual conveyance details are updated so the shipment can lawfully move with a completed transport record. If a transporter is involved, the handoff often includes transporter ID and transport document references before the final vehicle update is made. Operationally, that means the finance or dispatch team usually owns the accuracy of Part A inputs, while the logistics side finishes the live transport detail.

This is also where bad workflow design shows up. A wrong document number, wrong HSN classification, wrong delivery location, or wrong consignment value in Part A creates a compliance problem even if the truck number is later updated correctly. A correct Part A with the wrong vehicle number in Part B creates a different kind of risk: the e-way bill exists, but the movement record does not match the vehicle on the road.

Teams should also be careful with online summaries that compress the Part B relief rules too aggressively. Many pages still repeat an older broad "under 50 km" shortcut, but the current rule text is narrower. The key same-state relaxation in the rules concerns short movements of less than 10 km when goods move from the consignor's place of business to the transporter's place of business for further transportation, and a similar short final movement from the transporter's place of business to the consignee. That is not a blanket permission to ignore Part B whenever a trip is "local."

The practical takeaway is simple: treat Part A as the quality-control gate for invoice or challan data, and treat Part B as the live transport activation step. When teams know which side owns which fields, e-way bill generation becomes much more predictable.

Validity, Distance Rules, E-Way Bill 2.0, and the 2025 Controls

Once an e-way bill is generated, timing becomes the next compliance risk. The system's current operating logic uses 1 day of validity for every 200 km or part thereof, so the distance entered at generation is not just a formality. If the route is understated, the bill may expire before delivery. If the distance looks unrealistic, it can invite scrutiny because the portal and supporting systems increasingly validate movement data rather than simply storing it.

Extensions are available, but they are not a cure-all. They must be handled before the original validity expires, and the post-2025 controls place a hard ceiling on how far that process can be stretched. The system now limits e-way bill extensions to 360 days from the original generation date, which means long-delayed or repeatedly rolled-over records eventually hit a hard stop.

The other major change is document-age validation. As GSTN-linked guidance on the 180-day e-way bill restriction explains, from January 1, 2025 taxpayers using e-Invoice and e-Way Bill services cannot generate an e-way bill if the document date is more than 180 days old. For operations teams, that means an old invoice or challan is no longer something you can revive at the last minute when goods finally move.

Portal security has tightened as well. MFA has been rolled out in phases and is now part of the real operating environment for taxpayers using these systems, so access control belongs on the dispatch-readiness checklist alongside the document check.

E-Way Bill 2.0 adds another layer of operational awareness. The newer portal went live on July 1, 2025 to improve continuity and inter-operability with the original e-way bill portal. In practical terms, teams should understand it as a synchronized parallel environment rather than a new legal regime. The rules are not different because you use Portal 2.0, but your team may use it for cross-portal services such as updates, validity actions, or consolidated bill workflows if that fits your process.

How E-Invoicing Changes E-Way Bill Generation

For taxpayers covered by India's e-invoicing regime, the e-way bill workflow starts earlier than the transport stage. The key event is not just dispatch. It is invoice registration through the IRP.

When the invoice is prepared with the required data and registered successfully, the system can use that data to populate the e-way bill workflow. In many cases, Part A details are pre-filled or the e-way bill can be auto-generated when the relevant information is present in the e-invoice payload. That shortens manual entry, but it also raises the importance of getting the invoice data right before registration.

The operational chain looks like this: create the invoice, register it through the IRP, receive the IRN and related validation output, use that validated invoice data as the basis for the e-way bill record, and then complete the transport-side update so the goods can move. If a business wants a deeper view of that upstream control point, this companion guide to the India GST e-invoicing and IRP workflow is the natural next read.

This changes ownership inside the business. Under a manual e-way bill process, dispatch teams may think of the e-way bill as something completed close to loading time. Under an e-invoice-linked process, invoice readiness becomes part of transport readiness. A mismatch in GSTIN, document date, value, or goods details is no longer only an accounting issue. It can block or distort the compliance trail that should flow into the e-way bill.

It is also important not to overstate automation. E-invoicing helps with the source-document side of the process, but it does not remove the need to confirm transport details, vehicle updates, validity timing, or exception handling. The transport leg still has to be completed correctly. The best way to think about e-invoicing is that it improves the integrity of Part A, while the dispatch and transporter workflow still determines whether the movement record is complete and usable on the road.

Consolidated E-Way Bills, Multi-Vehicle Movement, Exemptions, and Penalties

The standard one-consignment, one-vehicle scenario is only part of real-world operations. When a transporter carries multiple consignments in one vehicle, the system allows a consolidated e-way bill. That helps at the vehicle level, but it does not replace the need for each consignment to have its own underlying e-way bill. The consolidated record is a wrapper, not a substitute.

Multi-vehicle movement needs the same discipline. If goods are shifted from one conveyance to another during transit, the transport details have to be updated properly. This is where hurried teams create risk by treating the e-way bill as static after generation. It is not. The record has to continue reflecting the actual movement chain.

Exemptions also need careful handling. Common examples include movement by non-motorized conveyance, certain notified goods, and specific customs-controlled or government-linked movements. The safe approach is to treat exemptions as category-based exceptions that must be confirmed, not as oral knowledge passed around the warehouse. If a shipment sits near the edge of an exemption, re-check the live CBIC or GSTN notification and portal rule set before relying on it.

Penalty risk is more straightforward. Moving goods without a required e-way bill, carrying a record that does not match the vehicle or movement details, or relying on stale source documents can lead to detention and enforcement action. A widely cited rule-of-thumb penalty is Rs 10,000 or the tax sought to be evaded, whichever is higher, but from an operations perspective the bigger problem is usually delay, detention, and the business disruption that follows when the truck is stopped.

That is why edge cases deserve process design, not improvisation. Consolidated shipments, vehicle changes, and exemption-based movements should have explicit SOP steps because they are exactly the scenarios where generic compliance summaries stop being helpful, much like the threshold and UIT-code reporting controls businesses face under Romania's RO e-Transport rules.

---

Dispatch Checklist for Compliance Teams

If you need a usable SOP summary, run through this checklist before goods move:

1. Confirm whether the movement needs an e-way bill at all. Check the Rs 50,000 baseline, the type of movement, and whether an intra-state state notification changes the answer.
2. Verify the source document. Make sure the invoice, bill of supply, or delivery challan is the correct base document and that its date is still usable under the 180-day restriction.
3. Check Part A inputs before generation. GSTIN, place of delivery, document number and date, consignment value, HSN, and reason for transportation should all match the source record.
4. Confirm who owns Part B completion. If the transporter or logistics team is updating the vehicle information, that responsibility should be explicit, not assumed.
5. Check validity against the planned route. The 200-km-per-day framework means route, timing, and possible delays should be thought through before dispatch, not after the bill is close to expiry.
6. Plan exception handling in advance. If the shipment may involve a vehicle change, consolidated movement, or a claimed exemption, decide the workflow before loading starts.
7. Make portal readiness part of dispatch readiness. User access, MFA, and role ownership matter just as much as having the right paperwork.

After dispatch, the control loop should continue. Receiving and reconciliation teams should be able to match the transport and source-document trail to the goods movement that actually occurred. That is where related records such as a goods received note and downstream document matching process become useful, especially when a shipment later feeds invoice matching, stock updates, or dispute handling. For Indian AP teams, the same receipt trail can also support MSME payment deadline tracking for supplier invoices, because acceptance dates and proof of receipt influence when the 15-day or 45-day clock starts.

Once the invoice moves from receipt into payment approval, many teams layer in a separate check for India's TDS rate sections and GST TDS triggers on invoice payments so dispatch evidence, invoice data, and withholding decisions stay aligned.

For most teams, that is the real value of understanding the India e-way bill system properly. It turns a portal task into a controlled workflow: first validate the document, then validate the movement, then keep the audit trail consistent from dispatch through receipt.