Expert verified
Your ERP went live two years ago and the implementation partner assured you that it was the best out there. Today, the board wants last quarter’s delivery margin by client vertical across Chennai, Bangalore, and the US subsidiary.
The ERP can show billing by entity, but not a consolidated view. So finance manually builds a spreadsheet which takes 12 days, by which time the numbers are already outdated.
The problem is quite common and no, it’s not your ERP. Your ERP was designed for a single-entity business, and your company now operates across multiple delivery centres, branch offices, and possibly legal entities, each with its own P&L, headcount, billing rates, and compliance obligations.
Standard ERP reports give you entity-level data, but not the consolidated view a multi-entity business needs, leaving CFOs reliant on manual workarounds.
This article explains why that gap exists, what a CXO dashboard should deliver beyond standard reporting, how to structure the underlying data, which technology layer fits businesses at this scale, who should own the definitions, how to build trust in the numbers, and how PKC helps.
Why Standard ERP Reports Stop Being Enough at Enterprise Scale
The problem with standard ERP reports is that they are designed around individual entities and transactions, while CXOs need a consolidated view of performance across entities, locations, functions and time periods.
Consider what happens when you ask your ERP for a group-wide view of revenue by service line. Your ERP might have three separate company codes for your delivery centres. Each code uses a different chart of accounts because they were set up at different times by different teams.
One centre codes cloud infrastructure revenue under “Service Revenue – Infrastructure.” Another codes it under “Cloud Services.” A third uses “IT Services – Hosting.” Your ERP cannot reconcile these definitions. It gives you three separate reports, and your finance team spends days mapping them manually in Excel.
The same problem repeats across cost centres, headcount, billing rates, and project codes. Each entity operates as its own silo, and the ERP reinforces that silo because it was never configured for group-wide consolidation.
This process becomes increasingly difficult as entities and reporting requirements grow. It also creates dependency on spreadsheets, individual analysts and manual reconciliation.
The manual of consolidation has its own problems. A spreadsheet stitched together from four systems is accurate only when built, quickly goes stale, depends on one analyst, and leaves COOs and CIOs unable to drill into the numbers without another manual pull. By the time the board sees it, the data is already old.
For companies with subsidiaries, Section 129(3) of the Companies Act, 2013 requires consolidated financial statements in the prescribed circumstances. But a CXO dashboard serves a different purpose. It should provide an ongoing view of operational and financial performance rather than waiting for a periodic consolidation exercise.
The issue extends beyond revenue.
Your management may need one view of profitability, utilisation, headcount, billing rates, project margins, receivables, cash flow and cost performance across several business units.
Without common definitions and controlled data integration, the result is a management dashboard built from stale or manually consolidated information. By the time a board review takes place, the figures may already be weeks old, and answering a simple follow-up question may require another spreadsheet exercise.
The CXO must make sure that the reports can be standardised, consolidated and transformed into a reliable management view without repeated manual intervention.
That is the point at which a dedicated CXO dashboard implementation becomes useful. It acts as a way to establish common KPI definitions, connect multiple data sources and give leadership one consistent view of what is happening across the enterprise.
What CXOs Actually Need: KPIs, Not Just Reports
A report tells management what happened. A well-designed CXO dashboard helps answer something more useful: Does this number require a decision now, and where should management act?
For a CFO of a multi-entity IT/ITES company, the relevant KPIs are not the same as they were when you were a single-entity business. You now need to track:
- Group-level revenue by service line, entity, and geography, including the contribution of each delivery centre to the group’s top line and how that mix is changing month over month.
- Utilisation rates across centres, including the variance between centres and whether under-utilised centres are dragging down group-level profitability.
- Billing realisation by entity and client, including what was billed versus what was collected and how the collection cycle varies across entities and client segments.
- Working capital at the group level, including the group’s net working capital position and whether inter-entity transactions are distorting the picture.
- Headcount and cost per employee by centre, including the cost structure of each centre and whether lower-cost centres are being optimally utilised.
Your standard ERP reports cannot deliver these metrics without significant customisation. And even if you customise your ERP, the customisation is entity-specific. It does not solve the consolidation problem.
You need a dashboard layer. This layer normalises data from ERP, timesheet, CRM, HR and other systems before presenting the consolidated KPI to the CXO team.
This dashboard needs to be real-time, or near-real-time, so that you are not making decisions on stale data. And it should be exception-based, alerting you to variances and outliers rather than forcing you to scan through pages of reports.
Remember, the goal of the CXO dashboard is not a screen filled with metrics. It is having a trusted management view that shows what is changing, where the variance is occurring, and what requires attention.
Data Architecture: Consolidating Across Entities and Systems
Building a CXO dashboard for a multi-entity enterprise requires a specific data architecture. You cannot simply connect your dashboard tool directly to your ERP and hope that it works.
You need to establish a reliable data foundation for extracting, normalising, reconciling and presenting data. The architecture involves three layers:
Layer 1: Data Extraction
This layer pulls data from all source systems. This includes your ERP instances, HRMS, CRM, project management tools, and any other systems that generate operational data. For each entity, you need to extract the relevant transactional data: revenue, costs, headcount, billing, collections, and project metrics.
The extraction needs to be automated and scheduled. Manual extraction defeats the purpose of a real-time dashboard.
If your finance team is still exporting data from each ERP instance and loading it into the dashboard, you have not solved the problem; you have just moved the manual effort from Excel to a dashboard tool.
Layer 2: Data Transformation and Normalisation
Raw data from different entities uses different definitions, different charts of accounts, different cost centre structures, and different project codes. Before you can consolidate it, you need to map these definitions to a common group-wide taxonomy.
For example, you need a mapping table that says: Entity A’s ‘Service Revenue – Infrastructure,’ Entity B’s ‘Cloud Services,’ and Entity C’s ‘IT Services – Hosting’ all map to ‘Group Revenue – Cloud Infrastructure.’
Similarly, you need mappings for cost centres, project codes, employee categories, and any other dimension you want to report on.
The same discipline needs to apply to KPIs. Utilisation, billable hours, revenue, project realisation and other management metrics should each have one documented group-level definition. Otherwise, the dashboard may combine numbers that are individually correct but calculated differently.
This mapping should be reviewed periodically. As the business evolves, new entities, service lines, and cost centres will be added. The architecture should therefore incorporate a governance framework for maintaining, updating, and validating these mappings over time.
Layer 3: Data Presentation
This is the dashboard itself. The presentation layer should be role-based: the CFO sees group-level financials, the COO sees operational metrics across centres, and the CIO sees IT performance indicators.
Each user should see the data that is relevant to their decision-making, with the ability to drill down from group-level aggregates to entity-level details.
The dashboard should also include alerting and exception reporting. Instead of scanning through pages of metrics, the CXO should be alerted when a metric crosses a threshold, let’s say when utilisation in a particular centre drops below 75%, or when receivables in a particular entity exceed 90 days.
If you are evaluating a dashboard implementation, the key question to ask is “Have we established one agreed definition of the data before we start presenting it?”
Choosing the Right Layer: ERP-Native, BI Tool, or Custom Dashboard
When you decide to build a CXO dashboard, you have three broad options, each with its trade-offs. The right choice depends on your specific situation.
ERP-Native Dashboards
ERP-native dashboards can be an effective option when a business uses one ERP system with a consistent data structure across all entities.
Most modern ERPs, including SAP, Oracle, and Microsoft Dynamics, offer built-in dashboarding and analytics capabilities. They work well because they are already integrated with your ERP data and require no additional investment in tools.
The limitation is that ERP-native dashboards are entity-specific. They can show you a dashboard for Entity A, and a separate dashboard for Entity B, but they cannot easily consolidate data across entities unless your ERP is configured for multi-entity consolidation from the start, which most are not. Even if your ERP supports multi-entity consolidation, the configuration is complex and expensive, and it locks you into your ERP’s reporting framework.
BI Tools
Business Intelligence tools like Power BI, Tableau, and Looker are designed to connect to multiple data sources, transform data, and build visual dashboards. They are more flexible than ERP-native dashboards and can consolidate data from multiple entities.
The drawback here is that they require substantial data modelling and governance. You need to build the data transformation layer, define the mappings, and maintain them as your business evolves. This is not a one-time project; it is an ongoing capability.
Many companies invest in a BI tool, build a few dashboards, and then struggle to maintain them because the underlying data definitions keep changing and no one owns the governance.
BI tools also require technical expertise. Your finance team cannot build and maintain these dashboards on their own; they need data engineers or BI developers. If you have that capability in-house, a BI tool can be a cost-effective solution. If you do not, you will either underutilise the tool or end up relying on external consultants for ongoing maintenance.
Custom Dashboards
Custom dashboards are built specifically for your business, with your data architecture, your KPIs, and your governance framework. They are built on a data warehouse or data lake, with ETL (extract, transform, load) processes that consolidate data from all source systems.
Custom dashboards offer the greatest flexibility and the best alignment with your business needs. They can handle complex multi-entity consolidations, role-based access, and exception-based alerting. They are also easier to maintain over time because the governance framework is built into the architecture rather than being an afterthought.
The challenge is cost and time. Custom dashboards take longer to build and require more investment than off-the-shelf solutions. For a mid-sized enterprise, a custom dashboard project takes around 8 to 16 weeks from requirements gathering to go-live, depending on the number of entities and the complexity of the data architecture.
Which Option Is Right for You?
If you have a single ERP instance with multi-entity capabilities already configured, and your consolidation needs are straightforward, ERP-native dashboards may suffice.
If you have multiple data sources and a capable in-house data team, a BI tool can be a good fit.
If you have multiple entities, inconsistent data definitions, and complex consolidation requirements and you do not have the in-house capability to build and maintain the data architecture a custom dashboard is mostly the right choice.
Governance: Who Owns Data Definitions and Refresh Cycles
Most multi-entity dashboard projects fail due to lack of proper governance. Someone needs to own the data definitions, the mapping tables, and the refresh cycles. Without clear ownership, the dashboard becomes stale, inaccurate, and ultimately unused.
For a multi-entity enterprise, data governance keeps the dashboard consistent after implementation, especially when new entities, service lines, cost centres or reporting requirements are added.
Data Definition Ownership
Every KPI should have one documented, group-wide definition. For example, revenue should clearly specify whether it means booked revenue, billed revenue or collections, and how inter-company transactions and pass-through costs are treated.
These definitions should be owned by a group-level data governance lead, ideally within finance. Other functions can provide input, but one owner should be accountable for the definition and any changes.
The same applies to utilisation, project realisation, headcount and cost per employee. Without common definitions, entities may report technically correct figures that are not meaningfully comparable.
Mapping Table Maintenance
The dashboard’s mapping tables translate local charts of accounts, cost centres, project codes and employee categories into the common group structure. These mappings require ongoing governance.
New service lines, cost centres or other structural changes should be reviewed and mapped before entering the consolidated dashboard. Without this, mappings can become incomplete within months of implementation.
PKC’s dashboard implementation approach therefore includes a data dictionary and mapping governance process, with defined ownership, review frequency and approval for material changes.
Refresh Cycles
“Real-time” should not imply continuous updates for every dashboard tile. Refresh frequency should reflect the underlying source and the decision the metric supports.
Operational metrics such as utilisation, attendance and ticket volumes may warrant daily or more frequent updates where systems support them. Financial metrics such as consolidated revenue and margin may depend on the monthly close and should clearly show their reporting period.
The dashboard should display the last refresh time or data-as-of date where relevant, so users do not mistake period close figures for current results.
Governance Resilient to Change
Data ownership should not depend on one person’s institutional knowledge. KPI definitions, mapping logic, source systems, calculation rules and approval history should be maintained in a written data dictionary and governance register.
Ask if someone new to the organisation can explain how every important KPI is defined, where its data comes from, when it was last refreshed and who approved the definition?
If the answer is no, the dashboard may look reliable without being governable. A strong CXO dashboard implementation therefore treats data ownership, mapping maintenance and refresh governance as part of the solution itself, not as administrative work to be addressed after the dashboard goes live.
Rollout Approach: Pilot With One Entity Before Scaling Group-Wide
The worst approach to implementing a multi-entity CXO dashboard is to try to do everything at once. You will spend months building the architecture, struggle with data quality issues across multiple entities, and end up with a dashboard that no one trusts.
The better approach is to pilot with one entity first.
Select a Pilot Entity
Choose one entity that represents a reasonable cross-section of your business. It should have clean data, a cooperative finance team, and a clear set of reporting requirements. Do not choose the entity with the messiest data as you will spend all your time cleaning data and none of your time building the dashboard.
The pilot entity should also be one where the leadership team is engaged and willing to provide feedback. You need a partner who will tell you what is working and what is not, not someone who will passively accept whatever you build.
Build the Pilot Dashboard
Build the full dashboard architecture for the pilot entity: extract the data, transform it, and build the presentation layer. This gives you an end-to-end working system that you can test and refine.
The pilot should include all the key components: data extraction, transformation, dashboard presentation, role-based access, and exception alerting. Do not cut corners because it is “just a pilot.” The pilot should be production-quality, because you will use it as the template for scaling to other entities.
Refine and Iterate
Run the pilot for 4 to 8 weeks. During this period, gather feedback from the pilot entity’s leadership team. What metrics are missing? What definitions are unclear? What would make the dashboard more useful?
Use this feedback to refine the dashboard. This is also the time to test the governance processes: how will mappings be maintained? Who will own the refresh cycles? What happens when something breaks?
Scale to Additional Entities
Once the pilot is stable and the governance processes are working, scale to additional entities. Add them one at a time, or in small batches. Each new entity will have its own data quirks, its own definitional differences, and its own set of stakeholders. By scaling incrementally, you can address these issues without overwhelming your team.
The full rollout for a multi-entity dashboard can take 3 to 6 months, depending on the number of entities and the complexity of the data architecture.
Run the new dashboard alongside existing reporting for at least one full reporting cycle before retiring the old reports. Any differences in reported figures should be treated as data architecture issues requiring resolution, not simply as old-versus-new discrepancies.
Identifying and resolving these differences while both systems are running reduces the risk of undermining leadership’s trust in the numbers after the legacy reports have been retired.
How PKC Designs CXO Dashboards for Multi-Entity Enterprises
PKC approaches CXO dashboard projects differently from technology vendors or pure-play BI consultants. As a CA-led consulting firm with 35+ years of experience across 10+ industries the starting point of our engagements is the business problem.
When we design a CXO dashboard for a multi-entity IT/ITES company, the engagement usually looks like:
Phase 1: Preparation (1 to 2 weeks)
We start by sitting with the CFO, controller, and operational heads to write down, precisely, what each KPI is actually meant to mean, utilization, delivery margin, realization rate, in language specific enough that two different delivery centres can’t quietly interpret it two different ways.
We aim to establish a consistent group-wide definition without forcing identical procedures onto genuinely different operations. This makes group-level reporting genuinely comparable.
Phase 2: Diagnosis (2 to 3 weeks)
PKC’s team maps the current reporting architecture: what data is available, from which systems, with what definitions, and with what frequency. This includes reviewing the chart of accounts across entities, understanding the consolidation process currently in use (often Excel-based), and identifying the specific KPIs that matter most to the CXO team.
The diagnosis phase also identifies the governance gaps: who owns data definitions today, who maintains them, and what happens when definitions change. In most multi-entity enterprises, these gaps are the root cause of reporting delays and inaccuracies.
Phase 3: Architecture Design (2 to 3 weeks)
Based on the diagnosis, we design the data architecture. This includes which systems will be the source of truth for each metric, how data will be extracted and transformed, and what the dashboard presentation layer will look like.
The architecture design includes the mapping tables that will normalise definitions across entities. PKC works with the finance team to document these mappings and establish the governance framework for maintaining them going forward.
Phase 4: Pilot Build (4 to 6 weeks)
PKC builds the pilot dashboard for one entity, following the architecture design. This includes setting up the data extraction, building the transformation layer, and creating the dashboard presentation.
The pilot is built using the technology stack that best fits the client’s situation. This can mean a BI tool like Power BI, a custom dashboard built on a data warehouse, or an ERP-native solution. PKC works across 30+ ERP systems, so the technology choice is driven by your needs rather than the consultant’s preferences.
Phase 4: Refinement and Scaling (8 to 12 weeks)
After the pilot is stable, we support the client in refining the dashboard based on user feedback and then scaling it to additional entities. This is done incrementally, with each new entity added one at a time.
The scaling phase also includes training the client’s team on dashboard maintenance and governance. PKC does not just hand over a dashboard; they ensure that the client’s team has the capability to maintain it going forward.
At PKC we don’t force a custom dashboard on every client. For some clients, an ERP-native solution or a BI tool may be sufficient. Our recommendation and implementation is based on an honest assessment of the client’s needs, capabilities, and constraints.
Now the question may arise “Can my internal finance and IT teams handle this on their own?”
You have a competent finance team and a capable IT team, then why bring in a consultant? That’s a genuine concern before hiring external consultants.
Your internal teams can handle parts of this project. IT team can set up the data extraction, finance team can define the KPIs. But the critical piece, the data architecture that consolidates data from multiple entities with inconsistent definitions, requires experience that most internal teams lack.
This is not about capability. It is about experience.
A multi-entity dashboard involves decisions on data modelling, mapping, governance and refresh cycles that have long-term consequences. Get them wrong, and you can end up with a dashboard that is expensive to maintain, produces unreliable data or is abandoned within a year.
A consultant who has delivered these projects for multiple clients brings practical experience of what works, what fails and where problems are likely to arise. That helps anticipate issues early and build a dashboard that is maintainable and functional.
If you are a CFO of a multi-entity company and you are spending too much time reconciling data from different entities, or if your management reviews are based on data that is weeks old, schedule a conversation with PKC.
FAQs
Q1: Why do standard ERP reports fall short for enterprises running multiple plants or branches?
Standard ERP reports are built for single-entity visibility. They show you what happened in one legal entity or one company code. When you operate across multiple entities, each with its own chart of accounts, cost centre structure, and data definitions, your ERP cannot consolidate that data into a group-wide view. The result is manual consolidation in Excel, which is time-consuming, error-prone, and produces data that is already outdated by the time it reaches the CXO team.
Q2: What is the difference between a BI dashboard and a custom CXO dashboard?
A BI dashboard is built using a commercial tool like Power BI or Tableau. It connects to data sources, transforms data, and presents it visually. A custom CXO dashboard is built specifically for your business, with your data architecture, your KPIs, and your governance framework. The difference is not the tool; it is the architecture and the governance. A custom dashboard includes the data consolidation layer, the mapping tables, and the governance processes that a BI tool alone does not provide.
Q3: Who should own data definitions for a group-wide dashboard?
The CFO’s office should own the process of defining and maintaining data definitions, but the definitions themselves need to be cross-functional. Finance defines revenue and cost metrics. Operations defines utilisation and productivity metrics. Sales defines pipeline and booking metrics. The governance framework should include representatives from each function, with the CFO’s office providing overall coordination.
Q4: How long does it take to implement a CXO dashboard across multiple entities?
A pilot dashboard for one entity takes 6 to 8 weeks from diagnosis to go-live. Scaling to additional entities takes 3 to 6 months, depending on the number of entities and the complexity of the data architecture. The full rollout for a mid-sized enterprise with 3 to 5 entities takes 4 to 6 months.
Q5: Does a CXO dashboard require replacing the existing ERP?
No. A CXO dashboard sits above your ERP and other systems, extracting data from them rather than replacing them. You keep your ERP for transactional processing and entity-level reporting. The dashboard provides the group-wide consolidation and presentation layer that your ERP does not.
Q6: How does PKC approach dashboard rollout for organizations scaling across locations?
PKC uses a phased approach: diagnose the current reporting architecture, design the data architecture and governance framework, build a pilot for one entity, refine based on feedback, and then scale incrementally to additional entities. This approach reduces risk, ensures that the governance framework is working before scaling, and gives the client team time to build the capability to maintain the dashboard going forward.
