Centralize reporting or standardize the ERPs first? The conditions that decide

In seven consolidation engagements the source systems were kept in every one and the comparable layer was built above them. Four conditions that really do force the ERP work first, four arguments that look like conditions and are not, and why federating ownership beat centralising it.

Three entities, three sets of numbers, and two proposals on the table. One builds a reporting layer above what you have. The other standardises the operating systems underneath. They end in the same place and they are not equivalent decisions.

The two routes side by side

Two routes to one set of comparable numbers

Both end at comparable reporting. They differ in what has to change, who has to agree, and when the first usable number arrives.

In seven consolidation engagements in our case library the source systems were kept in every one, and the comparable reporting was built above them. That is a pattern, not a law, and the conditions that break it are below.

Source: Thinklytics case library, the system consolidation and data foundation engagements, published durations and outcomes per engagement.

The differences that matter are not technical. They are who has to agree, when the first usable number arrives, and whether you can change your mind.

The reporting layer needs finance to agree on mappings and definitions. The ERP programme needs every operating entity to agree on process as well as data, which is a different conversation with different people and a different failure mode.

The reporting layer produces a comparable number in weeks, on whatever mapping exists so far. The ERP route produces one after the last entity cuts over, which means the programme carries political risk for its entire duration with nothing to show.

And the reporting layer is reversible. A mapping is a document and a set of transformations. An account map that turns out wrong is a day of work and a re-run. A cutover is not undone: the old system is decommissioned, history is converted, staff are retrained.

What our own work shows

Seven consolidations, what stayed and what it took

In every one the source systems were kept and the comparable layer was built above them. Duration tracks the number of sources, roughly, not the size of the company.

The cloud provider is the instructive one. Previous consolidation attempts had stalled on business unit resistance, so each unit kept control of its data and published through a shared catalogue instead. Federating ownership is what resolved the politics.

Source: Thinklytics case library, published delivery durations and outcomes per engagement.

Seven consolidation engagements in our case library brought multiple sources onto one comparable set of numbers. In all seven the source systems were kept and the layer was built above them.

A regional P&C insurer that had bought two carriers over eight years kept four claims systems and got a unified claims data layer in 13 weeks, with 1.2M policy records consolidated and loss ratio reporting accuracy rising from 71 to 97 of every 100. A credit union kept four core banking systems after three acquisitions in five years and reached same-day member analytics in 20 weeks, from three days of manual work, with annual data cost falling from $1.3M to $310K.

Duration tracked the number of sources, roughly. Four systems at 13 and 20 weeks, five at 18, nine at 26, eleven at 24, fourteen at 30. It is a correlation rather than a formula, and it is good enough for planning.

That is seven engagements, not a controlled study, and the selection is not random: these are companies that called a data consultancy rather than an ERP integrator. Read the pattern with that in mind. What it does establish is that comparable reporting across a multi-system estate is routinely achievable without touching the systems.

Federating ownership instead of taking it

The most instructive of the seven is the one where the politics were the binding constraint.

A cloud provider had let 14 business units build separate data warehouses over eight years. No shared metrics, no cross-unit reporting, $4.7M a year to maintain. The CTO had ordered a consolidation and previous attempts had stalled, not on technology but on business unit resistance.

So the architecture was chosen to dissolve the resistance rather than to overcome it. No central warehouse. Each unit kept control of its own data and published it through a shared catalogue with standard interfaces, migrated in groups of three over 30 weeks. By week 30 all 14 were integrated, infrastructure cost had fallen to $1.1M a year, cross-unit revenue and customer overlap reporting existed for the first time, and there were zero business unit escalations.

Worth being precise about what that example proves. It is not that a mesh architecture is generally correct. It is that when the previous attempts failed on ownership, changing the ownership model is the intervention, and the technical shape follows from it. See the federated data mesh engagement.

When the ERP work really does come first

When the ERP work really has to come first

At least one of these has to hold. If none do, the reporting layer is the cheaper and faster route to the same place.

• A source system is end of life with no support or patch path. You are replacing it regardless, so map into the target rather than the system you are retiring.
• A source cannot be extracted on a schedule. Interactive-only reports and screen-scrapes. The 7% of ERP estates with no integration at all sit here.
• The operating model itself is being merged, not just the reporting. Shared service centre, one procurement function, one order-to-cash process. Then the systems follow the process.
• A regulator or auditor requires the transactional system of record to be unified. Rare, and specific. Ask for the citation rather than accepting it as received wisdom.
• The acquisition closed recently and the numbers do not agree. Not a reason. This is the normal state after a deal and it is a mapping problem first.
• The estate has several ERPs. Not a reason on its own. 89% of companies run multi-instance ERP estates and most have no acquisition to blame.
• A platform vendor has proposed consolidation as the path to comparable reporting. Check whether the proposal includes writing the definitions down. If it does not, the new system inherits the disagreement.

A credit union with four core banking systems after three acquisitions kept all four and built a member data platform above them in 20 weeks. The board approved the next acquisition six weeks later, citing that unified view.

Source: Forrester Research, The Top Trends Shaping ERP, July 2026, as cited by HSO; Thinklytics case library, published engagement outcomes.

Four conditions. At least one has to hold.

A source is end of life with no support or patch path. You are replacing it regardless, so map into the target rather than into the system you are retiring.

A source cannot be extracted on a schedule. Interactive-only reports, screen-scrapes, no API. Vena's 2026 FP&A Impact Report, administered October 2025 with Benchmarkit across 431 finance professionals, found 7% with no integration at all between their FP&A tools and source systems, depending on manual uploads. If you are in that 7% for a material entity, the layer has nothing to stand on.

The operating model itself is being merged. One shared service centre, one procurement function, one order-to-cash process. Then the systems follow the process, and a reporting layer over divergent processes would be mapping a difference you are about to remove.

A regulator or auditor requires the transactional system of record to be unified. Rare and specific. Ask for the citation rather than accepting it as received wisdom, because this one gets asserted far more often than it applies.

Four arguments that are not conditions

The acquisition closed recently and the numbers do not agree. This is the normal state after a deal. It is a mapping problem first, and the six differences behind it are in why acquired companies cannot report comparably.

The estate has several ERPs. Forrester's The Top Trends Shaping ERP, July 2026, reports 89% of companies on multi-instance ERP estates and only 7% on a single instance, with 50% rating customisation, integrations and functional scope as complex. Those figures are attributed to the named Forrester report via HSO rather than read directly, so treat the attribution as secondary. The implication holds: most companies with no acquisition history have the same estate, so the estate is not what makes reports incomparable.

A platform vendor has proposed consolidation as the path to comparable reporting. Check whether the proposal includes writing the definitions down. If it does not, the new system inherits the disagreement in a more modern format, and the cost of that mistake is covered in the true cost of a platform migration.

Group policy prefers one system. A preference, not a constraint. It may still be the right call for reasons that have nothing to do with reporting, and it should be argued on those reasons.

What the reporting layer does not fix

Worth stating plainly, because a route chosen on an incomplete comparison gets re-litigated.

The source systems still differ at the record level. If the real problem is duplicate customers or suppliers across entities rather than conflicting rules, identity resolution has to be in scope too. A casino group found 14,200 players active at more than one property only after probabilistic matching across five property management systems. An insurer had to normalise policy numbers, match insured names and align effective dates across four systems before any of it was usable.

You are also still running and licensing every source system. The layer removes the comparability problem, not the estate.

If both are needed

Write the mappings and build the layer first, then migrate onto the definitions rather than carrying the old ones forward.

A migration transports existing rules unless somebody explicitly stops it, because the reports have to keep working through cutover. Then the new warehouse arrives with the same disagreement, the migration is blamed for not fixing a problem it was never scoped to touch, and the mapping work has to be funded a second time against an organisation that has just spent six months on systems and has nothing it trusts to show for it.

Both of the large consolidations in our case library built a shared semantic layer as part of the migration rather than after it, which is why reporting stayed usable through cutover. Our general position is on the record in why we almost never recommend a platform migration.

What we would do first

Test the four conditions against your estate, entity by entity, on one page. Most estates fail all four, which settles the question in an afternoon.

If one holds for a single entity, that entity is an ERP decision and the other entities are a mapping decision. Those are separable, and treating them as one programme is how a two-entity problem becomes an enterprise programme.

Then scope the mapping work. What belongs in it is in what to include in a multi-ERP consolidation scope, and the multi-ERP consolidation roadmap is the phased version we hand to whoever has to approve it.

Delivery sits in data foundation for the mapped layer, system consolidation where sources are being retired, data 360 consultant for cross-entity identity, and Microsoft Fabric or Snowflake where the layer needs a platform under it. The full set of work in this area sits under the data underneath is not ready.

Frequently asked questions

Should we centralise reporting or standardise the ERPs first?

Centralise the reporting above the systems you have, unless one of four conditions holds: a source is end of life with no support path, a source cannot be extracted on a schedule, the operating model itself is being merged rather than just the reporting, or a regulator requires the transactional system of record to be unified. If none of those apply, the reporting layer reaches the same place faster, costs less, and is reversible. A cutover is not.

What are the arguments that look like conditions but are not?

Four. The acquisition closed recently and the numbers do not agree, which is the normal state after a deal and a mapping problem first. The estate has several ERPs, which describes 89% of all companies per Forrester's July 2026 ERP trends report, most of which have no acquisition to blame. A platform vendor has proposed consolidation as the path to comparable reporting, which only works if the definitions get written down and the proposal usually omits that. And group policy preferring one system, which is a preference rather than a constraint.

What does the evidence from your own work show?

In seven consolidation engagements in our case library the source systems were kept in every one and the comparable layer was built above them. Four claims systems at a regional insurer, 13 weeks. Five property management systems at a casino group, 18 weeks. Four core banking systems at a credit union, 20 weeks. Eleven campus warehouses, 24 weeks. Nine reporting systems at a telecom, 26 weeks. Fourteen business unit warehouses at a cloud provider, 30 weeks. Duration tracked the number of sources, roughly, not company size.

Why did federating ownership work better than centralising it?

Because at a cloud provider with 14 business unit warehouses, previous consolidation attempts had stalled on business unit resistance rather than on technology. Instead of a central warehouse, each unit kept control of its own data and published it through a shared catalogue with standard interfaces. All 14 were integrated by week 30, infrastructure cost fell from $4.7M a year to $1.1M, and there were zero business unit escalations. The politics were the binding constraint and the architecture was chosen to dissolve them.

When is the ERP programme the right first move?

When the operating model is being merged, not just the reporting. One shared service centre, one procurement function, one order-to-cash process. Then the systems follow the process and a reporting layer over divergent processes would be mapping a difference you are about to remove. Also when a source is end of life, since you are replacing it regardless and should map into the target rather than the system being retired.

Does the reporting layer leave problems behind?

Yes, and they should be stated. The source systems still differ at the record level, so if the real issue is duplicate customers or suppliers rather than conflicting rules, identity resolution has to be in scope as well. You are also still maintaining every source system and its licence. What the layer does not leave behind is the comparability problem, which is the one the board asked about.

How reversible is each route?

A mapping is a document and a set of transformations, so changing an account map or a calendar rule is a day of work and a re-run. A cutover is not undone: the old system is decommissioned, the historic data is converted, and the staff retrained. That asymmetry is the strongest practical argument for doing the reporting layer first even when an ERP programme is eventually likely, because the mapping work is not wasted when the migration happens, it becomes the migration's specification.

What should we do if both are needed?

Write the mappings and build the layer first, then migrate onto the definitions rather than carrying the old ones forward. A migration transports the existing rules unless somebody explicitly stops it, because the reports have to keep working through cutover, and then the migration gets blamed for not fixing a problem it was never scoped to touch. Both of the large consolidations in our case library built a shared semantic layer as part of the migration rather than after it.

The work behind this

Seven consolidation engagements in the case library brought multiple source systems onto one comparable set of numbers, running 13 to 30 weeks. In all seven the sources stayed in place, and each engagement states the duration, the system count and the measured outcome.

System consolidation and data foundation engagements.