What Business Intelligence Actually Means for a Group CFO — and Why Most Implementations Miss the Point

A Group CFO who has been through one BI implementation already knows the pattern: the platform looked capable in the demonstration, the project delivered on time, the dashboards went live, and six months later the finance team was using a parallel Excel model for anything that actually mattered. The failure is consistent. And it is always the same failure - not the platform, but the data infrastructure underneath it.

Why the BI question is the wrong first question

Before any BI platform is selected, one diagnostic question determines whether the implementation will succeed: is the underlying data consolidation-grade? Not adequate for a single entity's own reporting. Consolidation-grade - meaning standardised across every entity in the group, with intercompany positions identified and eliminated, KPI definitions agreed and encoded, and the chart of accounts mapping consistently from entity to group without manual translation.

Most BI projects do not ask this question. They ask which tool fits the use case, how quickly it can be deployed, and whether it integrates with the current ERP stack. These are legitimate questions about the second step. They are the wrong questions to lead with. A BI platform connected to five ERPs with three different charts of accounts and no intercompany elimination will produce beautiful dashboards full of unreliable numbers. The unreliability surfaces three months after go-live, when the finance team attempts to reconcile the dashboard output to the management accounts and cannot do so within a reasonable period of time.

Gartner's analysis of enterprise BI implementations across industries finds that data quality failures - not platform capability failures - account for 70% of implementations that do not deliver expected value within 24 months. In multi-entity groups, the figure is likely higher, because the data quality problem in a group is structural rather than operational. It cannot be resolved by cleaning existing data. It requires redesigning the architecture that produces it.

Three data foundation problems specific to group BI

Multiple ERPs that produce incompatible data. Different ERP systems do not speak the same language. Connecting three ERPs to a BI platform produces a technical integration. It does not produce comparable data. Revenue in Entity A's ERP is defined by its recognition rules, its account codes, and its period timing. Revenue in Entity B's ERP may use different definitions on each of these dimensions. The BI platform aggregates both under the label Revenue and presents the sum as if it were a coherent metric. It is not. It is the sum of two different constructs that happen to share a name.

Intercompany transactions that inflate every consolidated metric. A group with significant intragroup activity - shared services charged across entities, management fees from holding to subsidiaries, intragroup platform costs - carries intercompany flows that inflate both revenue and cost simultaneously. Unadjusted BI data inflates the top line, inflates cost, and produces margin percentages that are arithmetically correct and economically misleading. The platform does not know to strip these out. That elimination logic must be built into the data model before the platform is deployed. Deploying first and planning to add elimination logic later is not a sequencing decision - it is a structural error that contaminates every report produced in the interim.

KPI definitions that have never been harmonised across entities. Gross margin, EBITDA, headcount - in most groups assembled through acquisition or market expansion, these metrics are defined differently in different entities. The differences reflect legitimate historical choices, not errors. But in a group context, they make comparative analysis impossible without a manual translation step that is time-consuming, error-prone, and invisible to anyone reading the BI output. A BI platform that shows Group Gross Margin is not showing a financial metric. It is showing an average of different calculations presented as if they were the same thing.

What a Group CFO must demand before a BI project begins

Before any dashboard is scoped, three deliverables must be on the table - none of which are standard BI vendor deliverables.

First, a data architecture assessment that documents how entity-level data will be standardised, how intercompany positions will be handled, and how group-level metrics will be computed. This is not a BI deliverable. It is a finance architecture deliverable that precedes the BI work. BI vendors do not typically scope it, because it falls outside their implementation methodology. Finance transformation partners do. The question to ask a BI vendor before selecting them is: who is doing the data architecture work, and what is the plan for getting the data to consolidation-grade before the first dashboard is built?

Second, a decision on the group chart of accounts - specifically, which account structures will be mapped to the group standard, who has the authority to mandate that mapping for entities that do not comply, and what the timeline for compliance looks like. This is a governance decision that requires Group CFO ownership. It cannot be delegated to the BI implementation team.

Third, a data quality audit at entity level. What does the data actually look like in each ERP today? What is the completeness rate for the key fields the BI system will depend on? What are the error rates in intercompany transaction matching? The answers to these questions determine the scope and duration of the foundation work before BI deployment can proceed reliably.

BI versus AI: the sequencing that determines whether either delivers value

The distinction between BI - structured reporting and dashboards - and AI - pattern detection, narrative generation, anomaly flagging - matters for sequencing decisions. BI sits closer to the data foundation than AI does. A group that cannot produce reliable BI output is not ready for AI. The AI layer will inherit whatever unreliability exists in the data and express it in confident, fluent language. A hallucinated variance commentary generated from unconsolidated entity data is more dangerous than an incorrect spreadsheet cell, because it is harder to identify as wrong.

The correct sequence: fix the data foundation, validate that BI output is reliable and trusted by the finance team, then layer AI on top as a reasoning and detection tool. Groups that skip to AI without the foundation in place do not save time. They generate a different, more expensive category of failure.

The EUR 75M professional services group: a case study in sequencing error

A VC-backed professional services group, EUR 75M revenue, 5 entities across four countries, allocated an EUR 180,000 budget to BI implementation and six months to delivery. The project plan included data integration in weeks 3-8. By week 12, the integration work was still incomplete. The discovery: two acquired entities had never harmonised their charts of accounts to the group standard, and the intercompany positions between three entities had not been formally reconciled in 14 months.

The BI vendor was not equipped to address either problem. The project was paused. A data architecture engagement ran in parallel for 11 weeks, resolving the CoA inconsistencies and establishing an automated IC reconciliation process. The BI implementation then resumed and delivered in 8 weeks. Total project duration: 31 weeks against a 24-week plan. Total cost: EUR 280,000 against an EUR 180,000 budget. The additional EUR 100,000 was the cost of discovering the data architecture problem at implementation stage rather than at diagnostic stage.

The Group CFO's assessment afterwards was direct: if we had spent EUR 20,000 on a data architecture diagnostic before the BI project started, we would have known the scope of the foundation work upfront and budgeted for it. The EUR 80,000 overrun was the price of skipping that diagnostic.

If your BI budget is approved and the implementation is being scoped - the most useful first conversation is about the data foundation, not the platform. Talk to us about what your group's data actually looks like today, and whether it will support the BI outcome you are expecting from the investment.