Multi-Entity Consolidation & Elimination

The problem

A group with more than a handful of legal entities in Dynamics 365 Finance & Operations usually reaches the same wall. The native consolidation company plus Financial Reporting handles a simple parent-and-subsidiaries roll-up, but it starts to strain the moment the group has partially owned subsidiaries, reciprocal intercompany trading, multiple functional currencies with different translation rules per account class, or auditors who want to click from a consolidated line all the way back to a source voucher in a subsidiary.

What happens next is predictable. Someone exports trial balances to a spreadsheet at month end. Elimination journals get typed by hand into a consolidation entity, then re-typed next month because there is no rule that regenerates them. Minority interest is a manual plug. Currency translation adjustments are calculated outside the system and cannot be reconciled back to a ledger. The consolidated statements are correct, probably, but nobody can prove it quickly and the close takes days longer than it should.

ECOSIRE builds a consolidation and elimination layer inside F&O so the group close runs on ledger data with a documented audit trail, not on a workbook.

What ECOSIRE builds

Everything is delivered as X++ extension code in your own model and package. No overlayering of Microsoft models, no changes that block a platform update. The work is scoped to your chart of accounts, your ledger dimension design and your legal entity structure.

Group structure and ownership model

New tables and forms model the group hierarchy: parent-child relationships between legal entities, effective-dated ownership percentages, consolidation method per entity (full, proportional, equity), and the reporting currency for each consolidation group. Ownership is effective-dated so an acquisition or disposal mid-year translates into the correct partial-period treatment rather than a manual override.

Currency translation with per-account-class rules

Translation rules are configured by main account category or by explicit account range: closing rate for monetary balance sheet accounts, historical rate for equity and fixed assets, average rate for profit and loss. The engine reads exchange rates from the standard ExchangeRate tables and the currency exchange rate type assigned to the consolidation group, so nobody maintains a second rate table. The residual is posted to a configurable cumulative translation adjustment account, and the calculation behind that figure is stored line by line rather than being derived on the fly.

Elimination rules that regenerate every period

Elimination is rule-driven rather than journal-driven. Rules are defined against account ranges and ledger dimension values — typically an intercompany partner dimension — and each run generates elimination entries into the consolidation legal entity with full traceability back to the rule that produced them. Common rule types are covered: intercompany receivable and payable offset, intercompany revenue and cost of sales, investment against subsidiary equity, unrealised profit in inventory, and dividend elimination. Re-running a period reverses and regenerates rather than double-posting.

Minority interest

For partially owned subsidiaries, the engine calculates the non-controlling share of net income and of equity from the effective-dated ownership percentage and posts it to the accounts you nominate. Because ownership is effective-dated, a change in stake produces a correctly split period rather than a full-year restatement.

Drill-through consolidated statements

Every consolidated balance is stored with its contributing components: which legal entity, which source voucher or elimination rule, which translation adjustment. A consolidated statement inquiry form lets finance and audit click from a consolidated line to the entity-level amount and then to the originating GeneralJournalAccountEntry record in the subsidiary. That single capability is usually why groups outgrow the spreadsheet approach.

Batch execution and period control

Consolidation runs are RunBaseBatch jobs so they can be scheduled in the batch framework overnight or triggered on demand. Each run is logged with its parameters, the user who started it, the rate set used and the number of entries generated. Periods can be locked once signed off so a late subsidiary posting cannot silently change a published consolidation without an explicit reopen.

Reporting and data access

Data entities are exposed through the data management framework and OData so consolidated results can feed Power BI, Excel or an external group reporting pack. Where you already use Financial Reporting, the consolidation results post to a real ledger in the consolidation entity, so existing row and column definitions continue to work against them.

Who this is for

Groups running Dynamics 365 Finance & Operations across several legal entities where at least one of the following is true: subsidiaries report in different currencies, some subsidiaries are partially owned, intercompany trading is significant enough that eliminations are material, or the audit requires traceability from consolidated statements down to source transactions. It is aimed at organisations that have already implemented F&O and have a stable chart of accounts and dimension design — this is a layer on top of a working ledger, not a replacement for one.

It is not the right fit for a single-entity company, or for a group whose consolidation is genuinely simple enough that the native consolidation company and Financial Reporting already produce a defensible result.

How delivery works

This is a build-to-order application. Nothing is downloadable today and there is no trial version, because the app does not exist until it is built against your configuration.

1. Scoping call. We walk through your legal entity list, ownership percentages, chart of accounts, dimension design, current close process and the specific eliminations you perform today. We ask to see a recent consolidation workbook, because that is where the real requirements live.

2. Fixed quote and specification. You receive a written functional specification covering rules, entity structure, forms and reports, with a fixed price and a delivery date. No work starts until you approve it.

3. Build. Development happens in our own F&O development environment on your target version. You get progress checkpoints; scope changes are handled as written change requests against the fixed quote rather than absorbed silently.

4. Install in your test environment. We hand over the deployable package and either deploy it through your LCS or Azure DevOps pipeline into your sandbox ourselves, or walk your team through it. Configuration is loaded, a real period is consolidated, and your finance team reconciles the output against their existing workbook line by line. Nothing moves forward until those numbers agree.

5. Production. Once you have signed off in sandbox, the same package moves to production through your normal release pipeline. We are available during the first live close.

6. Support window. A defect support period is included with the build, covering anything that does not behave as specified. Extension and enhancement work is quoted separately.

Typical lead time is two to four weeks from specification sign-off, depending on how many elimination rule types and how much reporting is in scope.