Release Notes 8/17/26 - 8/30/26

Disputes Workflow Updates

• Sorting has been added to the following columns in the Disputes Queue:
  • Age (Days)
  • Days Since Last Touch
• Sorting now exists for every numerical value column in the Disputes Queue.
• Filtering by Dispute Reason has been added as well. Users can click the "Reasons" button in the top right corner on tabs in the Disputes Queue to see a drop-down menu with all possible Dispute Reasons, which can be selected to filter what they see in the grid.

Dispute Group Description/ID added to API

• Tenants consuming Disputes via API will now have the Dispute Reason Group (identifier + description) returned alongside each dispute reason.
• This information can be used to route and distribute disputes internally.

Separate Missing Doc and Missing Signature Exceptions

• Tenants wanted more visibility into whether they're spending more time dealing with Missing Documents or with Missing Signatures. They're more comfortable removing signature requirements for certain customers than full document requirements, so this split will increase their automation.
• Previously, these exceptions were combined into the same exception message.
• The Flex rule has been updated to offer the ability to split these exception messages, making it easier to highlight what is actually missing:
  • Is Document present → No
    • Exception message displayed will call out which document is missing
  • Is Document present → Yes … Is Signature present → No
    • Exception message displayed will call out that the document requires a signature

New Canonical Rule: Customer and Charge Work Instructions

• A new canonical Flex rule has been created that can be used across any tenant with the need to trigger a work instruction when a specific customer / vendor / charge combination exists on a record.
• The rule includes a decision table with the following columns:
  • List of Customer IDs
  • List of Vendor IDs
  • List of Charges
  • Work Instruction Messages
  • Approval Blocking (True/False)

New Filters Added for Unmatched Invoices

• Building on the Bill-To column added to the Unmatched Invoices grid last release, users can now filter the grid as well. The following filter groups have been added:
  • Bill-To Location
  • Origin
  • Destination
• Each filter group filters on the following:
  • Name
  • Address
  • City
  • State
  • Zip

LINEITEMVARIANCE Variable

• A new variable, LINEITEMVARIANCE, has been created to assist with more granular dispute communication. Previously, users were not able to easily drill down to the specific individual charges that had a variance without manually calling them out in the email body of their dispute communication.
• Users can now create a Dispute Communication Template that uses the LINEITEMVARIANCE variable, which will automatically populate any individual charges on an invoice matched to an order where there are different charge amounts for the same charge type.

🐞Optimizations

Sunnybrook: fall back to order number when the carrier invoice has no invoice number

• When Navix pushes an approved carrier invoice document to Sunnybrook, it sends the invoice number from the audit result. Some carrier invoices arrive without an invoice number, so Navix sends nothing and Sunnybrook rejects the upload with: "The invoice number field is required when document.type is carrier_invoice."
• The document never reaches Sunnybrook, so the customer does not see the approved carrier invoice in their TMS and has to chase it manually.
• Expected behavior after fix:
  • When a carrier invoice document is pushed to Sunnybrook and the invoice has an invoice number, Navix keeps sending the invoice number — no change to today's behavior.
  • When the invoice has no invoice number, Navix sends the order number instead so the document is accepted.
  • The document is delivered to Sunnybrook in both cases — no failed pushes purely because the invoice number is missing.
  • If neither an invoice number nor an order number is available, the invoice is no longer dropped silently; it is reported as a failure that support can act on.

Sunnybrook: Approved-invoice document delivery stops entirely when one document is too large

• When Navix pushes approved-invoice documents to Sunnybrook, one oversized document fails the whole delivery. The remaining documents on that invoice are never sent, POD approval is skipped, and the message dead-letters with no way to recover — replaying it fails the same way.
• The size limit was also measured incorrectly. Documents are hex-encoded for transport, which doubles their size, but Navix only compressed files over 30 MB. Anything between ~15 MB and 30 MB was sent uncompressed straight into a guaranteed rejection — a real 16.22 MB document produced a ~32.4 MB payload and was rejected with a 413 Request Entity Too Large error.
• The result was that approved invoices reached Sunnybrook incomplete or not at all, blocking the customer's AP process, with no automatic recovery.
• Expected behavior after fix:
  • The size limit is now measured against the actual upload payload, so oversized documents are compressed first.
  • Documents that are still too large are skipped, and the rest of the invoice continues to be delivered.

Attested Work Instruction not Advancing to Next Record after Auto-Approval

• Unexpected behavior was identified for tenants with the Auto-Approve feature enabled, where a user had an invoice with only one work instruction present. After attesting to the work instruction, the invoice was auto-approved, but the application wasn't automatically advancing to the next record in the queue.
• This has since been corrected, and the application now automatically advances to the next record as expected.

📊Reports

• No Reporting updates to share in this release