Skip to content
Brihat InfotechBrihat Infotech

Platform Strategy

GST, e-invoicing and e-way bills at real volume

At a few documents a day this is a form. At a few thousand it is an integration in the despatch path, with failure modes that stop vehicles at the gate.

Animesh Pathak15 Jul 20264 min read

At a handful of documents a day, GST e-invoicing and e-way bills are a form somebody fills in. At a few thousand, they are an integration sitting directly in the despatch path — and when the integration fails, vehicles wait at the gate.

Gujarat, Maharashtra and Tamil Nadu generate some of the highest e-way bill volumes in the country. At that scale the question stops being "are we filing correctly" and becomes "does the loading bay stop when a government API is slow".

Where it actually breaks

The IRN sits in the critical path

An invoice above the threshold is not valid without an Invoice Reference Number from the Invoice Registration Portal. A government service is therefore a synchronous dependency of your ability to bill and despatch.

Systems built for low volume call the API inline and show the user an error when it fails. At volume that is not survivable. The pattern that works is asynchronous: the invoice is raised locally, queued for IRN generation, retried with backoff, and only blocked from despatch if the IRN genuinely cannot be obtained. The queue absorbs a slow portal instead of the despatch desk absorbing it.

The 24-hour cancellation window

An e-invoice can be cancelled on the portal only within 24 hours of IRN generation. After that the correction is a credit note, not an edit.

This is a workflow constraint, not a footnote. A system that lets a user edit an invoice freely — as most internal systems do — will produce documents that cannot legally be corrected the way the user expects. The window has to be visible in the interface, and a late correction has to route into a credit note automatically rather than leaving someone to discover the rule.

Part-B and the vehicle that has already left

The e-way bill has two parts: consignment details, and transport details including vehicle number. Part-B must be updated before movement, and it changes at every transhipment.

The failure is mundane and constant: goods move, the vehicle is swapped at a hub, and nobody updates part-B because the person who knows is the driver and the person with system access is at head office. The engineering answer is a mobile update path for the transport desk with the validity clock visible — not a rule in a training document.

Distance, validity and multi-leg journeys

Validity is derived from distance, and the calculation is unforgiving on long or multi-leg routes. An e-way bill that expires in transit is a detention risk. Systems that compute distance once at generation, rather than tracking the actual route and extending where the rules allow, produce expiries that look like driver error and are really a data model problem.

Reconciliation is the part that gets skipped

Most implementations stop at generation. The harder half is proving that what was raised on the portal and what sits in your books are the same set.

Daily, automatic, both directions: every IRN and acknowledgement number matched to an internal invoice, every internal invoice checked for a corresponding IRN, and anything unmatched raised as an exception the same day. Reconciling at filing time means finding a month of mismatches in the week the window to fix them is narrowest.

The mismatches are rarely dramatic — a cancelled document that was regenerated, a credit note against the wrong original, an amendment that never synced. They are cheap to fix on the day and expensive in aggregate.

Design rules that hold at volume

  • Asynchronous with retries. The portal is a dependency you do not control. Queue, retry, back off, and alert on queue depth rather than on individual failures.
  • Idempotency on every call. A retried request must never produce a second IRN for the same invoice.
  • Store the full response. IRN, acknowledgement number, timestamp and signed QR — not a success flag. An audit asks for the artefact, not your assertion.
  • Make the clock visible. Cancellation window and e-way validity belong on the screen where the decision is made.
  • Fail at the gate, not in a log. If a consignment cannot legally move, the despatch screen should say so before the vehicle is loaded.

GSP or direct

Most enterprises should integrate through a GST Suvidha Provider rather than directly. A GSP absorbs schema and endpoint changes when the portal moves, and carries part of the uptime problem.

Direct access is defensible at very high volume or where an existing agreement makes it cheaper, but it means owning onboarding, whitelisting and every future change. The decision matters less than the architecture around it — an asynchronous, idempotent, fully logged integration behaves the same either way.

Why this belongs in the ERP rather than beside it

Bolted-on compliance tools work until the reconciliation question is asked. When invoice, e-invoice and e-way bill live in three systems, proving they agree becomes a manual exercise someone performs monthly.

Built into the operational core, the IRN is a field on the invoice, the e-way bill is a state on the consignment, and reconciliation is a query rather than a project.

  • erp
  • compliance
  • integration
Questions this raises

Because it stops being a form and becomes a dependency in the despatch path. The common failures are portal unavailability at peak, part-B vehicle details not updated before movement, validity miscalculated on multi-leg journeys, and no retry path — so a vehicle waits at the gate for a document a queue would have handled.

AP

Written by

Animesh Pathak

Founder

Founded Brihat Infotech in 2022 and has led delivery on every engagement since. Works problem-first: map how the organisation actually runs before proposing a system, then stay on the engagement long enough to be accountable for whether it gets used.

Next step

Bring us the problem. We will bring the architecture.

A discovery call takes forty-five minutes. You leave with our read on the problem, the shape of the system we would propose, and a straight answer on whether we are the right team for it.

  • No sales deck
  • An engineer on the call, not an account manager
  • NDA before you share anything