A canceled load is not just a status change. The brokerage may need to release the carrier, preserve who canceled and when, collect agreed evidence, decide whether a Truck Order Not Used (TONU) charge is payable, decide separately whether the customer is charged, and keep the load out of delivered-work and ordinary billing queues.
The useful TMS question is not “Can I cancel a load?” It is: Can the team close a canceled move without erasing the event, paying an unsupported charge, billing the customer by accident, or making the load look delivered?
This guide gives freight brokerage owners, operations managers, dispatchers, and new-authority teams a four-case acceptance test. Use fictional data or records you are authorized to test. The method is operational—not legal, contract, accounting, or payment advice.
Public facts, practitioner guidance, and product claims are different
The current text of 49 CFR 371.3 says brokers must keep a record of each transaction. It lists specified party, carrier, reference, compensation, service, freight-charge, and carrier-payment information; requires the records for three years; and gives each party to the brokered transaction a right to review the required record.
That is a public regulatory fact. The rule does not define TONU, set a standard cancellation amount, prescribe the test below, or prove that any TMS creates a compliant cancellation record. Whether a particular canceled load or TONU event falls within a legal or contractual record obligation depends on the facts and governing terms; route that question to qualified counsel and your process owner.
Two 2026 practitioner articles—Alexander, Winton & Associates and iDispatchHub—emphasize defining the cancellation trigger and acceptable evidence in writing. Freight 360 likewise illustrates how timing and whether the carrier has begun acting on the load can change the commercial discussion. These are operational viewpoints, not federal rules or universal contract terms. This guide does not adopt their fee ranges or promise a payment result.
None of those sources verifies ServeOps functionality. A product claim requires separate evidence.
Prepare one controlled cancellation packet
Create a fictional load that has not moved. Use invented customer, carrier, driver, facility, reference, and dollar values. Before testing, write down:
- Internal load ID and customer reference.
- Carrier identity and the person who accepted the assignment.
- Pickup appointment and time zone.
- Rate-confirmation version and the cancellation/TONU terms being tested.
- Dispatch or acceptance time, if the case includes one.
- Cancellation source, time, reason, and operator.
- Evidence expected under the test terms.
- Separate proposed carrier cost and customer charge decisions.
- The downstream places that must not treat the load as delivered: invoice queue, payable queue, reports, integrations, and any completion metric.
Do not use a real carrier or initiate a payment. The goal is to observe controls, not manufacture a payable.
Run four cancellation cases
Reset the synthetic load between cases or make a clean copy with a distinct test ID.
Case 1: canceled before carrier dispatch
Record a customer cancellation before the carrier is marked dispatched or en route. Under your written test terms, expect the carrier assignment to be released, the cancellation timeline to remain visible, and all charges to remain unapproved unless a reviewer explicitly decides otherwise. Confirm that the load is not labeled delivered, invoiced, or completed.
Case 2: canceled after dispatch but before arrival
Record carrier acceptance and dispatch, then a customer cancellation. Add the evidence required by your fictional terms: acceptance message, dispatch time, written cancellation, and any authorized location or deadhead proof. The system should preserve the evidence and route the charge for a decision. It should not calculate entitlement merely because the status changed.
Case 3: carrier arrives but freight does not move
Record arrival at the pickup facility, then document that no freight was loaded. Attach only synthetic evidence. Verify that an operator can distinguish “arrived, not loaded, canceled” from “picked up,” “delivered,” and “detention.” If your workflow cannot represent that distinction, record the manual control needed to prevent a false movement event.
Case 4: canceled load is rescheduled
Cancel the original test load, then create or link a new load for the later appointment. The original cancellation, carrier release, and cost decisions should remain reconstructable. The new load needs its own carrier assignment, terms, references, and status history. Reopening the old record should not silently convert a canceled event into a completed move.
Score nine control surfaces
For every case, mark Pass, Manual, Fail, or Not tested. A demo statement is not observed evidence.
| Control surface | Passing evidence | |---|---| | Status semantics | Canceled is distinct from covered, dispatched, picked up, delivered, and completed. | | Carrier release | The former assignment cannot keep receiving active-load treatment; release time and owner are visible. | | Reason and source | Who canceled, why, when, and through which channel are attributable. | | Timeline | Acceptance, dispatch, arrival, cancellation, and decision times remain ordered and retrievable. | | Evidence | Terms, messages, and accepted proof stay linked without replacing the original record. | | Carrier-cost decision | Proposed, approved, rejected, and paid are separate states with amount, approver, reason, and time. | | Customer-charge boundary | Customer billing is a separate decision; carrier approval does not automatically prove a customer charge. | | Downstream handling | Canceled work does not silently enter delivery, invoice, payable, completion, or performance queues. | | Recovery and reporting | The team can later reconstruct the canceled load and any linked rescheduled load without guessing. |
Use this acceptance rule: do not approve the workflow while a canceled load can look delivered, create an unexplained charge, keep a carrier actively assigned, overwrite the cancellation evidence, or disappear from later review. A documented manual control may pass if its owner, trigger, location, and proof are explicit.
Keep the money decisions separate
Write two lines for each test case:
Carrier side: proposed cancellation charge → contractual/evidence review → approved, rejected, or held carrier amount
Customer side: proposed customer charge → customer-term/evidence review → approved, rejected, or held customer amount
Do not merge the two. A brokerage may owe a carrier under one agreement while still disputing or absorbing the customer side; the reverse assumption can also be unsafe. The test should show who made each decision and where the accounting or payment handoff begins. A TMS screen is not proof that money moved.
Questions to resolve before purchase or go-live
Ask the vendor or implementation owner to answer in writing:
- Which events distinguish acceptance, dispatch, arrival, pickup, cancellation, and completion?
- Can a cancellation preserve its original carrier, terms, documents, notes, and event history?
- How is the carrier released, and what notifications or integrations still run afterward?
- Can TONU eligibility, proposed amount, approval, payable, and payment remain separate?
- Can customer rebilling be reviewed independently from carrier cost?
- How are canceled and rescheduled loads linked without duplicating revenue or cost?
- Which reports, exports, billing queues, and integrations include canceled loads?
- What is manual, who owns it, and what proves it happened?
An explicit manual answer is more useful than an untested automation claim.
A restrained ServeOps trial step
If you want to run this test in ServeOps, use fictional or authorized records, do not contact a real carrier or customer, and do not initiate a charge or payment. Treat every unverified behavior as Not tested. 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.
This guide does not claim that ServeOps tracks dispatch acceptance, calculates TONU, determines eligibility, releases carriers, sends notifications, stores evidence, blocks delivery or billing, creates payable/customer charges, links rescheduled loads, exports records, integrates accounting or payments, or guarantees compliance. Those are product and process questions to verify.
Related Broker Guides
- Keep stops, charges, and route revisions aligned
- Test whether critical load instructions survive dispatcher handoffs
- Audit documents and charges before releasing an invoice
Confirm each related route is approved and live before inserting it in the CMS.
Sources
- eCFR, 49 CFR 371.3 — Records to be kept by brokers (current page reviewed August 23, 2026)
- Alexander, Winton & Associates, TONU Meaning in Trucking (published March 18, 2026; practitioner perspective reviewed August 23, 2026)
- iDispatchHub, How to Negotiate TONU and Layover Pay (published April 27, 2026; practitioner perspective reviewed August 23, 2026)
- Freight 360, TONU Explained for Freight Brokers (scenario-based practitioner explainer reviewed August 23, 2026)
- ServeOps registration (offer destination; complete terms require publication-day recheck)