Navix Labs - Ideas Portal
Navix currently accepts Order Updates from a customer’s TMS after the initial vendor’s invoice on that Order has been approved. This change was made to support multi-vendor Orders, where subsequent legs might complete after the first vendor is invoiced.
However, for customers like Evans—who only ever have one vendor per load—continuing to accept updates post-invoice creates problems. Since Evans’ TMS does not separate “Invoice Costs” from “Rate Costs,” the updated Order overwrites the original quoted rate with the Invoice Adjusted Total. This results in a loss of original rate history, impacting audit trails, reporting, and dispute management.
The goal of this project is to introduce a way to stop accepting order updates after invoice approval for customers who need to preserve original Order Rate data, while still supporting multi-vendor workflows for other customers.
Current State:
Orders arrive from the customer’s TMS at load pickup.
Navix processes Updates to Orders during the lifecycle of the load.
Once the first vendor’s invoice is approved, Navix currently still accepts updates from the TMS.
For multi-vendor loads, this ensures we can still process subsequent vendors.
Pain Point for Some Customers (e.g., Evans):
Only one vendor per load.
TMS systems do not differentiate between invoice costs and rate costs.
Post-approval updates from the TMS overwrite the original quoted rate with the invoice’s adjusted rate.
This results in losing historical rate data, impacting audit visibility and accuracy in downstream systems.
From Ben at Evans: "The idea here is that when an invoice gets moved to a terminated status or a approved status it takes a lock of what the order rates and all the details at that point are so that if a new invoice comes in we don't have details from mercury gate overriding that original one not being able to show variance adjustments and everything that has already happened."
Introduce logic to block Order Updates only once all vendors on the load have had their invoices approved.
Still allows updates to Orders in multi-vendor scenarios until all legs are complete.
For single-vendor loads (e.g., Evans), the result is the same as Solution 1—updates stop after that one vendor’s invoice is approved.
Trade-offs:
Pros: Protects original rate for single-vendor customers without breaking multi-vendor workflows.
Cons: Slightly more complex logic; must ensure robust vendor completion detection before blocking updates.
TONU- If we were to pay a TONU carrier before the new carrier has come in, we won't get the new Vendor update.
Implement a rule that prevents Navix from accepting any further Order Updates once any vendor’s invoice on that Order has been approved.
Reject updates received after the first invoice is approved.
Provide clear messaging/logging to the tenant when updates are rejected.
Trade-offs:
Pros: Completely prevents overwriting original Order Rate for customers with single-vendor Orders.
Cons: Breaks workflows for multi-vendor Orders where subsequent legs require updates after the first vendor’s invoice is approved. We would need to make this tenant specific
Do not change Navix’s acceptance rules. Instead, require customers like Evans to manage the separation of Invoice Costs and Rate Costs on their side.
Customer uses their TMS or integration layer to ensure post-invoice updates do not overwrite original rate data before sending to Navix.
Trade-offs:
Pros: Zero development effort for Navix; no changes to existing multi-vendor handling.
Cons: Shifts the burden entirely to customers, increasing their operational workload.
May negatively impact customer satisfaction and adoption if they see this as a gap in Navix’s automation capabilities.
Effort Estimate: None for Navix; unknown for customer.
Preserve Data Integrity: Prevents loss of original Order Rate data, critical for accurate auditing and dispute resolution.
Reduce Manual Work: Automating the “no updates after approval” rule reduces the need for manual data corrections.
Customer Retention: Addressing specific pain points for key accounts like Evans increases customer satisfaction and long-term retention.
Support Complex Use Cases: A configurable approach (Solution 2) maintains flexibility for multi-vendor customers, aligning with Navix’s goal of serving a wide range of brokerage models.
