How to Unify TMS, ELD, and Dock Data Without Replacing Your TMS

Brokers and asset carriers already run mature systems. The real question is not whether to adopt yet another platform. It is how to unify TMS ELD and dock data without replacing your TMS, because ripping out a working stack just to see everything in one place is a multi-year migration that almost nobody finishes. Your TMS holds the order. Your ELD holds the truck. Your dock scheduler holds the appointment. Each one is right about its own slice and blind to the other two, and the person who reconciles them is a dispatcher on the phone.

Why does rip and replace keep failing?#

Rip and replace fails because the value you are chasing does not live inside any single system you could migrate to. US business logistics costs reached roughly 2.6 trillion dollars, about 8.7 percent of GDP, according to the Council of Supply Chain Management Professionals State of Logistics Report. A meaningful share of that number is friction: time spent reconciling systems that should already agree. The instinct is to fix it by buying one platform that does everything. The instinct is wrong, and it is wrong for a structural reason.

The margin leak is the gap between what the TMS says you billed and what the ELD says actually happened at the dock. The detention claim is the difference between the appointment time in the scheduler and the gate timestamps in the telematics. No new system of record contains that gap, because the gap is a relationship across systems, not a record in one of them. When you migrate everything into a new platform, you have spent eighteen months and a large budget to recreate the same silos with a different logo on them.

There is also the operational reality that a working TMS is load-bearing. It is wired into your accounting, your carrier payments, your customer integrations, and the muscle memory of every person who touches a load. Replacing it is open-heart surgery on a running business. Most teams that start the project quietly abandon it once they confront the cutover risk, and they are left with the original problem plus a year of sunk cost.

Which systems hold your shipment data, and why don't they agree?#

Three systems each hold an authoritative slice of every shipment and disagree on the details that cost money. To unify data you first have to respect what each one is right about and what it is blind to.

TMS: the system of record that is not the system of truth#

The TMS owns the commercial shape of the load. It knows the customer, the rate, the carrier, the lane, and the accessorials you agreed to. What it does not know is what physically happened. The pickup it shows as on-time is the time someone typed in, not the time the wheels rolled. Whether you tender to a mega-carrier like J.B. Hunt or a ten-truck fleet, the TMS is the system of record for intent and a poor system of truth for execution.

ELD: ground truth nobody reconciles#

The electronic logging device and the broader telematics feed are the closest thing the industry has to ground truth. They know where the truck was, when it arrived, how long it sat, and how much driving time the operator had left under the FMCSA hours-of-service rules in 49 CFR 395. The Bureau of Transportation Statistics, whose Freight Facts and Figures program tracks roughly 54 million tons of goods worth about 52 billion dollars moving every day across the network, depends on exactly this kind of operational data to describe how freight flows. Yet inside a single carrier or broker, that ELD ground truth is almost never reconciled against the TMS record it should confirm or contradict.

Dock and yard: the data that never leaves the building#

The dock scheduler and yard management system hold the appointment, the door assignment, the check-in, and the real dwell. This is where detention is born and most often lost, because the dwell data that proves a claim never leaves the facility software. As FreightWaves has documented in its coverage of data fragmentation in trucking, counterparties end up making decisions on gut instinct precisely because the reliable data is trapped in systems that do not talk to each other in real time.

Three systems, three partial truths, one shipment. The shipment is real. The fragmentation is an accident of how the software was bought.

What does data unification actually mean, and what does it not mean?#

Data unification means connecting the systems you run and resolving their records to one shared shipment, not copying everyone into a new database that then argues with the originals. It does not mean a dashboard that embeds three other dashboards in tabs, and it does not mean a one-time export that is stale the moment it finishes.

Unification means three specific things working together. First, a live connection to each system you already run, through its API, pulling records as they change. Second, a resolution step that recognizes when a TMS load, an ELD trip, and a dock appointment are describing the same physical shipment, and binds them to one shared record. Third, and most important, a guarantee that the shared record never hides where a value came from. Every field on the unified shipment links back to the exact system and record that produced it.

That third requirement is the one most products skip, and it is the one that matters most. A unified number you cannot trace is just another number to distrust. A unified number with its source attached is something an operator will act on, and something a customer will accept in a dispute. This is the principle the entire Mithrilis platform is built around, and the reason we wrote it into our manifesto: you should be able to verify every result.

How do you unify TMS, ELD, and dock data without replacing your TMS?#

You unify without replacing by connecting through the interfaces your systems already expose, resolving their records to a shared shipment, and keeping every source visible. The practical path has three stages, and none of them touch the inside of your existing systems.

1. Connect, do not migrate#

Start by connecting to the systems through the interfaces they already expose. Modern TMS platforms, ELD providers, and dock schedulers all have APIs or event feeds. The connection reads from them. It does not write a new schema into them, it does not ask your team to change how they enter loads, and it does not require a cutover weekend. If a connector breaks, the underlying system keeps running exactly as before, because nothing about your operation was moved. This is the difference between adding a lens and swapping an engine.

2. Resolve to a shared shipment record#

Connection alone gives you three feeds that still do not know they are about the same load. The resolution step is the actual work. It matches a TMS load number to an ELD trip to a dock appointment using the identifiers and timing they share, and it builds one shipment record that points at all three. Done well, this is where the join you were chasing finally exists as a first-class object instead of living in a dispatcher's head. The harder cases, where identifiers disagree or a carrier used a different reference, are exactly the cases that were costing you money in the manual process.

3. Keep the source visible on every field#

The resolved shipment then carries every contributing source with it. The billed pickup time shows the TMS value and the ELD gate timestamp side by side. The dwell shows the appointment from the scheduler and the measured sit time from telematics. Nothing is overwritten, nothing is hidden, and disagreements between systems are surfaced rather than silently averaged away. The disagreements are the signal. They are where margin leaks, detention claims, and exception cascades come from.

Where does the money actually leak when your systems don't talk?#

The money leaks in the space between systems, where each one is individually correct and no one is looking at the join. Consider a broker moving forty loads a month out of a single produce shipper in California's Central Valley. The TMS shows those loads as profitable. The rate was good, the carrier was paid fairly, and the accessorial column is mostly empty. By the commercial record, this is a healthy lane that nobody would think to question.

Now bring in the other two systems. The telematics data shows that trucks arriving at that shipper sit an average of three hours and forty minutes before they are loaded, well past the two free hours the contract allows and deep into the driver's hours-of-service clock. The dock scheduler confirms it: appointments slip, doors are not ready, and the gate timestamps tell the same story every week. None of that dwell ever became a detention invoice, because the person who could have filed it never saw the three systems together. The TMS said the load was fine, and the TMS was the only screen anyone looked at.

The leak here is not a billing error. It is an invisibility error. Each individual system behaved correctly. The TMS recorded the commercial terms accurately. The ELD recorded the dwell accurately. The dock scheduler recorded the appointments accurately. The money left the building in the space between them, where no system was looking and no person had the full picture without making three phone calls per load, which at forty loads a month nobody actually does.

Once those systems resolve to a shared shipment record, the same lane tells a different story. The unified dwell view flags the shipper as a repeat offender, with the gate timestamps and the appointment record sitting next to the contracted free time. The pattern is no longer a feeling a dispatcher has. It is a number with its sources attached, ready to support a detention claim or a rate renegotiation at renewal. The broker did not work harder. The broker could finally see what was already true.

What can you see once TMS, ELD, and dock data are unified?#

Once the three systems resolve to one record, you can see true dwell, true margin, and cross-shipper patterns that no single tool could surface. This maps directly to what we call SEE mode: show me what I am missing.

True dwell becomes visible per shipment and per facility, which means a detention claim has its evidence chain already assembled instead of being reconstructed after the fact. True margin becomes visible because the accessorials in the TMS are reconciled against what the ELD and dock data say actually happened, so the number reflects reality rather than intent. Patterns across the connected set become visible, like which shippers consistently run long on dwell or which lanes quietly erode margin, because for the first time the data is in one place to be compared.

For freight brokers, the immediate win is margin and claims defensibility. For asset carriers, the same unified record exposes utilization, deadhead, and driver-level signals that were split across dispatch, telematics, and payroll. The data patterns differ between the two, but the structural problem and its solution are identical: connect the systems you have, resolve them to a shared record, and keep the sources visible.

None of this required replacing the TMS. The TMS is still the system of record for the commercial load, exactly as it should be. What changed is that it is no longer the only thing you can see, and it is no longer asked to be a source of truth about events it never witnessed. You added intelligence on top of connected data instead of automating around a silo.

How Mithrilis turns the systems you already run into one source of truth#

Mithrilis is a logistics intelligence platform built on a simple recognition: the visibility problem in freight is, underneath, a data problem. Its job is to give a broker or asset carrier one trusted, normalized, linked view of every shipment that moves through your operation, so the answers you pull produce decisions instead of debates.

The foundation is the unification engine. It connects to your TMS, ELD, dock scheduler, and accounting system through the interfaces they already expose, resolves their records into one shipment where a tender connects to its gate timestamps connects to its accessorials connects to its invoice, and keeps every field linked back to the system that produced it.

Atlas sits on top of that foundation. It lets anyone on your team ask questions of your logistics data in plain English, with the sources shown on every answer, so finance and operations stop waiting on a report and stop arguing over whose number is right.

See what it looks like on your own data. Request a demo, bring the systems you run today, and watch them resolve into one record you can finally trust.

Related Mithrilis capabilities

• The Mithrilis platform

  How connected data becomes verifiable intelligence.

• For freight brokers

  Margin and claims defensibility from a unified shipment record.

• For asset carriers

  Utilization and deadhead signals across dispatch, telematics, and payroll.

Frequently asked questions

What is logistics data unification?

It is the practice of connecting the separate systems that describe a shipment, the TMS, the ELD or telematics feed, and the dock or yard scheduler, and resolving their records into one shared shipment record while keeping every original source visible. It is a connection and resolution layer, not a new database that everyone migrates into.

Do I have to replace my TMS to unify my freight data?

No. The entire point of the connect-and-resolve approach is that your TMS, ELD, and dock systems stay exactly where they are. Unification reads from them through their existing APIs and builds a shared record on top. Nothing is migrated and there is no cutover weekend.

How is this different from a TMS data warehouse?

A data warehouse copies records into a central store on a schedule, which means the data is a stale snapshot and usually loses the link back to its source. Unification keeps a live connection and preserves source visibility on every field, so you can trace any value back to the system that produced it and trust it in a dispute.

What does freight data integration miss that unification solves?

Integration usually means moving data from system A into system B. That still leaves you reconciling. Unification adds the resolution step that recognizes when records across systems describe the same physical shipment and binds them together, which is where the margin and detention answers actually live.

How long does it take to unify TMS, ELD, and dock data?

Because nothing is migrated, the timeline is driven by connecting the systems and validating the resolution logic, which is measured in weeks rather than the multi-year horizon of a rip-and-replace platform migration. Your existing operation keeps running unchanged the entire time.