Keeping rates current is essential, but uncontrolled updates can break quoting, create double-pricing, or cause teams to send inconsistent prices to customers. This guide explains how to update rates safely in Velocity using version control, effective dates, duplicate/conflict rules, and operational best practices.
Velocity supports maintaining multiple rate versions, with rollback history and audit trails, so you can publish updates confidently and recover fast when something goes wrong.
Why Version Control Matters (Pricing Accuracy + Governance)
Version control is not just an administrative feature, it is a pricing safeguard.
Without version control, rate updates commonly lead to:
- Quotes using outdated pricing because someone is referencing an old spreadsheet
- Overlapping rate entries that cause unpredictable totals
- Two different teams quoting two different prices for the same lane on the same day
- No clear answer to: “Who changed this rate, when, and why?”
With version control, you gain:
- Consistency: One approved set of rates feeds quoting across teams.
- Traceability: You can prove what changed and when.
- Recoverability: You can roll back quickly if an upload or rule change is wrong.
- Controlled rollouts: Updates can be planned by effective date instead of pushed ad hoc.
Versioning Model: When to Create a New Version vs Edit in Place
A safe rate operation depends on knowing when to publish a new version and when to make a small correction.
Create a New Version When…
Use a new version for any change that could affect quoting outcomes at scale:
- New contract rates for a carrier or lane set
- Seasonal updates (peak season, fuel changes, general rate increases)
- Large spot-rate refreshes
- Changes to charge structures (renaming charges, adding/removing line items)
- Any upload that touches many lanes or many customers
Why: new versions preserve history, allow comparison, and enable rollback.
Edit In Place Only When…
Edit in place only for minor, low-risk corrections:
- Fixing typos in provider name or internal notes
- Correcting one lane that was clearly wrong and not broadly used
- Fixing a single charge value where you can validate impact immediately
Rule of thumb: If the change would require a customer explanation if discovered, it should be a new version.
Effective Dates: Validity Windows and “Go-Live” Planning
Effective dating is how you keep old and new prices from colliding.
Key Concepts
- Validity window: the date range during which a rate is considered active and selectable for quoting.
- Go-live planning: choosing a start date for the new version that avoids overlap with existing active rates.
Best Practices for Effective Dates
Set your new version Valid From to the intended rollout date (not “today” by default).
Avoid overlapping validity unless you have explicit conflict rules.
If a carrier provides rates “effective immediately,” still plan a controlled go-live:
- Publish the version first
- Validate with test quotes
- Then set it active for quoting (based on your governance model)
Common Effective Date Mistakes
- Backdating: can unintentionally change previously sent quotes.
- Overlaps: create unpredictable “winner” selection if two rates match the same lane.
- Gaps: lead to “no rate found” for valid shipments.
Duplicate Detection: What Counts as a Duplicate
Duplicates are the most common cause of double-pricing and inconsistent quotes.
A rate is typically considered a duplicate when all of the following match:
- Lane: Origin + Destination
- Mode: FCL / LCL / Air / Courier
- Provider: carrier/vendor
- Validity: overlapping or identical valid-from/valid-to
- Equipment/Unit: container type, per-CBM, per-kg, etc.
- Charge set: same charge lines (or functionally the same total structure)
Practical Examples
- Two rows for Dubai → Hamburg, FCL, Carrier A, 40HC, same dates, same base freight: duplicate.
- One row has “BOF” and the other has “Basic Ocean Freight” but values match: likely duplicate unless normalization rules treat them differently.
How to Prevent Duplicates
- Upload in batches (by carrier or by region) to isolate issues.
- Standardize your lane naming/codes and equipment formats.
- Use versioning instead of “adding on top” of existing rates without retirement rules.
Conflict Rules: How to Decide Which Rate Wins
A conflict occurs when more than one rate could apply to the same quote request.
You should define and document “winner” logic so pricing outcomes are predictable and explainable.
Common Conflict Rule Options
1) Newest Version Wins (Recommended Default)
Use when you treat each version as the authoritative set.
- Pros: predictable, simplest governance.
- Cons: requires discipline; bad uploads affect everything unless caught.
2) Best Price Wins (Use with Caution)
Use when you want the lowest buy rate automatically selected.
- Pros: can improve competitiveness.
- Cons: can select rates that are incomplete or missing required surcharges.
3) Preferred Provider Wins
Use when you have strategic carrier preferences.
- Pros: aligns with procurement strategy and service performance.
- Cons: may not reflect best market pricing at a given moment.
4) Source Priority Wins (Contract > API > Spot, or the reverse)
Use when you want stable contract pricing as fallback, or live APIs as the default.
- Pros: aligns to your commercial approach.
- Cons: requires clear documentation and training.
Recommended Operational Policy
- Use newest version wins within the same source type.
- Use source priority to decide between Contract vs Spot vs API.
- Document exceptions (e.g., key accounts use contract only).
Rollback Workflow (and When to Use It)
Rollback is your safety net when an upload, mapping, or rule change produces incorrect quotes.
When to Roll Back
- A major lane set shows incorrect totals in validation
- Currency or unit mapping was wrong in a bulk upload
- Duplicate rates cause doubled totals or unpredictable selection
- A new version goes live prematurely
Rollback Workflow (Safe Approach)
- Pause publishing of the new version (or remove it from “active” use, depending on your setup).
- Identify the impacted scope
- Which modes, lanes, providers, and customers are affected?
- Roll back to the prior known-good version
- Confirm the previous version restores expected quote results.
- Re-test “golden lanes”
- Run a quick set of baseline lanes you always use to validate quoting.
- Fix the root cause
- Correct file mapping, validity, duplicates, or charge lines.
- Re-publish as a new clean version
- Avoid patching a broken version unless the system governance requires it.
Best Practice
Maintain a short list of golden test lanes (top-volume lanes per mode) to validate every update before and after publication.
Audit Trail: What Gets Recorded and How to Use It
Audit trails reduce pricing disputes and help enforce governance.
A good audit trail should allow you to answer:
- What changed (lane, charge, validity, provider, rule)?
- Who changed it?
- When did it change?
- Which version was active at the time a quote was generated?
How Teams Use Audit Trails
- Pricing managers: explain pricing changes internally and externally.
- Ops leaders: enforce approval workflows.
- Sales ops: confirm which version applied to a customer quote.
- Admins: investigate issues after a spike in pricing complaints or lost deals.
Operational Tip
When issues arise, treat the audit trail as the “source of truth” for investigation:
- Identify the quote outcome that is wrong
- Identify which rate version applied
- Review what changed in that version
- Decide: fix-forward vs rollback
Quick Checklist: Safe Rate Updates Every Time
Use this checklist as a standard operating procedure:
- Create a new version for bulk or impactful changes
- Set effective dates intentionally; avoid overlaps unless conflict rules are defined
- Run duplicate checks: lane + mode + provider + validity + equipment/unit + charge set
- Confirm conflict rules: version priority, provider preference, source priority
- Test golden lanes before go-live
- Publish, then monitor early quote outputs
- Roll back immediately if outcomes are materially wrong
- Use audit trail to document the incident and prevent repetition