Multi-Company Consolidation in Business Central: Complete Guide

When a finance leader at a group of three, five or twelve legal entities evaluates Business Central, the question is rarely “does it post journal entries”. It is “can it close the group books in five working days, in three currencies, with two fiscal-year regimes, a Spanish parent filing SII and Verifactu, and a German subsidiary on GoBD”.

That question has a real answer, but it requires understanding what the platform does natively, what needs configuration, and what a Microsoft Solutions Partner with twenty-three years on Business Central brings to the table.

What multi-company consolidation actually means

These four concepts get conflated constantly, and the distinction matters when scoping a project:

• Multi-company: several legal entities sharing infrastructure, master data governance and reporting standards. Each entity has its own ledger, statutory accounts and tax registration; they roll up at group level.
• Multi-currency: transactions denominated in currencies other than the entity’s functional currency. A transaction-level and translation-level problem.
• Multi-country: each entity operating under a different tax and statutory regime (Spain SII/Verifactu, Italy SDI, Portugal SAF-T, Germany GoBD). A compliance and localization problem.
• Intercompany: transactions between group entities (subsidiary-to-subsidiary sales, parent funding, cross-border service recharges). An internal-flow and elimination problem.

A group with two Spanish entities and one French subsidiary trading with both has all four. The scoping conversation should enumerate which of the four are in play, in what volume, and where the complexity concentrates.

Business Central’s native consolidation framework

BC ships a consolidation framework in the core ERP, no extensions required. The building blocks:

• Consolidation company: a dedicated BC company that holds the group’s consolidated chart of accounts and elimination entries; it does not post operational transactions.
• Business Units: each subsidiary is registered inside the consolidation company with its source company, currency translation method and period mapping.
• Consolidation account schedule: a mapping that translates each subsidiary’s chart of accounts into the group’s chart. Subsidiaries keep their local accounts for statutory reporting while consolidating into a uniform structure.
• Currency translation methods: current rate (balance sheet at closing, P&L at average, the IFRS default), temporal (monetary at closing, non-monetary at historical), and current/non-current (legacy, still required in some jurisdictions).
• Elimination journals: entries in the consolidation company to eliminate IC revenue, IC receivables/payables, dividends and unrealized profit on intercompany inventory.

The framework is solid for groups up to roughly ten entities. Beyond that, dedicated CPM platforms add value, but the core ledger consolidation continues to live in BC.

Intercompany transactions: four capabilities you need

Intercompany is where multi-company implementations succeed or fail. Four capabilities to validate during design:

1. Master data synchronization. Customers, vendors, items and G/L accounts must map consistently across entities. BC handles this through Intercompany Partner Codes plus IC mapping tables; the discipline is putting governance behind it.
2. Sales/purchase intercompany flow. When entity A posts a sales invoice to entity B’s IC partner code, BC automatically generates the matching purchase invoice in entity B’s intercompany inbox. Avoids the double-entry that breaks reconciliation.
3. Intercompany eliminations at consolidation. Group revenue must exclude sales between subsidiaries; group COGS must exclude the matching purchases. The consolidation account schedule needs explicit elimination rules for every IC flow.
4. IC balances reconciliation. At month-end, IC receivable in A must equal IC payable in B. Asymmetries (timing, FX, unrecorded entries) must be flagged and cleared before consolidation. BC’s IC reconciliation reports surface the gaps; operational discipline closes them every period.

Multi-currency: the three thorny issues

Multi-currency is conceptually simple and operationally painful. Three issues consume most of the time:

Functional currency vs reporting currency. Each entity has a functional currency (the currency of its primary economic environment). The group reports in a reporting currency (usually EUR, sometimes USD). Translation happens at consolidation, using the method configured per Business Unit. Mistakes happen when teams confuse the two in dashboards: a P&L shown “in EUR” might be functional EUR for the Spanish entity but translated EUR for the UK entity, and the line items are not comparable without disclosing the basis.

Exchange rate management. BC supports multiple exchange rate sources (manual, ECB feeds, central bank APIs) and frequencies (daily, monthly, average). The decision points: which source, how often it refreshes, whether transactions revalue daily or at month-end, whether consolidation uses closing rate or monthly average. Different IFRS interpretations choose differently; document the choices in the accounting policy manual, not buried in BC’s setup screens.

Unrealized FX gains and losses. Open AR and AP balances in foreign currency need revaluation at period end. BC’s Adjust Exchange Rates batch job handles this, posting unrealized gain/loss to dedicated G/L accounts. Misconfiguring or running this batch job inconsistently leads to FX results nobody can reconcile.

Fiscal year alignment: what to do when subsidiaries don’t match

M&A is the usual source of fiscal year mismatch: the group bought a company whose fiscal year ends in March while the parent’s ends in December. Three viable approaches:

Align all subsidiaries to the parent’s fiscal year. Cleanest long-term answer. Requires a one-off stub period (a short three-month or fifteen-month fiscal year) and coordination with statutory auditors. Most groups eventually do this within twelve to twenty-four months of acquisition.

Consolidate with stub periods every month. The subsidiary keeps its own fiscal year for statutory purposes; for group consolidation it reports monthly trial balances mapped to the parent’s calendar. BC handles this through Business Unit period mapping. Works for IFRS and US GAAP.

Use BC’s Business Unit period mapping with non-aligned years. When alignment is genuinely impossible (rare, but happens in regulated industries), the Business Unit maps subsidiary periods to parent consolidation periods with explicit currency translation rules per period. Operationally heavier but supported.

Country-specific compliance: where BC plus Davisa shines

This is where abstract “multi-country consolidation” becomes a concrete project plan. Each EU jurisdiction has its own statutory layer: Spain (SII, Verifactu, AEAT modelos 303/347/349/390/720, IGIC, foral regimes), Portugal (SAF-T PT, ATCUD), Italy (SDI, FatturaPA), France (FEC, PCG), Germany (GoBD, DATEV).

BC ships Microsoft localizations for most EU countries, augmented by certified ISV extensions where local requirements run deeper. Davisa’s specialization is the Iberian layer: dvimpuestos (SII, Verifactu, AEAT modelos) and dvfactura-e (electronic invoicing) cover the Spanish compliance footprint in production at hundreds of customers. For non-Iberian jurisdictions we partner with Microsoft’s localization layer and local ISV extensions, integrating them into the group architecture.

Where dvfinance adds value over native consolidation

Native BC handles ledger consolidation well. Where dvfinance adds value is the layer above the ledger, where CFOs and group controllers spend most of their time:

• Treasury and consolidated cash flow. Rolling 13-week cash forecast across all entities, with drill-down to invoice-level detail and currency exposure.
• Factoring and confirming visibility. Group treasury sees committed positions across entities in real time.
• Cash pooling and intercompany financing. Automated IC loan postings when the parent funds a subsidiary’s working capital, with automatic interest accrual at the configured transfer pricing rate.
• Group-level FP&A. Variance reporting against budget per Business Unit, drill-through to source transactions, multi-currency presentation with explicit translation basis.

Native BC plus dvfinance gives a group controller the same toolkit mid-market groups historically built using a separate consolidation system plus a separate treasury system. Keeping it inside Business Central removes integration cost and reconciliation lag.

Common mistakes in multi-company implementations

After two decades of these projects, the same patterns recur:

• Setting up entities one-by-one without master data governance. Each company ends up with its own customer numbering, item codes and dimension structure. Consolidation becomes a mapping nightmare. Define governance first, then deploy companies into it.
• Manual IC reconciliation. If two AP clerks reconcile IC balances by email every month, the model is broken. Native BC IC reconciliation is the default; manual exceptions should be rare.
• Forgetting transfer pricing documentation. Intercompany flows have tax implications. Transfer pricing policies belong in the IC pricing setup, not in spreadsheets.
• Mixing functional and reporting currency in dashboards. A dashboard showing “Revenue EUR” without disclosing whether it is functional or translated will mislead every executive who reads it.
• Not standardizing chart of accounts. Subsidiaries keep their statutory chart, but the consolidation chart must be uniform. Skipping this means every cycle includes manual mapping work that should have been done once.

Timeline expectations for a multi-company rollout

Realistic ranges from completed projects:

• Two to three entities, single country, single currency: 4 to 6 months from kickoff to first consolidated close.
• Five to eight entities, multi-country, multi-currency: 6 to 9 months, typically phased (parent and two subsidiaries first, then the rest in waves of two or three).
• Ten or more entities, multi-country, with M&A in flight: 9 to 15 months, almost always phased by region and with a dedicated migration team handling the acquired entities separately.

These ranges assume an experienced partner (Davisa has delivered Business Central since 2003) and a customer team with bandwidth to decide on schedule. The number one cause of slippage is not technology; it is finance leadership being too thinly stretched.

---

If you are evaluating Business Central for a group consolidation scenario, the starting point is a scoping conversation: how many entities, which countries, which currencies, what fiscal year regimes, what intercompany volume. From there the architecture practically writes itself. Explore our Business Central practice and the dvfinance extension to see what the platform looks like in production.