When a group outgrows its accounting software — when the monthly close involves exporting from five different systems, reconciling mismatches in a spreadsheet, and spending three days on eliminations that should take three hours — the problem isn’t the data. It’s that the tools were designed for a single entity, not a group.
Choosing a multi-entity financial reporting platform is a significant decision. The right platform makes the close faster, the output more reliable, and the audit easier. The wrong platform adds process overhead without solving the underlying problems. This post covers the ten features that matter most — not in generic terms, but specifically: what the capability does, and what you lose without it.
01Flexible entity structure management
The platform should represent the group’s legal ownership hierarchy — parent, subsidiaries, intermediate holding companies — with ownership percentages applied to NCI calculations and consolidation method assignment. When the structure changes (new acquisition, disposal, reorganisation), the update should cascade through the consolidation without requiring a rebuild.
Without it: Group structure is hard-coded in a spreadsheet. Adding a new entity means updating multiple formula references across multiple sheets, with a high probability of missing one. The model works for the current structure and breaks whenever it changes.
02Centralised group chart of accounts with entity mapping
Each entity uses its own chart of accounts in its accounting software — different account names, different codes, different hierarchies. The platform needs a group COA that sits above all of them: each entity account is mapped once to the corresponding group line, and every report is generated from the group COA structure. New accounts added to any entity’s system are flagged for mapping before the next close.
Without it: “Revenue” means something different in each entity. Consolidated revenue is a sum of whatever each entity calls revenue — producing a number that is neither consistent nor reliable. Unmapped accounts fall into a catch-all or disappear, creating silent errors in the consolidated P&L.
03Automated intercompany identification and matching
The platform should identify which accounts in each entity carry intercompany transactions — by account tagging, counterparty coding, or transaction reference — and automatically match the two sides of each intercompany balance before the consolidation runs. Unmatched balances should be flagged as exceptions requiring investigation, not silently included or excluded.
Without it: Identifying which transactions are intercompany requires manually cross-referencing each entity’s ledger. In a group with ten entities, there are 45 possible entity pairs, each potentially carrying multiple transaction types. Manual identification at this scale is slow and produces misses.
04Structured intercompany elimination logic
Elimination entries should be posted in the consolidation system against confirmed matched balances — not against unmatched estimates. The platform should support both group-level eliminations (simple recurring charges) and entity-pair eliminations (where NCI is present and the allocation between parent and minority matters). Every elimination should be documented with counterparty, amount, account, and period.
Without it: Elimination entries are manual journal entries in a spreadsheet with no audit trail and no automatic validation that the debit and credit match in both amount and account type. Auditors requesting elimination documentation receive a spreadsheet no one is fully confident in.
05Multi-currency translation with centrally published rates
The platform should apply a centrally published rate table — closing rate for balance sheet items, average rate for P&L items — to each foreign entity’s trial balance. Rates are set once, applied consistently across all entities, and the resulting currency translation adjustment is calculated automatically and posted to group equity as a separate component. Entity-level FX gains and losses remain in the entity’s own P&L, separate from the group translation adjustment.
Without it: Each entity applies its own exchange rate from its accounting software’s live feed, pulling rates on different dates. The intercompany balances between entities translate to different amounts on each side, producing residuals that take hours to investigate and often can’t be fully explained.
06Period locking and close status management
The platform should track the status of each entity’s data submission — not yet submitted, submitted, reviewed, adjusted, locked — and prevent changes to locked periods without a documented reason. When management accounts have been distributed and an entity submits a correction, the correction should require approval and generate a new report version, not silently update the figures the board already received.
Without it: It’s impossible to know at any given time whether the numbers in the model are the final numbers or an intermediate state. The team distributes reports without confidence that all entities have submitted final data, and corrections arrive after distribution without a clear version trail.
07Drill-down from group total to source transaction
Every consolidated line item should be navigable: click on group revenue, see entity contributions; click on the entity contribution, see the underlying account detail; click on the account, see the transactions that compose it. When the CFO asks why UK revenue is down £180,000 versus prior month, the answer should be findable in minutes from the consolidated report — not through a manual investigation involving the UK entity’s controller.
Without it: Variance analysis requires returning to each entity’s accounting system and doing a manual comparison. Answering management questions consumes hours that should be consumed by analysis. Finance’s contribution to business decisions is limited by the time it takes to retrieve the information behind the numbers.
08Configurable reporting output for multiple audiences
The group, management team, subsidiary controllers, and lenders each need a different view of the same data — different scope, different level of detail, different period comparisons. The platform should generate each view from the same consolidated data set, not require a separate report to be built and maintained for each audience. The board pack structure, the segment reporting template, and the lender covenant package should all be configured once and run from live data each period.
Without it: Finance teams maintain parallel reporting files for different audiences — the board pack spreadsheet, the subsidiary pack, the bank reporting package — each with its own formatting and its own risk of inconsistency. The same number appears differently in different documents, and explaining the difference takes time the team doesn’t have.
09Integration with multiple accounting systems
In any group that has grown through acquisition, not every entity will use the same accounting software. The platform should connect via API to the main cloud accounting systems (Xero, QuickBooks, MYOB, Zoho Books) and accept trial balance data via Excel import for entities on desktop or legacy systems. Data from all sources flows into the same consolidation environment, mapped to the same group COA, with the same elimination and FX logic applied regardless of source.
Without it: Each acquired entity that uses a different accounting system requires a new manual export-and-paste workflow. The close process doesn’t scale with the number of entities because each additional entity means more manual data handling, not just more of the same automated process.
10Scalability without process redesign
The platform should handle growth in entity count, transaction volume, and reporting complexity without requiring the consolidation model to be rebuilt. Adding a fifteenth entity should involve connecting the entity, mapping its accounts, and including it in the relevant group hierarchy — not rebuilding the model from scratch because the existing architecture can’t accommodate another entity. The workflow that works for five entities should be the same workflow that works for twenty.
Without it: The consolidation model reaches a natural ceiling — a point where adding more entities introduces more fragility than functionality. Groups at this ceiling either stop growing their consolidation scope (excluding some entities from the group view) or rebuild the model at significant cost and risk each time the limit is reached.
These ten features are not an aspirational wish list. They are the capabilities that determine whether a multi-entity consolidation process is sustainable as the group grows — or whether it will require patching, workarounds, and eventual rebuilding every time complexity increases.
BrizoConsol is built specifically for multi-entity financial reporting — with all ten capabilities above in a single platform that connects to Xero, QuickBooks, MYOB, and Zoho Books. Learn more or see it in action →