E-way bills in a logistics system: the integration nobody scopes properly

Transport documentation gets estimated as a single integration: at dispatch, submit the consignment details, receive a number, print it. That is roughly a fortnight of work and it is roughly a tenth of the problem, because the document does not stop being relevant once the vehicle leaves.

What actually happens is that the vehicle changes at a transshipment point, the consignment sits at a hub longer than planned and the document expires, three consignments get consolidated onto one truck, the driver is in a stretch of highway with no signal when the update is due, and somebody in the back office cancels a dispatch that has already moved. Each of those is a state change on a document that is legally required to be accurate while the goods are in motion.

Two parts, generated at different moments

The document separates the consignment details from the vehicle details, and they are rarely known at the same time. The consignment is known when the invoice is raised. The vehicle is frequently not known until the truck is at the dock, which may be hours later and is often done by a different person in a different system.

Designs that assume both are available at once produce one of two workarounds: dispatch staff enter a placeholder vehicle and correct it later, or invoicing waits for the transport desk. The first creates documents that are wrong at the moment they matter most. The second is why the loading bay ends up running on a spreadsheet.

If two pieces of information arrive hours apart from different people, they are two events. Modelling them as one is what forces the workaround.

The vehicle changes, and the history matters

Transshipment is normal in Indian line-haul: goods move to a hub on one vehicle and onward on another, sometimes more than once. Each change requires updating the document with the new vehicle, and the sequence has to remain inspectable afterwards.

The implementation error is to store the vehicle as a mutable field on the consignment. Overwriting it satisfies the immediate update and destroys the trail, so that when a query arrives months later about where a consignment was on a particular date, the answer is unavailable. Vehicle assignment is an append-only log of events with timestamps, and the current vehicle is derived from the latest entry — not a column you update in place.

Expiry is a scheduling problem

The document is valid for a period related to the distance to be covered, and it can expire while goods are still in transit — a vehicle breaks down, a hub is congested, a route is closed. Extension is possible but only within a window around the expiry, which means the moment for action is narrow and predictable.

A system that only surfaces expiry when someone opens the consignment record is not helping. This wants a scheduled evaluation across all in-transit consignments, with alerting ahead of the window and escalation inside it, and it wants to be reliable enough that operations trust it rather than keeping a parallel spreadsheet of dates. That parallel spreadsheet is the signal that the feature was built as a screen rather than as a process.

Consolidation is a different document

One vehicle carrying consignments for several customers needs a consolidated document referencing the individual ones, which remain individually valid. This is a one-to-many relationship that has to exist in the data model from the start. Retrofitting it into a schema that assumed one consignment per trip is a migration rather than a feature, which is why it is worth asking about at design time even when the current operation is single-drop.

The truck is not always online

Any part of this that depends on a driver's device having connectivity at a specific moment will fail regularly, because Indian highway coverage is not continuous and the moments that matter — a transshipment yard, a remote checkpoint — are disproportionately the ones without signal.

The workable pattern is to queue the intent locally, sync when connectivity returns, and reconcile against the authoritative system rather than assuming the local queue succeeded. That means the mobile application needs a genuine offline store and a conflict policy, not an optimistic request with a retry. It is more work, and it is the difference between a tool drivers use and one they abandon.

Where it should sit

Documentation is not a separate module bolted to the side of a transport system. It reads from the same consignment, vehicle, driver and trip entities the rest of the operation uses, and writes state those entities need. Built alongside rather than inside, it produces the outcome we are most often called to fix: staff entering the same dispatch twice, once for operations and once for compliance, with the two diverging quietly.

One note on scope: this describes how the requirement shapes system design. It is not legal or tax advice, and the validity periods, distance bands and exemptions that apply to your operation are a question for your consultant. They change, which is the argument for holding them as configuration with effective dates rather than as constants.