Release Notes 11/10/25

We updated the fuzzy matching logic to function as below:
- If there is no "Remit To Name" on the invoice (or the "Remit To Name" is "N/A") Order
  - We perform a fuzzy match between the "Remit To Address" on the order and invoice
  - If they're within a certain threshold, we update the "Remit To Name" on the invoice

Up to this point, Navix only stored external contacts for Vendors and Customers, limiting our ability to automate communications that involve internal stakeholders such as Brokers, Carrier Sales Reps, AR/AP Contacts or other team roles.
In our current Disputes platform, 65% of our Disputes/Emails are internal
The Expand Contacts initiatives now introduces the ability to access and use these internal contact roles from the Order data sent by the TMS. By mapping these fields, we can work towards the following
- Automating communication workflows (e.g. “Email the Broker if a rate discrepancy occurs”)
- Power new reporting capabilities (e.g. “Exceptions by Broker”)
- Prepare Navix for more advanced automation under the Communication module
  - This will position us for proactive outreach, auto-disputes, and inbox management by ensuring Navix knows who to contact when exceptions occur

Since the Customer Billing queue was rolled out, users have been required to manually re-audit each Order in an attempt to resolve an exceptions that have triggered
We’ve made an update to automatically re-audit Orders similarly to how we already re-audit Invoices. The following events are when the Order will be automatically re-audited:
- Order created
- Order updated

Summation Node
- It was a previous limitation that we couldn’t have a Flex rule with multiple different Exception nodes that could trigger at the same time (i.e. only one of these exceptions could trigger at a time)
- This new node provides the opportunity to now have a rule where two completely different Exceptions can trigger at the same time
  - For example, if a tenant previously had two legacy rules checking for a CarrierHold metadata field value on one and checking for a CustomerHold metadata field value on the other, we can now have all of that logic within the same Flex rule and can trigger two different Exception messages if needed using this new node
Fuzzy Match Node
- This new node allows a user to compare two different variables in a Flex rule and evaluate the similarity of those value with our fuzzy matching concept
- An example of how this could be used (likely the most common scenario)
  - Variable1 = InvoiceRemitToName
  - Variable2= OrderRemitToName
- The node will then calculate the fuzzy matching score for the similarity of the two variables to determine if there is a difference that would require an exception to trigger
  - This can be done using the Similarity variable within the node, and using a Switch statement (RemitToSimilarity < 80)

An indicator has been added in the UI for an invoice that was received via the Quick Pay mailbox (and has the “isQuickPay” value set to true)

Previously, when an invoice was submitted via the “Ingest Documents” endpoint, the source on the invoice was showing as “Email”
This has been updated to list the source as “API” since the document was submitted via API
- This change also makes the troubleshooting process easier for tenants that are using the “Ingest Documents” endpoint. When testing, they can easily find the submitted item

A fix was implemented to ensure an error message displays in the UI when the re-audit endpoint returns a failed response in the Customer Billing queue

When users were applying filters to the Customer Billing Queue, they were disappearing when the user would leave the page
- This is not the same behavior that we have in our other queues, and was not the intended behavior for this queue
This issue has been fixed now, so that when the user leaves the page to go to another queue or even when they log out of the application, their filters in the Customer Billing queue remain

Up to this point, when an Order didn’t include a value for the Delivery Date, the value for the field in the UI was being auto-populated with “12/31/0001”
This has been updated to simply leave the value in the UI blank if there isn’t a Delivery Date provided

The Fuzzy Matching node stated it allows for Zen expressions, however wasn’t working properly with string literals; this has now been fixed.
For example, below is a snapshot of two strings that are very dissimilar, but return a similarity of 100:

There was a disconnect between what displayed in the Customer Billing queue and what was included when a user downloaded the queue into an Excel file
- These queue view and the Excel download are intended to match, so an update was needed
The fields and data included in the download feature have been updated to now include the following just like the UI does:
- Order External ID
- Order Number
- Exceptions
- Customer
- Vendor
- Delivery Date
- Doc Rec'd Date
- Has Invoice
- Approved Date
- Approved By

Release Notes 11/10/25 - 11/23/2025