Most Finance Architectures work. That’s the problem.

Why legacy architecture is becoming a constraint on the modern finance function

Most CFOs do not wake up one morning to find that their finance architecture has stopped working. The close still happens. Regulatory reports are submitted. Management gets its numbers.

But behind these outputs often sits an increasingly complex machinery of interfaces, data copies, data transformations, reconciliations and manual controls. Every new requirement adds another layer, mapping or workaround. Over time, tactical solutions become permanent parts of the architecture.

The cost is significant. Gartner estimates that banks spend around 70–80% of their IT budgets maintaining existing systems rather than driving innovation. Finance teams spend significant time reconciling, fixing, and substantiating data, and even relatively contained changes can turn into costly, multi-system projects.

For years, banks have accepted these limitations, often for good reason. Critical processes continued to work, while changing the underlying architecture was costly and risky.

Finance architectures are often not designed, they accumulate.

Today’s finance architectures are the product of decades of change. Basel III massively increased disclosure requirements around capital, liquidity, risk, and other supervisory areas. IFRS 9 added complexity around classification and measurement of financial instruments, impairment of financial assets, and hedge accounting. More recently, ESG disclosures brought entirely new data and reporting requirements. Acquisitions added further ledgers and core banking systems, while tight implementation timelines often resulted in tactical applications and bespoke integrations.

In many banks, the absence of a centralised subledger or common finance foundation also meant that accounting logic and financial data processing developed across core systems, calculation engines and downstream finance applications. Finance, risk, and treasury created their own transformations and interpretations of the same underlying business.

In isolation, many of these decisions made sense. In sum, they have consequences:

Cost and efficiency. Bespoke integrations, transformations, and manual process steps create structurally high run costs. Finance and IT teams spend significant time maintaining processes that exist because systems and data do not naturally connect. Finance teams can spend up to 45% of their time cleaning and reconciling data rather than analysing it, according to EY.

Time to change. A new regulatory or business requirement rarely affects one system. Changes must be traced through source feeds, mappings, calculation logic, accounting processes, controls, and reports. The more dependencies in the architecture, the longer it takes to implement, and test even seemingly contained changes.

Data and insights. Finance, risk, and treasury frequently operate on different data copies and at different levels of granularity. Before information can be analysed together, it must be extracted, transformed and reconciled. Valuable business context can be lost as data moves across systems. 40% of CFOs do not trust the accuracy of their financial data slowing down decision making.

Control and compliance. Controls are often added to compensate for breaks between systems. Reconciliations, manual adjustments, and substantiation become additional layers around the architecture, increasing operational and audit effort. Cash reconciliation alone can involve 3–5 systems and require 20–50 hours each month, illustrating the recurring control burden created by fragmented architectures.

Scaling. A new entity, product, or reporting requirement does not simply add volume. It can create new mappings, interfaces, calculation logic, and reconciliation points. Complexity grows disproportionately.

The result is a structural burden on both running and changing the bank. Technical debt becomes business debt when every new requirement becomes slower and more expensive to deliver.

The hidden cost of legacy finance architecture is not simply maintaining old technology. It is the increasing cost of everything the bank wants to do next.

The CFO mandate has outgrown the architecture

What has changed is not the core responsibility of finance, but the expectations around it. CFOs must now provide more granular evidence to regulators and auditors, give management a faster view of capital, liquidity and earnings, and turn AI investment into measurable productivity gains.

These demands require more than additional reports or processes. They require a different architectural foundation.

1. From reporting the number to proving the number

For the CFO, delivering the reported number is no longer enough. More than a decade after the publication of BCBS 239, supervisory reviews continue to identify weaknesses in data aggregation, lineage, and reporting capabilities across many banks.

Growing regulatory expectations require reported information to be traced through the finance process and back to its underlying financial positions. In a fragmented architecture, this can mean repeatedly tracing data back and forth across multiple systems, transformations, and reconciliations. Where position- or contract-level context has been lost through aggregation, substantiating a number becomes even more difficult.

The consequence is greater control and audit effort. Highly skilled finance teams spend time proving the numbers rather than interpreting what they mean.

2. From periodic reporting to real-time enterprise steering

The CFO is increasingly expected to help steer the bank, not simply explain its past performance. In a volatile environment, management needs to understand the impact of changing market conditions, volatility, interest / FX rates, liquidity conditions, credit risk factors, or business activity much faster.

This requires a connected view of capital, liquidity, and earnings across finance, risk, and treasury. Yet these functions often operate on separate data foundations, calculations, and reporting cycles. Creating an enterprise-wide view requires data to be extracted, transformed, and reconciled before it can be analysed.

By the time a consolidated view is available, the underlying business position may already have changed. Real-time bank steering requires more than faster analytics. It requires an architecture that connects finance, risk, and treasury around a common, trusted data foundation.

3. From AI experimentation to measurable productivity

CFOs are under growing pressure to demonstrate measurable returns from AI. The ambition is moving beyond individual productivity tools and isolated pilots towards automating processes, accelerating analysis, and fundamentally improving how finance operates.

But AI needs trusted financial context. Fragmented data, inconsistent definitions, and disconnected finance and risk systems limit its ability to operate across end-to-end processes. And in finance, AI-generated insights and actions must remain explainable, traceable, and controlled.

If a conclusion cannot be linked back to the underlying financial position, business event, or calculation, its use in critical finance processes will remain limited. The risk is that significant AI investment delivers isolated use cases and incremental efficiency rather than genuine finance transformation.

AI does not make fragmented finance architecture disappear. It makes its limitations more visible.

Modern CFO organizations need a different architectural foundation.

If the mandate of finance has changed, the underlying architecture needs to evolve with it. Continuing to address each new regulatory requirement, AI use case, or management need with another application risks reinforcing the very complexity that is holding finance back.

Instead, finance transformation should progressively simplify the architecture around a common foundation, ensuring that each transformation step moves the organisation closer to a clear target state rather than adding another layer of complexity. The objective is not only to reduce today’s complexity, but also to create an architecture that can adapt more easily to tomorrow’s regulatory, business and technology requirements.

This is the thinking behind an integrated and unified finance management platform:

• At its core is a single point of truth for granular, position-level information. Financial information is maintained from source to report with its context and lineage intact, enabling drill-down to the underlying position or contract.
• On this foundation, accounting and finance processes operate across business domains and accounting standards. Daily and period-end processes are connected, while accounting results remain linked to the granular financial information from which they were derived.
• Controls become an integral part of the end-to-end closing process. Reconciliation, adjustments, substantiation, and data validations are integrated rather than added to compensate for breaks between disconnected applications.
• A platform also provides a multi-domain foundation for bank management. Accounting, controlling, risk, treasury, and sustainability have distinct functional requirements, but they should not need to continuously recreate the same underlying financial reality. Each domain can add its own dimensions, calculations and business frameworks while working from consistent position-level information.
• It enables data products, analytics, and AI-enabled insights. With trusted and traceable finance data, semantics, and meta-data underneath, the platform provides a governed foundation for AI to accelerate and automate processes and workflows while maintaining the explainability and financial control banks require.

This is the architectural idea behind SAP Fioneer’s Finance Management Platform: trusted finance data, end-to-end controls, and a governed AI foundation to enable end-to-end bank steering across business domains where AI is safe, secure, explainable, and auditable.

A finance platform should not become another application in an already fragmented landscape. Its purpose is to simplify the architecture underneath finance.

The cost of waiting is increasing

Legacy finance architectures will continue to keep the lights on. Banks will still close their books, submit regulatory reports and deliver business change. But every new requirement added to an already fragmented landscape increases operational complexity, drives up the cost of change and slows the organization’s ability to respond to market and regulatory demands.

The greater risk is not that legacy systems stop working. It is that they become a growing constraint on the CFO agenda. As AI, real-time insights and heightened regulatory expectations reshape banking, finance organizations built on outdated architectures will struggle to scale innovation, attract investment and deliver the speed of decision-making the business requires. The longer modernization is deferred, the wider the gap becomes between banks that can leverage these capabilities and those that are constrained by technical debt.

The question is no longer whether legacy finance systems still work, but whether they can support the next decade of banking in an AI-driven era.