2026

July 2026 release notes

July Platform Release ETA: 24 July 2026

Performance improvements

Memory stability improvements across the application
A comprehensive review and remediation of memory leaks across the application has been completed. Two areas were addressed:
User interface:
 Multiple areas of the application were identified as leaking memory over extended usage sessions. All known leaks have been addressed, along with additional leaks discovered during the audit.
Server side:
 Internal components responsible for keeping the application running smoothly were identified as contributing to gradual memory growth in the backend. These have been fully resolved.
As a result, users working in the application for extended periods will experience a more stable and responsive interface, with reduced risk of slowdowns or unexpected browser behaviour during long sessions. Memory usage now remains stable throughout a typical working session, and the application backend maintains consistent response times over time.
Faster sheet navigation in large workbooks
Multiple improvements have been made to sheet navigation performance. Redundant computation steps that previously ran once per sheet during sort and navigation operations have been consolidated into a single operation, meaningfully reducing navigation times across all workbooks — particularly those with many sheets. In addition, a specific performance issue affecting calculations containing long or wide sheets with a large number of rows and columns, where navigation times were exceeding acceptable thresholds, has also been addressed.
Users working with large or complex calculations will notice significantly faster sheet navigation and sorting. A progress indicator is displayed if any processing still takes longer than a few seconds, keeping users informed throughout.
Faster sheet insertion for large entity calculations
Inserting sheets into datasets with a large number of entities (400+) previously took over two minutes. This operation has been optimised and now completes within 30 seconds. A progress indicator is displayed if the insertion takes longer than expected, keeping users informed throughout the process.
Improved horizontal scroll performance for wide workbooks
Several targeted optimisations have been made to improve the responsiveness of the workbook when scrolling horizontally through sheets with a large number of columns. Previously, all columns in a sheet were loaded at once regardless of whether they were visible on screen, which contributed to sluggishness when scrolling sideways through wide sheets. The application now loads only the columns currently visible on screen plus a small look-ahead buffer, fetching additional columns progressively as the user scrolls — rather than all at once upfront. Further refinements have also been made to reduce unnecessary data loading triggered by rapid scrolling movements.
Users working with wide workbooks will experience noticeably smoother and more responsive horizontal scrolling as a result. Vertical scrolling performance is unaffected by these changes and continues to perform as before.

Feature enhancements

Expanded import API capability: import data into individual cells
The target-based import API has been enhanced to support importing data directly into individual cells that fall outside defined import blocks, including cells on non-standard (Excel) sheets. This capability is available via the API only and is not accessible through the UI. Previously, imports were limited to IMP-marked blocks, requiring manual entry for populating cells outside of these blocks. Customers can now use the same familiar asynchronous import flow — with job tracking, status checking, and full audit trail — for single-cell data entry.
Accompanying UI updates to the Import Details, Drilldown, and Journal screens ensure imported single-cell data is fully visible and auditable. An optional protection control is also available, allowing customers to specify whether imported cells should be protected or remain editable after import. Note that, any updates to imported data will continue to be governed by the user's override permissions, regardless of the protection state of the cell.
For full details on how to consume this API, please refer to the API Developer Portal.
Currency columns now included in Excel report downloads
When downloading reports in Excel format, currency columns associated with amount fields are now included by default. Previously, these columns were hidden in Excel outputs, requiring users to manually identify or infer the currency of financial values.
This change reduces ambiguity and manual effort when reviewing exported data, ensuring the currency context is always available alongside the corresponding amounts.
User override values are now preserved across re-imports and prior period refreshes
When a user manually overrides a cell value — whether it was previously imported or brought forward from a prior period — that override decision is now respected and retained even when subsequent imports or prior period refreshes are performed on the same calculation.
This eliminates the need for users to repeatedly re-apply their overrides after routine data refresh operations, reducing manual effort and the risk of errors.
Import row order preserved to match source file
Imported data now appears in the calculation in the exact same row order as the source file. Previously, data was consistently imported in reverse order, which could lead to incorrect validation results — for example, where a validation rule checks whether a value in one row relates correctly to the value in the row above it — and required manual re-sorting after import.
This improvement applies to new imports and edited imports across all import methods, including the target-based import.
Duplicate client records no longer cause login or API failures
The system now correctly handles scenarios where multiple records with the same client name and client number exist in the database — for example, due to deletion of clients from ONESOURCE Administrator that are not reflected in the OCT database. Users are no longer prevented from logging in or receiving incorrect API results due to such duplicate records.
The fix ensures the correct, active client record is identified and used, preventing data ambiguity and ensuring a consistent experience.
UK e-filing validation no longer blocked by attachment errors
Previously, the Validate step in the e-filing workflow checked whether required attachments (as determined by answers to P-sheet questions) were present — but the application did not actually permit attachments to be uploaded at that stage. This created a deadlock where validation would fail due to missing attachments that users had no way of providing, blocking progression to the File step entirely. This release resolves the deadlock in two ways.
First, users can now upload attachments directly during the Validate step, which in most cases will be sufficient to clear attachment-related validation errors and allow progression.
Second, for situations where users are unable to procure all required attachments at validation time but will have them ready before submission, a new configurable setting has been introduced — described in detail in the following entry — that allows administrators to configure whether attachment presence is enforced during OCT's own validation step. Regardless of this setting, HMRC's own attachment checks are always performed independently at the point of submission and are not affected by this configuration. This applies to both Corporation Tax (CT) and Partnership (PT) filing types.
Configurable attachment enforcement during UK CT e-filing validation
In the UK CT e-filing workflow, customers answer P-sheet questions that determine whether attachments (such as accounts and computations) are required. Previously, these responses drove attachment-related schema validation during the Validate step — but attachments could not actually be uploaded at that stage. This created a deadlock where customers were blocked from progressing to the File step for reasons, they had no way to resolve.
A new tenant-level administrator setting — "Require attachments during validation" - has been introduced to give organisations control over this behaviour. When set to false (off), attachment presence is not enforced during validation, and customers can proceed to the File step even if attachments are indicated but not yet uploaded. When set to true (on), attachment-related schema rules are enforced, and validation will fail if required attachments are missing — useful for organisations that want a stricter validation gate once attachments are ready. The setting is available in the Administration > Settings and applies to all returns within the tenant.
Note: This setting governs OCT's own validation step only and does not affect HMRC's own attachment checks performed at submission time. If the setting is changed while a calculation is already open, the new value will take effect the next time the calculation is reopened.
PDF review package now scoped to the selected accounting period (UK)
When generating a review package PDF in the e-filing module for a return that has multiple accounting periods, users who select "Returns" in the P-Sheet dropdown ("Which sheets should be included in the review package PDF print?") will now receive a PDF containing only the return sheets relevant to the accounting period being submitted. Previously, the PDF always included returns for all accounting periods regardless of this selection, requiring users to manually remove irrelevant pages before sharing with clients.
Note that this scoped behaviour applies when the "Returns" option is selected. If "Tax computation and returns" is selected, the PDF continues to include all computation and return sheets across all accounting periods, as before. Backward compatibility is also preserved — if the configuration column controlling this feature is absent (e.g., on older templates) or manually set to off, the previous behaviour of including all periods is retained.
E-filing package generation stopped when errors are detected (UK)
An additional validation check is now performed during e-filing package generation. While calculations containing known errors are already prevented from being submitted, it is possible for unexpected errors to arise in the workbook during the package generation process itself — for example, cells that evaluate to an error state at runtime even though the calculation appeared clean beforehand. When such errors are detected, package generation is now halted rather than proceeding with a potentially flawed output, and a detailed error log is produced including the specific cells and locations affected.
This acts as a safety net against erroneous data making its way into an e-filing package due to unexpected runtime conditions, further improving the integrity and reliability of submissions.
XBRLPARAMS sheet hidden from iXBRL customer view (UK)
The internal XBRLPARAMS sheet, which is used by the system to generate valid iXBRL payloads, is now hidden when customers review an iXBRL return. This sheet contains system-level taxonomy parameters that are not relevant to customer validation and previously caused confusion.
The sheet remains present in the underlying file for processing purposes; only its visibility during customer review has been changed.
CIR export statuses added to Status Maintenance page (UK)
The Status Maintenance page in E-Filing Manager, now includes two new statuses for CIR (Corporate Interest Restriction) exports: Export Successful and Export Failed. These statuses are automatically updated following a CIR export action, giving users clear visibility into whether their export completed successfully or encountered a problem — consistent with how other e-filing workflow outcomes are tracked and reported.
CIR export: return type now included in JSON payload (UK)
The CIR export JSON payload has been enhanced to include a Header section containing a ReturnType field. The ReturnType is automatically populated based on the form code of the submitted return and will reflect one of the four supported CIR return types: Abbreviated interest restriction return, Appointment of reporting company return, Full interest restriction return, or Revocation of reporting company return.
This value is same as what is displayed in the E-Filing Wizard, ensuring consistency between and what is shown in the UI and included in the exported payload. This addition applies to CIR export payloads only.
CIR export operation now supported via Queue Package API (UK)
The Queue-a-Package API has been enhanced to support the CIR Export operation, providing consistent behaviour across the API, event notifications, and the UI. When a request is submitted with a CIR form code and without a User ID, the return is automatically processed as an Export rather than being placed in a standard queued state.
The Get E-Filing Status API has also been updated to return the appropriate CIR export-related statuses for the corresponding submission, clearly distinguishing export outcomes from standard queuing and filing statuses. This allows API consumers automating CIR export workflows to track export progress programmatically in the same way as other e-filing operations.
Test submission status added to Status Maintenance page (UK)
The 'Successful Test Submission' status is now correctly displayed on the Status Maintenance page, giving users and administrators full visibility of test submission outcomes alongside other filing statuses.
Confirmation receipt improvements for EFM submissions (UK)
The confirmation receipt exported from the E-Filing Manager History tab for successfully e-filed returns now includes two additional details: the Test vs Live submission indicator and the Document Class (e.g., Original, Amendment) for UK CT600 returns. This provides complete clarity on the nature of every completed submission directly from the exported receipt.
Optional sender email address for API-based e-filing submissions (UK)
API consumers and system integrators can now optionally specify a sender email address in the POST Submission endpoint. When provided, HMRC acknowledgement emails are delivered to the nominated business user rather than the technical machine application account used for the API call.
This is particularly useful for organisations automating submissions at scale, where acknowledgements need to be routed to the relevant tax professional responsible for the filing.

Notable defects remediated

Further improvements to WebSocket reliability for workbook notifications
  • Previous Behaviour:
     Despite improvements made in the previous release to WebSocket connection handling, users could still intermittently experience connection drops during workbook editing — sometimes requiring a browser refresh or logging out and back in to resume working normally.
  • Current Behaviour:
     Building on the foundation established in the previous release, further enhancements have been made to connection resilience. A dual-channel approach has been introduced whereby an alternate proxy channel automatically takes over if the primary WebSocket connection is interrupted, ensuring workbook editing and real-time notifications remain uninterrupted without any manual intervention from the user. Enhanced monitoring and traceability have also been implemented to detect and recover from connection issues more efficiently. Together, these improvements significantly reduce the likelihood of users needing to refresh their browser or re-login due to connectivity disruptions during a working session.
Cursor jumping to unexpected position while editing cells
  • Previous Behaviour:
     When editing cells in the workbook, users could experience unexpected movement in cell focus or the visible area of the sheet, particularly during save, refresh, or after navigating between sheets. This could disrupt the editing flow and make it harder to stay oriented around the cell being updated.
  • Current Behaviour:
     This release improves stability during cell editing and save operations. Users should see more consistent cursor positioning while editing, and saving calculations no longer shows the same jumping behaviour seen previously.
    However, this release does not fully address all scenarios. In some refresh-related actions, the visible area of the sheet may still shift, and users may need to scroll to return to the edited cell. Some cross-sheet navigation and browser refresh scenarios may also continue to show limitations. We will continue to make incremental improvements in this area in future releases.
Calculations remaining in read-only mode after being closed
  • Previous Behaviour:
     In some cases, calculations remained flagged as read-only in the system after they had been closed by the user, preventing subsequent users from opening the calculation in editable mode.
  • Current Behaviour:
     Calculations are now correctly released from read-only mode when closed.
Trial balance import status displayed as blank or failed incorrectly
  • Previous Behaviour:
     After uploading a trial balance, the import status was shown as blank or 'Failed' for some imports, even though the data had imported correctly and figures were flowing through in the dataset. This created confusion about the reliability of the import.
  • Current Behaviour:
     The import status now correctly reflects the actual outcome of the import operation. Users can trust the status displayed on screen as an accurate reflection of whether the import succeeded.
Import inserts duplicate rows and does not respect row/column context
  • Previous Behaviour:
     When using target-based imports, duplicate rows were inserted in certain scenarios, and the row and column context (RowColContext) defined in the import configuration was not being respected. This led to incorrect data placement and data integrity issues.
  • Current Behaviour:
     The target-based import process now correctly respects RowColContext settings and prevents duplicate rows from being inserted, ensuring data is placed accurately according to the import configuration.
Copy/paste not working in cells until 'Override System Formula' permission is enabled
  • Previous Behaviour:
     On databases where new permission module (Version 2) is enabled, users were unable to update the dropdown cell values via copy and paste unless the 'Override System Formula' permission was explicitly set to true, even for cells that did not require this permission.
  • Current Behaviour:
     Copy and paste now works correctly in cells regardless of the 'Override System Formula' permission setting. The permission is only enforced where it is genuinely applicable.
GetSheetsByTemplateId/TemplateName API returns 500 internal server error
  • Previous Behaviour:
     The public API endpoint for retrieving sheets by Template ID or Template Name intermittently returned a 500 Internal Server Error, preventing API consumers from reliably querying sheet information.
  • Current Behaviour:
     The API now returns the correct response for valid requests. Error handling has been improved to ensure reliable behaviour across all supported inputs.
Trial balance map not updated correctly during rollforward and prior period refresh
  • Previous Behaviour:
     Two related issues were observed with the Trial Balance Map following rollforward and prior period refresh operations.
    First, when a dataset was rolled forward to a new template where an analysis sheet had been decommissioned, the corresponding folder and mapped accounts for that sheet persisted in the Map despite the sheet no longer existing in the calculation — for example, rolling forward a 2024 dataset to a 2025 template where the "Investment Business Expense and Income Analysis" sheet (D4) had been removed would leave the "Management Accounts Analysis" folder and its mapped accounts still visible in the Map.
    Second, when a new analysis sheet was inserted and a prior period refresh was performed, the Map was not updated with the targets from the new sheet, preventing accounts from being mapped and trial balance data from being imported into those targets.
  • Current Behaviour:
     The Trial Balance Map is now correctly updated during both rollforward and prior period refresh operations. Folders and targets for decommissioned analysis sheets are removed during rollforward, and targets for newly inserted or updated analysis sheets are correctly generated after a prior period refresh, ensuring accounts can be mapped and trial balance imports completed without manual intervention.
Duplicate ledger account error when saving a calculation after inserting an analysis sheet
  • Previous Behaviour:
     After inserting an analysis sheet into a calculation and attempting to save, users intermittently encountered a save failure with the error: "23505: duplicate key value violates unique constraint 'pk_ledgeraccount_id'". This prevented the calculation from being saved and required users to seek support to resolve.
  • Current Behaviour:
     Improvements have been made to how duplicate ledger account entries are handled, which should reduce the occurrence of this error. In cases where the underlying condition is still triggered, the system will now produce a more descriptive error message to help the support team investigate and resolve the issue more efficiently. If you continue to encounter save errors of this nature, please contact support.
Prior period calculation name not updated in Calculation Setup sheet after rename
  • Previous Behaviour:
     When a prior period calculation was renamed or its purpose was changed, the Calculation Setup sheet in AU calculations continued to display the old name rather than reflecting the update.
  • Current Behaviour:
     The prior period calculation name in the Calculation Setup sheet is now updated automatically when the calculation is renamed or its purpose is changed.
Package generation fails for dataset or entity names containing special characters
  • Previous Behaviour:
     When a dataset or entity name contained special characters, the e-filing package generation process failed during XML/iXBRL construction. The failure was reported via the job status API, but no package was produced, blocking the user's automatic e-filing workflows and requiring manual workarounds.
  • Current Behaviour:
     Special characters in dataset and entity names are now correctly handled during XML/iXBRL construction. Package generation completes successfully regardless of the characters used in dataset or entity names, and no changes to the input data are required.
    note
    This fix addresses special characters that caused failures during package construction within the application. A separate, related improvement to detect invisible Unicode characters — such as zero-width spaces or non-breaking spaces that can be silently introduced via copy-paste and cause HMRC to reject submissions — is planned for a future release.
Error when opening a previous version of a calculation
  • Previous Behaviour:
     Attempting to open a previous version of certain calculations resulted in an unexpected error ('An item with the same key has already been added'), making it impossible to access historical versions.
  • Current Behaviour:
     The root cause of the duplicate key error during version retrieval has been resolved. Previous versions of calculations can now be opened successfully.
Updated values not immediately reflected in the calculation
  • Previous Behaviour:
     When a user updated a value in the workbook, calculated totals were correctly updated in the sheet where changes were made. However, navigating to a linked sheet via its hyperlinked cross reference could still intermittently display the previous (stale) value rather than reflecting the latest calculation. The linked sheet only updated after a manual refresh, which was not always obvious to users and could lead to incorrect figures being reviewed or reported.
  • Current Behaviour:
     Linked sheets now reflect the latest calculated values immediately upon navigation. Users no longer need to perform a manual refresh to see up-to-date figures.
E-Filing Manager access lost for users belonging to multiple groups
  • Previous Behaviour:
     When a user was a member of two or more groups with different roles assigned — for example, one group with an End User role and another with a System Admin role — a permissions conflict prevented the user's access rights from being synchronised correctly. As a result, the user was unable to access the E-Filing Manager entirely, despite having valid permissions assigned through their group memberships.
  • Current Behaviour:
     The permissions synchronisation issue for users belonging to multiple groups with differing roles has been resolved. Users in such scenarios now have their permissions correctly evaluated and applied, restoring full access to E-Filing Manager as expected.

Known issues

For the most up-to-date list of known issues, please refer to the Alerts and Notices page in the Online Help.

This article applies to:

  • Product: ONESOURCE Corporate Tax