One company is a report. A group is a consolidation problem: many entities, often many ERPs, different charts of accounts and currencies, all of which have to net into a single set of group accounts that survives an audit. This leaf is the ERP-agnostic shape of that problem — and where a warehouse makes it tractable.
Consolidation is the process of taking the individual financial statements of every company in a group and combining them into one — as if the group were a single entity. It's a reporting job with three complications a standalone company never faces: inter-company transactions that must be eliminated, different currencies that must be translated, and different charts of accounts that must be mapped to a common one.
Get it wrong and the group accounts double-count revenue, carry phantom debtors, or fail to tie out — which an auditor will find. The mechanics are the same whether the subsidiaries run ERPNext, SYSPRO, Sage or a mix; what changes is how hard it is to get clean data out of each.
Each subsidiary's ERP keeps its own books and stays the system of record. Consolidation reads those books into a separate layer, applies eliminations and translation there, and produces group output. It does not write adjusting journals back into the subsidiaries — those are statutory entities with their own filings.
Consolidation is conceptually simple — add up the entities — and operationally fiddly because of three adjustments that have to be exactly right.
| Adjustment | Why | The trap |
|---|---|---|
| Inter-company elimination | Sales between group companies aren't group revenue | Both sides must net to zero — they rarely do on the first pass |
| Currency translation | Subsidiaries report in their own currency (IAS 21) | Rate type matters: closing for balance sheet, average for P&L |
| Chart-of-accounts mapping | Each ERP has its own account structure | One company's "freight" is another's "logistics" — map once, carefully |
| Minority interest | You may own less than 100% of a subsidiary | The slice you don't own is reported separately |
Inter-company elimination is the one that eats time. Company A books a sale to Company B; B books the purchase; in the group they cancel. When A's number and B's number don't match — timing, FX, a missed invoice — someone has to chase the difference. It's exactly the kind of tireless reconciliation an agent is good at flagging.
The real difficulty isn't the accounting — it's getting comparable data out of several systems that were never designed to agree with each other.
A group acquired over time rarely runs one ERP. You'll find ERPNext in the company built recently, SYSPRO in the manufacturing subsidiary, Sage in the one bought from a founder, maybe a spreadsheet in the smallest. Each has its own API, its own chart of accounts, its own period-close timing.
ERPNext deserves a specific note: its native multi-company support handles inter-company accounts and a shared chart within one instance, which removes a chunk of this pain if the group standardises on it. But the moment a group spans systems, the only sane place to consolidate is a neutral layer that every ERP feeds into — a warehouse.
Consolidation is the strongest case for the warehouse-plus-code approach, because it's inherently multi-source. Each entity's trial balance lands in the warehouse; mapping, elimination and translation are dbt models; the group pack is Evidence. Reproducible, and the same every month-end.
Because the mapping and elimination rules are code in Git, the consolidation is auditable and repeatable: an auditor can see exactly how each group figure was derived from the subsidiaries, and re-running last quarter produces the identical result. Dedicated tools (OneStream, Workiva, CCH Tagetik) own the enterprise end of this market; for a mid-sized group the open warehouse approach delivers the same defensibility at a fraction of the cost.
Consolidation is heavy on reconciliation and mapping — work the agent accelerates — and ends in a signed group statement that stays a human responsibility.
Surface every inter-company pair that doesn't net to zero, ranked by size, with the likely cause (timing, FX, missing invoice). The agent finds; finance resolves.
When a subsidiary adds an account, propose where it maps in the group chart. A human confirms the mapping before it's committed to code.
Flag where the wrong rate type was applied, or where a translation reserve doesn't reconcile. Tedious, error-prone, perfect for a first-pass reviewer.
The agent assembles and reconciles; a person signs the consolidated accounts. Group statements are audited and filed — auditor-grade, every figure traceable.
| Consolidate in a warehouse when | Native ERP multi-company is enough when |
|---|---|
| The group spans multiple ERPs or instances | Every entity runs one ERPNext instance |
| Charts of accounts differ across entities | Entities share one chart already |
| You need an auditable, repeatable derivation | The ERP's own consolidation report satisfies the auditor |
| Foreign subsidiaries bring FX translation | Single currency across the group |
The honest line: if the whole group is on one ERPNext instance, use its multi-company features and don't build a warehouse to consolidate two companies. The warehouse wins the moment you're spanning systems or currencies — which is most groups that grew by acquisition.
Group accounts here are governed by IFRS 10 (consolidated financial statements — who and what you consolidate) and IAS 21 (the effects of changes in foreign exchange rates — how you translate). Both are mainstream IFRS, so the architecture is standard; the discipline is applying the right rate type and consolidating the right entities.
The common local wrinkle is the group with offshore subsidiaries — a holding company in South Africa over operations elsewhere in Africa or abroad. That puts FX translation and exchange-control awareness squarely in the consolidation, and makes the rand's volatility a line item in the group result rather than a footnote. Assurance, as ever, stays with a registered auditor.
It's the most multi-source job in finance — pulling from every ERP in the group.
The standards that govern group accounts, and the open layer that produces them.