A phased roadmap for consolidating reporting across multiple ERPs after acquisition, with dependencies, owners, and what becomes available at each stage.
Usually not. Standardisation is a multi year programme and reporting is the thing leadership needs now. Consolidating above the systems delivers comparable numbers in months and leaves the systems decision open. It also tends to change that decision, because once reporting works the case for migrating everyone weakens considerably.
The definition mapping is typically two to four weeks and the modelled reporting layer follows it. The first comparable pack usually lands within a quarter for a small portfolio, longer where entities use materially different revenue recognition and those differences have to be agreed rather than just mapped.
They will, and both are usually defensible on their own terms. This is a decision for the group controller rather than a problem to be analysed further. The roadmap stalls when that decision is deferred, so put a date on it in Phase 1 and name who makes it.
No. Phase 2 reads from each ERP as it stands and applies the mapping in a modelled layer. Nobody changes system, nobody retrains, and each entity keeps operating as it does today. That is what makes the timeline measured in months.
If the layer was built for it, a new entity is a mapping exercise against the existing group standard rather than a rebuild. Ask about this explicitly, because a layer built for a fixed set of entities will have to be reworked and that cost tends to surface later.
Consolidating reporting across acquired companies fails on sequence more often than on technology. Standardise the ERPs first and reporting waits years. Centralise reporting first and you inherit every inconsistency underneath. This is the phased plan, with the dependencies and the owner for each phase, so the sponsor can see what arrives when.
A phased roadmap for consolidating reporting across multiple ERPs after acquisition, with dependencies, owners, and what becomes available at each stage.
A multi ERP consolidation roadmap sequences the work of making acquired entities report comparably. The usual mistake is treating it as an ERP standardisation programme, which takes years. Reporting can be consolidated above the ERPs first, so comparable numbers arrive in months while the systems question is decided separately.
When do I get comparable numbers, and what has to happen first?
Before any system work. Two entities reporting revenue are frequently measuring different things, and no amount of integration fixes that.
Where accounts correspond, where they only appear to, and where one entity splits what another combines. This is the artifact everything later depends on.
Revenue recognition timing, what counts as a cost of sale, how intercompany is treated. Usually a short list, and usually the cause of most of the variance.
A decision, not a technical finding. Needs the group controller to make it and the entity finance leads to be told rather than consulted indefinitely.
Group controller owns it. Output is a written mapping document that every later phase reads from. Typically two to four weeks.
This is where comparable numbers actually arrive, and it does not require touching anyone's ERP.
No migration, no standardisation. Read what is there. Each entity keeps running the system its people know.
The translation lives in the data layer rather than in a spreadsheet owned by one person. This is the part that makes it repeatable.
The group figure has to tie to each local ledger, and there has to be a check that proves it. Without this, local finance leads will not trust the group number and will keep their own.
Group finance with the data team. Output is a comparable group view with entity drill down. This is where the board pack stops taking three weeks.
With comparable reporting already running, this decision stops being urgent and starts being economic.
Often the answer changes once reporting works, because the pain that justified the migration has gone. That is a legitimate outcome and it saves a great deal of money.
Usually driven by contract renewal dates and local capability rather than by size.
The layer built in Phase 2 keeps group reporting stable while individual entities move underneath it. This is the main argument for doing Phase 2 first.
CIO with the portfolio operating partner. Output is a costed systems decision with a date, or a documented decision not to proceed.
They will maintain shadow reporting and the group number will be disputed in every meeting. Involve them in Phase 1 or expect this.
Without a tie out, the group view is an assertion. Local teams will not adopt it and you will run two sets of numbers indefinitely.
Standardising systems before reporting is the sequence that produces a three year programme with nothing visible in year one. It is also the sequence most vendors propose.
Likely in a portfolio. The modelled layer has to be built to absorb a new entity as a mapping exercise rather than a rebuild.
A credit union running four core banking systems after consolidation. Reporting was unified above the systems rather than by migrating everyone onto one platform first.
The sequence answer tells you most of what you need to know about a firm.
Do you propose standardising the ERPs before consolidating reporting? If so, what arrives in year one?
How does the group figure reconcile back to each entity's own ledger?
What happens to the reporting layer when we acquire again mid programme?
Who decides which entity's definition becomes the group standard, and when?
What does the first comparable board pack look like, and in which month?
Usually not. Standardisation is a multi year programme and reporting is the thing leadership needs now. Consolidating above the systems delivers comparable numbers in months and leaves the systems decision open. It also tends to change that decision, because once reporting works the case for migrating everyone weakens considerably.
The definition mapping is typically two to four weeks and the modelled reporting layer follows it. The first comparable pack usually lands within a quarter for a small portfolio, longer where entities use materially different revenue recognition and those differences have to be agreed rather than just mapped.
They will, and both are usually defensible on their own terms. This is a decision for the group controller rather than a problem to be analysed further. The roadmap stalls when that decision is deferred, so put a date on it in Phase 1 and name who makes it.
No. Phase 2 reads from each ERP as it stands and applies the mapping in a modelled layer. Nobody changes system, nobody retrains, and each entity keeps operating as it does today. That is what makes the timeline measured in months.
If the layer was built for it, a new entity is a mapping exercise against the existing group standard rather than a rebuild. Ask about this explicitly, because a layer built for a fixed set of entities will have to be reworked and that cost tends to surface later.