What to include in a multi-ERP reporting consolidation scope

Six mapping artifacts, each with a named signer, and they are the actual deliverable. A scope that names a platform and not these six is a platform project. Plus the eight acceptance criteria, the residual run cost that landed near a quarter of the prior cost in three engagements, and what to ask before signing.

A proposal to consolidate reporting across several entities is in front of you. Most of these proposals describe a platform and a timeline. The thing to check is whether they name the six artifacts that actually make two entities comparable, because those are the deliverable.

The six mapping artifacts

The six mapping artifacts, which are the actual deliverable

A scope that names a platform and not these six is a platform project. These are what make two entities comparable.

The exception register is the one that gets left out and the one that keeps the programme honest. Something will not be comparable in phase one. Writing it down beats discovering it in a board meeting.

Source: Thinklytics engagement pattern across the system consolidation and data foundation engagements in the case library.

Each one needs a named signer, and the signer should be a person rather than a function.

Account map. Every source account to one target account, with the unmapped list visible at all times rather than reported at the end. The unmapped list is the real progress measure.

Entity and hierarchy map. Legal entity to reporting unit, with effective dates for anything acquired mid-year. The effective dates are what make a prior-year comparison legitimate.

Calendar map. Each source's fiscal calendar to the group calendar, including 4-4-5 retail calendars and non-December year ends. Cheapest to produce and the one that invalidates the most if it is missing.

Rate and currency policy. Which rate applies to which balance type, and the functional currency per entity. Signed by treasury or the CFO, not by the project.

Elimination and adjustment rules. Intercompany, minority interest, purchase accounting, and specifically where each one is applied in the chain, because applying an adjustment twice is the classic multi-entity error.

Exception register. What is deliberately not comparable yet, why, and the date it will be.

That last one is the artifact most often absent from a proposal, because it reads like an admission. It is a control. Something will not be comparable in phase one of a multi-entity programme, and the only question is whether the sponsor learns it from a signed document or from a board member.

What belongs in the scope, and what gets added

What belongs in the scope, and what does not

The unchecked items are each defensible on their own. None of them produce a comparable number sooner, and each pushes the first one further out.

• A named pack, audience and frequency, with the entities in scope listed. Group monthly management, quarterly board, statutory consolidation. Different rules, different packs. Name the entities and the periods.
• The six mapping artifacts, each with a named signer. Account, entity, calendar, rate policy, eliminations, exception register.
• A scheduled extract per source, plus an exception report that runs before the pack. Catches the unmapped account and the entity that closed late, before anyone builds a slide.
• A reconciliation bridge from each entity's local report to its line in the group pack. So a local finance director can see which mapping rule moved their number. Without it, local teams keep running their own version.
• Identity resolution where customers, products or suppliers overlap across entities. A casino group found 14,200 players active at more than one property. An insurer unified 1.2M policy records across four systems.
• A named owner per artifact after handover, and the residual run cost. Three engagements landed the residual near a quarter of the prior cost: $4.7M to $1.1M, $1.9M to $420K, $1.3M to $310K.
• Standardising the source ERPs. A separate programme with a different sponsor, a different risk profile and a longer timeline. It is not required for comparable reporting.
• Rebuilding each entity's local management reporting. Local reporting is working for local decisions. Replacing it buys resistance, not comparability.
• A redesign of the group pack's layout. A real piece of work, and a different one. It makes the delivery date negotiable, which it should not be.

Ask for the out-of-scope list in writing. A multi-entity proposal with no out-of-scope section has not been scoped.

Source: Thinklytics case library, published engagement scopes and outcomes.

Six items in, three explicitly out.

In: a named pack with its audience, frequency and the entities and periods listed. The six mapping artifacts. A scheduled extract per source plus an exception report that runs before the pack. A reconciliation bridge from each entity's local report to its group line. Identity resolution where customers, products or suppliers overlap across entities. And a named owner per artifact after handover with the residual run cost stated.

Out: standardising the source ERPs, rebuilding each entity's local management reporting, and redesigning the group pack's layout. Each is defensible work. None of them produces a comparable number sooner, and each pushes the first one further out. Whether the ERP work belongs at all is a separate decision, covered in centralize reporting or standardize ERPs first.

Ask for the out-of-scope list in writing. A multi-entity proposal with no out-of-scope section has not been scoped.

The reconciliation bridge per entity

This is the item that decides whether the programme holds after handover, and it is worth spelling out because proposals usually fold it into "validation".

The bridge walks from an entity's own local report to its line in the group pack, one row per mapping difference: calendar reclassification, account mapping, policy alignment, rate restatement, eliminations, and the resulting group figure.

What it buys is acceptance. A local finance director who can see that most of the variance was a calendar reclassification and the rest was one account mapping can sign off on the group number without conceding their own was wrong. It never was. Without the bridge the group figure is an assertion from the centre, the local team keeps its own version running in parallel, and within two cycles there are two sets of books again.

The single-company version of this is covered in what a reconciliation engagement delivers.

Identity resolution, where it applies

Not every estate needs this and the ones that do should know before signature.

If customers, products or suppliers overlap across entities, mapping accounts is not enough: you need to know which records refer to the same thing. A casino group found 14,200 players active at more than one property only after probabilistic matching across five property management systems, which turned into $2.4M of identified marketing opportunity and $680K of new revenue in the first 90 days. A regional insurer had to normalise policy numbers, match insured names and align effective dates before 1.2M policy records across four claims systems were usable at all.

If the overlap exists and identity resolution is not in the scope, the group numbers will be right at the account level and wrong at every count of customers, products or suppliers.

Acceptance criteria

Acceptance criteria to write into the contract

Each one is checkable on the last day by a sponsor who never attended a working session, and most are stated as numbers.

• Every entity in scope reports on the group calendar and the group chart of accounts. Named entities, named periods, in the statement of work rather than discovered at the end.
• The unmapped list is empty, or every remaining item is in the exception register with a date. An empty list is the ideal. A written exception is acceptable. A silent gap is not.
• A reconciliation bridge exists from each entity's local report to its group line. Test it by asking a local finance director to walk their own bridge in front of the sponsor.
• A stated cycle time for the group pack, measured the same way as the baseline. Three days of manual work to same-day at a credit union. Five days to two hours across 11 campuses. 18 days to 3 at a telecom.
• A stated accuracy or coverage figure where one is measurable. Loss ratio reporting accuracy from 71 to 97 of every 100 at an insurer. Ask for the measure, not the adjective.
• Local reporting kept running throughout, with no missed close. This is what buys cooperation from the entities. A programme that breaks local reporting loses the room.
• The residual annual run cost is stated, with a named owner per mapping artifact. Near a quarter of the prior cost in three of our engagements. A proposal showing no residual is hiding one.
• Zero entity-level escalations at handover. The cloud provider's consolidation hit this because ownership was federated rather than taken away. Earlier centralising attempts there had stalled.

Six of these are numbers or counts. Written in before the work starts, the final review takes an hour rather than a negotiation.

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

Eight, written before the work starts and tested on the last day, and the property that matters is that a sponsor who never attended a working session can check each one.

Two of them are worth expanding.

A stated cycle time, measured the same way as the baseline. Three days of manual work to same-day member analytics at a credit union. Five days to two hours for cross-campus reporting across 11 warehouses. Eighteen days to three for a monthly close at a telecom. Those were contracted figures, not outcomes discovered afterwards.

Zero entity-level escalations at handover. A cloud provider's consolidation of 14 business unit warehouses hit this, and the reason is instructive: ownership was federated rather than taken away, with each unit keeping control of its own data and publishing through a shared catalogue. Earlier centralising attempts at the same company had stalled on exactly that resistance. If your estate has already seen one failed consolidation, this criterion is the one to argue hardest for.

Timeline and what drives it

In our case library, 13 to 30 weeks, tracking the number of source systems rather than company size. Four claims systems at 13 weeks. Five property management systems at 18. Four core banking systems at 20. Eleven campus warehouses at 24. Nine reporting systems at 26. Fourteen business unit warehouses at 30.

The correlation is rough and there are only seven engagements behind it, so use it to sanity check a proposal rather than to price one. If a proposal quotes a duration before counting the sources and the entities by name, the number is a guess, and counting them is a conversation rather than a discovery phase.

Phasing matters more than the total. Name the entities in phase one, and pick them so the first comparable number arrives early. The multi-ERP consolidation roadmap is the phased version we hand to whoever has to approve the spend, with the responsibilities and dependencies written out.

The residual annual run cost

There is always one, and a proposal showing none is hiding it.

In three of our engagements the residual landed near a quarter of the prior cost. A cloud provider went from $4.7M to $1.1M. A casino group from $1.9M to $420K. A credit union from $1.3M to $310K. Three data points, not a benchmark, and enough to make the question concrete rather than abstract.

Ask what the figure buys. The exception report and its alerting, the test suite on each mapping, the named owner per artifact, and the forum that approves a mapping change when an entity's chart of accounts moves.

Five questions before signing

Show me an account map and a reconciliation bridge from a previous engagement. Which entities and which periods are in scope by name, and what is in the exception register on day one. Who from each entity has to be in the room, and for how many hours a week. What is the residual annual run cost, and who owns each artifact after handover. And what happens if one entity's finance team will not accept the mapping.

The last one is a governance question rather than a technical one. A firm that has run a multi-entity programme answers with escalation to a named decision maker and a documented dissent. A firm that has not answers with a workshop.

What we would do first

Before reading the proposal again, write two lists. The entities and periods you need comparable in phase one, and the metrics in the group pack that the investment case actually turns on.

Then check the proposal covers the six artifacts for those entities and those metrics, and nothing beyond them. Most multi-entity proposals are scoped to the estate rather than to the decision, which is why they come in long.

The six differences that create the problem are in why acquired companies cannot report comparably, and whether to rationalise the stack at all is in data stack consolidation and the application rationalization playbook.

Delivery sits in data foundation for the mapped layer, system consolidation where sources are being retired, data 360 consultant for cross-entity identity, real-time data observability for the exception reporting, and SAP data readiness and migration on SAP estates. The full set of work in this area sits under the data underneath is not ready.

Frequently asked questions

What are the actual deliverables of a multi-ERP reporting consolidation?

Six mapping artifacts, each with a named signer. An account map from every source account to one target, with the unmapped list visible. An entity and hierarchy map with effective dates for anything acquired mid-year. A calendar map covering 4-4-5 and non-December year ends. A rate and currency policy saying which rate applies to which balance type. Elimination and adjustment rules. And an exception register listing what is deliberately not comparable yet and when it will be. A scope that names a platform and not these six is a platform project.

Why does the exception register matter so much?

Because something will not be comparable in phase one, and the only question is whether you find out in a signed document or in a board meeting. The register lists each item, why it is deferred, and the date it becomes comparable. It is the artifact that lets a programme report honest progress, and it is also the one most often missing from a proposal because it looks like an admission of incompleteness rather than the control that it is.

What should be explicitly out of scope?

Standardising the source ERPs, which is a separate programme with a different sponsor and a longer timeline and is not required for comparable reporting. Rebuilding each entity's local management reporting, which is working for local decisions and whose replacement buys resistance rather than comparability. And redesigning the group pack's layout, which is real work and a different project, and whose inclusion makes the delivery date negotiable when it should not be.

What acceptance criteria should go in the contract?

Eight. Every entity in scope reports on the group calendar and chart of accounts. The unmapped list is empty or every remaining item sits in the exception register with a date. A reconciliation bridge exists from each entity's local report to its group line. A stated cycle time for the group pack, measured like the baseline. A stated accuracy or coverage figure where one is measurable. Local reporting kept running with no missed close. The residual annual run cost stated, with a named owner per artifact. And zero entity-level escalations at handover.

Why is a reconciliation bridge per entity necessary?

Because without it the local finance director cannot see which mapping rule moved their number, so they keep running their own version in parallel and within two cycles you have two sets of books again. The bridge walks from the entity's local report to its line in the group pack, one row per mapping difference: calendar reclassification, account mapping, policy alignment, rate restatement, eliminations. It converts a group number from an assertion into something a local team can check and therefore accept.

How long should it take and what drives the duration?

In our case library these ran 13 to 30 weeks and the duration tracked the number of source systems rather than the size of the company. Four claims systems took 13 weeks, five property management systems 18, four core banking systems 20, eleven campus warehouses 24, nine reporting systems 26, fourteen business unit warehouses 30. The correlation is rough rather than a formula. If a proposal quotes a duration before counting the sources and the entities by name, the number is a guess.

What should the residual annual run cost be?

There is always one and a proposal showing none is hiding it. In three of our engagements the residual landed near a quarter of the prior cost: a cloud provider from $4.7M to $1.1M, a casino group from $1.9M to $420K, a credit union from $1.3M to $310K. That is three data points rather than a benchmark, and it is enough to make the shape of the question concrete. Ask what the figure buys: the exception report, the test suite, the named owner per artifact, and the forum that approves a mapping change.

What should I ask a firm before signing?

Five questions. Show me an account map and a reconciliation bridge from a previous engagement. Which entities and which periods are in scope by name, and what is in the exception register on day one. Who from each entity has to be in the room and for how many hours. What is the residual annual run cost and who owns each artifact afterwards. And what happens if one entity's finance team will not accept the mapping, because that is a governance question and the answer tells you whether the firm has run a multi-entity programme before.

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, with the source systems kept in all seven. Each states the duration, the system count, the measured outcome and the residual run cost where there is one.

System consolidation and data foundation engagements.