OMS vs WMS vs TMS: what each system does and where they meet
An OMS owns the customer order and its commitment, a WMS owns stock and work inside the warehouse, and a TMS owns the movement of freight between places. The three are often bought separately and described with the same words, which is why so many operations end up with three versions of the truth. This guide sets out where each one stops, how they hand work to one another, and how to decide which you need.
Updated · Kargentra product team
The short answer: OMS vs WMS vs TMS
An order management system (OMS) decides what has been promised to whom, a warehouse management system (WMS) manages stock and work inside a building, and a transportation management system (TMS) moves freight between places. Each owns a different record: the OMS owns the order, the WMS owns inventory and warehouse tasks, and the TMS owns shipments, loads and trips.
The three overlap at their edges, which is where most confusion starts. An order becomes warehouse demand when it is confirmed; warehouse work becomes transport demand when goods are staged; a delivered movement becomes a billing candidate when evidence is accepted. Treating any of those handoffs as automatic, or letting two systems write the same fact, produces the familiar symptoms: duplicated orders, phantom stock, trucks waiting for freight that is not ready, and invoices nobody can reconcile.
What an order management system does
An order management system captures customer demand, checks it, promises a delivery against real availability and governs every change until the order is fulfilled. It is the system that answers the customer question "what did you agree to deliver, and when?"
A modern OMS receives orders from several channels at once: operators, a customer portal, partner APIs, ERP connectors and EDI. It records where each order came from, validates it with a fixed set of rules, and checks availability before making a commitment. When the customer asks for a different date or a hold, the OMS records the request, the answer and the reason.
- Intake and validation: one canonical order, whatever the channel, with duplicates recognised as repeats rather than new orders.
- Available-to-promise: stock on hand, allocated, held and committed elsewhere netted into a promiseable quantity.
- Commitment: requested, proposed and committed dates stored as separate facts, with exactly one current commitment.
- Change, hold and cancel: governed requests with reasons, and a view of what a hold or cancellation would affect downstream.
- Fulfilment orchestration: which part of the order goes to which warehouse and which transport leg, and who owns the next step.
What a warehouse management system does
A warehouse management system controls the physical flow of goods and the authoritative stock position inside one or more facilities. It answers the question "what do we actually have, where is it, and what is it committed to?"
A WMS works from scans and tasks rather than from orders. It receives against an advance shipping notice or a purchase order, records discrepancies, directs putaway, holds stock by item, owner, lot and location, and releases outbound work as waves or continuously. It then runs picking, packing and staging until freight is ready to hand to transport. For 3PLs, it also keeps each client's stock and service charges separate.
The WMS keeps its own careful distinctions. Expected stock is not received stock; received stock is not available until inspection and putaway; available stock is not allocated until an order claims it. Most importantly, warehouse ready is not dispatch ready: goods staged at the dock still need a released movement, an eligible vehicle and a booked carrier.
What a transportation management system does
A transportation management system turns transport demand into sequenced, sourced, released and delivered movements, then hands the result to finance. It answers the question "how does this freight get there, with whom, at what cost, and did it arrive?"
The TMS forms shipments from orders or staged handling units, builds loads, sequences routes, compares private fleet with contracted and spot carriers, tenders, checks dispatch readiness, follows execution and recovers exceptions. Our guide to what a transportation management system is covers each step in detail. The yard sits at the boundary between WMS and TMS: gate check-in, dock assignment and dwell belong to the facility, while the vehicle and its trip belong to transport.
Two parts of the TMS are often mistaken for separate products. Tracking and exception management, sometimes sold as a logistics control tower, are only useful when they sit on the same movement record as dispatch and recovery. Freight audit and the billing handoff, the step that turns a delivered movement into a carrier bill to audit and a customer charge to invoice, belongs with the TMS for the same reason: it depends on the tender price, the accessorials recorded during execution and the accepted delivery evidence.
OMS vs WMS vs TMS side by side
Side by side, the three systems differ in the record they own, the question they answer and the people who use them. The comparison below is vendor-neutral; use it to check which system in your estate owns each row today.
Scroll sideways to see every column.
| Dimension | OMS | WMS | TMS |
|---|---|---|---|
| Record it owns | Order and commitment | Inventory, warehouse tasks, handling units | Shipment, load, trip, tender |
| Question it answers | What did we promise, to whom, by when? | What do we hold, where, and what is it for? | How does it move, with whom, at what cost? |
| Primary users | Customer service, order desk, account managers | Receivers, pickers, packers, warehouse supervisors | Planners, carrier managers, dispatchers, supervisors |
| Key states | Validated, confirmed, allocated, on hold, fulfilled | Expected, received, available, allocated, staged | Routed, tendered, booked, released, delivered |
| Typical inputs | Portal orders, APIs, ERP, EDI | ASNs, purchase orders, release requests | Transport demand, EDI 204 load tenders, carrier responses |
| Hands off to | WMS for fulfilment, TMS for transport demand | TMS when freight is ready for handoff | Finance when delivery evidence is accepted |
| Should not own | Warehouse tasks or carrier choice | Customer commitments or carrier tenders | Stock position or order acceptance |
Where the three systems hand off
The three systems hand off at four points, and each handoff should be an explicit, recorded event rather than an assumption. Which system owns the shipment? In most designs the TMS owns the shipment as a transport record, while the OMS keeps the order and its commitment, and the WMS keeps the handling units that make it up.
- Order confirmed to warehouse request. The OMS opens a fulfilment request with the warehouse; a hold on the order should refuse this step.
- Allocation to shipment formation. Allocated quantities become shipments; any remainder stays visible as unallocated rather than disappearing.
- Warehouse ready to transport handoff. The WMS declares staged freight ready for, or blocked from, transport handoff; the TMS plans and releases the movement.
- Delivery evidence to billing. Accepted proof of delivery feeds billing readiness, which also needs resolved exceptions and a governed charge.
Common gaps between separate systems
When the OMS, WMS and TMS come from different vendors, the gaps appear at the handoffs, not inside the systems. Each product can be excellent on its own and the operation still loses time reconciling them.
The fixes are design rules rather than features. Give each stage exactly one owning system. Make every exchange idempotent so that a resent message is recognised as a repeat. Label every external fact with its source and freshness. And refuse local writes on a stage another system owns, instead of quietly accepting both.
- Duplicated orders when a partner resends a message and the receiving system treats it as new.
- Stale readiness when the TMS reads a warehouse status that changed an hour ago.
- Conflicting dates when one system measures on-time against the requested date and another against the committed one.
- Two writers when an external TMS and a local screen can both dispatch the same movement.
- Lost remainders when a partial allocation forms one shipment and the rest of the order goes quiet.
Do you need an OMS, a WMS and a TMS?
You need the systems that match the work you actually perform; many organisations need two of the three, and some need all three connected. The useful question is not "which software category am I missing?" but "which stage of order-to-delivery is run on email today?"
Scroll sideways to see every column.
| Operating model | Usually needs | Why |
|---|---|---|
| Shipper with outsourced warehousing | OMS and TMS | Orders and transport are yours; the 3PL runs the WMS and reports readiness. |
| 3PL running warehouses and transport | WMS and TMS, often OMS | Client-owned stock, client policies and transport for many accounts. |
| Distribution and retail | All three | Promises to stores and customers depend on stock and on delivery windows. |
| Freight broker | TMS with quoting | No stock to manage; the work is quote, tender, margin and carrier performance. |
| Carrier or private fleet | TMS with fleet and driver tools | Assignment, driver hours, dispatch and proof of delivery. |
Questions to ask before you connect or replace a system
Before connecting or replacing any of the three systems, map who owns each stage today and what evidence each handoff carries. Most integration projects fail on ownership and timing, not on message formats, so settle these questions in writing before choosing software.
Common exchange mechanisms include REST APIs and signed webhooks for orders and status, EDI X12 204 load tenders from customers, advance shipping notices from suppliers, event streams for analytics, and ERP connectors for master data and finance. The Kargentra integrations overview lists the standards and mechanisms it supports.
- For each stage from order intake to billing readiness, which system writes and which only reads?
- When a message is resent, how does the receiver recognise it as a repeat rather than a new order or shipment?
- How fresh is each external fact, and what does the screen show when two sources disagree?
- Which date does each system use to measure on-time performance: requested, committed or the latest estimate?
- What happens to the unallocated remainder of a partly fulfilled order?
- Who is told, and how, when a stage owned by another system stops reporting?
How Kargentra connects order, warehouse and transport
Kargentra runs order, warehouse and transport management on one record, and each tenant decides which stages Kargentra runs and which stay in an existing system. The Process Composer in Kargentra Administration sets an owner for each of nine order-to-delivery stages, from order intake to billing readiness: Kargentra, an external system connected through governed data exchange, an external system updated by hand, or not applicable.
That choice is enforced, not just displayed. One effective-availability decision drives what the API permits, what the Effective Preview shows and what navigation renders, and a stage owned by an external system refuses local writes with an ownership conflict. The same order management system can run on its own beside an ERP, and the warehouse management system and transportation management system can each be sold alone or connected.
Across the handoffs, the order workbench shows allocated and remaining quantity per line, a warehouse leg and a transport leg for each shipment, and chips such as With the warehouse, Warehouse reports ready, Fulfilled outside Kargentra warehouse and Sources disagree. A hold sits on top of the order and refuses new steps, such as acceptance, shipment formation, warehouse open and dispatch release, without unwinding work already under way. Requested, proposed and committed dates are separate facts, and the database allows only one current commitment per order.