This release brings updates to enhance your cash reconciliation accuracy and efficiency, simplify exception management, and boost your data analysis capabilities.
Reconciliation
New NRL rule operator for cash reconciliations
We continue to improve the user experience of the platform thanks to your feedback.
We have introduced a new NRL rule operator ‘matching type is opposite sign’, which returns true or false
IMPORTANT: Please note that ungrouped accounts will default to ‘false’ for this operator
This allows you to determine what matching type is configured for the account group of a transaction
In the March release we introduce it for the workflow rules. We are working to make this available in calculated fields in future releases.
Single row proposed matches in cash
We are grouping all the transactions that form part of a proposed match into a single line item on the transactions view. This will present the same information visible today for each transaction, but on a single row that has multi-value cells.
Exception management and other workflow actions (labelling, commenting, pinning) will then be performed at the proposed match level.
The pending change details panel at the bottom of the screen will show all the constituents of a selected proposed match, in the same way as on the constituents page.
Enhanced text filtering for comments
We have provided more flexibility to the comment filtering options. You can now use AND / OR logic when filtering the latest comment column.
This functionality is available in 2-sided and 1-sided reconciliations.
Improved visibility into submission routing status
Submission routing issues are now displayed more clearly in the UI, making it easier to identify and resolve configuration issues before they impact your process runs.
Clearer configuration descriptions
We have updated the descriptions for record tracking and auto‑close features in the process settings to give more clarity on how they work in practice.
Reporting
Export widget tables in csv or Excel format
You will now be able to download tabular data directly from individual widgets for further analysis. Data can be exported in csv and Excel formats. The export is available for the following widget types:
- Widgets that display tables as the primary view (e.g., ‘run status’).
- Drill-down tables (such as list of processes accessed from ‘exception by groups’)
Drilldown tables added to dashboard PDF export
We have updated the format of the Dashboard PDF export file. It now includes tables opened through drilldowns, so your downloaded reports match the exact detailed data you see on screen.
Fixed bugs
| Issue Addressed | Description |
| When users filtered a column in the cash results screen and saved that as a view, the data was correctly filtered when they came back – but the small “filter” icon on the column header disappeared. This made it look like no filter was applied | The UI was updated so that whenever a saved view has filters applied, the filter icon reliably appears on all filtered columns – even after changing buckets, refreshing the page, or opening the process in a new tab. This makes it clear at a glance that you’re working with filtered data. |
| On the “constituents” page, the history panel on the right was semi‑transparent, allowing the table’s vertical grid lines to be seen faintly. | The history panel’s background was made fully opaque on this page. When you open it now, it cleanly overlays the table underneath so no column dividers or grid lines show through, improving readability. |
| For custom text fields in parent transactions, the parent value should be taken from the child with the highest amount. In some cases, the parent text field was ending up empty, even though one of the children had a valid value. This meant downstream views and exports could show missing information at the rolled‑up level. | The logic was corrected so that empty text values are no longer treated as real values when building the parent. Only non‑empty values are considered, and the correct child value is promoted to the parent. As a result, rolled‑up transactions now reliably show a meaningful text value instead of a blank. |
| An edge case was discovered with advanced matching rules (with multiple passes and conditions comparing dates) where some transactions could not be fully processed. The system ended up in an error state (“Unprocessed transactions” on a statement) instead of simply deciding that the rule condition didn’t apply to those records and should have just resulted in “no match” for those transactions. | The matching engine was made more robust when evaluating these complex rule conditions, especially when fields can contain multiple possible values. In the problematic scenarios, the rule condition now safely evaluates to “not satisfied” rather than triggering an error. The outcome for users is that matching completes as expected and they no longer see “Unprocessed transactions” caused by this edge case. |
| On the Multi‑pass settings page, when a user edited a pass and cleared the “Name” field, the input box itself vanished. There was no way to type a new name without discarding all changes and starting over. | The behaviour of the name field was fixed so that the input remains visible even when it is empty. Users can now clear the old name and type a new one in the same place, then save. |
| When turning off the setting that allows clients to turn off the rule “every manual action must be done by the assigned user.”, the system behaved as if it was on behind the scenes. As a result, some users were blocked from taking manual actions in cash processes, even though the configuration said these assignment checks should not be enforced. | The permission checks were brought in line with the configuration so that when cash_enforce_user_assignment is turned off, the system genuinely stops enforcing those assignment rules. Users can now carry out manual actions as expected when the client has chosen not to require strict user assignment. |
| Sometimes changing field settings in a staging copy of a cash process (for example, changing a field from date to text, or changing match rules) could accidentally create duplicate internal field records. When those changed configurations were applied and users tried to export to Excel, the export failed with an error. From a user perspective, this looked like “Excel export just breaks after applying a change request”. | The process that applies field changes from staging to the live process was tightened up so that it no longer creates duplicate internal field entries. The validation module was updated and integrated so that configuration changes keep the field list consistent. With these safeguards in place, Excel exports now succeed after such changes, and existing customers affected by this pattern are protected going forward. |
| When configuring matching passes, rapid changes (for example, quickly clicking “Move up” multiple times) could sometimes result in two passes being given the same position in the list. This “duplicate order” confused the system and could cause errors or unstable behaviour when working with passes. | The reordering logic for passes was strengthened so that the system always reloads the latest pass position from the database once it has a lock, ensuring each pass keeps a unique order even under heavy or rapid use. In practice, this prevents two passes from ending up with the same position and removes the associated crashes and configuration inconsistencies. |
| When boolean fields were used in certain reconciliation views, their values were sometimes calculated incorrectly, shown as blank, or caused manual matches to fail. This meant users could see missing or misleading Yes/No information for grouped and manually matched transactions. | We’ve corrected how boolean (Yes/No) fields are calculated and displayed. Grouped and manually matched transactions now show the correct values in all relevant views, and manual matching no longer fails because of these fields. |
| When a match field and a reported field shared the same name (e.g. “Trade Date”), the record details screen could behave inconsistently due to duplicate internal identifiers. | Fields with the same display name are now handled correctly so record details render reliably without errors. |
| When adding a rule that pointed to an existing reference data table (RDT), the system could incorrectly require permission to create a new RDT, blocking valid configuration changes. | Rules that use an existing RDT now only check for the correct permissions and can be created/edited as expected. |
| After completing a bulk action in an NSR process, the success notification count could increase each time the user changed buckets, giving the impression that multiple actions had run. | Notification counts now remain accurate when switching buckets after a bulk action. |
| Filter values that began with a leading space were sometimes excluded and did not appear as available filter options. | The filter value handling has been updated so values starting with spaces are now correctly returned and can be used in filters. |
| When exception categories were locked due to workflow or change control, the tooltip incorrectly suggested that workflow exceptions needed to be configured, even when they already were. | The message shown for locked exception categories has been corrected to reflect the actual configuration state. |
| It was possible to start a new run on a matching process while a previous run was still reverting, which could lead to failures after a timeout. | When a previous run is reverting or being marked as failed, the Run button is now disabled with an explanatory message, preventing overlapping runs on the same process. |
| When uploading files to a Reference Data Table (RDT), the “Uploading…” notification sometimes stayed on screen indefinitely, even though the upload actually finished successfully within a few seconds. Refreshing the page made the notification disappear and showed the uploaded data, but the status message itself was not being updated correctly. | We fixed the logic that tracks the completion state of RDT uploads so that the notification now updates and disappears as soon as the upload has actually finished. No refresh or manual intervention is required anymore. |