Systems That Do Not Share What They Know

1. At a Glance

Issue study · From the public record. We found one public description of the problem from a firm in this sector, from 2022, and no public case of a mid-size logistics, travel or hotel firm harmed because its systems did not share what they know. The case is reported as the public record gives it.

Organisation type	An Indian logistics firm whose CIO described its systems as a sprawl of many separate programs on many separate machines (an older case), set beside the position of a mid-size firm whose booking, dispatch, tracking and billing systems do not share what they know
Size band	The case: not given by the source. Our reader: a mid-size transporter, courier, forwarder, warehousing firm, bus or tour operator, travel seller or hotel group with several systems of its own
Region	The case: India. The reader: anywhere; the tax rules in section 3 are Indian
The decision at stake	What to do about systems that disagree: keep re-typing and reconciling, buy a connection or integration product, replace everything with one new platform, or map every crossing and build the smallest join that helps
The public outcome	The firm’s CIO said it ran a great many separate programs on a great many separate machines, which made its technology sprawling and complex. The source does not say what the sprawl cost or what went wrong because of it
Why it matters to a mid-size firm	A firm can have many systems that each work and still give its customer two answers. The errors are made where a booking or consignment passes between systems, and in India some of the documents it carries now have time limits

2. The Business Problem, in the Buyer’s Words

“We have a booking system, a dispatch application, a tracking service for customers and an accounts package. Each does its job. But a consignment’s weight is typed at booking, again at dispatch and again in accounts, and the invoice does not always match what we carried. The portal says delivered while the depot says out for delivery. A program copies bookings to accounts every night, and once it stopped and nobody knew for days. Every supplier we ask says replace all four. I cannot approve that, and I cannot describe what we have.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The firm is caught between systems that each work and a business that needs them to agree. The cure it is offered, one new platform, is larger than the problem it can describe.

3. What We Found

Method. We went through the public record on firms in this sector whose systems do not share what they know: one Indian logistics firm’s own description of its systems, trade reporting on how Indian warehouses and freight firms work, one cross-sector survey of how firms see their old systems, and two advisories from India’s GST Network on e-way bills and e-invoices. The sources were published between 2022 and 2025. The sector research behind this study holds no case of a mid-size firm on this issue, no figure for how much re-typing is done, how often invoices mismatch or what a failed transfer costs, and nothing on the scripts, timed files and spreadsheets that join systems in practice.

One firm’s own description. The case is an Indian logistics firm. This is an older case, from 2022, and we use only the problem it describes.

What	Public record
Who said it	The firm’s CIO
What was said	That it ran a great many separate programs on a great many separate machines, which made its technology sprawling and complex
What it cost, or what went wrong	Not given by the source
What the firm did next	Described in the source; not used here, because it is another organisation’s story

How much joining is done by hand. Two software vendors’ co-founders, quoted in the Indian trade press in 2025, said that the great majority of Indian warehouses still run without any dedicated supply chain software, and most small firms still rely on paper, messaging apps and spreadsheets. A freight software vendor’s own research from 2023 found that about a quarter of the few dozen freight forwarders, logistics providers and ocean freight intermediaries it surveyed still worked entirely by hand; the source states no country. These describe the absence of software, not old software. We use them only to show that people, messages and spreadsheets carry much of the data in this sector.

What firms say about old systems. In one cross-sector survey of about 500 US IT professionals, which is not about this sector, about two in five named incompatibility with modern systems or tools among the top issues with their old systems. Among the reasons for not upgrading, more than two in five named budget limitations and more than a third fear of disrupting operations, and about three in five organisations still use legacy systems.

Documents with time limits, in India. These are rules, not cases, and we report them only in the GST Network’s words.

Rule	Public record	Who must act
E-invoice reporting limit (advisory of 5 November 2024, in force since 1 April 2025)	“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”; it covers “all document types (Invoices/Credit Notes/Debit Notes)” that need an invoice reference number; “no such reporting restriction on taxpayers with an AATO of less than 10 crores as of now”	In the advisory’s words, “taxpayers with an AATO of 10 crores and above”; the advisory 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
E-way bill limits (advisory of 17 December 2024, in force since 1 January 2025)	“The generation of E-Way Bills will be restricted to documents dated within 180 days from the date of generation”; “the extension of E-Way Bills will be limited to 360 days from their original date of generation”; a second login step compulsory in stages, and “from 1st April 2025 for all other taxpayers and users”	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

Our reading of why separate systems cause trouble. These four are our reasoning from the record above. None is a finding of any source.

1. Nobody has a list of the crossings. Each team knows its own screen. Nobody has a picture of every place a booking or consignment passes from one system to another.
2. The same facts are entered more than once, by people, by small programs and from spreadsheets, so a slip at one crossing is carried into the next.
3. The joins that exist were never recorded. Scripts, timed files and spreadsheets hold the systems together, stop without telling anyone, and are understood by one person or none.
4. The only cure offered is the largest. With no list of crossings, nobody can propose anything smaller than replacing every system.

Our reading of the rules, and only that: an invoice keyed from a printout or carried by a monthly file has used part of its 30-day window before anyone reports it, and an e-way bill typed from another screen is one more copy of the consignment that can part from the invoice. Whether either rule applies to a firm, and what it requires of it, is for the firm and its tax advisers.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
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; errors are found by the customer; documents keyed late use up their time limits	Right only for a small firm with few crossings
Buy a connection or integration product, or have one built	The crossings are already known, and the systems at each end can already send and receive	It joins only the crossings someone has listed; someone must run and watch it	The firm’s own choice and another firm’s product; IOanyT has none. Better after the crossings are mapped
Replace all the systems with one new platform	Most of the systems are failing, and the firm can carry a long change	Every screen and team changes; systems that work are thrown out; the crossing that hurts most waits for the whole programme	The firm’s own decision, and choosing or installing a packaged platform is not IOanyT’s kind of work; we would advise against this as the first answer, and it is sometimes right as the last
Map every crossing, 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	Costs money before anything is joined; each join is one more thing to look after; some crossings stay hidden until they fail	Our recommendation

5. Our Recommendation, and the Decision It Asks of the Board

For the applications a firm built or had built (booking and quotation tools, dispatch and trip-planning, consignment tracking, customer and agent portals, in-house billing), and the places where they meet the firm’s other systems: map first. List every place a booking or consignment crosses between systems, including by hand, by timed files, by scripts and by spreadsheets. Trace each kind of mismatch to the crossing that causes it, and have the business name one system as the source for each fact. Then deal with the crossing that causes most correction by the smallest join that helps: one connection built, or one application rebuilt, module by module, while the old arrangement keeps running, each module proven against what it replaces with a traceability matrix. Give each join an owner on the firm’s side. Replacing everything comes last, and is sometimes right.

6. Benchmark: Where You Are Now, and Where You Should Be

These are targets, not results. In an engagement the starting points are replaced by the firm’s own figures, taken in the first review.

Measure	Typical starting point	Where it should be	How it is checked
Crossings between systems, by program and by hand	Known in parts, to the people who make them	Every one listed: what it carries, from where to where, how often, and whether a program or a person makes it	The map of the system as it stands
The source for each key fact	Staff know which screen to believe	One system named as the source for each fact, decided by the business	The specification
Mismatches between systems	Blamed on “the systems”	Each kind traced to the crossing that causes it	The risk register
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 joins that matter	Left alone, because they work	Rebuilt as modules, each proven against what it replaces, each with an owner on the firm’s side	The traceability matrix and the list of joins
The size of one commitment	A new platform, or nothing	One module, with the freedom to pause after any accepted module	The staged plan
Records that already disagree	Corrected as they are found	Listed by the crossing that caused them, and put right by the firm’s own team	The firm’s own records, outside IOanyT’s work

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about your systems, where a booking or consignment crosses between them, and the last time the figures parted. 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.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This study is an example of that work.
3. 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.
4. 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. A traceability matrix links every old function to its replacement. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. 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.

8. What the Client Would Own

• The map and the specification: what the firm’s own applications do, in writing, with every crossing between its systems that the assessment finds and the staff point to.
• The risk register: the crossings behind the most correction, listed before any price is set.
• The list of joins: each with what it carries and an owner on the firm’s side.
• The traceability matrix: for every module IOanyT builds or rebuilds, every old function linked to its replacement, with how it was checked.
• The code: the modules are the client’s. No runtime or platform fee.
• The filled-in benchmark: each measure, where it started and where it stands.

Running the joins, correcting the records that already disagree, and every decision about tax rules belong to the firm and its advisers.

9. What This Approach Does Not Cover

• IOanyT has no connection or integration product, and does not sell or license one. A connection layer is the firm’s own choice and another firm’s product.
• IOanyT cannot change another supplier’s packaged reservation, booking, tracking, warehouse, property management, accounts or ERP product, and does not install, upgrade, move or choose one. Where such a product sits at the end of a crossing, IOanyT works only with what it already lets other programs send and receive; a product that lets nothing in or out cannot be joined by IOanyT at all.
• IOanyT does not run, host or monitor a connection or a rebuilt module once it is built, and is not told when one stops. The owner of each join is someone on the firm’s side.
• IOanyT does not clean, correct or reconcile records that already disagree, or what went astray while a join was down, and does not offer moving data from one system to another as a service.
• Some crossings will be missed until they fail, because nobody remembers them. Crossings made by hand appear in no code; only the firm’s staff can point to them. A spreadsheet that rests on someone’s judgement is not wholly replaced by a program. A join is one more thing to look after, and several joins can become a tangle of their own.
• IOanyT offers no tax, compliance or legal advice, does not say what the e-way bill, e-invoice or any other rule requires of a particular firm, and does not make a firm compliant.
• IOanyT does not work on the systems that run aircraft, trains or vehicles, or on anything on which a traveller’s safety depends.
• This study does not say IOanyT would have prevented anything at the firm described. IOanyT has no published case of this work for a logistics, travel or hospitality firm.

About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.

10. Sources

Source	Used for
Trade press article, 2022	An Indian logistics firm: its CIO’s description of its systems
Trade press article, 2025	Indian warehousing: how few run supply chain software; work on paper and spreadsheets
Trade press article, 2025	A freight software vendor’s 2023 research: firms working entirely by hand
A vendor’s survey, 2025	Incompatibility; budget limitations; fear of disrupting operations; organisations still using legacy systems
GSTN advisory, 5 November 2024 (copy on Maharashtra GST)	The e-invoice reporting limit
GSTN advisory, 17 December 2024 (copy on Maharashtra GST)	The e-way bill limits and the second login step

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. Your systems already touch in more places than anyone has written down; we list them before anyone proposes to replace them.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →