TMS: what a Transportation Management System is and how it works

In brief

TMS stands for Transportation Management System. There is no universal list of functions that software must have in order to call itself a TMS. The term is used in the market for very different products: from relatively simple tools for planning trips to enterprise platforms that manage carrier procurement, tenders, rates, international networks, cost audits, tracking, documentation and integrations with ERP and warehouse systems.

For an SME, the key question is not ‘do I need a TMS?’, but which processes do I need to control, and how complex are they? A company with five trucks receiving orders by email has very different needs from a logistics operator buying transport from hundreds of carriers or coordinating several European hubs.

What TMS really means

In practical terms, a TMS is an information system dedicated to transport management. It can support one or more stages:

request → order → planning → assignment → execution → monitoring → documents → costs → closure → analysis

Depth varies greatly from product to product. One system may be limited to planning its own transport; another may automatically choose among carriers based on rate and service; another may manage multimodal routes, appointments, SLAs, invoices and reconciliations.

That is why two offers both called ‘TMS’ can have completely different prices, implementation times and target users.

The operating cycle a TMS can manage

1. Capturing demand

Orders can arrive through manual entry, files, APIs, EDI, ERP, customer portals or other systems. The first task is to turn varied requests into usable data.

2. Planning

The system combines destinations, time windows, capacity, constraints, availability of vehicles and drivers, or carrier availability. More sophisticated systems may include optimisation engines; in simpler ones, planning remains mainly visual and manual.

3. Assignment

The trip is assigned to an internal vehicle/driver or to an external carrier. When transport services are purchased, rate tables, tenders, supplier rankings and procurement rules may come into play.

4. Execution

The office, driver and partners need to share statuses and changes: collected, arrived, loaded, en route, delivered, exception, and so on.

5. Documents and proof of service

The system can link the order, transport documents, POD and attachments. However, the presence of a document in the TMS does not mean that document is automatically correct from a legal, tax or technical standpoint.

6. Costs and control

More advanced TMSs compare estimated and actual costs, rates, surcharges, tolls, ancillary services and invoices received from carriers.

7. Analysis

Volumes, punctuality, route costs, resource utilisation, exceptions, carrier performance and other KPIs can become management data rather than manual month-end reconstructions.

The most common modules

A TMS can include:

• order management;
• customer, location and carrier master data;
• trip planning;
• vehicle/driver assignment;
• carrier procurement and tenders;
• rate management;
• tracking or integration with external tracking;
• appointment management;
• documents and POD;
• cost control and freight audit;
• invoicing or accounting integration;
• dashboards and KPIs;
• customer/supplier portal;
• APIs, EDI and ERP/WMS integrations;
• exception management;
• optimisation functions.

The right question during a demo is not ‘do you have this function?’, but how does it work in the company’s actual process, and what data does it require?

TMS, transport management software, FMS and telematics are not synonyms

Transport management software

This is a general term. It can refer to software focused on the administrative and operational organisation of a small business: customers, orders, drivers, trucks, daily plan and statuses.

TMS

It usually refers to a platform with greater depth in transport planning and control and, in enterprise settings, in managing networks, carriers, rates and integrations.

FMS / Fleet Management System

It is more focused on the fleet: vehicles, maintenance, fuel consumption, deadlines, utilisation, and possibly drivers and vehicle costs.

Telematics

It collects information from the vehicle or devices: location, kilometres, CAN data where available, diagnostics, driving events and other signals. A TMS can receive this data but is not, by definition, a telematics device.

ERP

It manages broader business processes: accounting, purchasing, sales, administration, warehousing and management control. A TMS can be an ERP module or a separate system integrated with it.

For an SME, it is normal to use more than one tool. The problem begins when nobody knows which system is the official source for each piece of data.

When a complex TMS is useful

Complexity tends to be justified as some variables increase:

• hundreds or thousands of orders;
• many collection and delivery sites;
• transport purchased from numerous carriers;
• complex rate tables and surcharges;
• national/international network;
• multiple transport modes;
• contractual SLAs and KPIs;
• a strong need for ERP/WMS integration;
• tendering and procurement processes;
• the need for systematic cost audits.

In these cases, the platform is not only for ‘seeing the plan’; it becomes part of the company’s information architecture.

When it can be oversized

A microbusiness with five or ten trucks can have a very concrete problem: scattered orders, changes in WhatsApp, planning in Excel and constant calls to drivers. Solving it does not necessarily require introducing:

• a six-month ERP project;
• complex rate configurations;
• a tendering engine;
• a data warehouse;
• dozens of roles and workflows;
• specialist consultancy for every change.

Software that is too large can move the problem from a lack of structure to difficulty in using the structure.

The criterion should be the minimum sufficient complexity: cover today’s real process well and leave room to grow, without buying years of functions that will not be used.

Data and integrations: the part that really costs

Software is only one component. A significant part of a TMS project concerns data.

Before implementation, it is worth establishing:

Master data. Who cleans up customers, addresses, vehicles, drivers, carriers and duplicate codes?

Data source. Does a customer address originate in the CRM, ERP or TMS? Who can change it?

Identifiers. Do the order, trip and document have consistent codes across systems?

Imports. Do existing files have stable columns, or does every customer use a different format?

APIs/EDI. Which flows are actually needed? Real time or batch?

Errors. What happens if an integration does not receive an order or receives it twice?

History. How much past data must be migrated? Everything, only master data, or the latest months?

Ownership. Can the business export its own data in a reusable format?

Poor data quality is not automatically resolved by a TMS: it is simply transferred into a more expensive system.

Digital documents and eFTI: why interoperability matters more and more

Regulation (EU) 2020/1056, on electronic freight transport information (eFTI), creates a European framework that allows economic operators to make certain regulatory information available to competent authorities in electronic form through platforms and services compliant with the eFTI framework.

The European Commission gives 9 July 2027 as the date from which the eFTI framework will be fully applicable and Member State authorities will have to accept information shared electronically by operators through certified eFTI platforms. From 2026, platforms and providers can prepare for operations along the path set out by the Commission.

This does not mean that every small business must buy an ‘eFTI TMS’ from 2027. It does mean that, when choosing a system today that is intended to last for years, it makes sense to ask the supplier:

• how it exports data;
• whether it provides APIs;
• how it handles standards and interoperability;
• what plans it has regarding eFTI developments;
• whether any functions declared ‘eFTI compliant/certified’ are actually supported by the required certification, where applicable.

European digitalisation is moving towards structured, exchangeable data. A closed archive from which it is difficult to retrieve your own data is therefore a greater risk than it was in the past.

How to evaluate a TMS without being led by the demo

A demo almost always shows the ideal path. Evaluation should instead use the company’s real cases.

Ask the supplier to simulate at least:

1. a standard order;
2. a collection with two deliveries;
3. a change after assignment;
4. a driver unavailable at the last minute;
5. an order imported from Excel;
6. a missing document;
7. a late delivery;
8. a cancelled trip;
9. an integration error;
10. the complete export of a period of activity.

Then measure:

• how many steps are needed;
• how much information is re-entered;
• who has to intervene;
• what the driver sees;
• what remains in the history;
• how errors are recovered.

Checklist

• Which process do we want to improve first?
• Is the product designed for an own fleet, a shipper or a freight forwarder?
• Does it really handle our type of order?
• Does it require modules we will not use?
• Is the plan understandable to operators?
• Are drivers and vehicles linked to orders?
• Is there a history of changes?
• Can data be exported in reusable formats?
• Are APIs included or charged separately?
• Which integrations are standard and which are projects?
• What costs exist beyond the licence?
• How long does implementation take?
• How are backups, security and continuity managed?
• Which functions are actually available today and which are on the roadmap?
• How is the evolution of eFTI addressed?