Consolidation 101: EPM for Multi-Entity Groups

1. What is consolidation, really? (Not the vendor version)

Most definitions of consolidation are either:

• Too legalistic – "the process of preparing consolidated financial statements for a group of entities…"
• Or too simplistic – "rolling up entities into one P&L."

Let's use something more useful:

Consolidation is the controlled process of:

• Aligning local books to a common chart of accounts, policies and currencies,
• Combining them into group-level views (P&L, BS, CF)
• Eliminating intra-group noise (intercompany, investments, etc.), and
• Explaining the movement from period to period in a way stakeholders can trust.

Key idea: consolidation is not just "adding." It's a sequence of transformations:

• Local → adjusted local (mapping, policies, reclasses)
• Local → translated (FX)
• Local → group (ownership, eliminations, reclassifications)
• Group this period → group last period (bridges & explanations)

When you're small, you can fake this with Excel. Once you have:

• Multiple entities
• Multiple currencies
• Real auditors
• Real board scrutiny

…you need something more industrial.

2. Core concepts of consolidation (EPM 101 lens)

Before we talk tools, you need a mental model for the moving parts.

2.1 Entities & hierarchies

Every consolidation starts with entities – legal companies and sometimes branches or reporting units.

You'll typically have:

• Legal entity list (by country, company code, etc.)
• Group structures (sub-groups, regions, segments)
• One or more reporting hierarchies (legal, management, segmental)

In an EPM world, these become dimensions and hierarchies you can re-use:

• Legal consolidation hierarchy
• Management reporting hierarchy
• Alternative views (e.g. geographic vs BU)

Design call: If you don't get your entity/hierarchy design mostly right up front, everything else will feel crooked.

2.2 Ownership & consolidation methods

Once you have entities, you need to know who owns what:

• 100% owned ⇒ full consolidation
• Majority-owned subsidiary ⇒ full consolidation with minority interest
• Joint venture ⇒ proportionate or equity method
• Associate ⇒ equity method

Each relationship has:

• % of ownership
• Method (full, equity, proportionate, cost)
• Effective dates (acquisitions, disposals, step-ups/downs)

In a good EPM setup, this isn't a static spreadsheet — it's a maintained ownership register the system uses to calculate:

• Consolidation scope
• Non-controlling interests (NCI)
• Equity pick-up entries

2.3 Chart of accounts & mapping

Your consolidation can only be as clean as your chart of accounts (CoA) and mappings:

• Local entities may have their own charts or flavors
• The group needs a standard chart with well-defined structures
• Mapping rules translate local accounts → group accounts

Done properly:

• You can onboard a new entity by mapping, not re-platforming
• Local teams can keep local detail, you map at the right level
• EPM enforces mapping consistency, not interns copy-pasting

3. Multi-currency & FX – where a lot of pain lives

Once you're in multiple currencies, consolidation without a proper engine becomes… "sporty."

3.1 Basic FX concepts you actually need

You don't need to be an IFRS nerd, but you do need to understand:

• Functional currency – the currency an entity "lives in" economically
• Presentation currency – the currency you report group results in

Rate types:

• Closing rate – period-end for balance sheet
• Average rate – for P&L (approximation of flows)
• Historical rate – for certain equity items, investments, etc.

In practice, consolidation needs to:

• Translate local balance sheets at closing rates
• Translate P&L at average rates
• Handle CTA (cumulative translation adjustment) correctly
• Track FX for equity and investments over time

3.2 FX in Excel vs FX in EPM

In Excel:

• Rates live in some tab only two people understand
• Logic is a patchwork of formulas and copy/pasted "FX tabs"
• Small mistakes accumulate into weird FX noise no one can fully explain

In EPM:

• Rate tables are managed centrally (by currency, rate type, period)
• Translation rules are built into the consolidation engine
• FX effects are classified correctly (operational vs translation vs other)

This is one of the first places where a proper EPM implementation pays for itself — especially when you hit your first major FX swing year and the board wants a clean bridge.

4. Intercompany: from knife fight to controlled system

Intercompany (IC) is where consolidation gets emotional.

4.1 What intercompany actually is

Any transaction between entities that are part of the group:

• Intercompany revenue & cost
• Intercompany receivables & payables
• Intercompany loans & interest
• Inventory transfers (with embedded profit)
• Cost allocations and shared services

Consolidation needs to:

• Identify IC balances and flows
• Match them between entities
• Explain mismatches (timing, rates, errors)
• Eliminate them at group level, often with supporting detail

4.2 Why intercompany is so painful in spreadsheets

Typical reality:

• Different entities use different partner codes or none at all
• Invoices are out of sync (amounts, FX, timing)
• Reconciliation happens in duct-taped Excel "IC match" files
• No one has a true group-wide view of IC exposure, mismatches, and aging

The result:

• Month-end IC firefights
• Manual journals to "force" eliminations
• Audit pain ("show us support for this elimination entry")

4.3 How EPM changes the IC game

In a proper EPM-enabled consolidation:

• Intercompany flags and partner dimensions are part of the model
• IC is tracked in a dedicated dimension (e.g. "counterparty entity")
• Matching logic surfaces:
  • Fully matched items
  • Partially matched (timing/FX differences)
  • Unmatched items requiring investigation
• Eliminations are generated by rules, not hand-crafted each month

And — this is big — you can finally:

• See IC by relationship (A↔B, A↔C, etc.)
• Track mismatches over time, not just "firefight this month"
• Give entities visibility into what the group sees as their IC position

5. Journals, adjustments, and the "second layer of truth"

Consolidation isn't just "local TBs rolled up." There's always a second layer:

• Reclasses
• Top-side adjustments
• Group-only entries
• Audit and control-related entries

5.1 Types of consolidation adjustments

You'll typically see:

• Local-posted adjustments – booked in ERP at entity level
• Top-side journals – booked only in consolidation (EPM)
• Reclasses – presentation changes (e.g., move something from "other" to a proper line)
• Standard adjustments – recurring, like accruals or allocations
• One-off adjustments – transactions, impairments, restructuring, etc.

The danger is when:

• Adjustments live in random workbooks
• No one can tell which adjustments are recurring vs one-off
• Audit trail is weak ("who posted this, when, and why?")

5.2 Journals in EPM vs journals in Excel

In Excel:

• Journals are effectively just "extra tabs" or manual changes
• Descriptions and rationales are often missing
• No approval workflow or segregation of duties
• Roll-forward logic gets messy quickly

In EPM:

• Journals are first-class objects:
  • Header (type, entity, period, currency)
  • Lines (accounts, amounts, dimensions)
  • Metadata (who posted, who approved, when, why)
• Workflows control:
  • Who can propose
  • Who can approve
  • Which journals are recurring / templates vs one-off

This is one of the main reasons auditors love a good EPM:

• They can see which numbers are system-driven vs adjustment-driven
• They can drill from group-level lines into the journal history behind them

6. The close process: calendar, workflow, and visibility

Consolidation lives inside the financial close. A solid close isn't just "we posted everything by day X." It's:

• Clear calendar
• Clear tasks
• Clear owners
• Clear status

6.1 Anatomy of a "grown-up" close

Key stages:

Pre-close

• Cut-off rules, timelines agreed.
• Subsidiaries know when to stop local bookings.
• FX rates and group policies communicated.

Local close

• Entities close their local books.
• Local reviews (controller, finance lead).

Group data collection

• Local TBs submitted (ideally automated from ERP).
• Mappings applied, validation checks run.

Consolidation engine run

• FX translation, eliminations, ownership rules applied.
• Automated controls and exception reports trigger investigations.

Adjustments & review

• Journals and reclasses entered where needed.
• CFO and group controller review key metrics and bridges.

Finalization & reporting

• Numbers locked.
• Packs generated and distributed.
• Disclosures and notes assembled (for statutory).

6.2 Where EPM fits

EPM, done right, becomes:

• The task list and status board for the close
• The data hub that connects ERPs into group numbers
• The engine for FX, eliminations, and consolidation logic
• The front-end for reports and drill-downs

Instead of asking "Where are we?" 30 times, you can see:

• Which entities are late
• Which tasks are stuck
• Which validation checks are failing
• Where the big deltas are vs last period

7. Data & systems: ERP vs EPM vs "everything else"

Consolidation is a systems conversation as much as it is an accounting conversation.

7.1 The "minimum viable stack"

In most mid-market groups you'll see:

• 1–3 ERPs (sometimes more)
• HR / payroll systems
• Possibly a data warehouse or data lake
• BI tools
• And then… a lot of Excel

EPM sits:

• On top of ERP(s) as the data consumer and transformation engine
• Next to BI as the source of governed financial truth for group numbers

7.2 Good integration patterns

You want:

Structured feeds from ERP(s) → EPM:

• Trial balance by entity, account, period, currency
• Subledger detail if needed (optional)

Clear mapping logic:

• Local CoA → group CoA
• Local entities → group entities and hierarchies

Regular, predictable refresh:

• Daily during busy times, otherwise as needed

Reconciliation processes:

• Group TB in EPM matches the sum of local TBs in ERP, by entity and account, within known adjustments

In a bad setup, every period feels like a custom ETL project. In a good setup, data movement is boring and repeatable.

8. Classic consolidation failure patterns

You've probably seen at least one of these.

8.1 "Excel is our consolidation system"

Symptoms:

• Group close = 20–40 linked workbooks
• Nobody fully trusts the master file
• Any design change = high risk of broken formulas
• Knowledge concentrated in 1–2 long-timers

Short-term fix: more checks, more templates.

Long-term reality: you're one resignation away from chaos.

8.2 Unclear ownership of data and mappings

Symptoms:

• No one knows who owns CoA mapping rules
• Entities make local changes without telling group
• Reconciliations are ad-hoc and late
• Discrepancies discovered by accident

Without clear ownership, every close is a small forensic exercise.

8.3 Overcomplicated design up front

Symptoms:

• 300+ group accounts, too much granularity
• Too many hierarchies and alternative views
• IC rules that try to solve every possible edge case
• Team drowns in model maintenance instead of analysis

Better approach: start with a clean, lean consolidation model, then enrich once it's stable.

8.4 Treating consolidation as "just a compliance task"

If you see consolidation as "something we must do for auditors," you'll under-invest in:

• Performance analysis
• Bridges (what actually changed and why)
• Linking consolidation with planning and forecasting

Result: your group financials lag reality, and decision-making happens on local / shadow numbers.

9. What "good" looks like – and what to do next

9.1 What "good" consolidation feels like

From a CFO/Controller's perspective, a good consolidation process:

• Lands on the same day every month
• Has no surprises after the fact ("Why did EBITDA move by that much?")
• Lets you answer:
  • "Which entities drove the change?"
  • "What part was FX vs volume vs price vs mix?"
  • "What adjustments and eliminations are in the number?"
• Is resilient to:
  • Staff changes
  • Structural changes (acquisitions, disposals)
  • FX swings and accounting policy updates

Technically, that usually means:

• An EPM tool with a real consolidation engine (not just "we can aggregate data")
• A clean CoA and hierarchy design
• Formalized IC and FX logic
• Clear journal/adjustment workflows
• Integration that doesn't require a ceremony every month