Generating E-Way Bills From E-Invoice IRN: Data Flow and Failures

The invoice has its IRN and a signed QR code, the truck is at the gate, and the e-way bill call keeps failing. The dispatcher sees "Invalid Vehicle Number", the TMS retries the same payload five times, and the driver waits forty minutes while someone reads the registration certificate aloud. Later the customer cuts the quantity, billing tries to cancel the invoice, and the portal refuses because an e-way bill now exists against it.

This guide follows one invoice from IRN to e-way bill on India's Invoice Registration Portal (IRP): which Part A fields the IRP lifts from the e-invoice, which Part-B transport fields your TMS must supply, how distance and validity are calculated, the order in which cancellations must happen, and what an ERP or TMS should do with each common error code. It ends with a test plan and an ownership split between billing, dispatch and the transport desk.

Where the IRN stops and the e-way bill starts on one invoice

The IRN is a tax document event; the e-way bill is a movement event. They share data but answer different questions, and treating them as one status in the ERP is the root of most failures. CGST Rule 48(4) requires notified taxpayers to prepare the invoice only after obtaining an IRN by uploading the invoice particulars in FORM GST INV-01, and Rule 48(5) says an invoice issued any other way by such a person is not treated as an invoice.

The e-way bill sits under a different rule. CGST Rule 138(1) requires a registered person moving goods of consignment value above ₹50,000 to furnish Part A of FORM GST EWB-01 before movement starts, with Part B carrying the conveyance details. The IRP's "generate e-way bill by IRN" service connects the two: the invoice already lodged on the IRP supplies the Part A data, and the caller adds the transport details.

• Who must issue IRNs: Notification 10/2023-Central Tax reduced the aggregate-turnover threshold in Notification 13/2020-Central Tax from ₹10 crore to ₹5 crore with effect from 1 August 2023.
• What the IRN is: the NIC specification describes it as a SHA-256 hash of the supplier GSTIN, document number, document type and financial year of the document date.
• What the e-way bill adds: distance, transport mode, transporter, vehicle or transport document, and a validity date, which the IRP returns only once Part B exists.

This article covers creating the e-way bill from the IRN. Changing the vehicle after the truck has left is a different workflow, covered in our guide to handling an e-way bill vehicle change; read that one for breakdowns and transshipment, and this one for the moment the first e-way bill is raised.

Which Part A details the IRP takes from the signed e-invoice

When the e-way bill is generated by IRN, the caller does not resend the invoice. The IRP already holds the supplier, recipient, document number, date, item lines with HSN codes and values, so the request carries only the IRN plus transport details. Anything wrong in those invoice fields is fixed only by cancelling and reissuing the e-invoice, never in the e-way bill call.

The NIC specification adds two rules that decide whether an e-way bill is possible at all. No e-way bill is generated for debit notes, credit notes or services, and at least one item on the invoice must carry an HSN code for goods. An invoice that bills only freight or installation therefore returns an error however clean the transport details are.

Part-B transport fields and the validations that reject them

Part-B data is where most rejections happen, because it is typed or scanned at the gate under time pressure. The IRP applies mode-specific rules: road needs a vehicle number and vehicle type, rail and air need a transport document number and date, and ship accepts either. Sending a field that the mode forbids is also an error.

• Distance: mandatory; a number from 0 to 4000 kilometres. Zero tells the IRP to use its stored PIN-to-PIN distance.
• TransMode: 1 road, 2 rail, 3 air, 4 ship.
• TransId: the 15-character transporter ID or GSTIN. Sending only this produces a Part-A-only e-way bill.
• VehNo and VehType: 4 to 20 alphanumeric characters, checked for format and against the Vahan vehicle database; type R for regular or O for over-dimensional cargo.
• TransDocNo and TransDocDt: up to 15 characters and a date that cannot be in the future or earlier than the invoice date.

The IRP also refuses an e-way bill where the supplier or recipient GSTIN is blocked for non-filing of returns, returned as error 4015. No amount of retrying fixes that, and the TMS should stop at once and route the case to the indirect tax team rather than leave the dispatcher guessing.

// Decrypted Data for "generate e-way bill by IRN" (NIC e-invoice API v1.03)
// Illustrative values; Irn is the 64-character hash returned at IRN generation
{
  "Irn": "<64-character IRN from the e-invoice>",
  "Distance": 0,
  "TransMode": "1",
  "TransId": "29AAACX1234M1Z5",
  "TransName": "Example Roadways",
  "TransDocNo": "LR-118204",
  "TransDocDt": "13/11/2026",
  "VehNo": "KA01AB1234",
  "VehType": "R"
}
// Decrypted success response
{
  "EwbNo": 141008683051,
  "EwbDt": "2026-11-13 14:52:00",
  "EwbValidTill": "2026-11-17 23:59:00",
  "Remarks": "Pin-Pin calc distance: 640KM"
}
// Store all four values against the invoice and the TMS load; EwbValidTill
// is returned only when Part-B details were supplied.

Distance, PIN codes and the validity clock under Rule 138(10)

Distance decides validity, so it must be right before the truck moves. The IRP checks the declared distance against its stored PIN-to-PIN figure and accepts a variance of plus or minus 10 percent; where the stored distance is under 100 km the accepted range is 1 km up to plus 10 percent. Sending zero avoids the argument by accepting the IRP's own figure.

• Same PIN code: the actual distance must be sent, between 1 and 100 km; zero is rejected with error 4029.
• PIN pair not stored: the IRP uses the declared distance, up to 4000 km, and returns 4030 if zero was sent.
• Validity for ordinary cargo: Rule 138(10) gives one day for the first 200 km and one more day for each further 200 km or part of it.
• Validity for over-dimensional cargo: one day for the first 20 km and one more day for each further 20 km or part.
• Extension: a proviso to Rule 138(10) allows extension within eight hours of expiry.

The Explanation to the validity rule counts from the time the e-way bill is generated, and treats each day as ending at midnight of the day following the generation date. A movement generated at 14:52 on 13 November with 640 km therefore gets four days ending at 23:59 on 17 November. Always store the EwbValidTill value the IRP returns rather than computing your own.

Under CGST Rule 138(10), an e-way bill for ordinary cargo is valid one day for the first 200 km plus one day per further 200 km or part, so a 640 km dispatch raised by IRN from an ERP gets four days, with extension allowed within eight hours of expiry.

Two ways to raise the e-way bill: inside the IRN call or after it

Choose the timing by when the vehicle is known. If billing already has the vehicle and distance, the e-way bill details can travel inside the IRN request and both numbers come back together. If not, generate the IRN alone and raise the e-way bill by IRN once the truck reaches the gate.

• Combined in the IRN request: the Generate IRN payload accepts an EwbDtls object with distance, mode, transporter, document and vehicle fields. The response then carries AckNo, the signed QR code, EwbNo, EwbDt and, when Part B was given, EwbValidTill.
• Separate call after the IRN: the "generate e-way bill by IRN" service takes the IRN and transport fields only, and can also add dispatch or ship-to addresses that were missing from the invoice.
• Part A only: sending just the transporter ID creates the e-way bill without Part B; the transporter adds the vehicle later, and the IRP returns no validity date until then.

The separate call needs its own retrieval path. The "get e-way bill details by IRN" service returns EwbNo, EwbDt, the generating GSTIN, a status of ACT or CNL, and EwbValidTill only where Part B exists. A TMS that lost a response after a timeout should call it before trying to generate again, because a second attempt returns error 4002.

Cancelling in the right order when an invoice or load changes

When an invoice must be withdrawn, cancel the e-way bill first and the IRN second, both inside their 24-hour windows. Reversing that order fails: the IRP refuses to cancel an IRN while a valid or active e-way bill exists for it, returning error 2230.

• IRN cancellation window: 24 hours from IRN generation; afterwards the IRP returns error 2270.
• IRN cancel reasons: 1 duplicate, 2 data entry mistake, 3 order cancelled, 4 others, with optional remarks up to 100 characters.
• E-way bill cancellation: Rule 138(9) allows cancellation within 24 hours of generation, but not once the bill has been verified in transit under Rule 138B. The IRP's own error 4055 words its window as 24 hours from Part B entry.
• After an IRN is cancelled: the NIC specification does not allow an IRN to be generated again for the same document number, so the corrected invoice needs a new number.

The NIC e-invoice IRP cancels an IRN only within 24 hours of generation and refuses while an active e-way bill exists, while CGST Rule 138(9) allows e-way bill cancellation within 24 hours unless verified in transit. An ERP correction workflow must therefore cancel the e-way bill first, then the IRN.

The trace below shows what a change looks like when the ERP treats both documents as one status. All numbers are illustrative.

1. 10:02 IRN generated: billing posts invoice KA/2627/004517 for ₹8,49,600 and receives its IRN without e-way bill details, because no truck is assigned yet.
2. 14:30 first e-way bill attempt: the gate TMS calls generate by IRN with vehicle KA01AB1Z34. The IRP returns 4014, Invalid Vehicle Number; the TMS retries the same payload five times in two minutes.
3. 14:52 e-way bill generated: the dispatcher corrects the number to KA01AB1234 from the registration certificate; the IRP returns EwbNo 141008683051, valid until 17 November.
4. 16:10 customer cuts the order: billing calls Cancel IRN with reason 3; the IRP returns 2230 because the e-way bill is active. The ERP shows the invoice as cancelled anyway.
5. 16:25 recovery: the transport desk cancels the e-way bill, billing cancels the IRN, and a new invoice number KA/2627/004533 is raised for the reduced quantity with a fresh e-way bill.

IRP error codes a TMS should route, not blindly retry

Most IRP errors describe data that will fail identically on every retry. The integration should map each code to an owner and an action, retry automatically only for transport-level faults such as a timeout, and look up the existing e-way bill before any repeat generation attempt.

Who in billing, dispatch and the transport desk fixes which field

Split the work by the document each team controls. Billing owns everything that lives in the e-invoice; dispatch owns the vehicle and gate time; the transport desk owns carrier masters, distance lanes and e-way bill cancellations. The ERP should show one dispatch case with both document states, not one combined green tick.

That split also decides which tasks can be automated. The IRP itself enforces its validations, so the ERP and TMS can apply the same checks before calling it. Software, including AI tools, helps with the human parts: reading a number plate or explaining an error. Decisions with tax consequences, such as cancelling an invoice, stay with named people.

E-way bill generation by IRN on the NIC IRP accepts a road movement only with vehicle number and type, checks the number against Vahan, and allows declared distance within 10 percent of the stored PIN-to-PIN figure, while CGST Rule 138(1) sets the ₹50,000 consignment value that triggers the requirement.

Proving the IRN-to-e-way bill path in the NIC sandbox

Run every failure in the NIC sandbox before go-live, not only the happy path. Each scenario below has an expected result the integration must reproduce, including the error code. A build that shows the right code to the right person passes; one that retries or swallows the error fails.

Shortages and damages found at the customer's dock are a separate reconciliation problem; our guide to dock-to-dispatch e-way bill and POD shortage reconciliation covers that end of the trip. For freight bills that later reference the same LR and invoice, see freight accounts payable automation and GST reconciliation.

Running both documents as one visible dispatch case

The fix for most IRN and e-way bill failures is organisational as much as technical: show both document states on one dispatch case, map every error code to an owner, and let only the right person cancel. With that in place, the gate stops waiting on retries and billing stops cancelling invoices the portal still considers live.

• Separate states: IRN status, e-way bill status and Part-B status shown side by side, each with its time remaining to cancel.
• Coded error routing: every IRP code mapped to billing, dispatch, the transport desk or the tax lead, with automatic retry only for timeouts.
• Cancellation guard: the ERP blocks an IRN cancel request while the e-way bill status is active.

Related transport and GST compliance guides are collected in our logistics section. If your ERP or TMS needs this flow built or reviewed against the NIC specification, share your requirements with us and we will map your current error handling against the codes above before any build starts.