Home / Transport management system

Logistics — TMS selection

Transport management system: how to test one before you sign

Every TMS demo looks competent, because every TMS handles a straightforward shipment competently. The differences appear in two engines that demos rarely stress: the one that prices your work and the one that plans it. This page is about testing both on your own data, plus the integration questions that decide what the system costs you in year three.

By Tom Joseph · Last updated: 18 August 2026

Free consultation Pricing

In short

A TMS is judged on two engines: the tariff engine that turns a shipment into a correct invoice line, and the planning engine that turns a day of orders into a workable schedule. Test both by replaying one real week of your own historical orders and comparing the output against what you actually invoiced and actually drove. Differences are the conversation — in either direction, because a TMS that prices higher than you invoiced has found revenue you were leaking. We run this replay as part of a €2,500 audit, which is also where it becomes clear whether a TMS is what you need at all.

What to test a TMS on

The two engines and the three integrations

Every demo looks competent. The differences sit in what a demo rarely stresses.

Tariff engine
Where margin leaks
Hand over your three most awkward tariffs and have them configured live. Compounding surcharges break most systems.
Planning engine
Driving hours as a rule
Does it respect driving hours as a constraint, or report violations afterwards? The latter is a compliance tool.
Telematics
Connected today?
The data comes off your fleet. Ask whether a live connection to your board computer exists today — "possible" means you are paying for it.
Charters
Purchase beside sale
Visible per trip, not at month end. Otherwise subcontracted margin stays invisible.
The replay
One real week
Replay a real week against what you invoiced and drove. Every difference is an error or a leak.

Tariff engine

The tariff engine is where margin is won or lost

Ask a vendor whether the system supports customer-specific tariffs and the answer is always yes. The real question is how much of your tariff reality it models without someone doing arithmetic on the side.

Hand every vendor your three most awkward customer tariffs and require them to configure all three in front of you. What to watch for:

Zone and distance models simultaneously — many operations price some customers per zone and others per kilometre band, with a minimum charge that interacts with both.
Surcharges that compound. Fuel surcharge on the base rate, then a toll surcharge on the total, then a customer discount off the lot. The order of operations is where systems quietly disagree with your invoicing.
Waiting time and extra stops as chargeable events flowing from execution rather than typed in later — the single most common leak in Dutch road transport.
Charter purchase against sale on the same shipment, so subcontracted margin is visible per trip rather than at month end.

Planning engine

How to test the planning engine honestly

Planning demos use a clean set of orders that fit neatly. Yours do not. Replay a genuine week — ideally an ugly one, with a breakdown or a customer who added stops at 15:00 — and compare against what you actually drove.

Three tests separate real optimisation from a digital whiteboard:

Does it respect driving hours as a constraint, or report violations afterwards? Reporting afterwards is a compliance tool, not a planner.
Can it replan mid-day without discarding the morning? A system that only produces a fresh plan from scratch is unusable at 11:00 when a truck is down.
What does it do with an order it cannot fit? Silently dropping it, or surfacing it with the binding constraint named, is the difference between a tool a planner trusts and one they work around.

Integration

The two integrations that decide year three

A TMS sits between systems, so its value is capped by what it can reach. Two connections matter more than the rest.

Telematics. Actual times, positions and driving hours should flow in without anyone typing. Ask specifically whether the vendor has a live connection to your board-computer supplier today, not whether one is possible. "Possible" means you are paying for it.

Carriers and charters. If you subcontract, every partner has their own way of receiving orders and returning status. Ask how many are supported out of the box, and what a new one costs — this is the cost that grows silently as you add partners.

Customer connections come third and are worth scoping honestly: a large shipper will eventually ask you to receive orders their way, and the answer should not be a new project each time.

Compliance

Treat eCMR and eFTI as a roadmap question, not a feature

Digital consignment notes and the coming European freight-information rules will change what a TMS must be able to hand to an authority. The mistake is asking whether a system supports them today and accepting a yes.

Ask instead: what has this vendor already shipped, what is dated on their roadmap, and is it included in the licence or a paid module? A vendor with a concrete answer has thought about it. A vendor who answers only that they are "compliant" has told you nothing you can plan around.

The practical requirement underneath is unglamorous: your shipment data must be complete and structured enough to be handed over at all. Operations running on scanned PDFs and free-text notes have a data problem that no compliance module fixes.

Migration

What comes across from the old system, and what does not

TMS migrations are scoped as "move the data" and then discover that most of it is not movable in a useful form. Three categories behave differently and it is worth deciding each one deliberately:

Master data moves. Customers, addresses, vehicles, drivers. Tedious but mechanical — and a good moment to delete the addresses nobody has shipped to in three years.
Tariffs get rebuilt, not migrated. Every system models rates differently, so tariffs are re-entered and re-tested. This is the bulk of the work and the reason implementations slip.
History usually stays behind. Keep the old system readable for a defined period rather than forcing years of shipments into a new structure. Decide explicitly how long, and who may access it, before go-live rather than after.

The replay

The one-week replay, step by step

This is the single most useful thing you can do before signing, and it costs a week of your own time rather than money:

Pick a real week — recent, busy, with at least one thing that went wrong.
Extract the orders as they arrived, including the ones added on the day and the ones you refused.
Give each vendor the same pack with your three awkward tariffs, and have them price every shipment.
Compare against what you invoiced. Any shipment priced differently is either a system error or a leak you did not know about. Both are worth finding.
Then plan the same week and compare against what you drove — on total kilometres, on vehicles used, and on how many orders the system could not place.

Not a TMS

When you do not need a TMS

Below roughly ten vehicles on simple, stable tariffs, a TMS often adds administration that a good invoicing package and a shared planning board already cover. The threshold is not fleet size but tariff and exception complexity.

Two signals that you have crossed it: someone is maintaining a spreadsheet to work out what may be invoiced, or a planner is the only person who knows why yesterday looked the way it did. The first is a revenue risk, the second a continuity one.

If you are earlier than that, the honest next step is usually to fix invoicing accuracy first. It is cheaper, it produces the tariff clarity a TMS selection needs later, and it stands on its own.

Vendor side

A note if you build TMS software rather than buy it

This page is written for buyers. If you are a software vendor putting AI into a TMS product — planning copilots, document extraction, ETA models — that is a different problem with different constraints, and we cover it on our page for AI in transport management software.

FAQ

Frequently asked questions

What is a transport management system?

The system that owns a shipment from order to invoice: what was agreed, what it should cost, who drives it, and what may be billed.

It is distinct from telematics, which records what happened, and from planning, which may sit inside the TMS or beside it.
It is also distinct from a WMS: a TMS moves goods between locations, a WMS manages them within one.
For how a TMS fits alongside the other systems you run, see our transport software stack page.

What is the difference between a TMS and planning software?

A TMS owns the commercial and administrative truth of a shipment. Planning software decides which vehicle takes which load in which order.

Most TMS packages include planning that is adequate for straightforward vehicle allocation.
A dedicated optimiser earns its cost when constraints genuinely interact — driving hours, time windows, capacity and multi-drop together.
Test the TMS module on a real historical week before assuming you need a separate optimiser.

How long does a TMS implementation take?

Three to six months for a road-transport operation, and the variance is almost entirely tariff modelling rather than software.

Customer-specific tariffs with compounding surcharges take longer to configure and test than anything else in the project.
Telematics integration adds time if the vendor has not connected to your board-computer supplier before.
Run the old and new invoicing in parallel for at least one full cycle. It is the only reliable way to catch a tariff modelled subtly wrong.

Should we choose a TMS from our board computer supplier?

It removes one integration, which is a genuine advantage. Weigh it against the tariff engine, which is where TMS value concentrates and where telematics-first vendors are often thinner.

Test their tariff engine on your three most awkward customers before deciding.
Ask whether the shipment or the vehicle is the core record — a load crossing two vehicles must remain one shipment.
If the tariff engine holds up, the tighter telematics coupling is worth real money in captured waiting time.

What does a TMS project cost with Crux Digits?

Fixed steps, so the risk is priced before the commitment.

A €2,500 audit including the one-week replay against your own invoiced and driven history.
A €20,000 proof of concept where a specific risk — an unusual tariff model, a difficult integration — needs settling on your data first.
Production from €50,000. Package licences go to the vendor you choose; we do not resell them, which is why we can tell you not to buy one.

Choosing a TMS this year?

The €2,500 audit replays a real week of your orders against candidate systems — and shows what your current invoicing is leaking, whichever system you pick.

Book a conversation