Can freight software show who approved every change to a load?
Key Takeaways
- A buyer should expect to open any load and see, for each change that needed approval, who approved it, what changed from and to, when, why and what evidence supported it.
- Four changes usually need approval under a company's rules: a rate above the configured limit, a carrier change, an added accessorial and a pickup or delivery date change.
- Changes that run within the rules should still appear in the shipment history, so the record shows both what was approved and what did not need approval.
- The test is one load with several deliberate changes, traced afterward by someone who was not involved.
- Wilson, by Cartage, applies the company's configured approvals and records messages, confirmations and changes in shipment history, so the request, the reply and the action sit on the same load.
Can freight software show who approved every change to a load?
It should, for every change your rules say needs approval: the load's history should show the request, the person who answered, the exact change, the time, the reason and the evidence, without anyone searching email or chat. If the only proof of an approval is a coordinator's memory of a phone call, the software did not keep it.
This is a different question from how to set approval rules, which booking approval rules before automating covers, and from how finance signs off a quote before booking, covered in how finance should approve freight quotes. Those decide who should approve what. Traceability asks whether, after the load has moved and three things changed along the way, anyone can still see who said yes to each one.
The question usually comes up after something goes wrong: a carrier invoices a rate nobody remembers agreeing to, or a controller asks who switched carriers on a load that cost more than planned. The answer should come from the load itself.
Which changes to a load should need an approval
Start by listing the changes that need a person's yes, because traceability can only be tested against a known list. Four are common:
Rate above the limit. A negotiated rate, or a carrier's revised rate after booking, that lands above the target or approval limit the company configured.
Carrier change. Moving a load to a different approved carrier after a decline, a cancellation or a missed pickup, when the rules require approval for the switch or the new rate.
Accessorial added. Liftgate, inside delivery, an extra stop, detention or any service not in the original booking.
Date change. A pickup or delivery date that moves, especially when the customer's committed date is affected.
Each company sets its own thresholds. One manufacturer may let small accessorials pass within a dollar limit and require approval above it; another requires approval for every date change on customer-committed orders. What matters for traceability is that the list exists, so each change on a load can be checked against it: approval needed or within the rules.
What the record should show for each approved change
Each approved change needs five facts on the load: who, what, when, why and evidence.
- Who. The person who approved, by name, and how the approval arrived: an email reply, a Slack or Microsoft Teams message, or a reply to the system's request. A group inbox or "logistics team" is not a who.
- What. The change in before-and-after terms. "Rate changed from $1,900 to $2,150" or "delivery moved from Thursday to Friday," not "rate updated."
- When. The time of the request, the time of the approval and the time the change was acted on. The order matters: the approval should come before the carrier was told.
- Why. The reason given in the request: the carrier declined, the consignee asked to reschedule, the second stop was added by sales.
- Evidence. The message or document behind the change: the carrier's revised quote, the consignee's email, the decline.
Two things often break this record. Phone approvals leave no trace unless someone writes them down on the load. Approvals given in a side conversation never reach the shipment at all. A good system asks for the approval in a channel it records, so the reply lands next to the change it authorizes.
How should a buyer judge the answers?
Judge the record by whether an outsider can rebuild the decisions, not by how the screen looks. These rules help separate a pass from a near miss:
- Approval after the action fails. If the carrier was told about the new date before anyone approved it, the record shows the problem even if the approval came later.
- A change with no approver fails when the rules say it needed one. A change that was within the rules passes only if the record shows it ran under the rules rather than skipping the check.
- Vague "what" is partial. "Rate updated" without the old and new amounts forces someone back to email.
- A reason in the approver's head is partial. The request should carry the why, so the approval is informed.
- Two changes, one approval, needs care. If a carrier switch also raised the rate, the record should show both were in front of the approver.
Also ask where the record lives. It should be on the shipment, readable by operations and finance alike, and exportable when a customer or auditor asks. Be wary of overclaiming in either direction: a shipment history that records messages, confirmations and changes is what a freight team needs here; it is not the same thing as a formal compliance system, and a buyer with specific regulatory requirements should test against those separately.
The traceability test: one load, five changes
Run the test on one real or realistic load, introduce five changes in sequence, then hand the finished load to someone who was not involved and ask them to fill in the table from the record alone. Amounts and thresholds below are illustrative.
| # | Change introduced | Needs approval? (illustrative rule) | Reviewer must find on the load | Fails if |
|---|---|---|---|---|
| 1 | Best negotiated rate lands $180 above the configured target | Yes, above the limit | Request with both rates, approver name, approval time before booking | Booked first, approved afterward |
| 2 | Booked carrier cancels; next approved carrier quotes higher | Yes, carrier change plus new rate | Cancellation message, new carrier, new rate, approver, time | Only the new carrier appears, no link to the cancellation |
| 3 | Consignee asks for liftgate at delivery | Yes, accessorial | Consignee request, carrier's charge, approver, time | Liftgate shows up first on the invoice |
| 4 | Customer moves delivery one day later | Yes, date change on a committed order | Customer message, old and new date, approver, carrier confirmation | Carrier told before approval |
| 5 | Pickup window shifts two hours, same day | No, within rules | Change and carrier confirmation recorded, marked within rules | Not recorded at all |
Score each row pass, partial or fail. A load passes when every row is a pass and the reviewer never had to leave the shipment record. Row 5 matters as much as the others: a record that only captures exceptions leaves gaps in the story of the load.
How Wilson, by Cartage, keeps approvals on the load
Wilson asks for approval when a change falls outside the company's configured rules, and records the request, the reply and the resulting action in the load's shipment history. Wilson, by Cartage, is an AI logistics agent that replaces the TMS for freight execution and connects to the company's ERP.
Wilson negotiates against the company's rate targets under configured rules and approval limits; a rate outside those limits goes to the logistics team. It books only carriers the company has approved, and when a carrier cancels, it starts rebooking from the approved list, within the rules or with approval, depending on configuration. How accessorial and date changes are routed depends on the approval rules the company configures. Messages, confirmations and changes are recorded in shipment history, so the carrier's revised quote, the approval request and the reply sit on the same load, and the records can be searched and exported.
Wilson starts with assisted execution. The company sets the approval boundaries, and what runs inside them can expand step by step as the team gains confidence. Exactly which fields an approval request carries and where approvers reply depends on the customer's setup and scope.
Bring a load that changed three times before it delivered, and see how each change is handled under your approval rules and recorded in shipment history.
Sources
- Cartage, Wilson product FAQ and product scope, October 2026: https://cartage.ai