LTL Freight Software Problems: The 5 That Leak Margin, and How to Avoid Them

Why does the shipment data model break as soon as freight moves?

Because a shipment in this business is a tree and most systems store it as a row.

A pro number arrives with four handling units. Two get short shipped and follow the next day. One splits at breakbulk and travels on two different trailers. Another is reconsigned mid transit to a different consignee. Part of the shipment delivers Tuesday and the rest Thursday. Each of those is ordinary, and each of them breaks a model that assumes one record with a status and a destination.

The consequences show up everywhere downstream. You cannot say which trailer a specific pallet was on, so you cannot assign a damage claim to a hop. You cannot allocate linehaul cost accurately because the manifest and the shipment record disagree. Your customer service desk answers where is my freight with a terminal name rather than a location.

The model that survives is handling units as first class objects under a shipment, with custody events at every transfer: origin dock, linehaul trailer, breakbulk dock, delivery trailer. Every event carries a time, a terminal, a door, an operator and a device.

Screen for this in the first conversation. Ask a developer what happens to a pro number when a shipment splits at breakbulk. If the answer is a status change on one record, they will rebuild the data layer halfway through the project and charge you for it, and you will find out in month four.

What goes wrong with dimensioner and rating data specifically?

Three things, and they compound.

The first is timing, described above. If the measurement arrives after the invoice, you are not correcting a rate, you are asking a customer to accept a new charge after they have taken delivery, which is a dispute you frequently lose on relationship grounds even when you are right.

The second is provenance. Most systems treat dimensions as a field on the shipment, so a later value overwrites an earlier one and there is no record of who measured what, when, on which device. You cannot re rate cleanly against a field that has been overwritten, and you cannot defend a correction without the photograph, the timestamp and the operator.

The third is the integration itself. Dimensioner vendors differ enormously in what they expose. Some offer a clean interface. Others write to their own database and leave you a scheduled file drop, and a file drop that silently stops is the classic failure in this category, because nothing is waiting for it and the gap surfaces at month end.

Treat every measurement as an immutable event with capture time, terminal, door, operator, device serial, the photograph, the derived density and the calculated freight class. Fire it into rating within seconds of the pallet crossing the door, compare declared against actual, and open a correction with the photograph attached before the trailer is unloaded. Then require the integration to be monitored, with an alert when expected volume does not arrive.

Why does linehaul planning software get abandoned by the person who plans linehaul?

Because the rules that govern your network live in one person's head and the project never extracted them.

Your linehaul manager knows which lane can run direct on Tuesday and must hit the breakbulk on Friday, that a specific customer's flooring needs held space on the Thursday run, that the breakbulk backs up after a certain hour, and which driver will not take an early departure. None of that is in a system. A generic optimiser produces a plan violating three of those rules on its first run, he rebuilds it by hand, and the engine becomes a report nobody opens.

The second failure is planning against what has arrived rather than what will arrive. A plan built in the afternoon from freight on the dock is obsolete by the evening cutoff, which is why the supervisor rebuilds trailers in his head while trucks wait.

Do the extraction work first. Have the linehaul manager build one real week and narrate every decision into a document, then encode the network graph properly: terminals, lanes, breakbulk relationships, cutoffs, equipment pools, driver domicile, hazardous materials segregation. Make it re solve continuously rather than produce a single daily plan, so the evening rebuild takes seconds rather than a phone call. And run it in parallel with the existing spreadsheet for several weeks, using his overrides as tuning input, rather than cutting over on a Monday.

What happens when the dock is left uninstrumented?

Claims become negotiations rather than determinations, and you pay them.

Your dock creates overage, shortage and damage, cube waste and late departures, and it is usually the least instrumented part of the operation. A forklift operator sees a crushed corner on a shrink wrapped pallet. His scanner only accepts a pro number, so he tells a supervisor, who may or may not write it up, and eleven days later a concealed damage claim arrives with no evidence that the freight was already damaged when it reached you.

Bolt on mobile applications from the large transportation management vendors tend to be office screens delivered to a rugged handheld. They assume connectivity in a metal building, they make photograph capture awkward with gloves on, and their underlying model has a single status field, so they cannot distinguish damaged at origin from damaged in transit.

What works is offline first with a local queue so the operator never waits for a network, two taps to flag an exception, one tap to photograph, and a condition at handoff record written every time custody changes. Then when a claim arrives you can point to the specific hop where condition changed, which is the difference between paying and denying with evidence.

Scope this properly or leave it out entirely. A half built dock application that stalls waiting for signal is worse than a clipboard, because the crew stops trusting the whole system.

Should you build custom or stay on McLeod or TMW and buy hardware instead?

Buy, honestly, if you run three or fewer terminals and under roughly six hundred shipments a day. McLeod LoadMaster or TMW Suite with a good dimensioner will hold you, and your capital does better in a dimensioner and a second breakbulk door than in software. The complexity that makes a custom build pay is not there yet.

The stronger position for larger carriers is also a partial buy. Do not replace your transportation management system. Replacing McLeod is a multi year migration with a poor record, and it is genuinely competent at billing and general ledger integration. Build the margin layer beside it: dimensioning into rating, linehaul planning, dock capture and shipment level costing. Read from the incumbent freely and be careful about writing back, because write back is where schedules die.

The signals that justify building show up together. Your reweigh and inspection team is a headcount line and still catching only part of the density misses. Your linehaul plan lives in one spreadsheet. You added a terminal recently and the systems never absorbed it. Customers ask for programmatic access and you send a portal login. And the clearest tell of all is shadow tools: the database, the shared sheet with scripts, the messaging group where dock supervisors coordinate. Those are your requirements document, written by the people doing the work.

How do hidden costs get into an LTL software quote?

Five places. The first is terminal count, because each site has a different physical layout, a different door numbering scheme and its own opinions, and rollout is on site work rather than a configuration change.

The second is dimensioner integration quality. Ask the vendor for the specific interface before anyone quotes, because a documented interface and a scheduled file export are weeks apart in effort and years apart in reliability.

The third is electronic data interchange. A handful of transaction sets across a dozen trading partners, each with their own interpretation, is weeks of unglamorous work that gets quoted as one line.

The fourth is hazardous materials. Segregation rules, placarding logic and lithium battery restrictions change the shipment model, and retrofitting them into a model that did not anticipate them is expensive. Scope it explicitly at the start even if you carry very little.

The fifth is tariff logic that currently lives in a person. If your classing decisions depend on judgement that is not written down anywhere, extracting it is analysis work with your people's time in it, and it is nobody's line item until it is late.

What separates a build that pays for itself from one that stalls?

Three things. The first is that value lands in production early. Pick one loop, ship it properly and let it be measurable within a quarter. The dimensioner to rating loop with automated corrections and photographic evidence is usually the right first bet because reweigh capture is countable within weeks. A programme whose first delivery is a year away loses its sponsor before it lands.

The second is that the people who do the work were in the room. Dock supervisors, the linehaul manager and the reweigh team know the exceptions, and the shadow tools they built are a free specification. A build designed from an executive summary will produce a system your terminals route around, and you will hear about it late because nobody wants to say so.

The third is that you own the model. Your tariff logic, your cost allocation rules and your accumulated measurement history are the competitive asset, not the user interface. Get the repository, the deployment and the data in your name in the contract on day one rather than as a handoff at the end. Anything that leaves that inside a vendor's platform means renting your own margin, and the renewal conversation in year three will not favour you.