As the 2028 Companies House digital filing deadline draws closer, multinational groups with UK subsidiaries are increasingly looking at ONESOURCE Statutory Reporting (OSR) as the platform to carry them through it. The interest is understandable - OSR is a capable, proven platform for multinational statutory and financial reporting. But a technology decision and a successful implementation are two different things.
This article is for finance and tax leaders who want to understand what an OSR implementation actually involves - before committing to one.
What OSR is, and what it is not
OSR is a statutory accounts production platform. It sits downstream of your ERP and tax systems, not inside them. You are not replacing your general ledger, your tax computation platform, or your consolidation tool. OSR receives data from those systems, applies your reporting templates, and produces accounts that are ready for digital filing.
It is a reporting layer, not a source system. That distinction matters, because the most common implementation challenges are about data - what comes in, in what format, and how reliably.
Why groups are implementing now
Three factors are converging for multinational groups with UK entities.
The 2028 Companies House deadline. Mandatory software-only filing in iXBRL format applies to annual accounts filed on or after 1 April 2028 (confirmed by the government on 9 June 2026, after the original 2027 timetable was paused). For groups with 20, 50, or 100 UK entities, preparing for this requires either manual iXBRL tagging (which scales badly) or a platform that generates tagged accounts natively.
Group scale. Producing statutory accounts for multiple entities with consistent formatting, automated comparatives, and controlled disclosure populations is exactly what OSR was built for. The platform’s template architecture means the same configuration drives accounts across every entity in scope.
The ONESOURCE suite. Groups already using ONESOURCE Corporate Tax or ONESOURCE Tax Provision gain additional value from OSR because of native integration between the platforms. Tax disclosures can flow directly from the computation into the accounts, without manual rekeying.
The four phases of an OSR implementation
1. Scoping and design
This is where the implementation is won or lost. The scoping phase involves understanding your entity structure, the GAAPs in scope (UK GAAP, IFRS, FRS 101, multi-GAAP), your chart of accounts and how it maps to the statutory presentation, and the disclosure requirements specific to your group.
The output is a functional design: which templates will be configured, how data will flow in, what the account mapping looks like, and which disclosures will be automated. This phase typically takes two to four weeks, depending on group complexity.
Groups with a complex COA and multiple GAAPs should invest more time here - not less. Decisions made in scoping flow through to every subsequent phase.
2. Configuration
Template configuration is the core technical work of an OSR implementation. This involves building or adapting financial statement templates for each GAAP in scope, mapping your chart of accounts to the template structure, configuring automated disclosures, and setting up any additional roll-forward logic for opening balances and prior-year comparatives.
For groups with a well-organised COA and a single predominant GAAP, configuration is relatively straightforward. For groups with fragmented account structures or multiple GAAPs, it requires careful judgement and experienced hands.
3. Data loading and testing
Once templates are configured, the focus moves to data. Trial balances are loaded, mapped, and validated. Adjustments are applied. The system runs accounts for one or more test periods, and the outputs are compared against existing statutory accounts to identify discrepancies.
This phase is iterative. Expect to run multiple rounds of test accounts before results are clean. Discrepancies usually arise from mapping gaps, adjustment timing, or disclosure logic that needs refinement - not from fundamental configuration errors.
4. Go-live and parallel run
The first live period almost always runs in parallel with the existing process. The team runs accounts through OSR and compares them to accounts produced through whatever process existed before. This builds confidence, surfaces any remaining issues, and provides the evidence needed to sign off on the new process.
A well-managed go-live includes having experienced OSR support available - not just on call, but actively involved during the first live close.
Internal resource requirements
OSR implementations do not require a large internal team, but they do require the right people.
Finance lead. The single most important internal resource. This person needs to understand the group’s entity structure, the COA, and how accounts have historically been prepared. They make the decisions in scoping and validate outputs in testing. Expect 20-30% of their time during the implementation.
IT involvement. Minimal, unless the data extraction from the ERP requires IT resource. Most OSR implementations handle data via flat file or API - both of which can be managed outside IT once the initial connection is established.
Reviewer availability. Test accounts need to be reviewed by someone with enough knowledge of the entities to identify whether the outputs are correct. This is often the bottleneck in the testing phase - plan for it.
Common challenges
COA complexity. Groups that have grown through acquisition often have fragmented chart of accounts structures - multiple ERPs, inconsistent coding, accounts that do not map cleanly to the statutory presentation. This does not make OSR impossible; it makes the mapping work more intensive, and the importance of getting scoping right is higher.
Template proliferation. Groups with entities under multiple GAAPs, or with bespoke disclosure requirements for certain entities, can end up with a large number of templates to configure and maintain. The solution is to invest in well-designed base templates and variant logic, rather than creating one-off templates for each entity type.
Late trial balance data. OSR can only produce accounts from clean, complete data. If your TB extraction and adjustment process is slow, OSR will not speed it up - it will just wait. The automation gains come after the data is in. For groups where TB loading is itself a bottleneck, addressing that separately (with Alteryx, for example) before the OSR implementation often makes sense.
Disclosure population. Automated disclosures require structured data inputs - the right numbers in the right fields. Where disclosure information has historically been held in unstructured documents or narrative spreadsheets, converting it to a structured format requires effort. This is rarely a blocker, but it is worth scoping explicitly.
What success looks like
A well-implemented OSR deployment produces accounts in hours, not days. The first entity runs through the same template as the fifty-first. Comparatives are generated automatically. iXBRL tagging is embedded in the output rather than applied as a separate step. A change to an adjustment flows through to the accounts immediately, without requiring a manual update in a separate document.
For groups with large UK entity populations, the difference between a well-implemented OSR environment and the status quo is not incremental - it is transformative. The compliance team’s capacity shifts from production to review. That is a materially better use of qualified people.
Is OSR right for your group?
OSR is likely the right choice if your group has ten or more UK entities, entities reporting under multiple GAAPs, an intention to use ONESOURCE Corporate Tax or Tax Provision (or already does), OR a need to be ready for digital filing before the 2028 Companies House deadline.
It is worth having a clear-eyed conversation about group complexity, COA structure, and internal resource before committing to an implementation timeline. The platform is excellent; the implementation requires investment to realise its value.
If you are scoping an OSR project and would like to understand what it would realistically involve for your group, get in touch. We are happy to have a direct conversation, without obligation.
