Why Business Central Financial Consolidation Lags
Multi-entity groups running Microsoft Dynamics 365 Business Central use its consolidation feature to close the books at the group level. The setup is straightforward enough: a consolidation company, subsidiaries defined as business units, an import process that pulls trial balances from each unit. It works in the sense that it produces a consolidated statement. The details behind the way Business Central financial consolidation works are the problem.
Starting out, consolidation runs as a batch import. The consolidated view it produces is a snapshot, current only as of the last sync. Drill into any of those numbers in the consolidation company and the audit trail stops at an imported journal entry, with no path back to the source invoice. Even a domestic consolidation, with one currency and one country, hits the same wall. The cause is structural, and finance teams have been working around it in spreadsheets for as long as the feature has existed.
Business Central financial consolidation runs on imported snapshots
BC’s consolidation feature works by importing data from each subsidiary into a dedicated consolidation company. You set up the consolidation company, define each subsidiary as a business unit, and run an import process that pulls G/L entries from each unit into the consolidation company’s books.
The import is a discrete event. It runs when someone triggers it. The consolidated balances reflect the source subsidiaries at the moment of import, and nothing afterward. Any journal posted in a subsidiary after the import, whether it’s a routine entry on Tuesday morning or a late accrual on close-day Thursday, will not appear in the consolidated view until someone runs the import again.
Modern reporting assumes the numbers on screen reflect the current state of the business. BC’s native consolidation cannot do that. It will only ever be as fresh as the last import, which means controllers end up managing the import cadence as a workflow of its own, separate from the close itself, with no good way to tell at a glance whether the consolidated view is current or four days behind.
Drill-down goes dark inside the consolidation company
Another frustrating problem is what happens when someone clicks on a number. In a subsidiary company, drilling on a G/L balance walks back through the journal lines to the source documents, the invoices and postings that produced it. The audit trail sits right there.
The consolidation company does not preserve that. Imported balances live as aggregated entries tagged with the source business unit and period. Drill on a revenue line in the consolidation company and you land on the import journal. The underlying invoice stays in the subsidiary, and the consolidation company has no link back to it. To get to source detail, you have to leave the consolidation company, open the subsidiary, and re-run the analysis there.
For an auditor walking through a consolidated P&L, that is unworkable. For a CFO asking why consolidated SG&A is up 8 percent month over month, it is the difference between a five-minute answer and a half-day investigation. Modern reporting tools assume drill-to-source. BC’s consolidation company stops at the imported journal layer and goes no further.
Intercompany eliminations stay manual even in domestic groups
Eliminations are where most consolidation processes spend their time, and the work is the same whether subsidiaries share one currency or twelve. A parent sells inventory to a subsidiary. The subsidiary records the cost, the parent records the revenue. At the group level, both have to disappear. The intercompany receivable on one side and the payable on the other have to net to zero.
In BC, the intercompany features help with recording matched transactions between linked partners, but the elimination entries themselves are journals someone has to book. Microsoft documents this directly: processing consolidation eliminations is a manual process. They either go into the consolidation company directly or sit in a working file outside the ERP. Controllers typically build a working file. Each period, the file gets pulled together by hand from intercompany trial balances and prior-period workpapers, with reconciling differences chased down before anything balances. It’s the kind of work that takes three days when it should take three hours.
What chart of accounts mapping costs over time
Holding companies and groups built by acquisition usually run different charts of accounts across their entities. The subsidiary acquired in 2019 has a different account structure than the one acquired in 2022. Standardizing those COAs in BC is a project. Maintaining the standardization is another project, because subsidiaries keep adding accounts to match the nuances of their business.
Mapping is the realistic option. Each subsidiary’s COA maps to a consolidated COA, and the mapping has to update as accounts change. Native BC handles this through Consol. Debit Acc. and Consol. Credit Acc. fields on the Consolidation FastTab of each line in the subsidiary’s chart of accounts. If those fields are left blank, BC assumes the account maps to one with the same number in the consolidated company. The configuration drifts. Six months in, the mapping is missing accounts and someone reconciles the differences manually. That is the maintenance burden controllers don’t see at implementation and are sitting with at year two.
Business Central financial consolidation at the reporting layer
The alternative is to run the consolidation in Excel against live BC data, with no import step and no separate consolidation company. Velixo was built for exactly this work.
Each entity’s trial balance pulls into Excel through BC’s API and OData web services on every workbook refresh, filtered by date, dimension, or business unit. There is no snapshot. There is no stale consolidation company. When the workbook opens tomorrow, the numbers reflect what’s posted in the subsidiaries today.
Eliminations sit in their own worksheet, with Velixo functions referencing the live trial balance ranges directly, so when actuals refresh, the eliminations refresh with them. When the close is ready, the elimination entries can be posted back to BC from Excel rather than rekeyed. COA mapping becomes a lookup that maps each subsidiary’s accounts to the consolidated COA, visible in the workbook rather than buried in BC configuration. Multi-currency, if it applies, gets handled at the reporting layer, either by referencing BC’s translation ledger from Velixo functions or by applying rates in the workbook directly.
Drill-down is the difference that matters most. Every number on a Velixo-built consolidated statement ties back to a live transaction in a specific subsidiary. Click a consolidated revenue line, drill to the entity-level subtotals, and from there into the actual GL transactions in the source company. The audit trail stays intact because no part of the workflow ever broke it.
For partners scoping BC implementations at multi-entity organizations, the timing matters. If Business Central financial consolidation gets treated as a Day 2 problem, the implementation closes and the CFO has a complaint two months in. Scoping the reporting layer alongside the ERP keeps consolidation from becoming a surprise.
Velixo connects Excel directly to Business Central through API v2 and web services, runs consolidation logic, intercompany eliminations, and currency translation against live subsidiary data, and preserves drill-down from the consolidated statement back to the source GL transaction in any underlying company. Journal Writeback and Budget Writeback push the adjustments, budgets, and forecasts that follow the consolidation back to BC from the same workbook.