How reporting consolidated results is usually set up in finance and ERP systems

Reporting consolidated results usually sits in a layered setup. Each subsidiary closes its own ledger in the ERP. A consolidation module or separate tool then collects those balances, translates currencies, strips out intercompany activity and produces group statements. Management packs and statutory filings are built from that consolidated data.

Where the numbers start

Everything depends on the local ledgers. Each legal entity books its transactions in its functional currency, under its own chart of accounts or a local variant of the group one. Local teams run their period close, post accruals and sign off a trial balance.

The link between local accounts and group accounts is a mapping table. In a well kept setup the mapping lives in one place, is owned by group finance and changes only through a controlled request. In a poorly kept one, mappings are adjusted quietly by whoever needs a number to land in a different line. That table deserves a hard look before any redesign.

The consolidation layer

Some groups run consolidation inside the ERP itself. Others extract trial balances into a dedicated consolidation product. Smaller groups often still rely on spreadsheets fed by ledger exports. Each approach can work. The risk profile differs.

Data typically arrives by scheduled load, by manual upload of a standard template, or by direct integration where entities share an ERP instance. Validation rules check that the trial balance nets to zero, that required dimensions are filled and that balances tie to the prior period close. Entities that fail validation get sent back to fix their submission.

Currency translation

Foreign entities report in their own currency and the group reports in its presentation currency. The system applies closing rates to balance sheet items and average rates to income and expense. Equity is usually held at historical rates, and the resulting difference flows to a translation reserve.

Rates are loaded into a rate table each period. Who loads them, from which source and at what moment matters more than people expect. A late or wrong rate quietly distorts every foreign subsidiary at once.

Intercompany elimination

Sales, loans, recharges and dividends between group companies must cancel out. The usual mechanism is a partner dimension on intercompany accounts, so each posting names the counterparty entity. The consolidation tool pairs up both sides and eliminates them.

Mismatches are normal. Timing gaps, currency differences and disputed charges all leave residues. Most groups run a matching report before the close deadline and agree a tolerance, with anything larger escalated to the entity controllers involved. Unresolved differences often get parked in a suspense line and forgotten.

Adjustments and the reporting layer

After eliminations, group finance posts top side entries. These cover items such as goodwill, fair value adjustments from acquisitions, minority interests and reclassifications that only make sense at group level. They should be journaled in the consolidation tool with supporting documents attached, never typed straight into a report.

Reports draw on the locked consolidated data. The statutory pack, the board pack and segment disclosures are usually separate templates reading the same source. Cost reporting by cost centre, project or responsibility segment often runs alongside, using the dimensions carried up from local ledgers. A cash flow projection is frequently bundled into the same pack, built from consolidated balances plus treasury forecasts of large expected receipts and disbursements.

Questions to ask the people who run it

Documentation describes the intended process. The people at the keyboard know the real one. Useful questions include:

• Which entities submit late most often, and what happens when they do?
• Are any balances loaded by hand even though an integration exists?
• Who can change the account mapping, and when was it last changed without a ticket?
• How are intercompany differences actually cleared before sign off?
• Which top side entries recur every period, and why have they not been pushed down to the entities?
• Where do the exchange rates come from, and has anyone ever had to reload them?
• Is there a spreadsheet that sits between the system and the final report? Who owns it?
• What gets rechecked manually because nobody trusts the system output?
• Which numbers in the board pack cannot be traced back to a posted journal?

Answers to the last few questions usually reveal where the real work and the real risk sit.

Where setups tend to drift

Over time, workarounds accumulate. A recurring top side adjustment replaces a fix that should have happened in a local ledger. A shadow spreadsheet appears because one report never matched. New entities from acquisitions get bolted on with their own mappings and their own close calendars.

None of this shows up in a process map. It shows up when someone tries to shorten the close or switch tools and discovers a manual step nobody wrote down. Tracing a handful of reported figures back to source transactions, with the preparers present, is the quickest way to find those hidden steps before changing anything.

APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.