E-way bill extraction

An e-way bill travels with the goods, and it reaches your inbox a week later as a PDF, a scan, or a screenshot forwarded on WhatsApp. Someone has to read the supplier and buyer, the invoice reference, the vehicle and transporter, and the goods value, then carry them into a tracking sheet or against the invoice. Dynamite Docs reads the e-way bill into rows, Part A and Part B fields, GSTINs, document references, and goods value, so movement tracking and matching start from clean data instead of a retype.

Try this workflow free or view pricing.

Movement documents are the ones that get retyped

E-way bills arrive as scans and screenshots far more often than clean exports, so the details have to be read off an image, not copied from a text layer.
The two-part structure means data sits in two places: Part A carries the supplier, buyer, and document reference, while Part B carries the vehicle and transporter details.
A transposed digit in a GSTIN or a wrong document number breaks the match back to the invoice, and that mismatch surfaces weeks later in reconciliation.
Every movement adds another document to track. Vehicles, goods values, and dates pile up across a month of dispatches with no consistent format between them.

How Dynamite Docs handles e-way bills

01 — Drop the e-way bills in

Upload the PDFs, scans, and screenshots alongside the invoices they reference. Clean digital exports parse deterministically from their text layer; scans and photos are read by the vision model you choose.

02 — Part A and Part B are inferred

Supplier and buyer GSTIN, document number and date, goods value, vehicle number, and transporter details are pulled from the layout automatically. No templates to build per transporter or state.

03 — Review the low-confidence rows

Confidence scores flag the fields worth a glance, usually a GSTIN or a vehicle number. Corrections become patterns, so the next e-way bill from the same transporter extracts cleanly.

04 — Export and match

Rows export to Excel, CSV, or JSON, or push to Google Sheets, ready to be matched against invoices and delivery records in your tracking workflow.

Document types this workflow handles

Digital e-way bill PDFs — parsed deterministically from the text layer
E-way bill scans — read by the vision model you choose
WhatsApp / email screenshots — no text layer, handled as images
E-way bills in invoice batches — transport documents alongside purchase invoices

What gets extracted from an e-way bill

Inferred per layout. A typical e-way bill run yields the Part A and Part B fields, each confidence-scored:

E-way bill number — 9210 2334 5678
Supplier GSTIN (Part A) — 27AABCS1429B1ZP
Buyer GSTIN (Part A) — 29AABCC3456C1ZD
Document number (invoice ref.) — INV/24-25/0144
Document date — 2026-08-02
Dispatch from / to — Pune → Bengaluru
Vehicle number (Part B) — MH12 AB 3456
Transporter — UrbanMiles Logistics
Goods value — ₹1,86,000
HSN summary — 8467 × 6

A realistic example

A batch of e-way bills extracts to rows like these, ready to match against the invoices they reference:

E-way bill no.	Invoice ref.	Date	From	To	Supplier GSTIN	Vehicle	Goods value
9210 2334 5678	INV/24-25/0144	2026-08-02	Pune	Bengaluru	27AABCS1429B1ZP	MH12 AB 3456	₹1,86,000
1310 8899 0012	SB/2026/118	2026-08-03	Mumbai	Ahmedabad	27BAAFG2874Q1ZX	MH04 CD 9988	₹93,500
2026 4455 6677	GT-8821	2026-08-05	Chennai	Coimbatore	07AAECU4471L1ZF	TN38 AB 2210	₹12,000

The movement document, read into a table

The e-way bill is a movement document: it travels with the goods and records who supplied, who received, which invoice or other document backs the movement, and how the goods moved. Because it accompanies goods rather than sitting in an accounting folder, it tends to arrive as a scan, a photo, or a screenshot long after the invoice it references. That is exactly the kind of document that usually gets retyped into a tracking sheet and then ignored until reconciliation. Reading it into rows the moment it is uploaded keeps the tracking sheet populated without the keystrokes.

Part A and Part B read as two halves of one table. Part A carries the supplier and buyer details, the document number and date the movement refers to, and the goods summary. Part B carries the transport details, the vehicle, and the transporter. When an e-way bill is printed, both parts sit on the same document, and extraction treats them as one schema: GSTINs, references, goods value, vehicle, transporter, all in a single row that ties the movement back to its invoice.

The match against the invoice is where e-way bill data earns its keep. Every movement has to be traced back to a document, and that match only works when the reference numbers and GSTINs are exactly right. A transposed digit hides in plain sight on a PDF but breaks the match immediately once rows are compared. That is why the low-confidence fields, usually the GSTINs and the vehicle number, are the ones worth a second glance, and why corrections are remembered so the same transporter’s bills extract cleanly next time.

Batch processing matters because e-way bills never arrive alone. A month of dispatches is dozens of movements, each with its own document, vehicle, and goods value. Processing them alongside the invoices they reference puts the whole transaction flow in one workspace: the invoice, the e-way bill, and the delivery details side by side, ready to export for your tracking sheet or reconciliation.

Why bring-your-own-AI matters for e-way bills

E-way bills arrive as scans and screenshots more often than as clean exports, which makes the vision reader the centre of the work: the model that reads the supplier and buyer GSTIN, the document reference, and the goods value off an image is your choice, paid at your provider’s rate with zero markup.

Clean digital e-way bill exports parse deterministically for free, identical results every run. Scans and screenshots are read by the vision model you pick, so you control both accuracy and per-page cost on the image-heavy side of the work.

Part A and Part B come out as one row, GSTINs, references, goods value, vehicle, and transporter, ready to match back to the invoice. Corrections are remembered per transporter, and the rows export to Excel, CSV, or JSON for your tracking sheet.

Questions, answered

What is the difference between Part A and Part B on an e-way bill?

Part A records the supplier, buyer, and the document the movement refers to, such as an invoice. Part B records the transport details, the vehicle, and the transporter. Both sit on the same document and are extracted together into one row.

Can it read e-way bills that arrive as screenshots?

Yes. WhatsApp and email screenshots have no text layer, so they are read by the vision model you choose, with the same schema inferred as for clean digital exports.

Does it extract the GSTIN on the e-way bill?

Yes. Supplier and buyer GSTINs come out as separate confidence-scored fields, so a transposed digit stands out before the movement is matched back to its invoice.

Does it validate e-way bills against the GST portal?

No. Dynamite Docs reads the document and structures the fields on it. Validation against portal records, and decisions about what the current rules require, stay with your team and your compliance process. Consult the GST portal for current rules.