Version 5.16.0 has been released on 20th of January 2026 and contains a couple of enhancements and bug fixes. Below you can find more information related to the enhancements and bug fixes. We will update your Production account automatically and the Sandbox account can be updated from your (the customer's) end at any given time.

Enhancements

BR-1458 Auto-matching not working when string does not contain any number

This version release introduces an enhancement to the Bank Statement Matching logic to support transaction references that do not contain numeric characters. Previously, the matching engine automatically ignored any reference strings lacking digits, which prevented automatic matching for users using purely alphabetical Order IDs. 

To address this, a new "Allow non-numeric matching" checkbox has been added to the Bank Account Configuration record under the Matching Preferences section. 

When this option is enabled, the system will successfully match transactions based on exact strings, even if they contain no numbers. This setting is disabled by default, so users requiring this flexibility should update their relevant account configurations to ensure seamless automated reconciliation.

BR-2920 [Bank Connectivity] Duplicate transactions created

An architectural update has been implemented in the Plaid integration to eliminate duplicate bank statement entries by refining how "Pending" and "Posted" transactions are handled. Previously, the system synced both transaction statuses, which resulted in duplicates when Plaid replaced a temporary "Pending" ID with a permanent "Posted" ID for the same financial event. 

To resolve this, the retrieve logic for both scheduled and ad-hoc syncs now evaluates the pending transactions and exclusively processes transactions where pending: false. 

Bug fixes

BR-1539 Run Match Error: Unexpected non-whitespace character after JSON at position xxxxx

In previous versions, the "Run Match" functionality could become stuck in a matching state due to a JSON.parse() error triggered by unexpected HTML comments appended to the response body. Accordingly, this version release introduces a more robust handling mechanism that strips any trailing HTML comments and explicitly sets the Content-Type header to application/json. These changes ensure that the matching engine correctly parses the data, allowing users to re-trigger matching rules after an import without encountering syntax errors or hanging processes.

BR-1634 Matching DDRs: SSS_USAGE_LIMIT_EXCEEDED

To address performance bottlenecks in large-scale reconciliations, this version release introduces a significant optimisation to the Direct Debit Reversal (DDR) matching logic. Previously, the system would reach NetSuite usage limits when processing statements with approximately 80 or more lines, as it triggered a high-governance saved search for every individual line. 

By refactoring the logic to utilize a streamlined search method, leveraging the existing BS TR C AC search with dynamic filters, the governance unit consumption has been drastically reduced. This change ensures that customers processing large batches of direct debits can now automate their reversals without encountering "Exceeded Usage Limit" errors, eliminating the need for manual selection and increasing overall system stability for high-volume accounts.

BR-1636 Optimise Matching of Closed Transactions Based on Parameters

A performance-driven refactor has been implemented in this update to resolve execution timeouts during the matching of Closed Transactions, specifically for accounts managing high volumes of data. By moving away from the previous method of processing an entire pool of thousands of potential matches, the system now utilizes a sophisticated "pre-filtering" mechanism. 

The matching logic extracts all description strings from the imported statement lines into a single array and uses it to isolate only the relevant transactions before the matching algorithm begins. This optimisation ensures that even statements with thousands of lines can be reconciled against massive datasets, such as the 4,500+ records encountered by users, without hitting script timeout limits. This improvement provides a more stable and scalable reconciliation process for enterprise-level transaction volumes.

BR-1735 Processing of Advanced Intercompany Journal as Closed Transaction: SSS_RECORD_TYPE_MISMATCH The record you are attempting to load has a different type: advintercompanyjournalentry from the type specified: journalentry

This version further resolves a persistent "Record Type Mismatch" error that occurred when users attempted to link Advanced Intercompany Journal Entries (AIJE) to bank statement lines. In earlier versions, the matching engine was hard-coded to treat all journals as standard "journalentry" types, leading to a system failure ($SSS\_RECORD\_TYPE\_MISMATCH$) when encountering an Advanced Intercompany record. The processing logic has been enhanced to dynamically verify the specific record type before loading the transaction. By utilizing a lightweight lookup to distinguish between standard and intercompany journals, the system now ensures that AIJEs are processed and linked correctly without manual intervention or script errors.

BR-1744 Matching of Closed Foreign Currency Transactions Based on Amount > Exchange Rate is Changed to NetSuite's Daily Rate

This release introduces a critical fix for Exchange Rate handling to ensure foreign currency transactions, such as Vendor Prepayments, maintain their intended GL impact. Previously, even when a custom exchange rate was used to match a bank's actual rate, the matching engine would overwrite it with NetSuite’s default daily rate during processing. The logic has been refined to detect when a transaction’s currency differs from the bank account’s base currency, correctly triggering the "fx" parameter to lock the original rate. This prevents unintended currency fluctuations and eliminates the need for manual rate corrections after auto-matching.

BR-1779 Transactions with same Reference and Amount: Entities are assigned incorrectly

A data integrity fix has been implemented in the Open Transaction Matching engine to resolve issues where identical amounts and references exist across different entities. In previous versions, the matching loop could correctly identify a transaction but then incorrectly overwrite the associated entity name with a different vendor from a subsequent match, leading to mismatched GL entries and unlinked journals. This update introduces a strict entity validation check to maintain a precise 1:1 relationship between the selected transaction and its specific entity. This improvement ensures that even when dealing with similar billing records from multiple vendors, the system maintains total consistency between the matched ID and the party being paid.

BR-2928 5.14.x > Bank Balance NetSuite not Calculated when it is 0.00 (map/reduce context)

A targeted refinement has been applied to the Map/Reduce processing logic to ensure that NetSuite Bank Balances are correctly updated when the resulting total is exactly zero. Previously, when processing large statements via background scripts, the system would fail to update the balance field if the calculation reached 0.00, as the underlying code treated a zero value as a "false" trigger. This led to discrepancies where the balance would remain at a previous non-zero value despite the statement being fully reconciled. By updating the validation logic to explicitly recognize zero as a valid balance figure, the system now ensures consistent and accurate balance reporting across all statement sizes and processing methods.

BR-2944 5.14.x > New SFTP Private Key > Fail to evaluate script: org.mozilla.javascript.EcmaError: ReferenceError: \"window\" is not defined

This update resolves an issue that prevented users from creating new SFTP Private Keys within the ZoneReconcile setup. Previously, a system error would occur when trying to open the "New SFTP Private Key" page, blocking the generation of the secure credentials. 

Finance teams can once again manage their secure SFTP connections and generate private key pairs without interruption, keeping their automated bank feeds running securely.

BR-2952 Optimize Matching of Direct Debit Reversals

In addition to optimising the closed transaction logic, this release significantly improves the speed and stability of Direct Debit Reversal (DDR) matching for accounts with high transaction volumes. 

Previously, when matching reversals against already reconciled payments, the system scanned thousands of historical records, often causing the process to time out. The matching engine is now more intelligent; instead of scanning every reconciled payment in the system, it pre-filters results to focus exclusively on the specific transactions referenced in the current bank statement. 

By narrowing the search scope from thousands of results to only the relevant records, the system eliminates timeout risks and ensures even the largest statement imports are processed quickly.