6 Steps to Implementing BI Across a Multi-Entity Group — What the Standard Playbook Gets Wrong

The standard BI implementation playbook was written for a single entity. In a multi-entity group, each of its six steps requires a fundamentally different approach - and the failure modes at each step are different in kind, not just in degree, from those a single-entity implementation encounters. The steps are the right steps. What they require in a group context is not what the standard playbook describes.

Why the standard playbook understates group BI complexity by 3 to 5 times

The gap between single-entity BI and group BI is not a matter of scale. It is a matter of structural incompatibility. A single-entity BI implementation connects one ERP, maps one set of metrics, and builds dashboards for one reporting structure. The data definitions are internally consistent because they come from one system. The close timing is uniform. There are no intercompany positions to eliminate.

In a group with six entities, three ERPs, and five years of accumulated accounting conventions, none of these conditions hold. The data definitions are not internally consistent. The close timing differs across entities. Intercompany positions must be identified, reconciled, and eliminated before any group-level metric is meaningful. Ignoring these differences at the project plan stage does not make them go away. It makes them appear later - when the implementation is in progress, when they are more expensive to resolve and more disruptive to manage.

EY research on BI implementation outcomes across European mid-market groups found that group BI projects experienced scope overruns averaging 3.2 times the planned budget for the data integration phase. The primary driver in 78% of cases: discovery of chart of accounts inconsistencies and unreconciled intercompany positions that were not identified or scoped during the initial project definition phase.

Step 1: Define data needs - but audit data definitions first

The standard playbook begins: identify what the business needs to measure. In a group, that question cannot be answered until a prior question has been resolved: do the same words mean the same things across all entities? Revenue, gross margin, headcount, EBITDA - in most groups assembled through acquisition or organic expansion, these are defined differently in different entities. Before the Group CFO's data needs can be specified, the entity-level definitions must be audited and inconsistencies must be resolved into group-level standards that all entities are required to adopt.

This step typically takes three to four weeks in a group context. It requires structured conversations with entity-level finance leads, not just the group finance team. The output is not a data dictionary - it is a policy document that defines group-level metrics and that carries governance authority over how those metrics are calculated at entity level. Without that authority, the definitions that are agreed at this step will drift as entity finance teams revert to local conventions.

Step 2: Data integration - where most group BI projects discover the real scope

In a single entity, data integration means connecting the ERP to the BI platform. In a group, it means resolving structural incompatibilities between multiple ERPs, billing systems, CRM platforms, and banking feeds - then building consolidation logic that handles chart of accounts mapping, intercompany elimination, FX translation, and period alignment automatically. The technical integration is the smaller part of this work. The larger part is the policy and governance work that defines how the incompatibilities are resolved.

A PE-backed professional services group, EUR 75M revenue, 4 entities across three countries, allocated six weeks for data integration in its BI project plan. The actual work took twenty-two weeks. The discovery: two acquired entities had never aligned their charts of accounts to the group standard, and the intercompany positions between them had not been formally reconciled in over a year. The BI vendor was not equipped to address either problem. The group engaged a finance transformation partner to run the data architecture work in parallel with the BI project. Total project duration extended by 16 weeks. Total additional cost: EUR 95,000.

Step 3: Dashboard design - the Group CFO and entity GMs need different products

A group BI implementation serves two fundamentally different audiences. The Group CFO needs a consolidated view with drill-down capability - the ability to see which entity drove a group-level variance and to disaggregate consolidated performance by entity, market, and business unit. Entity general managers need an operational view calibrated to their own P&L - their own KPIs, their own performance against plan, their own entity-level drivers.

These are different dashboards built on the same data model. They are not the same dashboard shown to different users with different access permissions. A dashboard designed for the Group CFO is too aggregated for a GM to manage an entity from. A dashboard designed for a GM contains entity-level operational detail that is irrelevant and distracting at group level. Designing both audiences' needs as if they were a single problem produces dashboards that serve neither well.

Steps 4 and 5: Analysis and training require organisational work, not technical work

Once the BI system is live, the instinct is to begin analysis immediately. In a group, this step requires a validation layer. Numbers across entities are only comparable if they have been produced consistently - same accounting period, same KPI definitions, same intercompany treatment. If the data has not been fully standardised upstream, analysis will surface observations that reflect definitional inconsistency rather than operational reality. The governance question at this step is: who certifies that the data in the BI system is comparable across periods and entities before it is used for management decisions? If nobody owns that certification, the analysis is not trustworthy, regardless of how sophisticated the BI platform is.

Training in a group context is an organisational challenge, not a software challenge. Entity-level finance teams must understand and trust the group definitions that have been applied to their data. When a German entity controller sees that their gross margin in the BI system differs from the margin they report locally, they will not trust the BI number unless they understand why the difference exists and have been given the opportunity to validate it. This trust-building process is not a training session. It is an organisational change programme that requires Group CFO authority to be credible.

Step 6: Ongoing governance - the step that determines whether the investment holds

A BI system without active governance decays faster in a group than in a single entity. As entities evolve, definitions drift. New entities are acquired with their own conventions. Business models change. The definitions agreed at implementation begin to diverge from current practice entity by entity, reporting period by reporting period. Within two years, without active governance, a group BI implementation frequently returns to a state of limited trust - not because the platform has failed, but because the data architecture underneath it has not been maintained.

Ongoing governance in a group context means a defined process for reviewing data definitions when entities change, a protocol for onboarding new entities to the group data standard, and a named owner - at Group CFO level - for the integrity of the data model. Without these, the investment in the BI platform is a depreciating asset rather than a compounding one.

If you are planning a group BI implementation, the most valuable investment before the project begins is a data architecture assessment. Talk to us about what your group's data looks like today and what it will take to make a group BI implementation deliver the consolidated view you need from the budget you are allocating.