E-Way Bill vs E-Invoice: How the Two Systems Differ

The difference between an e-way bill and an e-invoice is what each one is actually about: an e-invoice validates a document, while an e-way bill authorises a movement. E-invoicing is triggered by your turnover and produces an IRN on the Invoice Registration Portal. An e-way bill is triggered by the value of the goods on the truck and produces a 12-digit e-way bill number on a different portal entirely. They are separate obligations that happen to overlap on most goods invoices, which is why they get confused.

The difference between an e-way bill and an e-invoice

Put the two documents next to each other and the distinction is easy to hold onto.

An e-invoice is not a special format of invoice. It is your ordinary tax invoice, submitted in a prescribed JSON schema to a government Invoice Registration Portal before you issue it, and returned to you with a unique Invoice Reference Number and a digitally signed QR code. Without that IRN, a covered taxpayer's invoice is not a valid tax invoice at all — which means the buyer cannot claim input tax credit against it. The system exists so that the tax department sees the invoice at the moment it is raised rather than when a return is filed weeks later.

An e-way bill is a transport document. It says that a specified consignment, described by invoice and HSN, is moving from A to B in a particular vehicle, and it is valid only for a limited period tied to the distance involved. It exists so that goods in transit can be checked against a live government record at a roadside interception. It says nothing about whether the underlying invoice is valid for ITC.

So one is a document-integrity mechanism and the other is a movement-control mechanism. That is the whole difference, and everything below follows from it.

Two portals, two record systems

E-invoices go to an Invoice Registration Portal (IRP). There is more than one government-approved IRP, and a taxpayer can use any of them; the IRN a portal returns is a hash computed from key invoice fields, so the same invoice cannot be registered twice on any portal. E-way bills are generated on the national e-way bill system at ewaybillgst.gov.in, which is a separate application with its own records, its own reports and its own cancellation rules.

In practice most businesses log into both with the same GST credentials, and many ERP and billing tools present them as one screen, which is exactly why the two get treated as one system in people's heads. They are not. An IRN failure and an e-way bill failure are different failures with different consequences, and you can be perfectly compliant on one while being exposed on the other.

What triggers each one

This is the practical heart of the difference, because the two triggers have nothing to do with each other.

E-invoicing: a turnover trigger

E-invoicing applicability is a property of your business, not of the transaction. It attaches once your aggregate annual turnover crosses the notified threshold in any financial year since GST began, and it stays attached even if turnover later falls. As of publication that threshold has stood at AATO above ₹5 crore since 1 August 2023 — the detail, including the exempt categories and the 30-day IRP reporting limit for larger taxpayers, is covered in our guide to the e-invoicing threshold. Once you are covered, every eligible B2B invoice needs an IRN, whether it is for ₹500 or ₹5 lakh. There is no per-invoice minimum.

E-way bills: a value trigger

An e-way bill obligation is a property of the consignment, not of the business. The central rule under Rule 138 requires one where consignment value exceeds ₹50,000, with several states having notified a higher limit for movement wholly inside their own borders, and a handful of movements (inter-state job-work despatches, for example) requiring one irrespective of value. A tiny business well below the e-invoicing threshold still needs an e-way bill the moment it ships a consignment over the limit — the rules and the exceptions are set out in our e-way bill rules and limits guide.

The consequence worth internalising: a large services firm generates thousands of IRNs and never generates an e-way bill in its life, while a small trader generates e-way bills every week and no IRNs at all.

What you actually get: IRN and QR vs EWB number

The outputs look nothing alike, and knowing what each one is stops people accepting the wrong artefact as proof of the other.

• From the IRP — an IRN, which is a long hash string, plus a digitally signed QR code and signed invoice JSON. The QR encodes key invoice details and the signature, so anyone with a scanner can confirm the invoice was genuinely registered on the government system rather than typed up in a spreadsheet. That QR is meant to be printed on the invoice you hand over.
• From the e-way bill system — a 12-digit e-way bill number, with a validity period that starts running from the first Part B entry and is calculated from the approximate distance. This is what a roadside officer asks for, and it expires; an IRN does not. Validity and distance is its own topic.

There is a downstream difference too. E-invoice data flows into your GSTR-1 automatically, and from there into the recipient's GSTR-2B, which is why registered invoices largely stop being a reconciliation problem. E-way bill data does not populate returns at all — it sits in a parallel dataset that the department uses analytically, including for spotting movements with no matching outward supply reported.

Side-by-side comparison

Generating Part A automatically from the IRN

The two systems are separate, but they were deliberately wired together — and this is the part most teams under-use.

Form GST EWB-01 has two halves. Part A is document data: supplier and recipient GSTIN, place of delivery with PIN code, invoice number and date, consignment value, HSN and reason for transportation. Part B is the conveyance: vehicle number, or the transport document number. Notice that every single Part A field already exists on the invoice you just reported to the IRP.

So there are two ways to avoid keying it twice:

1. Send transport details with the e-invoice payload. The e-invoice schema carries optional e-way bill fields. Populate them — transporter ID or vehicle number, transport mode, distance — and the IRP will return an e-way bill number alongside the IRN in the same response. One API call, two compliances.
2. Generate from the IRN afterwards. If transport wasn't known at invoicing time, go to the e-way bill portal and generate against the IRN. Part A populates itself from the registered invoice and you only supply Part B.

Both routes have the same real benefit, which is not keystrokes saved: it is that Part A can no longer disagree with the invoice. A mismatch between the invoice value or GSTIN on an e-way bill and the same fields on the registered invoice is precisely the kind of inconsistency that surfaces later as a query, and generating one from the other makes that class of error structurally impossible.

One, the other, or both

Work through the two triggers independently and the answer falls out. A few common cases:

The B2C row is the one that catches people. E-invoicing largely does not apply to B2C supplies, so a covered retailer will have invoices with no IRN — but the goods still move, and the e-way bill obligation is completely unaffected by the absence of an IRN. A large taxpayer may separately be subject to the dynamic QR code requirement on B2C invoices, which is a different rule again with its own turnover trigger; check the current notification rather than assuming it applies to you.

Where teams get this wrong

Four failure modes come up repeatedly, and they are all versions of assuming the two systems are one.

• Treating an IRN as transport cover. A signed QR code on the invoice proves the document is registered. It does not authorise the vehicle. Goods moving on an e-invoice with no e-way bill are as exposed at a check post as goods moving with no paperwork at all.
• Treating an e-way bill as invoice validity. The reverse error, and the more expensive one on the buyer's side. A valid e-way bill number tells you nothing about whether the supplier registered the invoice on the IRP, and if they were required to and did not, the ITC you claim against that document is sitting on an invalid invoice.
• Assuming the threshold you know applies to both. ₹50,000 has nothing to do with e-invoicing, and ₹5 crore has nothing to do with e-way bills. Mixing them produces confident, wrong answers in both directions.
• Keying Part A by hand when the IRN already exists. Every manual re-entry is a chance for the two records to disagree on value, GSTIN or HSN.

On the buyer's side, the useful habit is checking the counterparty rather than the paperwork. If your supplier's GSTIN is inactive or cancelled, or if they are e-invoicing-enabled but handing you invoices with no IRN, that is visible from a GSTIN lookup before you post the bill — which is a better place to catch it than in a vendor reconciliation three months later. An enablement flag on the lookup tells you whether to expect an IRN at all, and status tells you whether the registration behind the invoice is even live.

Frequently asked questions