She Had Every Document. She Couldn't Prove She Had Them Before the Crash.

A broker I know spent three days pulling everything together after she got the call. SAFER snapshot. BASIC scores. ACORD 25. Carrier agreement. CSA percentiles. She had it all.

Then discovery started.

Her attorney asked her to produce everything she'd used to vet the carrier before she tendered the load. She sent the file. The plaintiff's attorney spent about fifteen minutes with it and then sent over the deposition questions. One of them was: "For each document in this file, can you tell me when you obtained it — before you assigned this load, or after my client was injured?"

She couldn't. Not because she'd lied, but because the documents didn't have timestamps that proved anything.

The problem wasn't her vetting. The problem was her paper trail.

Why Timestamps Are the Argument

After Montgomery v. Caribe Transport II, LLC, brokers face state-law negligent selection claims in any court in the country. The core question in those claims is whether the broker exercised reasonable care when they selected the carrier for this specific load. That means reasonable care before the truck moved.

A document pulled after an accident doesn't prove pre-tender due diligence. It proves you were worried after the accident. That's the opposite of what you need.

Here's the thing most brokers don't think about: most vetting workflows generate documents with the current date baked in — SAFER printouts, screenshot saves, COI scans. The file creation date is the date you ran the check. If you ran it before the load tendered, the metadata shows that. If you ran it two days after you heard about the accident, the metadata shows that too.

Discovery has gotten efficient at this. You'll see requests for file creation dates, email timestamps, system login logs. "I already had it on file" only works if you can actually prove "already."

How a Typical Carrier File Fails

Take a carrier — call them MC-1891047, DOT-4223819, just over two years of authority, 18 power units, Satisfactory rating. Your rep has used them on 30 loads over the past 18 months without a problem.

Load 31 goes wrong. Rollover on I-80. Serious injuries. Your rep, asked in deposition what vetting she did before tendering load 31, says she checked SAFER. The plaintiff's attorney asks to see the documentation. She produces the SAFER printout from the carrier file — no date on it, because she printed it the first time she used the carrier, 14 months ago, and filed it there.

She didn't re-check for load 31. Or load 30. Or loads 11 through 30. There's one 14-month-old document in the file.

That's the most common failure mode. Not fraud, not incompetence — just a vetting process that worked at carrier setup and never generated per-load records afterward. Now the entire carrier file is a single snapshot from over a year ago, and this carrier's Vehicle Maintenance BASIC has climbed 22 percentile points in the past six months. Something that would have shown up if she'd run a check before load 31.

The file doesn't just fail to protect her. It actively helps the other side.

The Four Ways Carrier Files Fall Apart Under Timestamp Scrutiny

Undated SAFER and BASIC screenshots. If you don't have the system auto-generate these with a timestamp in the filename or header, you're creating documents with no provenance. A BASIC score screenshot from six months ago looks identical to one pulled the morning after an accident unless the metadata survived the save. "I had this before the accident" is not provable from a PNG file named carrier_check.png with no embedded timestamp.

ACORD 25s with no verification date. A COI has an expiration date. It does not have a "verified on" date. You can have a COI on file from 14 months ago and it looks exactly the same as one you received this morning. The certificate itself tells a deposition attorney nothing about when you checked insurance status. When you verified the policy with FMCSA's L&I database matters. When you called the insurer to confirm the policy was still active matters. If none of that is in the file, the COI is just a piece of paper that proves the carrier had insurance at some point.

Carrier agreements with no tie-back to specific loads. The agreement has a signature date from when you first set up the carrier relationship. The load tendered 14 months later. A signed carrier agreement isn't a vetting record for a specific load — it's evidence of a relationship. It tells a jury you had an agreement with the carrier. It doesn't tell them you verified anything before this particular shipment moved.

Spreadsheets and manual notes. A row in a spreadsheet that says "Checked 6/28" means nothing if the spreadsheet file was last modified at 11 PM the night after an accident. Metadata on spreadsheet files is accessible — "last modified" timestamps survive in discovery. If your notes don't match the file metadata, you've created a document that looks like it was backdated. Even if it wasn't.

What Actually Makes a Record Defensible

Three things: who created it, when the system created it, and what system generated it.

System-generated records beat manually entered records in discovery. When a verification tool queries FMCSA data and logs the result with a server-side timestamp, that timestamp isn't something your employee typed. It came from an external system's database. That's harder to challenge than a number you entered in a cell — and it's essentially impossible to challenge if the system is a third-party platform with its own audit log.

The timestamp has to link to the specific load. Not "I ran this check sometime last month." The record needs to tie to a carrier, a load number, and a tender date. If your process is to run a SAFER check and save the PDF to a folder organized by MC number, you've proven you checked the carrier at some point. That's not proof you checked them for this load on this date.

Timing matters more than most brokers expect. If you check a carrier Monday morning and tender the load Monday afternoon, that's fine. If you checked a carrier on February 3rd and tendered 40 loads over the next eight months with no re-checks, the February 3rd record is now evidence that you relied on stale data — repeatedly, for eight months. Post-Montgomery, your monitoring cadence is on trial, not just your initial carrier setup.

The Regulatory Gap That Plaintiffs Exploit

49 CFR § 371.3 requires freight brokers to keep records of each transaction — carrier name, freight bill, amount paid — for three years. That regulation says nothing about vetting records. There is no federal requirement that you document how you screened a carrier before assigning them a load.

That absence works against you in civil litigation. It means your internal process is the entire standard of care. If you have no documented process, there's no floor. A plaintiff's attorney will argue to the jury that since there's no regulatory requirement and no internal policy, you made no professional judgment at all — you just handed freight to whoever had capacity.

If you DO have a process — and most brokers do, even if it's informal — then every element of that process becomes part of what "reasonable care" required. Every gap in your documentation becomes evidence the process failed for this load.

This is why "we check every carrier" is dangerous language in your contracts if you can't produce a per-load record proving you actually ran a check for this carrier on this load before this tender.

Your Email Trail Is Part of the Carrier File

This one gets overlooked. When your rep emails a carrier to request an updated insurance certificate, that email has a timestamp. When you receive the ACORD 25 as an attachment, the received timestamp lives in your email server. When you send a rate confirmation and the carrier replies signed, that exchange is timestamped.

Your email trail is part of the vetting record — or it should be. Some TMS systems pull email correspondence into the load file automatically. If yours doesn't, someone should be forwarding the relevant emails into the carrier record manually. An email at 10:43 AM saying "please confirm your cargo insurance is current before we dispatch" — with a carrier reply at 11:17 AM — shows a broker who asked, received confirmation, and moved forward. That's documented reasonable care that exists in your email server whether you think to print it or not.

If your vetting generates email exchanges, keep them. Specifically associate them with the load they belong to.

How I Document This

Every load gets its own check, and every check gets a timestamp.

The check runs before the carrier gets the load number. Not the same day, not after the rate confirmation — before the assignment. That sequence is what the timestamp has to show.

I want the verification logged by the system — not a screenshot I took and filed, but a platform-generated record tied to the MC number and the shipment reference, with a query time I didn't control. If I'm working without that kind of tool on a given load, I create a dated note in the file: "SAFER checked 7/5/26, 10:44 AM CDT — status Active, Unsafe Driving at 38th percentile, Crash Indicator at 44th percentile, no BASIC alerts. Insurance verified via FMCSA L&I, no lapse in the past 24 months. COI on file, current, National Liability & Fire policy." Short, specific, timestamped, and signed off by the person who ran it.

When the carrier is under 18 months' authority, I also document the T-call. Name of who I reached, their role, the date and time, and the key things I asked and heard. Not verbatim — just enough that I could reconstruct the conversation. "Spoke with the ops manager, confirmed 3 active units, all with Samsara ELD, confirmed cargo coverage $100K, policy with Northland, no claims in past 12 months, driver for this load is their only owner-operator under permanent lease." That call log is a vetting document for this load.

After the load delivers, the file is closed. Nothing goes into it retroactively without a note that says when it was added and why. "Added 7/6/26 post-delivery — certificate emailed per carrier request after load completed." That kind of entry makes the file honest. Attorneys know post-incident file-loading is common. A file that's transparent about what's retroactive is more credible than one that looks too clean.

Don't build a file that looks like you knew what you'd need before you needed it. Build a file that shows exactly what you did and when you did it. The difference between those two things is whether you're reading this post or wishing you had.

— Mason Lavallet

Founder, DOTScreener.com