What Your TMS Doesn’t Tell You | Cleo

Freight Order Execution

What Your TMS Doesn’t Tell You

A dispatcher opens the TMS home screen Monday morning. Every active load is there with its current status. Nothing is flagged. The screen is green.

Three things are already wrong. How does that happen?

A truck that sat four hours at a receiver on Friday generated detention the carrier will never bill for. A slow unload at the second stop has quietly made tomorrow's first appointment unreachable. And on a third load, every status arrived and every status was accepted, in an order that never happened. None of them look like a problem, because the TMS recorded exactly what it received. Recording it and interpreting it are two different jobs.

The costliest freight problems usually aren't single-load status questions with a yes or no answer. They are comparisons:

This timestamp against that one
This stop against the next commitment
This event against the sequence it should have followed
This week's activity against what normal looks like for that facility

Nothing on the screen answers those questions, so nobody asks them until the revenue is gone or the customer calls.

Your TMS Is Doing Exactly What It Was Built To Do

A TMS plans, dispatches, executes, records, and supports billing. It isn't built to compare across transactions, stops, commitments, and elapsed time. The failures in each scenario are not the TMS's fault. Nobody bought the wrong system. The operation simply needs a layer of intelligence a TMS was never designed to provide.

The difference shows up in the question being asked. A TMS answers "what is the status of this load?" and it answers accurately. The questions that actually cost money sound similar but are not the same question:

How long has this truck been sitting, and does that cross a billable threshold?
Does the transit time left still support tomorrow's appointment?
Did these events arrive in an order that makes sense?
Is this facility slower this month than it was last month?

Every one of those requires holding two or more facts side by side and judging the distance between them. A system of record is built to store facts accurately, not to analyze data to see what they add up to. So the information sits there, correct and complete, waiting for someone to notice.

Usually nobody does, because there is no reason to look. The load isn't flagged. It looks green like all the others.

Scenario 1: A Long Stop Can Mean Missed Detention Revenue

A truck arrives at a receiver at 10 a.m. and leaves at 2 p.m. The TMS records both times correctly. Arrival, departure, delivery complete. Nothing about that load is inaccurate or incomplete.

But the contract says detention starts accruing after two hours of free time. Two of those four hours are billable, and the only way to know that is to subtract one timestamp from the other and compare the result against the terms for that customer. The TMS holds both timestamps. It just has no reason to do the math, because that isn't the question it was built to answer.

So the invoice goes out for linehaul and accessorials that someone happened to catch. The detention doesn't appear on it. Not because it was disputed and lost, but because it was never claimed.

The pattern repeats quietly. A dozen loads a week, a few billable hours each, at a rate the carrier already negotiated and is entitled to collect. None of it shows up as a loss, because you can't miss revenue you never knew you had. It looks like a normal week.

The same four hours cost twice, too. Whatever that truck was scheduled to do next just lost half a day of margin, which takes us to the next scenario.

Scenario 2: A Late Stop This Morning Is A Missed Appointment Tomorrow

Stop two runs long. The facility is slow, the dock is backed up, and the driver leaves two hours behind plan. The TMS records the departure and the load moves on. Still no flag, because nothing has technically gone wrong yet.

The problem isn't the current stop. It's the next commitment. Between here and tomorrow's delivery window there is a fixed amount of drive time, a required break, and a receiver that only takes freight between 7 and 11 a.m. Two hours ago that math worked. It doesn't anymore.

Knowing that means comparing three things the TMS holds in separate places:

Where the truck is now
How long the remaining run actually takes, and
What was promised to the customer

Nobody is doing that comparison at 2 p.m. on a Tuesday for a load that isn't late yet.

So it surfaces the next morning, when the truck rolls up outside the window and gets turned away. Now it's a reschedule, a second trip, a driver burning hours in a parking lot, and a customer who found out from their own dock instead of from you.

The delay itself may have been unavoidable. Slow facilities are slow. But the last-minute phone call is a choice, and it's the part that damages the relationship. Two hours of warning turns the same delay into a rescheduled appointment that everyone can prepare for.

Scenario 3: Every Status Is Valid, But The Story Is Wrong

The first two scenarios assume the data arrived cleanly. Often it doesn't, and that failure is harder to see because every individual transaction passes inspection.

A driver arrives and departs within minutes of each other, and both events get stamped at nearly the same time. A partner sends status updates in a nightly batch, so events that happened hours apart land together and potentially out of order. A terminal status like "delivered" comes in early, and the milestones that should have preceded it get rejected because the load is already closed.

Each of those transactions is individually valid. The codes are right, the format is right, the load ID matches. Nothing errors out. But the sequence they form no longer describes what happened on the road, and everything downstream inherits that version of events: the dwell calculation, the on-time percentage, the scorecard you show that customer at the quarterly review.

This is the failure mode that survives an audit. Someone asks why the numbers look off, pulls the load, and finds every status present and accounted for. The gap isn't a missing transaction. It's that no one was checking whether the transactions told a story that made sense.

Integration Moves The Data. Something Has To Read It.

The instinct at this point is to add another system. That is usually the wrong read, because the systems already in place are each doing their job.

The TMS manages transportation execution: plan the load, dispatch it, record what happened, support the invoice. EDI moves freight transactions between you and your partners, so the tender, the status updates, and the invoice arrive in a format both sides can process. Visibility tools show where the truck is and when it's expected to arrive.

Every one of those is necessary, and none of them is the layer that was missing in the last three scenarios. Integration delivers the data. Visibility displays it. Neither one is responsible for continuously analyzing it and deducing what it means.

That's the job of the next layer: interpreting events as they arrive against the commitments on the load, the history of that lane and that facility, and the sequence a normal delivery follows.

So, four hours of dwell becomes a billable exception. Two hours lost at stop two becomes an at-risk appointment you can still move. Out-of-order milestones become a data quality flag before they impact the performance scorecard.

Same data the operation already has, in the systems it already runs. The difference is that something is finally connecting the dots.

From Monitoring Every Load To Managing The Exceptions

Most operations already know these gaps exist. They just close them with people instead of software.

Someone refreshes the board every twenty minutes. Someone else logs into three customer portals to check appointment times. A third person scrolls EDI logs looking for transactions that didn't land. Dispatchers make check calls. A report runs Monday morning and gets read by whoever has time. It works, in the sense that problems do get caught, but the catching depends on who is looking and how busy the day is.

The cost isn't only the hours. It's that attention gets spread evenly across every load, when almost all of them are fine. A team watching two hundred moves is spending most of its effort confirming that nothing is wrong, which leaves less time for the eight exceptions that need a phone call today.

Managing by exception reverses that. Instead of reviewing every load to find the few that need attention, the loads that deviated from what was planned, promised, or normal come to you.

Same team, Same team, same headcount, but their time goes only to the loads that need it.

How Freight Order Execution Handles It

Freight Order Execution is the layer that interprets freight data rather than simply recording it or moving it. It reads every event tied to a freight order as that event arrives, compares it against what was planned, what was promised, and what normal looks like for that lane and facility, and surfaces the orders that no longer match. The TMS remains the system of record. EDI still moves the transactions. The Freight Order Execution layer determines what all of it means.

Cleo Freight Order Execution is an add-on to Cleo Integration Cloud, the platform already moving those EDI and API transactions between you and your partners. CIC moves the data. Freight Order Execution reads it. So for operations already using CIC, there's no new integration to build. Enabling it is a platform setting that you turn on in minutes, rather than requiring an entire implementation project.

Together, they tell the team which orders need a human today. Six capabilities do that work.

Connected Freight Order View

Every transaction, status, and stop for a single move assembled into one record, instead of the tender in one system, the status updates in another, and the invoice in a third. The comparisons in this post are only possible once the pieces sit in the same place.

Stop-Level Planned Vs. Actual

Each stop carries what was supposed to happen and what did, including dwell. The four-hour stop from Scenario 1 shows up as four hours against a two-hour allowance, not as two accurate timestamps nobody subtracted.

Proactive Risk Notifications

When elapsed time and remaining transit stop supporting the next commitment, the order surfaces while there is still room to move the appointment. That's Scenario 2 caught on Tuesday afternoon instead of Wednesday morning.

Anomaly Detection

Sequences that don't make sense, events that arrive together when they happened hours apart, milestones rejected after a terminal status. Flagged as a data quality problem before the numbers reach a customer conversation.

Freight Execution Insights

Pattern recognition across loads and lanes rather than one order at a time. Which facilities run long, which lanes slip, where the same exception keeps repeating.

Trading Partner Scorecards

Performance by partner, built from the same interpreted events, so the quarterly review starts from a shared record instead of two sides comparing spreadsheets.

None of this asks the operation to move off its TMS. The TMS keeps doing what it was built to do. This is the additional layer that reads the output and determines what deserves attention.

FAQs

Can A TMS Detect An Appointment Risk Before The Appointment Is Missed?

Usually not on its own. A TMS records that stop two ran long, and it holds the appointment window for the next stop, but the two facts live in different places and nothing continuously compares them.

Detecting the risk means recalculating whether the remaining transit time still supports the promised window every time a new event lands. Some platforms offer ETA features through a visibility integration, which helps, though the ETA still has to be measured against the commitment and turned into an alert someone acts on. That comparison is the interpretation layer, not the record.

Doesn't My TMS Already Have EDI?

Some do, and that's a different capability than the one this blog describes. EDI moves freight transactions between you and your partners in a format both sides can process. It gets the data to you. It doesn't read across those transactions to decide what they add up to.

It's also worth being clear about what an embedded EDI module usually is. In most TMS platforms with EDI, it was added to check a box. So the TMS covers a narrow set of EDI transaction sets, works with the partners the vendor already built maps for, and sends every new onboarding or spec change back through that vendor's queue. When something fails, it fails into a log instead of into someone's day. That's a real constraint, and it's a separate one from the gap described here.

Every scenario above assumes the EDI worked correctly and the transactions arrived. The gap opens after that.

Does Freight Order Execution Replace My TMS?

No. It runs alongside the TMS and reads what the TMS and your EDI connections produce. Planning, dispatch, execution, and billing stay where they are. Nothing about the way loads get tendered or invoiced changes.

What EDI Transactions Support These Insights?

Mostly the ones already flowing in a motor carrier operation. The 204 carries the tender, including stop sequence and appointment windows, which is the "planned" side of every comparison. The 990 records whether the load was accepted. The 214 carries shipment status, including arrival and departure events at each stop, which is where dwell time and out-of-sequence milestones come from. The 210 carries the invoice, where an unclaimed detention charge shows up as revenue that was never billed. The 997 acknowledges receipt, so a missing one points to a transaction that never landed.

Dwell comes from arrival and departure pairs in the 214. Appointment risk comes from 214 events measured against the windows in the 204. Sequence anomalies come from the order and timing of the 214s themselves.

Is Freight Order Execution A Separate Product?

It's an add-on to Cleo Integration Cloud. If you already run CIC for EDI and API integration, Freight Order Execution layers on top of the transactions flowing through it, and because the context it needs is already there, it can be turned on in minutes. If you don't, the integration layer comes with it, since interpreting freight events requires the events first.

The Loads That Look Fine

The loads that need attention aren't always the ones showing an error. They're the ones where the data no longer adds up. Your TMS already has the data. Cleo already has the context. Freight Order Execution turns it into a signal.

Schedule a personalized demo with a solutions architect to see which of your loads those are, using your lanes and your trading partners. Or reach out to our team at sales@cleo.com to learn more.