Which Rate Confirmation Did the Carrier Accept? A Three-Scenario TMS Test

August 26, 2026 freight broker rate confirmation acceptance

# Which Rate Confirmation Did the Carrier Accept? A Three-Scenario TMS Test

A freight broker can have a rate-confirmation PDF, a sent email, and a carrier assigned to a load—and still be unable to prove which terms the carrier accepted. That gap becomes obvious when a pickup time changes, an accessorial is added, the carrier cost is revised, or a carrier declines after an earlier document was sent.

The buying question is narrower than “Does the TMS generate rate confirmations?” It is: Can a second person connect one accepted document version to the right carrier, signer, time, and current load state?

Use this controlled three-scenario test before treating any e-signature, tender, or document-workflow claim as complete. It is an original evaluation method, not an industry standard, legal opinion, representation of ServeOps functionality, or conclusion that a document is enforceable.

Build a nine-part acceptance record

For each rate confirmation, try to recover nine elements without asking the person who sent it:

Load identity: a stable load number or other record key.
Carrier identity: the carrier legal name and identifier your approved process requires.
Document identity: a version number, generated-at time, file hash, or another reliable fingerprint.
Recipient: the exact email address, phone number, portal user, or other destination used.
Delivery state: generated, sent, delivered, opened, expired, declined, or failed—kept distinct.
Acceptance act: the recorded action that your process treats as acceptance.
Signer evidence: the name and other identity evidence actually captured, without assuming it proves authority.
Acceptance time: timestamp and timezone.
Supersession state: whether this version is current, replaced, withdrawn, declined, or expired.

Do not merge these fields into one vague status. “Sent” does not mean delivered. “Opened” does not mean accepted. A typed name does not automatically establish that the person had authority to bind the carrier. A current PDF does not prove that the same file was the one accepted.

Prepare the test safely

Use synthetic or properly authorized records, never a live shipment created only for testing. Create two user accounts and a fictional carrier contact. Write an answer key before touching the TMS: load ID, carrier, recipient, initial carrier rate, stops, appointment times, instructions, and the exact change planned for each scenario.

Save the generated documents outside the TMS as test evidence. Give each file a simple name such as `L100-v1`, `L100-v2`, and `L100-v3`; that label is your answer key, not proof that the product versions documents. Record every manual email, external signature step, upload, or administrator action.

Scenario 1: a clean first acceptance

User A creates a simple load and generates the first rate confirmation. Send it through the product only if that channel is authorized for the test. The fictional carrier contact completes whatever acceptance action the product supports.

User B should then answer: Which version was sent? To whom? What did it contain? What action was recorded as acceptance? Who appeared to perform it? When did it occur? Is the accepted copy attached to the correct load and distinguishable from an unsigned draft?

Score the workflow Manual if acceptance happens by ordinary email, external e-signature, phone, or another system and a user must upload or annotate the evidence. Manual is not automatically a failure; undocumented manual work is.

Scenario 2: revise after acceptance

Start with an accepted version, then change one material test field—such as the carrier rate, pickup window, or approved accessorial. Generate a revised document. Do not change several fields at once; the point is to see whether the evidence chain remains understandable.

Check whether the earlier accepted version remains identifiable, the new document receives a distinct identity, the change is visible, the correct recipient gets the revision, and the revised version requires a new acceptance when your process calls for one. Confirm that the load does not display a generic “accepted” state that silently refers to the older terms.

The cold reviewer must be able to say: “Version 1 was accepted at this time, Version 2 changed this field, Version 1 is now superseded, and Version 2 is—or is not—accepted.” If the reviewer has to compare file names, inbox threads, and memory to discover that sequence, mark the workflow Manual or Fail according to your written requirement.

Keep this narrow. The TMS audit-history test owns broad before-and-after reconstruction across load fields and documents. This guide owns the acceptance-to-version connection.

Scenario 3: decline, expiry, or carrier falloff

Create a third load and send a test tender or rate confirmation. Then use one safe negative path the product actually supports: decline, expiry, withdrawal, failed delivery, or carrier replacement. Do not create a fake cancellation or delete irrecoverable evidence.

Verify that the negative state cannot be mistaken for acceptance; that the carrier assignment, dispatch state, and current document do not contradict one another; and that a replacement carrier receives a newly identified document rather than the prior carrier’s accepted copy. The original recipient and evidence should remain attributable without making stale terms look operative.

For the operational replacement sequence, use the dedicated carrier-falloff TMS test. For an accidental two-carrier release, use the duplicate-carrier-booking containment test. This scenario checks only the document-acceptance boundary.

Make a cold handoff decide the result

Give a third reviewer only the three load IDs and this checklist:

identify every generated version and its distinguishing evidence;
identify recipient, delivery state, acceptance act, signer evidence, timestamp, and timezone;
state which version is current and which versions are superseded, declined, expired, or unaccepted;
reconcile the accepted carrier terms with the current load and carrier assignment;
list every fact that exists only in email, an external signature service, a phone note, or an administrator report.

Use four labels: Pass when saved evidence answers the question; Manual when a named external step supplies the evidence; Fail when the answer is missing, contradictory, or dependent on memory; and Not tested when the scenario was not safely demonstrated.

Reject the requirement if a material revision inherits the old acceptance, the accepted file cannot be distinguished from another version, a decline or expiry looks accepted, signer evidence is represented more strongly than the system captures, or a replacement carrier can be associated with the prior carrier’s document.

Separate public facts, vendor signals, and product proof

Current 49 CFR § 371.3 requires brokers to keep a record of each transaction containing specified information and retain the required record for three years. It does not prescribe this nine-part acceptance record, define a rate-confirmation acceptance workflow, establish signer authority, or make this test a compliance safe harbor.

Current vendor materials make the buying question concrete. EZ Loader describes mobile electronic signing of rate confirmations with the signed copy uploaded to its TMS. Vektor presents rate confirmation and freight tendering as a product area. Those are vendor-authored market signals, not independent proof, competitor comparisons, or evidence about ServeOps. ServeOps' existing public rate-confirmation article discusses clarity and fairness in broker-driver relationships; it is not product documentation for e-signature, delivery tracking, acceptance, or version control.

Verified ServeOps functionality: this guide makes no claim that ServeOps generates or sends rate confirmations, supports e-signatures or tenders, verifies signer identity or authority, tracks delivery or opens, sets acceptance windows, invalidates revisions, blocks dispatch, attaches signed files, versions documents, preserves audit history, exports evidence, or guarantees retention, compliance, enforceability, accuracy, or outcomes. Every behavior above is a requirement to demonstrate and score.

If ServeOps is on your shortlist, run the test only with synthetic or properly authorized records and mark every unproved behavior Not tested. The verified offer language is unchanged: 60-day free trial; card collected upfront; no charge for 60 days; cancel anytime; then $49 per seat/month or $490 per seat/year. Card is required upfront. No charge during the trial. Confirm the complete checkout terms before signup.

Start a controlled evaluation only when your team is ready to preserve the evidence and score the result.

Sources

Electronic Code of Federal Regulations, 49 CFR § 371.3 — Records to be kept by brokers, accessed August 26, 2026.
EZ Loader TMS, Digital Documentation, accessed August 26, 2026. Vendor-authored product description only.
Vektor TMS, Rate Confirmation & Freight Tendering, accessed August 26, 2026. Vendor-authored product page and market signal only.
ServeOps, Rate Confirmation: Broker and Driver Relationships, accessed August 26, 2026. Existing editorial context; not product-functionality evidence.
ServeOps, registration page, accessed August 26, 2026. Visible page confirms the 60-day trial, no-charge period, and cancel-anytime language; card and pricing terms require a complete checkout recheck before publication.