Your TMS Is a System of Work. Is It Also a System of Record?
There’s a phrase no one wants to hear before a deposition: "I don't remember."
It’s an honest answer. It’s also what happens when the best record you have of a load is a person.
Ask anybody in your office what happened on a load last March and they’ll tell you. Ask them to show you, and the story changes. The rate confirmation is in somebody's email. The carrier check happened in a browser tab that’s now closed. The call that mattered was a text. The rep who made the call left in June.
Your transportation management system (TMS) recorded that the load moved. But it didn’t record how you decided to move it. Those are two different things, and the gap between them is where broker liability lives.
System of Work vs. System of Record: What Is the Difference?
A system of work runs the load. It quotes, covers, dispatches, tracks, and invoices. It’s measured by how fast the work moves.
A system of record proves the load. It holds a complete, time-stamped, tamper-evident account of what was known, what was decided, and who decided it, in order, for as long as you need it. It’s measured by what it can still show you three years from now.
Every brokerage has the first. Very few have both in the same place. The usual arrangement is a TMS that executes and a scattered archive that remembers: email, spreadsheets, screenshots, a vetting tool's dashboard, somebody's notebook. That arrangement works perfectly until the day somebody asks you to prove something.
Why Broker Liability Looks Different Post Montgomery
For years, brokers leaned on federal preemption under the Federal Aviation Administration Authorization Act (FAAAA) to keep negligent selection claims from reaching a jury. That shield is narrower now. In Montgomery v. Caribe Transport II, the Supreme Court ruled unanimously that the safety exception can carry these claims through. Justice Kavanaugh's concurrence is the line worth reading twice: a broker who selected the carrier should be able to explain why.
I’m not a lawyer, and this isn’t legal advice. Nothing in that decision makes a broker automatically liable for a crash. A plaintiff still has to prove a duty, a breach, and causation. What changed is the venue. More of these questions now get answered in front of a jury instead of being dismissed on a motion, and the answer you give is only as good as the evidence behind it.
So the practical question for an operator is narrow: when somebody asks why you picked that carrier on that load, can you show them, or can you only tell them?
The Problem Is Not Missing Data. It’s Where the Data Lives.
Brokers aren’t short on information. A mid-size brokerage runs a dozen tools on a given load: a vetting and fraud platform, an insurance monitor, a visibility provider, a load board, a document capture tool, a payments system, email, text.
Each one is good at its job. Each one keeps what it learns. And it keeps it in that vendor's ecosystem, not in yours.
That’s fine on a normal day. It’s not fine when you need the whole sequence. Reconstructing a load across a dozen systems means a dozen exports, date formats, retention policies you did not write, and makes for a dozen or more chances for a gap. You’re not producing a record at that point. You’re producing an argument about a record, assembled after the fact, by people with an obvious interest in the outcome.
Three years from now, somebody asks you what happened on this load. Where do you go? How do you prove it?
Neutral With Better Dashboards Is Still Neutral
Highway’s Michael Caney put it plainly: “…a TMS can no longer take a neutral stance on fraud.” I would go further. Most TMS platforms have responded by surfacing more signals, and surfacing a signal isn’t taking a position.
If your system shows a carrier's authority age, an insurance lapse, and a double-brokering flag, and then waits for a human to notice all three and connect them at 4:47 on a Friday, that’s still neutral. It’s just neutral with better dashboards.
Information with no next step attached is one more thing to miss. The useful version is a system that acts: it holds the load, it blocks the dispatch, it requires the second approval, and then it writes down that it did, who overrode it, and why. At Transfix, we don’t provide updates. We provide outcomes, and provable ones.
The Action Is the Entry
Here’s the design principle that makes the difference, and it’s less about compliance than it is about physics.
In most brokerages, doing the work and documenting the work are two separate jobs. The rep covers the load, and then somebody is supposed to write down that they covered it. The second job is unpaid, unloved, and is far too often the first to go when the day gets long. Any record built that way has holes in it by definition.
A system of record removes the second job. The action is the entry. Sending the rate confirmation writes the entry. Signing it writes the entry. Verifying the signer writes the entry. Nobody files anything, because filing isn’t a separate step.
That’s also what makes the record defensible. A log a person maintains is a log a person can forget, backfill, or tidy up. A log the work itself produces is evidence.
What a Broker Audit Trail Looks Like on One Load
Forget the platform for a second and walk one load end to end. There are four phases, and each one should leave something behind.
Win it. The quote, the cost model and version behind it, the margin assumptions, who approved the number, and when.
Cover it. The carrier considered and the carriers passed over. The authority, insurance, and fraud checks as they read at the moment of dispatch, not as they read today. The score. The override, if there was one, and the name on it.
Operate it. Tracking events, check calls, exceptions raised, exceptions resolved, documents in and out, every status change with a time on it.
Pay it. The proof of delivery, the invoice, the settlement, the accessorials, and the dispute if one happened.
The test isn’t whether your brokerage holds all of that somewhere. It almost certainly does. The test is whether one shipment number returns all of it, in order, in one place, in seconds, three years later, without an export or a favor from a vendor. That is the answer: in order, in seconds.
Build the App. Own the Ledger.
The obvious objection is that all of this sounds slow, and brokers don’t have time to be slow. Fair. Especially now. Every brokerage has workflows nobody else has, and waiting two quarters for a vendor to build a screen is its own kind of risk.
So build it. Build the app, the view, the automation, the thing your team needs this month. Move fast at the edges, where speed compounds and a mistake is cheap to undo.
Just don’t fragment the ledger to do it. The moment a custom tool keeps its own copy of the truth in its own database, you haven’t extended your system of record. You’ve started a second one, and now you have two accounts of the same load that can disagree.
The design that holds up is one ledger underneath and as much custom surface as you want on top. Every app, integration, and automation writes to the same record. At Transfix, we take it a step further: we built this as a brokerage before we licensed it as software, and the code that writes to that ledger is read and reviewed line by line by a real team of engineers.
Six Questions to Ask Your TMS Vendor Before the Next Claim
Take these into your next renewal conversation. The answers separate a system of work from a system of record faster than any demo.
If I give you a shipment number from three years ago, what comes back, and how long does it take?
Does the carrier vetting result as it read at dispatch get stored, or only the carrier's status as it reads today?
When a rep overrides a block or a warning, is the override captured with the reason and the name, or does the system simply proceed?
Which parts of my load history live in your database, and which live in a third party's? What happens to the second group if I stop paying that vendor or cancel the contract?
Can an administrator edit or delete a past entry? If so, is that edit itself recorded?
When I export, do I get the record, or do I get a report built from the record?
If a vendor cannot answer question one in a sentence, the rest of the conversation is about a system of work that likely…needs work.
Having the Data Is Table Stakes
Every vendor in this market can show you data. That’s table stakes now. Acting on it is what matters, and being able to prove what you acted on is what protects you.
Two separate worlds- the one where the work happens and the one where the record lives- is how the industry has operated for twenty years. It no longer survives contact with a courtroom. The record shouldn’t be something you assemble after the fact. It should be the byproduct of doing the work correctly the first time.
So the only question left is the one worth taking back to your team this week.
Is your system built to protect you, support you, or just operate?
