A case study in finance transformation for UK social housing

Oracle Fusion Finance implementations in UK social housing are not straightforward projects. They involve complex organisational structures, long-established legacy systems with years of accumulated data, integration requirements with specialist housing management platforms, and the need to maintain payroll accuracy and financial compliance throughout the transition. When they go well, the results are transformative. When they go wrong, the costs are significant and highly visible.

This article describes how VE3 approached a finance transformation programme for a UK housing group, the specific challenges that defined the project, how we solved them, and what the organisation achieved as a result. All client details have been anonymised.

Engagement at a Glance

Client: UK social housing group operating across multiple legal entities. Scope: Oracle Fusion Financials, Procurement, and Accounts Payable, with integration to an existing NEC housing management platform. Complexity: Multi-entity structure with consolidated group reporting requirements, multiple pension schemes, and a diverse workforce of over 1,500 employees. VE3 role: Full implementation partner from design through go-live and hypercare.

The Starting Point: Why the Organisation Needed to Move

The housing group had been operating on a legacy finance platform that was no longer fit for purpose. The system had been heavily customised over many years, and those customisations had accumulated into a significant maintenance burden. Every reporting period, the finance team spent days manually consolidating financial data across entities using spreadsheets. Intercompany transactions were tracked outside the finance system, reconciled manually, and periodically corrected when discrepancies were found.

The organisation was also planning a significant structural change: consolidating its group entities from ten legal companies to six over a two-year period. This restructuring made the case for moving to a modern, configurable cloud ERP even stronger. The legacy system could not accommodate entity restructuring without bespoke development. Oracle Fusion, by contrast, is designed to handle exactly this kind of evolving group structure through its configurable enterprise design.

The decision to move to Oracle Fusion Cloud was made at board level, driven by a combination of financial sustainability pressures, regulatory compliance requirements, and the recognition that the finance function needed a platform that could serve the group for the next decade, not just the next two or three years.

10 entities

reduced to 6 over the course of the programme, managed within Oracle Fusion's multi-entity architecture without disruption to live finance operations

Phase One: Enterprise Design Before Configuration

The most important work VE3 did on this engagement happened before a single line of configuration was written. The enterprise structure design phase is where multi-entity Oracle Fusion implementations succeed or fail, and it is frequently the phase that is underestimated or compressed by implementation partners under commercial pressure to reach build milestones.

We spent the first weeks of the engagement working with the group finance director, the financial controller, and the payroll manager to map the organisation's legal entity structure into Oracle Fusion's architecture. This meant defining every legal employer, establishing the correct Payroll Statutory Unit configuration for PAYE and National Insurance reporting, and designing the chart of accounts to accommodate both entity-level statutory reporting and consolidated group reporting within a single ledger.

Chart of Accounts Design

Designing the chart of accounts for a multi-entity housing group is a precision exercise. Oracle Fusion's General Ledger supports up to three balancing segments, and best practice is to assign one of these segments to the legal entity. This enables Oracle to produce entity-level trial balances automatically, satisfying statutory reporting requirements without manual intervention. For this client, we designed a chart of accounts structure that accommodated the current ten-entity group, with sufficient flexibility to absorb the planned consolidation to six entities without requiring chart of accounts changes, which Oracle strongly recommends against once the system is live.

Intercompany Configuration

Intercompany transactions between group entities were a significant source of manual reconciliation effort on the legacy system. Oracle Fusion's intercompany module generates balancing entries automatically whenever a transaction crosses a legal entity boundary, posting the correct intercompany receivable and payable accounts on both sides without manual journal entries. We configured the intercompany rules for this client's trading patterns and tested them thoroughly against the most common intercompany transaction types before go-live. The result was the elimination of the monthly intercompany reconciliation process that had previously occupied a senior finance team member for several days each period.

Ledger and Consolidation Structure

The group required consolidated financial reporting across all entities at period close. We configured a primary ledger covering the full group with balancing segments mapped to each legal entity, enabling Oracle's consolidation reporting to produce group financial statements directly from the system without balance transfers or external consolidation tools. This single-ledger approach, appropriate for a UK-only group operating in a single currency, simplified the technical architecture significantly and reduced the ongoing maintenance overhead compared to a multi-ledger design.

The Integration Challenge: Connecting Oracle Fusion to NEC

The housing group's primary operational system was a NEC housing management platform hosted in an AVS environment. This system drives the core property management, tenancy, repairs, and rent transactions that generate the majority of the organisation's financial activity. Integrating it with Oracle Fusion Finance was not optional: it was the critical path item that determined whether the new finance system would have accurate, timely data.

The existing connection between the legacy finance system and NEC relied on a combination of flat file transfers and a direct database connection, built and maintained by the organisation's internal IT team. This approach was fragile, poorly documented, and had been the source of several significant reconciliation issues over the preceding years.

Integration Architecture

VE3 designed a structured integration architecture using Oracle Integration Cloud (OIC) as the middleware layer. Rather than replicating the existing flat file transfer approach, we designed event-driven integrations that triggered Oracle Fusion transactions in near-real time as activity occurred in NEC. Rent receipts, works order costs, and purchase transactions generated in NEC were mapped to Oracle Fusion's subledger structures and posted to the general ledger without manual intervention.

The integration design went through three rounds of review: technical review against Oracle Integration Cloud's supported NEC connection methods, business review against the finance team's reconciliation and reporting requirements, and security review against the organisation's data governance policies. Documented integration specifications were produced for each data flow before build began, providing the test team with a clear baseline for validation.

Data Quality at the Interface

One of the most valuable discoveries during integration design was the extent of data quality issues in the NEC system. Property reference codes, cost centre allocations, and supplier identifiers that fed from NEC into the legacy finance system carried accumulated errors that the legacy system had been silently absorbing for years. Oracle Fusion, with its stricter validation rules, would have rejected a significant proportion of transactions on day one if these issues had not been identified and resolved.

We ran a data profiling exercise against the NEC data flows early in the project, identifying the most common validation failures and working with the client's housing management team to resolve them at source. This upstream data cleansing work, which is rarely scoped explicitly in Oracle Fusion implementation proposals, was critical to achieving a clean go-live.

Key integration principle

More than 75 percent of Oracle Cloud implementation delays are attributable to data issues identified late in the project, typically during integration testing or user acceptance testing. VE3 brings data quality assessment forward to the design phase, before build begins, which is the only effective way to prevent these delays from materialising.

Accounts Payable Automation: Eliminating Manual Processing

The housing group processed a high volume of supplier invoices each month, covering maintenance contractors, material suppliers, and professional services providers. On the legacy system, a significant proportion of these invoices were matched manually to purchase orders by the accounts payable team, creating a processing bottleneck and a source of payment delay that affected supplier relationships.

Oracle Fusion's three-way matching engine was configured to automatically match invoices against purchase orders and goods receipts for approved suppliers. Tolerances were set to allow minor discrepancies to be processed automatically, with material exceptions routed for manual review. Oracle's Intelligent Document Recognition capability was also deployed to automate invoice capture, extracting key data fields from supplier invoice PDFs and pre-populating Oracle Fusion's invoice entry screen without manual keying.

By go-live, the proportion of invoices processed without manual intervention had increased substantially. The accounts payable team, which had previously spent the majority of its time on routine invoice matching, was able to redirect capacity to exception handling, supplier query resolution, and payment run management.

Data Migration: The Work That Determines Go-Live Quality

Oracle Fusion implementations are only as good as the data that is migrated into them. This is particularly true for housing finance, where the opening balances, supplier records, fixed asset registers, and purchase order history that carry over from the legacy system form the foundation for all future reporting and transaction processing.

Migration Scope and Approach

We agreed with the client that the migration would cover: opening general ledger balances at the go-live date by entity; the active supplier master; open purchase orders and associated receipts; and the fixed asset register. Historical transaction data beyond the opening balances was retained in the legacy system, which was maintained in read-only mode for a defined period post go-live to support any historical reporting requirements.

Supplier Master Cleansing

The legacy supplier master contained over 3,000 records accumulated over many years. Analysis showed that approximately 30 percent were duplicates, inactive, or contained incorrect bank details. We ran a supplier master cleansing exercise that consolidated duplicates, validated bank account details for active suppliers, and confirmed VAT registration numbers against HMRC's database. The cleansed supplier master that went into Oracle Fusion was materially smaller and significantly more accurate than what had existed in the legacy system.

Balance Migration and Validation

Opening balances were extracted from the legacy system at the go-live date, mapped to the new chart of accounts structure, and loaded into Oracle Fusion using Oracle's file-based data import tools. Each balance was validated against the legacy system's trial balance at the entity level. Where discrepancies were found, they were investigated and resolved before the go-live date was confirmed. The validation pack produced during this process provided the external auditors with the evidence they needed to confirm the accuracy of the opening position in Oracle Fusion.

Change Management and User Adoption

Finance system implementations fail more often because of people factors than because of technical ones. The housing group's finance team had been using the legacy system for many years. Some staff had built significant expertise in navigating its limitations, and there was understandable concern about what the transition to Oracle Fusion would mean for their day-to-day working lives.

VE3 treated change management as a parallel workstream throughout the implementation, not as a final phase before go-live. We ran process workshops with the finance team at the design stage, which served two purposes: gathering the process knowledge that informed configuration decisions, and beginning the familiarisation process so that team members understood the new system's logic before they were asked to use it.

Role-based training was delivered in the two weeks before go-live, structured around the specific tasks each team member would perform in Oracle Fusion rather than a generic system overview. Accounts payable staff trained on invoice processing and supplier management. Budget holders trained on the self-service reporting and commitment tracking tools. The finance management team trained on period close procedures and consolidated reporting.

A hypercare period of eight weeks post go-live was built into the engagement, with VE3 consultants available to support the team through their first payroll cycles, period close, and management accounts production in Oracle Fusion. This sustained support period proved invaluable in identifying and resolving the configuration adjustments that only become apparent when real transaction volumes are running through the system.

Outcomes: What Changed After Go-Live

The housing group went live on Oracle Fusion Finance on schedule and within budget. The results in the months following go-live demonstrated the value of the upfront investment in enterprise design, data quality, and integration architecture.

Days eliminated

from the monthly period close cycle, through automated intercompany balancing, integrated subledger posting from NEC, and real-time general ledger reporting

Consolidated reporting

available in Oracle Fusion directly, replacing a manual multi-spreadsheet consolidation process that had previously taken several finance team members most of a week

The accounts payable function processed its first month's invoices in Oracle Fusion with a significantly higher rate of automated matching than had been achieved on the legacy system. The supplier master, cleansed during migration, generated fewer exceptions and required less manual resolution than the finance team had anticipated.

The intercompany reconciliation process that had consumed senior finance team time every period was eliminated entirely. Oracle Fusion's automatic intercompany balancing entries meant that entity-level trial balances were in balance from the moment transactions were posted, without any manual journal intervention.

As the group progressed with its entity consolidation programme, the Oracle Fusion configuration was updated to reflect each structural change. Because the enterprise design had been built with this flexibility in mind, each consolidation step was handled as a configuration change rather than a development project.

What This Engagement Taught Us About Housing Finance Transformation

Every Oracle Fusion Finance implementation in social housing has its own specific challenges, but the pattern of what matters most is consistent. The organisations that achieve the best outcomes are those that invest in enterprise design before configuration, treat data quality as a first-class workstream rather than a late-stage concern, and plan their integration architecture around the long-term operational model rather than replicating existing fragile connections.

For housing finance directors and IT leaders evaluating their options, the most important question to ask of any prospective implementation partner is not what their methodology is. It is whether they have done this before in a housing context, with the specific complexity of NEC integrations, multi-entity consolidation, and regulated sector reporting requirements. Generic Oracle implementation capability is not the same as housing sector experience, and the difference matters at every stage of the project.

1. Enterprise design must precede configuration. Chart of accounts, entity structure, and intercompany rules set the foundation for everything that follows

2. Integration architecture should be designed for the future operating model, not built to replicate existing fragile connections

3. Data quality assessment belongs at the design stage, not the testing stage. Discovering data issues in UAT is expensive. Discovering them in design is not

4. Change management is a delivery workstream, not a communication exercise. Finance teams need process-level familiarity before go-live, not a system tour

5. Hypercare is not optional. The first period close and payroll cycle in Oracle Fusion will surface configuration adjustments that no amount of testing in a non-production environment can predict

Work with VE3 on Your Oracle Fusion Finance Transformation

VE3 is an enterprise AI, data, and digital transformation consultancy and Oracle partner with delivered Oracle Fusion Finance implementations across complex, multi-entity organisations in UK social housing and the public sector. We bring housing-specific knowledge of NEC integrations, multi-entity consolidation, and regulated sector reporting requirements to every engagement. To discuss your finance transformation programme, visit ve3.global