TMS Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does a TMS build turn into a full system replacement?

Because the pain that starts the conversation is diffuse. Quoting is slow, tendering is a phone relay, settlement leaks and the per seat bill keeps growing, so the natural response is to scope one project that fixes all of it. In freight that instinct is unusually costly, because settlement and accounting sit at the end of a chain that touches every trading partner you have.

The specific trap is carrier payment. Once settlement is in release one, you need the rate confirmation, the proof of delivery, the carrier invoice arriving by EDI 210 or document capture, your accessorial schedules, your accounting integration and a reconciliation your controller will sign off. None of that can ship until all of it works, and none of it saves a coordinator an hour on the day it goes live. Meanwhile the rate desk is still building quotes in Outlook.

The fix is sequencing that follows the hours. Release one is the rating engine, load management, the tender waterfall and status capture for one mode. That is where the daily leak sits and it can be in production in 12 to 16 weeks while the legacy TMS keeps doing billing untouched. Settlement, freight audit and the customer portal come in phase two, by which point your data model has survived real freight and you know whether stops, legs and charges were modelled correctly. Cutting over quoting is reversible in an afternoon. Cutting over carrier payment is not.

What goes wrong when you extract data from a legacy TMS?

Legacy platforms rarely give you direct database access, so migration works from scheduled report exports, and report exports are shaped for humans rather than for systems. That difference produces three predictable problems.

The first is that rate tables come out flattened. A contract rate with an accessorial schedule, a fuel surcharge basis and effective dates often exports as one line with the current effective rate, which means your new rating engine inherits today and loses history. If you cannot reproduce what you charged a customer in March, you cannot defend a chargeback in June. Ask for the export format before you sign, not after.

The second is carrier identity. Ten years of lane history contains the same 40 truck fleet entered four times with different spellings, different motor carrier numbers where one was a predecessor authority, and remit addresses that changed twice. If you load it as is, your carrier performance data is worthless on day one and your team stops trusting the system, which is very hard to reverse. Entity resolution across carrier records, proposing merges from name, authority number, address and payment overlap with a human confirming each, is a real workstream and belongs in the plan.

The third is sequencing. Move customers, carriers and rate tables first and reconcile them against known totals. Then open loads. Then history, last, into a warehouse rather than into the live system. Run in parallel for two to four weeks and cut over customer by customer rather than all at once, because a broken tender on your largest account is a different event to a broken tender on your smallest.

Why do EDI and telematics integrations break after go live?

Because a certified EDI flow is a relationship, not a feature. You certify 204, 990, 214, 210 and 997 with a specific trading partner against their specific implementation guide, and the guide is theirs to change. A retailer adds a required qualifier, a carrier starts sending 214 timestamps in a different timezone convention, and your loads stop tendering or, worse, keep tendering with a wrong appointment time.

The pattern that hurts most in freight is silent partial failure. A 214 that arrives out of order will happily overwrite a delivered status with an in transit one if your model applies the last message received rather than the last event by event time. Coordinators then chase a truck that is already unloaded, and nobody reports it as a bug because it looks like a driver being slow.

Electronic logging device feeds have their own version of this. Samsara and Motive change API surfaces, tokens expire, and a carrier that swapped providers last month simply stops appearing on the map with no error anywhere. Driver location by text link degrades differently: it works until a carrier tells its drivers to stop replying.

Three fixes are worth building into release one. Order every status by event time, not receipt time, and store both. Put a heartbeat on every trading partner and every telematics account, so a feed that has gone quiet for four hours raises a queue item rather than a gap on a dashboard. And keep the mapping layer as versioned data so a partner change is a configuration edit reviewed by an operations lead, not a release.

What happens when carrier compliance is a flag rather than a gate?

You tender to a carrier whose insurance certificate lapsed nine days ago, and you find out when there is a claim. This is the gap that turns a software problem into an insurance problem, and it is almost always caused by the same design choice: compliance data is displayed, but nothing stops the tender.

Carrier onboarding checks operating authority and safety data against Federal Motor Carrier Safety Administration sources and verifies an insurance certificate. That is a point in time check. What breaks between checks is everything: authority gets revoked, a certificate expires, a safety rating changes, and an ordinary Tuesday tender goes to a carrier that would not pass onboarding today. Services such as Highway or RMIS exist precisely to keep that monitoring continuous, and plenty of brokerages subscribe to one and still tender to non compliant carriers, because the monitoring result lives in a portal and the tender lives in the TMS.

The fix is enforcement at the point of tender. A carrier whose monitored status has failed becomes untenderable, with an override that requires a named person and a recorded reason rather than a checkbox. Then the override report is reviewed weekly, because the overrides are where your actual exposure sits. The enforcement gate matters far more than which monitoring source you buy.

Should you build custom or configure the TMS you already rent?

Configure, if you move fewer than roughly 20 loads a day, or if your lane strategy is still changing weekly. Tai, Aljex or a broker portal will run that operation and rented seats are cheaper than iterating on custom software while the workflow is still moving. A young brokerage that builds too early is paying to encode a process it has not settled.

There is also a serious configuration case at larger scale. Ask your incumbent, in writing, what it would take to encode your actual margin rules and routing guide. If the answer is a professional services engagement that lands inside a quarter, take it. Many build requests we receive turn out to be implementations that were rushed at go live and never revisited, and a week with a good consultant on your existing platform is a fraction of any build.

Build when the signals stack: you employ people whose real job is moving data between systems, quote turnaround is losing you freight you would have covered profitably, your customisation backlog at the vendor is older than six months, per seat and module fees have crossed six figures a year, and your pricing edge lives in spreadsheets that walk out when a senior broker leaves. Two or more of those and renting is quietly costing more than building.

How do hidden costs get into a TMS quote?

Trading partner count is the first and the most consistently underestimated. Every EDI partner needs mapping and certification testing against their guide, and in our delivery experience that is roughly one to two weeks of work per major partner. A quote scoped against three partners and delivered against eleven is not the same project.

Rating complexity is the second. Truckload contract rates are straightforward. Less than truckload rating against SMC3 plus dynamic carrier application programming interfaces is materially more work, and it is the line most often assumed rather than asked about. If less than truckload is in scope, it should have its own estimate.

Data model reach is the third. Multi stop, multi leg, cross border and intermodal each multiply the model. A load with two picks, one drop and a rail leg is not a bigger version of a single pick truckload, it is a different object, and retrofitting legs into a model that assumed origin and destination is one of the more expensive rewrites in this category.

The fourth is maintenance, which belongs in the original proposal as an annual figure. Plan for 15 to 20 percent of build cost per year covering hosting, monitoring, partner changes and steady workflow improvement. Carrier interfaces change and new partners arrive, so a zero maintenance TMS does not exist. That figure still usually lands under what a growing team pays in per seat and module fees.

What separates a TMS build that works from one that fails?

The data model, decided in week one and very hard to change afterwards. Ask any developer to whiteboard a load with two picks, one drop, accessorials and a tender history before you sign anything. If stops, legs and charges are not distinct objects, rating and settlement will collapse under real freight later, and the rewrite arrives at exactly the moment you have volume.

The second separator is whether tender history is captured from day one. Every offer, counter and decline stored against the carrier and the lane is close to free while you are building the tender waterfall, and it is expensive to reconstruct afterwards. Within a quarter it tells you which carriers accept at what price on which lanes, which is the difference between a routing guide and folklore.

The third is ownership. You should hold the repository, the database and the cloud accounts from day one, with an exit path that needs no cooperation from the developer. The entire reason a brokerage looks at building is that ten years of lane history sits in a schema it cannot reach. A developer who prices ownership as an upgrade is rebuilding the trap you are trying to leave.