Automated E-Way Bill Generation and Expiry Tracking in India

What this service covers

AiStaffo connects your billing or ERP system to the official e-way bill system and runs the dispatch paperwork in the background. Each dispatch is read from your invoice and transport records, the bill is prepared with every field completed, and the bill is generated. From that point the validity clock is tracked for each consignment until delivery. Your team sees only the consignments that need a decision.

Why the manual process breaks down

Under the CGST Rules, 2017, an e-way bill is needed for movement of goods above Rs 50,000 in value, and it has to be generated before the goods start moving. The penalty for non-compliance is the greater of Rs 10,000 or the tax evaded. A team that generates bills by hand works well with a few dispatches a day. It struggles once hundreds of invoices go out each week. The same invoice data gets typed twice, vehicles change after the bill is raised, and nobody sees which bills are close to expiry until a truck is stopped on the road.

What is included

• Mapping from your billing or ERP invoice and dispatch records into every e-way bill field, including the GSTIN of the supplier and recipient, HSN code, taxable value, tax split and mode of transport.
• URP handling. Where a party has no GSTIN, the field is filled with URP, and the master data is checked before generation so that a blank GSTIN is caught early.
• Ship-To GSTIN logic for bill-to and ship-to sales, built so the field can be made mandatory without rebuilding the flow.
• Generation of the bill through the government API, or through a GST Suvidha Provider or Application Service Provider you already use, after testing in the sandbox environment.
• Part B and vehicle updates, with a queue for any change made after the bill is generated.
• An expiry register showing, for each bill, the validity end time, the time left and the start of the extension window.
• An exception queue for rejected entries, vehicle changes, extension requests and cancellations.
• A monthly reconciliation of generated bills against invoices, with a log that an auditor can read.

The validity rules the tracker follows

Under Rule 138(10) of the CGST Rules, 2017, validity for regular cargo is one day for every 200 km, and over-dimensional cargo gets one day for every 20 km. Any part of a 200 km bracket counts as a full day. The table gives examples on Indian routes. The distances are approximate, and the days follow from the rule.

Guides disagree on when validity starts. Some say the clock starts when the vehicle number is first entered in Part B. Others say it runs from midnight of the day the bill was generated. The difference matters most when a bill is raised days before dispatch. The tracker is set up to the rule confirmed in the audit, and the audit checks a sample of bills against the portal so the start point is known before go-live.

Extensions have a narrow window. An extension can be requested within 8 hours before or 8 hours after expiry, with a reason and updated Part B details. Since 1 January 2025, the total extension is capped at 360 days from the original generation date. Once a bill has expired, the goods must not move until it is extended or a new bill is raised. The tracker alerts the operations team before the window opens, so the request is made in time.

Generation also has a time limit. Since 1 January 2025, a bill can be generated only for a document dated within the last 180 days. Older invoices appear in the exception queue rather than being pushed to the portal.

How the engagement runs

Audit

We read a sample of recent dispatches, your invoice and dispatch exports, your transporter arrangements and the exceptions your team handled over the last few months. The output is a list of fields that are reliable, fields that are often wrong, and the bills that failed or expired without anyone noticing.

Process map

We map each step from invoice creation to delivery: who creates the record, which field carries the vehicle number, where the buyer's GSTIN is held, and who approves a movement. Gaps in master data are listed with an owner. Nothing is built until the map is agreed.

Build

The connection is built against the current government documentation. Integrators are expected to test in the sandbox environment before going live, so every bill type is generated there first, including URP and bill-to, ship-to cases. The exception queue and expiry register are set up in the same stage.

Run

Once live, bills are generated as invoices are approved, Part B updates are sent when the transporter confirms a vehicle, and the expiry register is refreshed continuously. The bill can be closed after delivery where the portal allows it, and the closure is logged. Your team works from the exception queue each day.

Support

We monitor failed submissions, handle changes to the government API, and update the rules when the portal changes. Changes to master data or to the billing system are logged and reviewed before they reach the connection.

What you provide

You provide read access to your billing or ERP system or a scheduled export, the GSTIN and portal login for each registered entity, a list of transporters and their usual vehicle arrangements, and a named person who approves exceptions. You also provide clean customer master data, especially the GSTIN for each buyer and the state and pincode of each delivery address. Without those, the automation will reject more bills, and the rejections will fall back on your team.

Typical timeline

For one billing or ERP system and one set of transporters, the usual planning range is four to six weeks from the audit to live running. The audit sets the final dates. Extra time is needed where the ERP has no export, where master data needs cleaning, or where more than one legal entity uses the same bills.

The rules that are still moving

GST e-way bill rules changed several times in 2025 and 2026. A GSTN advisory from May 2026 described the Ship To GSTIN field becoming mandatory in Bill-To/Ship-To transactions from 1 August 2026, along with changes to the API. A later update reported that the Ship To GSTIN amendments had been deferred and suspended until further notice. The build keeps the field configurable, and the status is confirmed on the portal before the field is switched on.

What this service does not cover

Automation works from the data you hold. It cannot tell whether an HSN code, tax rate or invoice value is correct, and it cannot confirm the physical goods. It does not drive the vehicle, and it cannot force a transporter to update Part B. A rejection that the portal gives for a reason outside the rules is passed to a person, and it is not resolved by the system. The service does not file GST returns, and it does not give a legal opinion on state-level rules. It is also not worth setting up if your business generates only a few bills a month, because a person can enter those in less time than the setup takes. Businesses with heavily customised ERPs that cannot export clean dispatch data may need that work done first.