How do I consolidate multiple Business Central companies?

Consolidation in Business Central is a standard function for the group view: several companies are run as separate entities and transferred into a consolidation company, across currencies as well. The standard covers financial consolidation: balances from several companies are taken over according to mapping rules, with currency translation and elimination entries for intercompany relationships. For a mid-market group with a manageable shareholding structure, that is usually enough. Whether consolidation actually runs automatically is decided not by the function but by the groundwork: a mapped chart of accounts, uniform dimensions and the same master data rules in every company. Without that basis, consolidation stays manual work in Excel. The limits show up with complex group structures: sub-groups, minority interests or statutory consolidated accounts under HGB or IFRS need a specialised solution built on top of Business Central.

What can consolidation in Business Central do, and where are the limits?

The standard covers financial consolidation: balances from several companies are transferred into a consolidation company according to mapping rules, with currency translation and elimination entries for intercompany relationships. For a mid-sized group with a manageable ownership structure, that is usually enough.

Source: Microsoft Learn: Consolidated company reporting

The limits show with complex group structures: sub-groups, minority interests, equity accounting, or a statutory consolidated financial statement under HGB or IFRS with full notes mechanics. For those, specialised consolidation solutions sit on top of Business Central. The honest question is not whether the standard can do everything, but whether your structure needs it.

For a mid-sized company the distinction is practically helpful: the standard covers the monthly and quarterly consolidation for management purposes, while the statutory group close remains a matter for the auditor or a specialist tool. Keeping the two apart saves you from searching for a function that does not exist.

Which groundwork decides whether consolidation runs automatically?

• Chart of accounts: local per company is fine, but with clean mapping to the group chart
• Dimensions: the same dimension logic in all companies, otherwise analyses are not comparable
• Master data: shared rules for customers, vendors and items, otherwise eliminations fail
• Intercompany: clean counter-accounts and document flows, otherwise differences remain a monthly guessing game
• Calendar: aligned closing dates per company, otherwise you consolidate interim states

This list is the real project scope. Setting up the consolidation feature itself is manageable afterwards. That is why the consolidation question belongs at the start of a multi-company project, not at the end: it defines the master-data and dimension rules that must apply from day one.

Of these five points, the calendar is the one most often underestimated.

One database, several companies, or several environments?

In Business Central, several entities can run as companies in one environment as long as they get by with the same localisation. Countries with their own localisation need their own environments; consolidation then runs across those boundaries via API or data export.

The rule of thumb: as few environments as legally necessary. Every additional environment costs maintenance and release coordination and makes intercompany processes harder. This decision belongs early, because a later restructuring is a migration in miniature.

Rule of thumb: as few environments as the law requires. Decide before you create the first company.

The decision almost always turns on the localisation: as long as entities manage with the same country version, little argues against a shared environment. As soon as a separate localisation is needed, there is no way around a second environment.

It is important to answer this question before the first company is created. Extracting a company from an environment afterwards is a project of its own and not a configuration step.

How do you get from Excel consolidation to the push of a button?

The typical mid-market situation: consolidation lives in a grown Excel file that one person understands. The switch succeeds not by rebuilding the file, but by catching up on the rules: first unify account mapping and dimensions, then run one month in parallel, then switch off Excel.

A realistic horizon: take the groundwork seriously and you consolidate automatically after two to three closing cycles. After that, effort drops, and above all the reliability of the figures rises, because every elimination sits traceably in the system instead of in a formula.

The switch does not succeed by rebuilding the spreadsheet logic but by questioning it. A spreadsheet grown over years contains corrections nobody can justify any more, and those are exactly the ones that need clarifying rather than carrying over.

Running in parallel over two closes has proven itself in practice: the spreadsheet and the system consolidation run at the same time and the differences get explained. Only once both agree is the file switched off.

How does a consolidation project run over time?

The timeline is rarely set by the configuration, it is set by the alignment. This sequence has proven itself: the first two weeks for the stocktake, meaning the charts of accounts of all companies side by side, dimensions compared, ownership structure and currencies clarified. Then four to six weeks for mapping and cleansing, which is the real effort. Only then the setup of the consolidation company, which is done in a few days.

The first test run always uncovers differences. That is not a setback, it is its purpose: it shows where account mapping, intercompany postings or closing dates do not yet fit together. So plan two to three closing cycles in parallel operation, with old and new running side by side. Switching over after the first run moves the troubleshooting into live operation.

This order cannot be shortened, because each step depends on the result of the previous one.

Why does consolidation fail in practice?

Almost never on the functionality. The same five causes every time:

• Different closing dates: one company is still posting while consolidation runs. The result: interim states in the group view.
• Intercompany differences: two companies post the same transaction with different logic or in different periods. The elimination then does not balance.
• Exchange rates: which rate type applies where? Balance sheet items at the closing rate, the income statement at the average rate, equity at the historical rate. Without this set up cleanly, you produce translation differences every month.
• Retrospectively changed prior periods: one company corrects the previous year while the consolidation still holds the old state.
• Unmaintained ownership percentages: after a change in shareholding, the percentage is not updated in the system.

All five are matters of agreement, not matters of the system. At the start of a consolidation project, therefore, there belongs no configuration workshop but an understanding about who posts what and when.

In DGP projects this understanding is put in writing before the first configuration exists in the system. It costs two days and saves the rework that otherwise surfaces in the first close.