Version 5.15.0 has been released on 6th 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-2667 [Bank Connectivity] UI Restructure & Secure Connection Revocation
This update introduces a significantly improved layout for the Bank Connectivity Dashboard, designed to make multi-account management more intuitive. To provide better organisation, we have introduced a new Bank Institution grouping level, allowing users to view all accounts associated with a specific bank under a single heading. This restructure also includes a clearer, tiered table design with shaded backgrounds for child levels to improve readability at a glance.
Key user interface improvements include:
The "Link Bank Account" button has been renamed to "Link Bank", and the "Filter By" label has been removed to create a cleaner header
The "Bank" column at the account level is now accurately labeled as "Bank Account"
New buttons for "Link Bank Account" and "Remove Bank Connection" have been added at the Institution level. With "Link Bank Account" users can now add additional Bank Accounts to an already existing Bank connection
With this release, the "Remove Bank Connection" action is introduced too. When initiated, the system performs a secure API call to revoke the access token, ensuring end to end removal of ZoneReconcile's Bank data ingestion and access. To maintain data integrity, the system will automatically inactivate the Bank Institution record and all linked Multi-Statement and Bank Account Configurations, while clearing connectivity metadata to prevent orphan syncs. A new confirmation modal provides a clear warning before removal, and robust error handling ensures that if a revocation or record update fails, the dashboard remains active for troubleshooting without data loss.
BR-2814 [BankConnectivity] Missing counterparty (entity) data
The system's Plaid synchronisation logic has been upgraded to improve data quality and matching rates for credit transactions. Previously, certain transactions resulted in "Undefined Counterparty" entries due to gaps in the data import. The updated parser now uses a tiered approach: if the primary counterparty field is missing, the system automatically pulls from the Merchant Name tag, with a fallback to the Name field for older files. This ensures credit transactions contain the richest possible data, matching the quality of manual CSV exports, while maintaining full compatibility with historical records and existing debit workflows.
BR-1938 Bank statement Custom matching rule "AND" expression
The system’s Custom Matching Rule (CMR) logic has been updated to provide broader matching capabilities when multiple criteria are defined. Previously, when a user entered values for both the "If Description" and "If Counterparty" fields, the system lacked clear logical processing for these combined filters. With this update, these criteria now function using "OR" logic instead of "AND."
This means a custom rule will be triggered if the system finds a match for either the Description or the Counterparty, significantly increasing the success rate of automated matching for statements where data may be inconsistent or incomplete across different fields.
BR-2862 Remove the deletion (roll-back) of transactions created in processing scripts
This version removes the legacy "rollback" logic that automatically deleted transactions if a bank statement process was only partially successful. Previously, if the system created a Payment Difference Journal but failed to generate the final payment, it would delete the journal to reset the line. To support strict audit requirements, the system now preserves all created records, even if the overall process encounters an error. Instead of deleting data, the system will now keep the created journals and flag the Bank Statement Transaction with a clear error message for manual review. This ensures a complete audit trail and prevents the "silent" disappearance of transactions during complex reconciliations.
Bug fixes
BR-1953 EFT batch popup > amounts are shown with consolidated rates
This update resolves a display issue where EFT batch amounts were incorrectly displayed using consolidated exchange rates instead of the subsidiary's base currency. In multi-subsidiary environments where the parent company’s currency differs from the child subsidiary, the system previously defaulted to a consolidated view in the Alternate Match Type popup. This led to manual calculation errors and unexpected validation warnings during the reconciliation process.
To address this, the underlying transaction search logic has been refined to disable consolidated exchange rates. The system now correctly displays batch amounts in the actual currency of the subsidiary and the specific bank account. This fix ensures that Bill Payment amounts reflected in the matching window align exactly with the bank statement lines, eliminating the need for manual adjustments and ensuring a seamless, error-free submission.
BR-2581 Invoice / Vendor Bill applied in Multiple Statements > Payment is created with incorrect Amount
The PSP payment processing logic has been upgraded to prevent discrepancies that occur when a single invoice or vendor bill is matched across multiple bank statements simultaneously. Previously, if an open transaction was matched in two different statements (a common occurrence for high-volume customers using Customer IDs as matching parameters), the system could incorrectly generate a payment for the remaining balance even if it did not match the bank statement line amount.
This update introduces a strict integrity check during the processing phase. The system now validates that the available balance on a matched invoice or bill is sufficient to cover the statement line. If the amounts do not align, typically because a portion of the balance was consumed by another statement processed moments earlier, the system will block the payment creation. Instead, the line will be marked with a clear error message: "Payment amount ($X) does not correspond to the Bank Statement Transaction Line amount ($Y). Review is required." This ensures that no "silent" differences are created between the bank statement and the General Ledger, maintaining full financial accuracy for both Customer and Vendor payments.
BR-2775 5.13.2 > Matching closed on Parameters > Overpayment is selected automatically incorrectly
The system's matching logic has been refined to prevent the incorrect auto-selection of closed transactions during bank statement processing. This update addresses a high-priority issue where the system was automatically marking transactions as "Selected" (Select = Yes) when a match was found based on parameters, even if the transaction amount was lower than the bank statement amount (an overpayment).
BR-2824 5.13.x > Customer Payments are booked to Undeposited funds
This update resolves an issue where the system incorrectly recorded Customer Payments against the Undeposited Funds account rather than the designated bank account. This behaviour occurred in cases where the selected Payment Method was configured to group funds, causing the system to override the bank account selection during processing.
BR-2908 Fix "Sum Postings in One Grand Amount" functionality
This version resolves an issue where Custom Matching Rule (CMR) aggregation failed to correctly identify unique configurations when multiple Multi-Statement setups shared the same identifier.
To ensure robust behaviour, the aggregation logic has been updated to reference the search result identifier property directly, rather than relying on object keys. This fix ensures that bank statements are imported correctly, listing transactions individually when no CMR is present and that specific rules are applied accurately even across overlapping configurations.
BR-1782 Discount not taken over in Popup from auto-matched lines
Previously, when a bank statement line was auto-matched to an invoice with an eligible discount, opening the matching popup would fail to display the discount details, forcing users to manually re-select the transaction to trigger the calculation. With this enhancement, the system now ensures that when the Show Payment Discounts preference is enabled, the Disc. Taken and Percentage Paid fields are automatically populated upon opening the popup for any auto-matched line. This ensures visual consistency between the background matching logic and the user interface, eliminating redundant manual clicks and providing immediate confirmation that discounts have been correctly applied.