What WMS transport functions cover
Inside the WMS, transport already covers:
- Forecasted volumes from article dimensions, weight and palletisation rules
- Carrier selection through configurable algorithms: cost, destination, service level, fixed panel
- Transport pallet optimisation for minimum volume
- Freight pre-invoicing on the same master data
- Dock and appointment scheduling, slot reserved before picking starts
- Yard management (YMS), tracking trailers and vehicle movements across the yard, from gate check-in to dock assignment
None of this is bolted on. It runs on the data the WMS already owns: article dimensions and weight, plus the number of parcels or pallets estimated from the preparation rules, before a single item is picked.
A WMS knows every article it manages: its dimensions, its weight, how it stacks, how it palletises. That knowledge is what makes the transport side work.
Take an order for three washing machines and three packs of detergent. The WMS reads it as three pallets and one parcel. The carrier is selected, the freight pre-invoiced, the dock slot booked.
Picking hasn’t started yet.
On a fixed carrier panel, the algorithm decides. Nobody picks up a phone to reserve a pallet.
“The WMS produces the data. Either it uses that data itself, or it hands it over to a third-party system, but only when one is actually needed.” says Alban.
In practice: a shipper running three sites with no pure-player TMS handles carrier selection, freight invoicing and shipment scheduling inside the WMS, on top of the item data that already lives there.
WMS transport functions vs. a dedicated TMS
For years, the line between WMS and TMS was drawn tighter. A WMS handled the warehouse. A TMS handled transport.
Each side kept its scope, and a clean integration sat between them.
We see it moving.
Transport data lives in the WMS first. For extended-suite WMS, API and event-based integration is a real differentiator, letting us call specialists when customer needs go beyond the WMS itself. The TMS market itself has not consolidated.
Here is how we draw it now:
| Transport function | Where it sits in the WMS stack |
| Carrier selection on a fixed panel | Native |
| Carrier appointment scheduling | Native |
| Freight pre-invoicing | Native |
| Transport labels, CMR, manifests | Native |
| Multi-drop route optimisation (last-mile) | Called via API (PTV Logistics, others) |
| Real-time open-market carrier booking | Called via API (Shiptify, others) |
| Multi-modal freight sourcing | Pure-player TMS only |
Look at one row in particular. With WMS-native pre-invoicing, our customers reconcile carrier invoices within a 1% tolerance. It comes from getting the WMS & IT architecture right.
Some shippers have multi-modal flows or real freight-sourcing needs. For them, a pure-player TMS is the right tool, and we say so. We connect to it through events and APIs, and we let it run. Not the line a vendor wants to draw in a sales meeting. We draw it anyway.
Take one of our customers, a shipper running same-day and next-day van deliveries from a distribution centre south of Paris. Their Hardis WMS calls PTV Logistics, a route-optimisation specialist, because PTV solves multi-drop routing at a scale no WMS can match. The WMS does what PTV will never do. It holds the article master, the picking sequence, the dock plan, the customer order. PTV returns the D+0 and D+1 rounds. The WMS dispatches, executes and tracks.
Why TMS market fragmentation opens the door to WMS
Here is how we read the TMS market today: fragmented, with low entry barriers.
The top five vendors hold 28% (MarketsandMarkets, 2025), the 2026 Gartner Magic Quadrant evaluates 16 vendors, and hundreds more are active.
The market is at $18.5B today, projected at $37B by 2030. WiseTech bought E2open. Körber spun off MercuryGate, now Infios.
“There’s no entry barrier. Every logistics software editor sees there’s an opportunity, there’s a market, so they develop features and jump in.”
Five angles share the space. Each one is real.
- Start-ups grown from one pain point: Shiptify began with carrier appointment booking and stretched into a TMS. Sharp on the original problem, thinner elsewhere.
- Tier-one software suite vendors: SAP, Oracle, Infor invest on the multi-modal end. Useful for shippers who live in that complexity.
- European specialists: Transporeon, Alpega, TesiSquare hold deep niches, useful when local carrier networks and tariffs matter.
- Supply chain platform editors. Blue Yonder, Manhattan, Generix offer their TMS as best-of-breed, with suite integration always the question.
- WMS editors with native transport: Hardis Supply Chain sits here: transport functions built where the article data lives, with specialists called through APIs when needed.
Stacking a generic TMS on top of a WMS that already covers the need carries two risks: functional duplication and a data silo.
Why data still underpins everything
Strip away the features, the market analysis, the vendor categories. One question sits underneath. Who owns the data?
If you’ve read this far, you probably already know the answer.
Every transport decision sits on the same set of facts. The article master, the physical constraints, the palletisation outcome, the picking sequence, the dock plan. They are created in the warehouse, and they live in the WMS. They do not improve with travel. By the time they reach a TMS through an integration, they are at best a copy.
Alban puts it plainly:
“The WMS knows the items and their physical constraints. It can compute the forecasted volumes precisely, before physical preparation begins.”
That has always been true. What changed is that the WMS can now act on this data without handing it off. The functions are built. The integrations let it call a specialist when the work justifies one.
The asymmetry runs one way. A WMS can grow into TMS space because it owns the article data. No TMS can walk that path in reverse.
A mature WMS that talks transport speaks from where the data is born. That is why it no longer has to hesitate.