Broker workflow
Moving a Carrier Review Into Your TMS Without Losing the Conditions
By VerifyCarrier · · 4 min read
A TMS usually stores a carrier as approved or not. The review behind that flag also had a date, a set of sources, checks still outstanding and conditions such as one load only or a callback before dispatch. If only the flag reaches the TMS, the next person tenders against an approval it does not describe. VerifyCarrier has no native TMS integration. The handoff is a CSV export, an API call or a person copying fields, and each carries a different part of the review.
Sources: VerifyCarrier monitoring guide
Decide what the TMS flag asserts
Write down what approved means in your TMS: the carrier record was reviewed on a stated date, against named sources, for a stated scope such as any load, a lane or one shipment. Without that definition, an approval from a dormant period looks the same as one made yesterday.
Federal rules do not define this record for you. Under 49 CFR 371.3, a broker keeps a record of each brokered transaction for three years, including the shipper, the motor carrier, the bill of lading and the compensation received. It does not prescribe a carrier vetting record. The review is your own policy, and the TMS entry should point to it rather than replace it.
What VerifyCarrier keeps, and what leaves it
A saved review stores the decision (Approved, Needs review or Rejected), your rationale, an optional load or reference number, four checks and a server-side snapshot of the evidence you reviewed. The checks are authority reviewed against the source, insurance document received and reviewed, coverage confirmed with the insurance agent and carrier contact independently confirmed. Each is Outstanding, Recorded complete or Not applicable, and each is your assertion, not an automated verification. Reviews are append-only, outstanding checks stay visible on an Approved entry, and a save is refused with a reload prompt if the source evidence changed while you were reviewing.
Three routes take data out, and none carries the whole review:
- The watchlist CSV from the monitoring dashboard has one row per watched carrier with its latest decision, and one row per recorded change with date, type, field, old and new value. It does not include rationale, checks, load reference or the evidence snapshot.
- The evidence API returns public source evidence for a USDOT number, with source dates and statuses. It does not include private notes or decisions.
- Change-list CSVs export FMCSA authority, suspension and insurance-cancellation changes across all carriers for a day or week. They are included with paid plans and are not tied to your reviews.
Sources: VerifyCarrier monitoring guide; VerifyCarrier: API documentation and user guides
Carry conditions as fields, not prose
Anything beyond the decision label has to be copied by a person or rebuilt by your integration, so map it into fields the TMS can act on. A recommended set: review date, USDOT number, docket, scope, decision, each outstanding check with its owner and due date, conditions, and a link or ID back to the full review. A condition buried in a notes paragraph is not enforced at tender. A field such as callback to the SAFER-listed phone required before dispatch can be, and it follows FMCSA’s advice to call the number in SAFER rather than one supplied with the load.
The blank review log template already uses this structure, with columns for shipment or scope, decision, conditions, unresolved questions, follow-up owner and due date, and can serve as the field map. Pull source evidence through the API only if you also store its dates and statuses, as described in the guide to keeping API responses as evidence.
Keep the evidence date through the handoff
The date that matters is when the sources were read, not when the TMS record was created. If the TMS entry is made a week after the review, it should still show the review date. When the evidence is refreshed, save a new review instead of editing the old one; VerifyCarrier’s Continue this review copies the reference and check statuses into a new entry and leaves the previous one unchanged. The TMS can then point to the observation the approval relied on.
A change after approval should reopen the TMS status, not only send an email. VerifyCarrier alerts and the watchlist export report recorded changes; deciding which ones suspend tendering is a rule your TMS process has to apply and someone has to own.
Sources: VerifyCarrier monitoring guide
Test the handoff
A recommended check: take a recent review that still has an outstanding check, open only the TMS record, and ask a colleague whether they would tender a load. If they cannot see that the check is outstanding, or when the evidence was read, the handoff dropped the part of the review that mattered. Fix the field mapping before the next approval, not after an incident.
Sources checked . Procedures are VerifyCarrier’s recommendations; examples are illustrative. How we prepare and correct these guides.