For some operators, one of the biggest worries about changing the transport management system (TMS) is what happens to the systems already embedded in the operation. The tracker hardware is fitted. The finance team relies on the accounts package. Replacing either can turn a TMS project into a much bigger change than it needs to be.
That is where TMS integration earns or loses its keep. Done properly, it can let you keep compatible systems that already work for you while removing the re-keying between them. Done as a logo wall on a website, it means your office keeps typing the same job into three screens. A logo tells you very little on its own. The real question is how much manual work the connection removes.
What does TMS integration actually mean?
TMS integration means a data connection between the transport management system and the other systems an operation runs, the vehicle tracker, the accounts package, customer systems, so that information entered once flows where it is needed without anyone re-typing it. The test is not whether a vendor lists your tools; it is what data moves, in which direction, and what manual work disappears as a result.
Those three questions separate three very different things that all get sold under the same word.
A logo claim is a badge on an integrations page. It suggests a connection is available, but tells you nothing about your version, your configuration or your workflow.
A data feed moves data in a single direction: live vehicle positions feeding the fleet view, or invoices pushed to accounts. Genuinely useful, and often exactly the right architecture. Two-way is not automatically better; the right integration moves the data the workflow actually needs, and no more.
A workflow integration is defined by the manual work it removes, whichever direction the data flows. Approved invoices reach the accounts package without being entered again. Live vehicle positions feed the fleet view and support the ETAs shown to customers. That is the standard to hold any vendor to, including us: measure the integration by the re-keying that disappears, not by the number of arrows on the diagram.
What stays, what connects, what moves
Applied to a real operation, the keep-what-works principle sorts the stack quickly.
The tracker can often stay. The hardware is fitted, the contract has term left, and the operation trusts the data. Where the exact provider and version are supported, it connects to the new platform, with the connection scoped and quoted as a one-off before any work starts. Confirm your specific tracker during the evaluation; the integrations page is the starting point, and a written answer for your exact system is the finishing one.
The accounts package stays. Finance’s history, controls and month-end processes already live there, and moving them is a project nobody needs. With supported accounting integrations, including Xero and Sage, approved invoices flow from the TMS into the accounts package instead of being entered again manually. Confirm the exact package and the workflow you need during the evaluation.
Retired systems leave records behind. If a separate defect or maintenance system is being retired in the consolidation, preserve the records you are required to retain before it is switched off. Under DVSA’s Guide to Maintaining Roadworthiness, defect reports recording faults and rectification, and safety inspection and repair records, must remain available for at least 15 months; nil-defect reports are recommended for at least three months.
The TMS itself moves. That is the whole project: one platform for planning, driver jobs, ePOD, checks, tracking views and invoicing, connected to the tools above rather than replacing them. If you are weighing that move, our guide to switching TMS without stopping the trucks covers the migration itself; this piece is about the connections around it.
What a connection should cost, and how it should be quoted
Integration pricing is where vague promises can become expensive, so ask every vendor for the scope in writing. HaulierMagic currently publishes indicative one-off integration pricing alongside the subscription rates: from £500 to connect an existing supported integration, from £3,500 for a new one-way integration and from £7,500 for a two-way integration, with every project scoped and quoted for the individual operation and published figures excluding VAT. Any vendor who cannot tell you which category your tracker and accounts package fall into, in writing, has answered a different question: how the relationship will run after you sign.
Put the same questions to every vendor on the shortlist, on the same paper, and file the answers next to the quotes.
| Question | Why it matters | Vendor answer |
|---|---|---|
| 01 Is our exact tracker and accounts package supported today? | ”Supported” for your specific systems and versions is the only answer that counts; a category logo is not a commitment. | |
| 02 What does each connection cost, itemised? | Existing supported connections and new builds are different price categories; the quote should say which is which. | |
| 03 What data flows, and in which direction? | Live positions to the fleet view? Approved invoices to accounts? The exact flow tells you which manual steps disappear. | |
| 04 Can we test a representative example on our own workflow? | A connection proven on sample files can still behave differently on your setup; one real job tells you more than any logo. | |
| 05 Who supports the connection when it fails or the third-party API changes? | Integrations break at month six, not day one; a named owner beats two vendors pointing at each other. |
Testing TMS integration before you rely on it
A standard demo can make an integration look straightforward; the useful test is a representative example on your own workflow. One or two real jobs, the tracker connection you rely on, and the finance data that needs to reach your accounts package. Then check three things: what moved automatically, what still needed manual intervention, and who owns support if the connection fails later. If the demo cannot run on a representative sample, ask for it as a condition of the pilot instead, with the commitment in writing.
The stakes are not abstract. An established operation can be running five or six systems around the TMS, and every pair that does not talk is a person doing the talking. Our piece on the real total cost of that stack puts numbers on it; the questions sheet above is how you make those numbers fall.
Keep what works is not a slogan; it is the test TMS integration exists to pass, and you run it on every vendor, us included. Where your tracker and accounts package are supported, they should survive a TMS switch connected rather than replaced, with the connection priced in writing before you sign. The vendors who mean it will put it on paper. The ones who will not have told you what “integrates with” meant all along.
Already have a tracker and accounts package you want to keep? Bring us the names of the systems you use and we will show you what can connect today.
TMS integration: what operators ask
Can we keep our existing vehicle tracker when we change TMS?
In many cases, yes, where the exact provider and version are supported. The fitted hardware and the contract can then stay while the data connects to the new platform, with the connection scoped and quoted as a one-off before any work starts. Whether your specific tracker qualifies is a written question for the evaluation, put to every vendor on the shortlist, so the answer and the cost appear in every quote rather than surfacing after signature.
What does a TMS integration cost?
HaulierMagic publishes indicative one-off starting prices in three categories: from £500 to connect an existing supported integration, from £3,500 for a new one-way integration, and from £7,500 for a two-way integration, with every project scoped and quoted for the individual operation and figures excluding VAT. The category matters more than the headline number, so ask which one your exact systems fall into, in writing, before comparing quotes.
What actually flows between the TMS and the accounts package?
For supported accounting integrations, approved invoices, credit notes and payments flow from the TMS into the accounts package, so they are created once instead of entered again manually. The exact workflow varies by package, which is why the evaluation question is specific: name your package and version, ask what flows in which direction, and test a representative example with your finance person watching what lands where.
What if our tracker is not on the supported list?
Three possible routes. Ask the vendor to scope a new integration, quoted individually against the published new-integration starting prices, and weigh the cost against the re-keying it removes. Run the tracker alongside the TMS unconnected for now, which loses the position feed into the platform but keeps everything else. Or weigh a tracker change at its own contract renewal rather than forcing it into the TMS project. The wrong answer is letting one unsupported tool veto the whole move by default.
