Which rate confirmation version should a broker use?
Format: Article.
Use the version your approved rate reviewer has checked and cleared for the load. Do not pick a file just because it arrived last. A new filename or the word “final” does not make it the agreed version. Receiving a rate sheet is not the same as accepting its terms.
When rate confirmations clash, keep both files. Show what differs so the right person can decide. The task is to choose which terms apply to a load already on the books. It is not a profit check or an invoice process. Keep those jobs separate from the version review.
The steps below are a proposed way to manage file versions. They do not settle whether a contract is legally binding. If the terms or proof of agreement are unclear, ask the company's approved commercial and legal reviewers. A software label cannot resolve that question on its own.
Give every received version an identity
Save each file unchanged. Give it its own ID and keep the source message, sender, and time it arrived. Keep the filename too, but do not use it as the only way to tell versions apart. Two different files can both be called final.pdf. The review must still show both.
Link each file to the internal load, customer, and the other party named in the deal. Different customers may use the same load number. That number alone is not enough to match the file. If staff fix a wrong link, keep a record of the old one and why it changed.
Give each version a clear state. It may be received, under review, cleared for use, replaced by a newer version, or disputed. These are suggested office labels, not legal findings. Define what each label means and which proof it needs. Keep that proof beside the decision so staff can check it later.
Prepare a version comparison packet
| Packet section | What to show |
|---|---|
| Load identity | Internal load ID, parties, customer reference |
| Candidate files | Original files, sender, receipt time, document IDs |
| Current authority | Last accepted version and the evidence for its use |
| Changed amounts | Old and new values, currency, named charge components |
| Changed work | Stops, dates, equipment, service, or other changed terms |
| Acceptance evidence | Relevant correspondence or approval record |
| Open questions | Unexplained differences and missing confirmations |
| Decision | Reviewer, selected version, reason, effective scope |
Check the terms, not just the main amount. The rate may be the same while a stop, appointment, or charge rule has changed. Show those differences too. Do not write “no financial impact” unless the approved reviewer has checked that claim. The same price can cover a different job.
If a tool reads text from the file, show the original beside the result. A missed line or page can change what the comparison shows. Matching text tells us about the files. It does not prove that both parties agreed to those terms.
Work through a hypothetical revision
Imagine a broker receives version V1 for load B730. Later, an email supplies V2 with a changed delivery stop and an additional charge line. A separate message says the change is still being discussed. These are invented records for training.
The operator saves V2 as received, not accepted. V1 stays marked as the last version cleared for use. That does not mean staff should act on disputed instructions. The reviewer checks the discussion first. The packet shows the changed stop and charge. It keeps the message that says the change is still being discussed.
The reviewer asks the approved contact on the other side to clarify the terms. Use the company's agreed contact process. If the records support V2, record that proof and exactly what the decision covers. If they do not, V2 stays disputed. The system must not choose an amount just to clear the conflict.
Dispatch must also check the stop change through its own process. Accepting a rate sheet does not prove that the driver got the new plan. Both teams need a clear answer, but they are checking different things.
Preserve the decision history
When a new version replaces an old one, keep the old file. Record why it changed and when staff used it. A later review may need to show which terms the office had at that point. Do not put V2's contents under V1's ID. That would make the old record misleading.
Name who made the choice and the proof they used. If they cleared just one changed charge, say so. Do not use a broad “approved” label. Staff may read it as approval of every page and term, not just the part the reviewer checked.
If another version arrives after review, reopen the comparison for that revision. Earlier approval should not automatically attach to a new file, even if the filename and headline rate are unchanged.
Use three practical tests
First, send two different files with the same name. The review process should preserve both and flag the content difference. Second, send the same file twice. It should retain the receipt history without creating a new commercial decision.
Third, send a new version while someone approves the one before it. The final record must name the exact file they approved. The new file still needs review. The system must show that both events happened. It must not guess that the reviewer meant to approve a file they had not seen.
Core Agentic's TMS sales material describes rates and files tied to loads. Bring two rate sheets that clash, with private details removed. Discuss how a custom version review could help your team choose which file to use. Book a Demo.
Sources and scope
Core Agentic TMS and design context. The operating steps and fictional examples are first-party recommendations, not verified installed controls or customer results.