Your Systems Each Work. The Trouble Is Where a Consignment Crosses Between Them.

A customer rings about a consignment. The tracking page says it was delivered on Tuesday. The invoice that arrived this morning is for more weight than was sent.

The accounts clerk opens the billing system. The dispatcher opens the dispatch application. The booking desk opens the booking screen. Each shows the consignment, and no two of them agree on its weight.

Each system is right by its own account. The weight was typed in four times, by three people and one overnight program, and somewhere along the way it changed. Nobody can say where.

What We Found

For this article 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, and one cross-sector survey of how firms see their old systems, published between 2022 and 2025.

First, what we did not find: no case of a logistics, travel or hotel firm harmed because its booking, tracking and billing systems did not share data, and no figure for how much re-typing is done, how often an invoice does not match what was carried, or what a failed transfer costs. We give none.

One logistics firm has described its own systems this way. This is an older case, from 2022, and we use only the problem it describes. The CIO of an Indian logistics firm said that 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 the firm or what went wrong because of it, and we add nothing. What the firm did afterwards is its own story and is not part of this article.

Much of the joining in this sector is done by hand, or not done at all. 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 figures describe firms with little or no software, which is not the same as old systems that do not connect. We use them for one point: where systems are few or do not meet, people, messages and spreadsheets carry the data between them.

Old systems are widely seen as hard to fit with newer ones. In one cross-sector survey of about 500 IT professionals in the US, 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.

Our reading: when a booking, dispatch, tracking and billing system each hold their own copy of a consignment, the errors are made where the consignment passes from one to the next. Those places are rarely listed. So when two systems disagree, the firm blames “the systems”, and nobody can say at which crossing the figure changed.

What Waits While the Systems Disagree

Separate systems are usually treated as a technology problem for another year. Our reading is that the cost is paid every day, by other people.

The customer hears two answers. Tracking says delivered, billing says pending, and the person on the telephone has to choose which screen to believe.

The invoice drifts from the load. A weight corrected at the depot stays wrong on the invoice. A credit note follows, and nobody can say where the figure parted.

People carry the data. The staff who know the customers best spend their mornings typing what is already on another screen, and their afternoons correcting the copies. They are doing it well. Their time appears in no budget line.

Every fix is a guess. Asked to “integrate the systems”, the technology team has no list of where they already touch, so the only proposal anyone can make is to replace everything.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Deal With Separate Systems, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Keep re-typing and reconciling by hand	Volumes are low, there are few systems, and staff know which screen to believe	The work grows with every customer and every system, and errors are found by the customer
Buy a connection or integration product, or have one built for you	The crossings are already 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. This is 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, and the one 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	The systems are used every day, and a few crossings cause most of the correction	It costs money before anything is joined, a map joins nothing by itself, and some crossings stay hidden until they fail

Where You Are Now, and Where You Should Be

Before any work begins we set a benchmark: a few measures taken from your own systems, each with a target. For this issue it would look like this.

Measure	Typical starting point	Where it should be	How it is checked
Crossings between systems	Known in parts, to the people who make them	Every one listed: by program, timed file, spreadsheet or person, with what it carries	The map of the system as it stands
Where each key fact begins	A weight, address or rate typed wherever it is needed	For each, where it is first entered and every place it is copied to	The specification
The source for each fact	Staff know which screen to believe	One system named as the source for each fact, decided by the business	The specification
Mismatches	Blamed on “the systems”	Each kind traced to the crossing where the figures part	The risk register
Records that already disagree	Corrected as they are found	Listed by the crossing that caused them, and put right by your own team	Your own records, outside our work

The starting points above are what we expect to find; in an engagement they are replaced by your own figures, taken in the first review. 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

1. We listen: a free Reliability Review. A first conversation about your systems, where a booking or consignment crosses between them, and where the figures part. 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 article 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. You get the options and our recommendation.
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. Each module has a traceability matrix. 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.

What we do not do: we have no connection or integration product, and we do not sell or license one. We cannot change another supplier’s packaged reservation, tracking or accounts product; where one sits at the end of a crossing, we work only with what it already lets other programs send and receive. We do not run, host or monitor a connection once it is built; your own team or supplier does. We do not clean, correct or reconcile the records that already disagree, and we do not offer moving data from one system to another as a service. 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	When two systems disagree about a customer’s consignment, the firm can say where the disagreement began, and stops blaming “the systems”.
CTO or CIO	A map of every place a booking, consignment or invoice passes from one system to another, by program or by hand, with what is sent and what is re-typed.
CFO	An invoice that does not match what was carried can be traced to the crossing where the figures parted.
COO	Operations can see which re-typing its teams do every day, and which of it leads to the errors they later correct.
Head of sales and marketing	Sales can tell a customer which screen holds the true status of a consignment, and why another showed something else.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
The CIO of an Indian logistics firm described a sprawl of many separate programs on many separate machines. An older case.	Our part is narrower, IOanyT did not work on this case, and we say nothing about what it did next. We have no product that connects systems. For a firm’s own applications, we map every place data passes between them, so the firm can see which crossings to deal with first.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. Before anyone proposes to replace your systems, we would list where they already touch.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →