Home / Transport software

Logistics — the transport software stack

Transport software: which systems you actually need, and in what order

A transport company is sold software in the order suppliers happen to call, not in the order its problems appear. This page maps the five systems a Dutch transport business actually runs, what each one is genuinely for, which to buy first, and where the money leaks between them. It is deliberately not a product comparison — it is the decision that comes before one.

By Tom Joseph · Last updated: 18 August 2026

Free consultation Pricing

In short

Most transport companies run five systems: a TMS, a planning tool, telematics or a board computer, a financial and invoicing package, and — if they hold stock — a WMS. The costly mistake is buying them in the wrong order, because each one assumes the data of the one before it. The practical rule: buy the system that owns the decision currently losing you the most money, and make sure it can hand data to the next two before you sign. We start with a €2,500 audit that establishes which decision is actually leaking — planning, invoicing, or the gap between them — before anything is purchased.

The five systems

What each system actually owns

Transport companies run five systems. The costly mistake is buying them in the wrong order.

TMS
Order to invoice
The backbone: the shipment, the tariff, the carrier. It owns what may be billed.
Planning
Who drives what
Which vehicle takes which load, within driving hours and time windows. Sometimes a TMS module, sometimes separate.
Telematics
What happened
The board computer reports reality. It decides nothing — and prices nothing.
Invoicing
The ledger
Receives what the TMS calls billable, with no view on whether that was correct.
WMS
Only if you hold stock
Warehouse work on a transport system is the most common cause of a stock position nobody trusts.

The stack

The five systems, and what each is genuinely for

The vocabulary overlaps badly. Suppliers use "transport software" for all five, which is how a company ends up with two systems that half-do planning and none that does it well.

TMS — the order-to-invoice backbone: the shipment, the tariff, the carrier, the paperwork. It owns what was agreed and what may be billed.
Planning — which vehicle takes which load, in which sequence, within driving-hours and time windows. Often a TMS module, sometimes a separate optimiser, occasionally still a whiteboard.
Telematics / board computer — where vehicles are, what drivers did, tachograph data, fuel. It reports reality; it does not decide anything.
Financial and invoicing — the ledger. It receives what the TMS says is billable and has no view on whether that was correct.
WMS — only if you hold and pick stock. Warehousing on a transport system is the single most common source of an unusable stock position.

Scoping

Three questions that reveal which system a supplier is actually selling

Because all five functions get called "transport software", the fastest way to place a supplier is to ask what their system refuses to do. Honest vendors answer this quickly; the answer tells you which of the five you are being sold.

"What happens to a shipment you cannot price?" A TMS holds it and flags the missing tariff. A telematics product simply has no opinion, because pricing is not its job.
"Show me an order that has not been accepted yet." Planning and TMS products hold unaccepted work so you can decide. Execution-focused products only know about work already assigned to a vehicle.
"Which of these numbers is yours, and which came from another system?" Asked over a dashboard, this separates a product that owns data from one that displays someone else's — a distinction that matters enormously when a figure turns out wrong.

Buy order

What to buy first, decided by where money leaks

The order is not universal — it follows your constraint. Three patterns cover most Dutch operators:

Invoices leave late or wrong. Start with the TMS. When the tariff and the trip live in different places, revenue leakage is invisible and permanent, and no planning tool recovers it.
The plan is fine but the day falls apart. Start with telematics and execution rather than an optimiser. A better plan you cannot follow is not the constraint; knowing at 11:00 that the 14:00 window is gone is.
Planners are the bottleneck and margins are thin. Now an optimiser earns its place — but only on clean master data about vehicles, capacities and time windows, which is usually the real project.

All-in-one

All-in-one or best-of-breed

The honest answer depends on how unusual your operation is, and the question is not which is better but which failure you would rather have.

All-in-one means one supplier, one dataset and no integration project. You pay for it in fit: when your tariff structure or planning constraints are unusual, you adapt to the package or pay for development. For a straightforward general-cargo operation this is usually the right trade.

Best-of-breed means each system is genuinely good at its job, and you own the integration for the life of the stack. That is a permanent cost, not a project. It is worth it where one function is your competitive edge — specialised planning, or a tariff model competitors cannot copy.

What decides it in practice: how many exceptions your operation runs on. Few exceptions favour all-in-one. Many favour best-of-breed, because packaged software handles the common case well and the exception badly.

Board computer

The board computer you already pay for is not a planning system

Telematics suppliers have added trip registration, order screens and messaging, so it reasonably looks as though you already have transport software. You have an excellent record of what happened and no system that decides what should happen.

The distinction shows up in three places. A board computer cannot price a shipment against a customer tariff, so invoicing stays manual. It has no view of unaccepted orders, so it cannot help you decide what to take on. And its data model is the vehicle, not the shipment — which means a load moving across two vehicles is two records that nobody reconciles.

What it is genuinely good for is feeding everything else: actual times against planned, real driving hours, fuel per lane. Any TMS worth buying takes that feed. Ask how, and how often, before you sign.

Integration

Where the money leaks between systems

Each handover is a place where reality and record diverge. Four leaks show up in almost every audit we run:

Waiting time that nobody bills. The driver records it on the board computer; the TMS never receives it as a chargeable event; the invoice goes out without it. This is usually the largest single leak, and it is pure margin.
Extra stops added on the day. Agreed by phone, executed, never entered as an order line.
Fuel surcharge applied to the wrong period. The index updates in one system on a schedule that does not match the invoicing run.
Charter costs booked without the matching sale. Subcontracted work invoiced to you promptly and billed onward late, or at the wrong rate.

Not software

The problems software will not fix

Worth stating plainly, because these get sold as software problems:

Structurally unprofitable lanes. A planning tool will run them more efficiently and they will still lose money. That is a pricing conversation.
Customers who book too late. Optimisation cannot recover information you do not have at planning time.
Not enough drivers. Better planning gets more from the hours you have, which is real but bounded, and the bound arrives quickly.
Disagreement about what was agreed. A TMS records agreements; it does not make commercial terms clear.

Running cost

What the stack costs to run, not just to buy

Licences are quoted per user or per vehicle and are the predictable part. What surprises people is the annual change budget: tariff structures shift, customers demand new file formats, a carrier changes its API. Budget for that deliberately rather than treating each change as an incident.

The second recurring cost is the integration layer, if you chose best-of-breed. Someone maintains it. If nobody is named, it decays quietly until an invoicing run breaks, and the diagnosis takes days because no one owns both ends.

FAQ

Frequently asked questions

What is the difference between transport software and a TMS?

A TMS is one system within the transport software stack — the order-to-invoice backbone. "Transport software" is the whole set, including planning, telematics and invoicing.

Suppliers use the broader term for whatever they sell, so ask specifically which of the five functions a product owns.
Most confusion comes from planning: it may sit inside the TMS or be a separate optimiser, and the difference matters commercially.
If you are choosing a TMS specifically, our TMS selection page covers that decision.

Do we need separate planning software if our TMS includes planning?

Usually not at first. TMS planning modules handle straightforward vehicle allocation well; a separate optimiser earns its cost when the combinatorics genuinely exceed a person.

The trigger is scale and constraint density — many vehicles, tight windows, driving-hours limits interacting, multi-drop routes.
An optimiser is only as good as vehicle capacities, loading times and time windows in your master data. That data work is the actual project.
Test the module against a real historical week before assuming it is insufficient.

Can we run warehousing on our transport software?

For a handful of pallets in a buffer, yes. For picking customer orders from stock, it produces a stock position you cannot trust.

TMS stock handling is typically location-free — it knows quantity, not where something is or in what condition.
The moment you need batch or serial traceability, a transport system will not carry it.
See our WMS selection page for what changes when stock becomes a real function.

What does transport software cost in the Netherlands?

Licences are usually priced per user or per vehicle per month, which makes the licence the predictable part and everything else the variable.

Implementation depends almost entirely on tariff complexity — how many customer-specific rate structures must be modelled.
Budget an annual change allowance rather than treating tariff and format changes as incidents.
With us: a €2,500 audit to establish which decision is leaking, a €20,000 proof of concept where the approach is uncertain, production from €50,000. Package licences are paid to your chosen vendor; we do not resell them.

Our board computer supplier says they offer transport software. Is that enough?

It can be, for a small operation on simple tariffs. Test it against three specific things before accepting it.

Can it price a shipment against a customer-specific tariff, including surcharges, without manual work?
Does it hold orders you have not yet accepted, so you can decide what to take?
Is the shipment the record, or the vehicle? A load crossing two vehicles must remain one shipment.

Not sure which system to buy first?

The €2,500 audit establishes where money actually leaks in your stack — planning, invoicing, or the handover between them — before anything is purchased.

Book a conversation