On a Wednesday morning in September, a carrier at Bronco Logistics was approved at 11:00. The load it was booked on still wouldn’t move to Alerted. Sixty-three seconds later, the desk replaced the carrier with itself to get past the refusal, and typed the reason in capital letters.
The checkpoint was doing its job with the wrong copy of the facts. This is what happened, what we changed, and four questions it left us asking of any rule that blocks a load.
What happened, from the audit log
| Time (Central) | Event |
|---|---|
| 10:27 | The load is created |
| 10:37 | A new carrier is added. Its compliance status isn’t Approved yet. Fourteen seconds later it’s booked on the load |
| 10:41 | The tracking request goes to the driver, who accepts four minutes later |
| 10:59 | The signed rate confirmation is uploaded |
| 11:00:58 | The carrier’s status is changed to Approved. The checkpoint still refuses the load |
| 11:02:01 | The carrier is replaced with itself as a workaround. The compliance refusal clears |
| 11:07 | Tracking is stopped by hand. It’s still attached to the first booking, and the new booking can’t start its own |
Every step the desk took was reasonable. The carrier was new, so approval took a while, and the team got on with the driver, the tracking and the paperwork while it came through.
Bug one: the checkpoint read a copy made at booking
To move a load to Alerted, the carrier’s compliance status has to read Approved. That rule lives in the database, which we’ve written about before.
When a carrier is booked on a load, the system copies the carrier’s status onto the booking. The idea was sound: keep a record of what the status was. The mistake was that the checkpoint read that copy and not the carrier record. Approving the carrier changed the record and left the copy alone, so the checkpoint kept refusing, and nothing on the screen said why.
Replacing the carrier with itself worked because a swap re-reads the carrier and writes a fresh copy. It should never have been the only way out.
Bug two: the old booking kept the tracking
The swap cleared one refusal and caused the next. The tracking session was still live and still attached to the first booking. The system won’t start a second session on a load while one is open, so sending tracking from the new booking came back with “tracking is already active on this load” and no obvious way to clear it.
What we changed
- The checkpoint reads the carrier’s status live, at the moment someone tries to move the load.
- The refusal is specific. It names the carrier that’s blocking the load and gives its current status.
- The copy of the status is still kept, but it’s written when the Alerted checkpoint passes. That’s the moment the brokerage commits a truck, so it’s the moment worth having on record.
- When a booking falls off or is cancelled, its tracking ends with it. A stop request goes to the tracking provider and a note goes on the load.
- A sweep runs behind that. Any tracking session more than 10 minutes old that’s still open on a booking that’s no longer current gets closed.
Four questions we now ask of any rule that blocks a load
- When does it read the facts? A rule that checks a status should read it when the decision is made. A copy taken earlier is a record. It shouldn’t be the thing that decides.
- When is the record taken? If you keep a snapshot for your compliance file, take it when you commit the truck, not when you first picked the carrier. What you knew when you sent the truck is the question you’ll be asked later.
- Does the refusal say what’s wrong, and with whom? “Carrier must be approved” sends people hunting. A message with the carrier’s name and its current status tells them who to call.
- What else was hanging off the thing you replaced? A booking carries tracking, a rate con and a driver. When the booking ends, each of those needs an answer.
One more habit came out of it. When someone on the desk finds a workaround that works, treat it as a bug report. The swap worked because it took a different path through the same data, and that showed us where the two paths disagreed.
What we left alone
A carrier swap voids the old rate confirmation, and the new booking needs its own signature before dispatch. That’s deliberate. A signature belongs to the booking it was given for. On this load it meant a carrier that had already signed had to sign again after being swapped with itself. It’s a nuisance in this one case, and as of this writing the rule stands.
The same goes for the compliance status. The checkpoint enforces whatever your team recorded. It doesn’t vet the carrier. That part is covered in our carrier onboarding guide and on the carrier management page.
If you’re shopping for a TMS
Ask the vendor to run this exact sequence in a demo. Book a carrier that isn’t approved, approve it, and try to move the load. Then swap the carrier and watch what happens to the tracking and the rate con.
Our broker TMS buyer checklist has more tests like it, and the workflow enforcement page shows what each FreightVero checkpoint requires.
Run this sequence in our demo
Bring a real load. Book a carrier that isn’t approved yet, and see what the database says back at each step.