LTL Freight Software: Fixing the Terminal, Linehaul and Dimensioning Problems Off-the-Shelf TMS Leaves Behind

Why LTL freight software makes or breaks a carrier

A regional LTL carrier with nine terminals and 1,800 shipments a day is running a business where the software decides the margin, not the drivers. The rating engine decides whether a 48x40x62 pallet of foam insulation bills as class 175 or class 70. The load planner decides whether the 8pm linehaul to the breakbulk leaves at 68 percent cube or 91 percent. The dock app decides whether the forklift operator scans the pro number at the pallet or writes it on a clipboard and keys it in at 11pm from memory.

Most carriers at this size are running a mix: McLeod LoadMaster or TMW Suite for the core, an Ancra or Cargo Spectre dimensioner bolted onto the inbound door, SMC3 CzarLite or RateWare for the tariff, a homegrown Access database that nobody wants to touch for linehaul planning, and a lot of Excel. The dimensioner captures a perfect 62-inch height. The rating engine never sees it because the integration was scoped as a nightly CSV drop, so the shipment bills at the customer-declared 48 inches and the reweigh and inspection team catches it four days later, if at all. In the carriers we have audited, the density misses nobody catches add up to a four-figure daily number. Nobody puts it on a slide, because no single system owns it, which is exactly why it survives.

The scene that repeats in every terminal we have worked in: it is 6:40pm at the Charlotte dock, the linehaul to Atlanta is scheduled for 7:15, and the dock supervisor is standing between two trailers with a printed load plan from the Access database that was built at 4pm. Three shipments on that plan never showed. Two heavy freight-all-kinds shipments showed up that were not on it. He rebuilds the trailer in his head, calls the Atlanta terminal manager, and the truck leaves at 7:52 with 71 percent cube utilization. The TMS records that it left. It records nothing about why it was late or half empty, so the same thing happens tomorrow.

Problem 1: The dimensioner captures the truth and your rating engine never hears it

You spent six figures on a forklift-mounted or freestanding dimensioner. It produces a length, width, height, weight and a photo per handling unit in about two seconds. Then the data goes somewhere useless. In most carriers we have audited, the dimensioner writes to its own vendor database, exports a nightly file, and by the time the reweigh and inspection team reconciles it, the invoice is already out and the customer disputes the correction because you are asking them to accept a charge four days after delivery.

McLeod and TMW cannot fix this because their rating call happens at pickup or bill entry, before the freight physically arrives at your dock. Their data model treats dimensions as a field on the shipment, not as a time-stamped measurement event with provenance, a photo and a confidence score. You cannot re-rate cleanly against a field that has been overwritten.

A custom build treats every measurement as an immutable event: capture time, terminal, door, operator badge, device serial, the photo, the derived density and the calculated NMFC class. That event fires a webhook into the rating service within seconds of the pallet crossing the door. The system compares declared versus actual, computes the delta in dollars, and if the delta clears a threshold you set, say $25, it opens a correction with the photo attached before the trailer is even unloaded. The customer gets the dispute evidence in the same email as the correction. You stop arguing and start showing. A vision model on the dimensioner photo also does real work here: it flags freight that is clearly not what the BOL says, a pallet of stacked tires billed as auto parts class 85, and routes it to the inspector's queue instead of making him walk the whole dock.

Problem 2: Linehaul planning is a person, not a system, and that person goes on vacation

Ask a carrier who builds the linehaul plan and you get a name. Usually a linehaul manager with 18 years in and a spreadsheet with tabs he built himself. He knows that the Thursday Atlanta run needs to hold space for the Greenville flooring customer, that the Nashville driver will not take the 4am departure, and that the breakbulk in Memphis backs up after 9pm. None of that is in a system. When he retires, you lose cube utilization for a year while someone rebuilds his instincts.

Off-the-shelf TMS load planning modules assume truckload thinking: a load, an origin, a destination. LTL linehaul is a network flow problem with breakbulk hops, cutoff times, trailer type constraints, hazmat segregation rules, driver hours, and freight that has not physically arrived yet. TMW and McLeod will let you record the plan. They will not build it, because they do not model your specific network topology, your service commitments by lane, or the fact that your Charlotte to Atlanta run can go direct on Tuesday but must hit the breakbulk on Friday.

A custom linehaul planner starts from your actual network graph: terminals, lanes, breakbulk relationships, cutoffs, equipment pools, driver domicile. It ingests inbound shipment forecasts, not just what has arrived, and it re-solves continuously. At 4pm it gives the supervisor a plan. At 6:40pm when three shipments are missing and two heavy ones showed, it re-solves in under ten seconds and reprints. The forecasting piece is where AI does concrete work rather than demo work: a model trained on your own two years of pickup history predicts, by 2pm, what will actually arrive on the dock by 6pm per lane, per customer, with a confidence band. That turns the 4pm plan from a guess into a plan. Carriers we have shipped this for move cube utilization by 4 to 9 points, and at 1,800 shipments a day that is measured in trucks you did not have to run.

Problem 3: The dock knows what happened and the office finds out tomorrow

Your dock is where OS&D, damage claims, cube waste and late departures are created, and it is the least instrumented part of your operation. The forklift operator sees a shrink-wrapped pallet with a torn corner and a crushed edge. He is holding a scanner that only lets him scan a pro number. So he tells his supervisor, who maybe writes it up, or maybe the freight goes on the trailer and becomes a $1,900 concealed damage claim in eleven days when the receiver opens it.

Bolt-on mobile dock apps from the big TMS vendors are usually a thin wrapper around bill entry. They were designed for the office user and shipped to a rugged handheld. They do not work offline in a metal building with dead spots, they do not take photos well with gloves on, and they do not know the difference between "damaged at origin" and "damaged in transit" because the underlying data model has one status field.

What a custom dock app does: it is offline-first with a local queue that syncs when the device finds signal, so the operator never waits. Scanning a pro opens a screen with two taps to flag exception, one tap to shoot a photo, and it writes a condition-at-handoff record every single time the freight changes custody, origin dock, linehaul trailer, breakbulk dock, delivery trailer. Now when the claim comes in, you can point to the exact hop where condition changed. That is the difference between paying the claim and denying it with evidence. One carrier we built this for cut concealed damage payouts by roughly a third in the first two quarters, purely because they could prove the freight left their dock clean.

Problem 4: Customer quoting and after-hours booking is a phone call you did not answer

Your customer service desk closes at 6pm. A shipper's warehouse manager finishes his day at 6:30 and needs a rate and a pickup for tomorrow. He calls you, gets voicemail, calls the other carrier, gets a human. You lost the shipment and you never knew it existed. Meanwhile during the day, your CSRs are keying BOLs from PDFs and faxes because a third of your small shippers will never touch an EDI 204 or a portal.

The incumbent portals shipped with McLeod or TMW exist and technically work. They also assume the shipper knows their NMFC class, which they do not, so the quote comes back wrong, gets re-rated after dimensioning, and now your customer thinks you bait and switch. That is a data model problem the vendor cannot solve for you because correct classing depends on your tariff, your customer's actual freight, and your reweigh history with them.

A custom build does two things here. First, document extraction: an AI pipeline reads the PDF or emailed BOL, pulls shipper, consignee, pieces, weight, dimensions and commodity description, and pre-fills the shipment for a CSR to confirm in six seconds instead of keying for ninety. Once tuned on your own document mix it is accurate enough to be a real time saver, and you keep the human confirm step because the cost of a wrong pro number is higher than the cost of a click. Second, an after-hours booking agent that quotes from your live tariff, asks the two or three questions that actually determine class for that commodity, checks lane capacity against the linehaul plan, and books the pickup. It is not answering philosophy questions. It is quoting freight against rules you wrote, which is a bounded problem these models handle well.

Problem 5: You cannot answer "what did that lane actually cost us" for six weeks

The CFO asks what the Charlotte to Birmingham lane made last month. Somebody exports from McLeod, exports the fuel from the card provider, pulls driver pay from the payroll system, guesses at the linehaul allocation, and produces a number in a spreadsheet three weeks later that everyone quietly distrusts. So you keep running lanes that lose money and you price renewals on feel.

The reason off-the-shelf cannot fix this is not that the reports are bad. It is that the cost data lives in four systems with no shared shipment-level key, and the allocation logic, how you split a linehaul trailer's cost across the 34 shipments on it, is a business decision unique to you. No vendor will encode your allocation model.

A custom costing layer sits on top and assigns cost at the shipment level in near real time: pickup cost from the P&D route's actual stops and time, linehaul cost allocated by cube and weight across the actual trailer manifest, breakbulk handling cost per handling unit, delivery cost from the route. Now the lane P&L is a dashboard, not a project, and when the customer wants a 4 percent rate reduction at renewal you know within a day whether that lane survives it. Pair it with per-customer profitability that includes their reweigh correction rate, their detention, their redelivery rate, and you find the two accounts that look like your biggest customers and are actually your biggest losses.

What this actually costs and how long it takes

These are Digital Heroes delivery numbers across 2,000+ projects, not industry averages. A focused first release, one of the loops above done properly and in production, typically lands at $60k to $130k and ships in 12 to 16 weeks. The dimensioner-to-rating loop with corrections and photo evidence usually sits at the lower end. The linehaul planner with forecasting sits higher because the optimization and the data prep are real work. A full platform, dock, linehaul, costing, customer portal, AI booking, runs $150k to $400k phased across 6 to 12 months, and we will not quote it as one release because you should have value in production by week 14 or the project is structured wrong.

What pushes an LTL build up the range specifically: the number of terminals with different physical layouts and processes, because each one has an opinion. Dimensioner vendor integration quality, some expose a clean API, some expose a Windows share with CSVs and a prayer. Whether your tariff logic lives in SMC3 or in someone's head. EDI depth, 204/210/214/990 with a dozen trading partners each with their own quirks is weeks of work nobody enjoys. Hazmat and lithium battery segregation rules if you carry them. And integration with an incumbent TMS you are keeping, because reading from McLeod is fine and writing back to it is where schedules go to die.

Build versus buy: take a position

Buy, honestly, if you run three or fewer terminals and under about 600 shipments a day. McLeod LoadMaster or TMW with a decent dimensioner will hold you, and your money is better spent on the dimensioner and a second breakbulk door than on software. The complexity that makes custom pay off is not there yet.

Build when these signals show up, and they show up together. Your reweigh and inspection team is a headcount line item and still catching only a fraction of density misses. Your linehaul plan lives in one person's spreadsheet. You have added a terminal in the last two years and your systems did not really absorb it. Your customers ask for API access and you send them a portal login. And the tell that matters most: your operations people have built shadow tools, an Access database, a Google Sheet with scripts, a WhatsApp group where dock supervisors coordinate, because the real system does not do the thing. Shadow tools are your requirements document, written by the people who do the work, for free.

The strongest position: do not replace your TMS. Replacing McLeod is a two-year project with a bad ending. Build the margin layer on top of it, dimensioning to rating, linehaul planning, dock capture, shipment-level costing, and let the TMS keep doing billing and the general ledger integration it is fine at. That is a $60k to $130k first bet with a payback you can measure in reweigh capture within one quarter, not a bet-the-company migration.

How to choose a developer for LTL freight software

Ask them to explain NMFC class versus density-based rating without you helping. If they cannot describe why a 48x40x62 pallet at 190 pounds is a different animal than the same pallet at 900 pounds, they are going to model your shipments wrong and you will find out in month four. This is the fastest filter there is.

Ask what happens to a pro number when a shipment splits at breakbulk. The answer tells you whether they understand that LTL shipments are trees, not rows. Handling units, sub-pros, partial delivery, reconsignment. A team that models a shipment as one record will rebuild the data layer halfway through and charge you for it.

Make them name the dimensioner and TMS integrations they have actually shipped, and ask what broke. Ancra, Cargo Spectre, Freight Snap, McLeod, TMW, SMC3 RateWare. The honest answer is always a story about a CSV drop that silently stopped or a rate call that timed out at 200ms and blew up bill entry. If they have no war stories, they have no production experience in this category.

Confirm you own the code, the repository and the deployment on day one, in the contract, not as a handoff at the end. In this category the data model is your competitive advantage, your tariff logic and your allocation model and your two years of reweigh history. Any arrangement where that lives in a vendor's multi-tenant platform means you are renting your own margin, and the renewal conversation in year three will not go your way.