Consignments Now Meet Tax Clocks. Replacing Everything Is One Answer of Four.
India's e-way bill and e-invoice rules put time limits on documents that separate systems pass by hand. Here is what waits while a consignment is typed into four systems, the four ways to answer it (keep re-typing, a connection product, one new platform, or map and build the smallest join), weighed, and our recommendation.
The presentation has forty slides. Its argument is on the third: four systems is three too many. One platform for bookings, dispatch, tracking and billing, and every screen in the firm will change.
The owner thinks of two smaller things. Invoices go out with the wrong weight, because accounts types the weight again. And last week the tax adviser asked how quickly the firm’s invoices reach the tax portal, because firms of its size are no longer allowed to report invoices older than a set number of days. Both are crossings between two systems. The proposal on the screen replaces all four.
The paradox: The firm has small, specific problems with clocks attached, and is offered only the largest possible cure.
What We Found
We looked at what India’s tax portals now ask of a consignment’s documents, and at one cross-sector survey of why firms keep old systems.
In India, e-invoices have a 30-day reporting limit for larger suppliers. India’s GST Network announced on 5 November 2024 that “from 1st April 2025, taxpayers with an AATO of 10 crores and above would not be allowed to report e-Invoices older than 30 days from the date of reporting on IRP portals”. AATO is aggregate annual turnover, here 10 crore rupees or more; the IRP is the e-invoice portal. The limit covers “all document types (Invoices/Credit Notes/Debit Notes)” that need an invoice reference number, and the advisory says “there would be no such reporting restriction on taxpayers with an AATO of less than 10 crores as of now”. In force since 1 April 2025. Who must act: the advisory speaks of “taxpayers with an AATO of 10 crores and above”; it names no sector. Which firms in this sector that covers, and whether it reaches a road transporter or a bus operator at all, is for a tax adviser to confirm.
In India, e-way bills have time limits too. In an advisory of 17 December 2024, the GST Network said that from 1 January 2025 “The generation of E-Way Bills will be restricted to documents dated within 180 days from the date of generation”, and “the extension of E-Way Bills will be limited to 360 days from their original date of generation”. It also made a second login step (a one-time code as well as a password) compulsory in stages, and “from 1st April 2025 for all other taxpayers and users”. All of this is already in force. Who must act: those who generate or extend e-way bills; the advisory speaks of “taxpayers” and “users” and names no sector. Whether that includes a transporter as well as the firm whose goods it carries is for a tax adviser to confirm.
Firms hold back from the large cure. In one cross-sector survey of about 500 US IT professionals, not about this sector, more than two in five named budget limitations and more than a third fear of disrupting operations among the reasons they had not upgraded. In the same survey, about three in five organisations still use legacy systems, and about two in five named incompatibility with modern systems or tools among the top issues with them.
What our review does not show: We read the GST Network’s two advisories, not the laws and notifications behind them. No source ties either rule to any firm’s old systems, or says that separate systems make a firm late. We found no named mid-size firm in this sector with this problem, and nothing from the Middle East on this issue. The survey is cross-sector, from a firm that sells related services.
What Waits While a Consignment Is Typed Four Times
The usual answer is that the problem must wait for a new platform. The better question: what can the business not do meanwhile?
Documents on time. Our reading, and only that: an invoice keyed from a printout, or carried across by a monthly file, has used part of a 30-day window before anyone reports it. An e-way bill typed from another screen is one more copy of the consignment, and one more place for its figures to part from the invoice. And a join that logs in to a tax portal, clerk or program, now has a second login step to pass. Whether either rule applies to your firm, and what it requires of it, is for you and your tax advisers.
The invoice weight and the carried weight. Dispatch and billing must agree. While accounts types the weight again, a correction at the depot never reaches the invoice, and a credit note follows.
The gap we see: judged as an integration project, joining the systems looks large, so it waits for a replacement nobody approves. Set beside documents with time limits and invoices that drift from the load, it is a different decision: find out once where a consignment crosses between systems and where its figures part, then deal first with the crossing that causes most correction.
This is our reading of the evidence. It is not a measured market figure, and we do not put a rupee value on it here. That figure has to come from your own business.
Four Ways to Answer Separate Systems, Weighed
| Option | When it fits | What it risks |
|---|---|---|
| Keep re-typing and reconciling by hand | Volumes are low, there are few systems, and no time limit is close | The work grows with every customer. Documents keyed late use up their time limits |
| Buy a connection or integration product, or have one built for you | The crossings are known, and the systems at each end can already send and receive | It joins only the crossings someone has listed, and someone must run and watch it. Your choice and another firm’s product; we have none |
| Replace all the systems with one new platform | Most of the systems are failing, and the firm can carry a long change | Every screen changes, systems that work are thrown out, and the crossing that hurts most waits for the whole programme. Choosing or installing a packaged platform is not our kind of work |
| Map every place a booking or consignment crosses between systems, then build the smallest join that helps, module by module | The systems are used every day, and a few crossings cause most of the correction | It costs money before anything is joined. Each join is one more thing to look after, and several joins can become a tangle of their own |
Our recommendation: map every crossing first, including those done by hand, by timed files, by scripts and by spreadsheets. Then deal with the crossing that causes most correction by the smallest join that helps: agree which system is the source for a fact (which needs no software), build one connection, or rebuild the one application that cannot send or receive, module by module. Replacing everything comes last, and is sometimes right. If you also want a connection product, that is your choice, and the map tells it what is there. We have no connection or integration product. We cannot change another supplier’s packaged product; we work only with what it already lets other programs send and receive. We do not run or monitor a connection once it is built.
The honest costs. A join is one more thing to look after, and it can fail, or need changing when a supplier changes its product. A packaged product that lets nothing in or out cannot be joined by us at all. And a join does nothing for records that already disagree; your own people put those right.
Where You Are Now, and Where You Should Be
Before a replacement is quoted, we would set a benchmark for the decision.
| Measure | Typical starting point | Where it should be | How it is checked |
|---|---|---|---|
| Answers weighed | One: replace everything, or wait | Four, each weighed against the crossing that causes most correction | The cost comparison |
| How a consignment reaches billing and the tax portals | By hand or by monthly file, not written down | Every step written down, with what carries it and how long it waits | The map of the system as it stands |
| The cost of staying as you are | Never counted: copying, corrections, credit notes | Set beside the price of each stage | The cost comparison |
| The cost of change | One large replacement quote | A price for each stage, set after the system is read | The staged plan and quote |
| The size of one commitment | Everything at once, or nothing | One module, with the freedom to pause after any accepted module | The staged plan |
The starting points above are what we expect to find. In an engagement they are replaced by your own position. The targets are what we would work towards with you. They are not results we have already achieved for a logistics, travel or hospitality firm.
How We Work With You
- We listen: a free Reliability Review. A first conversation about your systems and where a consignment crosses between them. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
- We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
- We read the system and propose: the Legacy System Specification Assessment. Here the system is the booking, dispatch, tracking or billing application your firm built or had built, and the places where it meets your other systems. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
- If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means the smallest join that helps, built as a module of your own software, or the one application that cannot send or receive, rebuilt. We never do a single cutover. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
- We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.
The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.
What you need to bring: a budget for the assessment; read-only access to the code once the assessment begins; what each supplier publishes about how its product sends and receives data; an hour each from the people who copy details between systems; someone on your side to own each join; and your own team keeping every system running.
What we do not do: we have no connection or integration product. We cannot change another supplier’s packaged reservation, tracking or accounts product. We do not run, host or monitor a connection or any of your systems. We do not clean, correct or reconcile records that already disagree. Meeting the e-way bill or e-invoice rules, or any other rule, is your own work: we offer no tax, compliance or legal advice, we do not say what any rule requires of a particular firm, and we do not make a firm compliant. We do not work on the systems that run aircraft, trains or vehicles. We have no published case of this work for a logistics, travel or hospitality firm.
What changes for the business:
| Role | What they gain |
|---|---|
| CEO | Joining the systems stops being a choice between doing nothing and replacing everything. |
| CTO or CIO | One connection or one rebuilt application at a time, each proven against what it replaces, with everything that works left working. |
| CFO | Money goes to the one join that causes the most correction, and the rest can wait until it has proved its worth. |
| COO | One piece of daily re-typing ends, and the people who did it check the exceptions in place of copying. |
| Head of sales and marketing | A customer or agent sees the same status on the portal as the depot sees on its screen. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| In an advisory of 5 November 2024, India’s GST Network set a 30-day limit, from 1 April 2025, for reporting e-invoices, for taxpayers with an aggregate annual turnover of 10 crore rupees or more. | Our assessment shows how a consignment reaches the system that issues the invoice, and what rebuilding that part would take. Whether the limit applies, and meeting it, is the supplier’s work with its tax adviser. |
| In an advisory of 17 December 2024, India’s GST Network limited e-way bills, from 1 January 2025, to documents dated within 180 days and extensions to 360 days, and made a second login step compulsory in stages, the last “from 1st April 2025 for all other taxpayers and users”. | Our part is narrower. We supply no e-way bill product and give no tax advice. For a firm’s own software, the map shows where the data for an e-way bill is held and how it gets there. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. Before you approve a platform to replace everything, we would find the one crossing that causes most of the correction.
Sources
In this issue
Too many separate systems
Research note 1
Your Systems Each Work. The Trouble Is Where a Consignment Crosses Between Them.
When booking, dispatch, tracking and billing each keep their own copy, errors start where data crosses. What we found, the options, our benchmark.
Research note 3
Your Systems Are Already Joined, by Files, Scripts and Spreadsheets. Here Is the Benchmark We Would Set.
Nightly files, scripts and spreadsheets already join most logistics systems. The benchmark we would set for them, what we would rebuild, what we will not claim.
Issue study
Systems That Do Not Share What They Know
Booking, dispatch, tracking and billing systems that do not share data: system sprawl, how much joining is manual, e-way bill rules, the options.
More from Logistics, travel and hospitality
Scarce skills and missing documentation
A Record Your Staff Open Before They Pick Up the Phone. Here Is the Benchmark We Would Set.
Inherited systems nobody understands
A Year After the Deal You Still Run Two of Everything. Here Is the Benchmark We Would Set.
Too slow and costly to replace