Your Group’s Finance Function Wasn’t Built for the Structure You Now Have. Here’s How to Fix It.

The finance function was not designed for the group you now run. It was designed for the company you were before the second acquisition, before the new market, before the holding structure emerged. What you have now is the original architecture stretched across a structure it was never intended to manage. The accumulation of workarounds has become the process. And the process is breaking.

How to recognise a finance function that has outgrown its original design

The signal is not a single failure. It is the pattern. Month-end close that cannot be completed without the institutional knowledge of one or two specific individuals. Board pack preparation that consumes five days because the underlying data requires manual assembly and validation before it is presentable. Management accounts that diverge from statutory accounts in ways nobody at entity level can explain cleanly. An FP&A function that spends the majority of its capacity assembling data rather than analysing it.

None of these are evidence of a failing team. They are evidence of a finance architecture that was built for a smaller, simpler structure and has been extended, month by month, by adding manual steps and workarounds rather than redesigning the foundation. The architecture is the constraint. The team is working around it - with skill, often, but at a cost that compounds as the group grows.

A Deloitte study of finance function resilience in European mid-market groups found that 61% of finance leaders at companies with five or more entities described their current close process as "highly dependent on specific individuals" - a configuration they acknowledged as a governance risk but had not yet addressed. The average tenure of the individual most critical to close was 6.2 years. The average time to recover full close functionality after that person departed was 4.1 months.

A post-M&A manufacturing and services group, EUR 180M revenue, 8 entities across five countries, had a Group Controller who maintained the group consolidation in a 47-tab Excel workbook developed over six years. The workbook was effective. It was the only mechanism that translated entity-level ERP data into a group view the board could use. When the controller was promoted to CFO and could no longer dedicate the same time to the workbook, close slipped from day 12 to day 22 in the first month. A reconciling item of EUR 380,000 in the board pack - a difference between the management accounts and the statutory figures - remained unexplained for four weeks. The problem was not a new one. It had been present in every prior close, absorbed by the controller's familiarity with the model. The promotion made it visible.

The five components that require redesign

When a finance function has outgrown its original architecture, five structural components need to be addressed in a defined sequence. Addressing them out of order produces a result that is temporarily better and structurally unchanged.

Source data and document flow standardisation. The starting point is not technology. It is the chart of accounts and the close process. A group that does not operate on a unified chart of accounts across all entities cannot produce a consolidation without manual translation at every reporting cycle. Every translation introduces potential error. Every potential error requires manual review. The chart of accounts question must be resolved - and the governance mechanism to enforce compliance established - before any other structural work produces durable results.

Fixed and variable cost visibility at group level. In a group, understanding the cost structure requires more than categorising costs as fixed or variable at entity level. It requires answering which entity is bearing which cost, whether group overhead is allocated to entities on a defensible and consistent basis, and whether costs that appear in one entity's P&L genuinely represent costs incurred by that entity or reflect intragroup allocations that should be stripped before entity performance is assessed. The group overhead allocation methodology must be defined, agreed, and applied consistently - not because entity GMs will be satisfied with every allocation, but because without a consistent methodology the entity-level profitability picture is undependable as a management tool.

Profitability by entity and business unit on a post-elimination basis. The Group CFO needs to know which part of the group earns and which part consumes - on a basis that accounts for intercompany eliminations and shared overhead allocation. An entity-level profitability view that includes unadjusted intragroup charges is not a measure of entity performance. It is a measure of how the group has chosen to allocate costs. These are different questions with different answers. The profitability picture that the Group CFO uses to allocate capital across entities, make restructuring decisions, and assess entity management must be based on the former.

Group cash flow visibility - not treasury management. Entity-level cash positions, intercompany loan schedules, and a consolidated view that identifies where cash is genuinely available and where it is structurally trapped. This is not a question about treasury systems. It is a question about data governance: what information is collected from entities, on what frequency, and in what format. The weekly group cash view that most Group CFOs need does not require a treasury management system. It requires a data discipline - consistent entity submission, IC reconciliation before aggregation, and a simple consolidated output that tells the Group CFO where the group's money actually is.

The escalation decision: operational improvement versus structural rebuild. The inflection point most groups miss is the distinction between an operational response and a structural one. Hiring another controller, buying another FP&A tool, redesigning the management report template - these are operational responses. They improve the efficiency of an architecture that is not fit for purpose. When the root cause is a data foundation that does not match the group's current structure, the operational response does not fix the problem. It adds cost and complexity to the layer of workarounds that already exists. The structural response - rebuilding the data foundation to match the group's actual architecture - is what breaks the cycle.

The inflection point: when to stop optimising the workarounds

McKinsey Global Institute's analysis of finance function transformation programmes across European mid-market groups finds that the average group addresses the structural problem 2.7 years after the structural mismatch first becomes visible in close duration and reporting quality metrics. The cost of that delay - in finance team headcount, in manual effort, in board pack quality, and in missed management decisions - is typically 4 to 6 times the cost of the structural rebuild itself.

The groups that address the mismatch earliest share one characteristic: a Group CFO who distinguishes between the symptoms (slow close, unreliable consolidation, contested numbers) and the cause (an architecture that was designed for a different, simpler structure). Once that distinction is clear, the path forward is less about choosing between operational improvements and structural investment than about sequencing structural investment correctly so it delivers durable results rather than temporary relief.

If your finance function is absorbing more manual effort each month to produce the same output, or if your board has started asking questions the existing reporting structure cannot answer from the data it holds - talk to us about what rebuilding the finance architecture for your current group structure would actually involve and what the payback period looks like.