Replacing legacy ERP across diverse divisions: architect's playbook

Holding companies replacing multiple legacy ERPs on a single D365 program face a specific design tension: each division has its own processes, chart of accounts, and fiscal calendar, but corporate finance needs consolidated reporting and some standardization. The architect's job is to balance autonomy and consistency without forcing every division into the same mold - or giving every division a separate environment.

Two common mistakes

Multiple tenants, one per division. Isolates divisions but eliminates the consolidation story entirely. Every cross-division integration becomes middleware work. Corporate reporting becomes a data-warehouse project on top of Dynamics. M&A becomes exponentially harder. This path looks autonomous; it's actually siloed.

Single legal entity with everything dumped in via financial dimensions. Differentiates divisions using financial dimensions only, without legal-entity separation. Breaks when divisions have different fiscal calendars (quarterly vs monthly close), different statutory obligations, or different audit cycles. Financial dimensions are powerful but they're not a substitute for legal-entity boundaries.

The structure that accommodates real-world diversity

Multiple legal entities in a single environment, with organizational hierarchies and ledger configurations layered per division.

Components:

• One LE per division (or one LE per country-and-division combination for multi-country divisions). Fiscal calendar, chart of accounts, and closing cycle are per-LE.
• Shared chart of accounts at the framework level where it makes sense, with LE-specific overrides for accounts that differ
• Ledger configuration per LE - accounting currency, reporting currency, posting layers, exchange rate types
• Organizational hierarchies for the corporate reporting structure (division → business unit → cost center) that cuts across LEs
• Financial dimensions for reporting cuts that need to cross LE boundaries (product family, channel, geography)
• Cross-company data sharing for master data that should stay consistent: vendors used by multiple divisions, shared customers, shared product master for shared categories

The result: each division runs its close on its own calendar with its own chart, but corporate can roll everything up via consolidation + organizational hierarchies.

Chart of accounts design

Chart of accounts usually surfaces the biggest design debate. Three patterns work:

Common chart with LE-specific exceptions. A corporate-level COA defines shared accounts; each LE can add LE-specific accounts for unique needs. Good for companies where divisions share significant accounting conventions.

Division-specific charts mapped to a consolidation chart. Each division retains its own COA, and mapping rules translate to a consolidation COA at rollup time. Good for highly diverse divisions where forcing a common chart would break divisional finance.

Hybrid. A core chart of accounts is mandatory (revenue, COGS, major expense categories) with division-specific detail below the mandatory level. Usually the right answer for mid-diversity groups.

The choice isn't technical - it's about what divisional CFOs will accept.

Fiscal calendar per LE

Divisions with different operational rhythms need different fiscal calendars. F&O supports this out-of-the-box - configure fiscal calendar per LE, close on each calendar's own schedule. Consolidation handles the alignment when calendars differ.

The one gotcha: consolidation translates based on the period-end rate of each source LE. If three divisions close on different days, the consolidated date is the latest close + alignment logic. Document this for the CFO before go-live; surprise at month 2 is unpleasant.

Process standardization vs divisional freedom

The architecture supports both. What's standardized:

• Global master data framework (even if some dimensions are division-specific)
• Posting profile conventions (vendors, customers, products)
• Approval workflow scaffolding (divisions fill in their own rules)
• Period-close sequence and corporate consolidation schedule
• Security model foundation

What's divisional:

• Specific business process flow variations
• Chart of accounts detail beyond the mandatory core
• Fiscal calendar
• Local customizations via extensions in a division-specific model
• Integration endpoints to division-specific systems

Document which is which at go-live. "Division X wants a different AR aging" is a divisional call; "Division X wants a different GL close framework" is a corporate decision.

Integration with divisional legacy systems

Not every division goes live on D365 on day one. Phased rollouts are the norm. While divisions are still on legacy:

• Standard consolidation includes "manual consolidation" - import divisional trial balances via DMF
• BYOD (Bring Your Own Database) or Export to Data Lake from D365 combines with legacy extracts in a data warehouse for Power BI reporting
• Intercompany across the D365/legacy boundary runs via data-entity-based integrations until the legacy side migrates

The intermediate state is uncomfortable but unavoidable when divisions have different readiness.

What ships with the pattern

A working multi-division D365 deployment has:

• Per-division LEs with ledger and calendar configured
• Chart of accounts decision made and documented (common, per-division, or hybrid)
• Organizational hierarchies for corporate reporting cuts
• Financial dimensions for cross-LE reporting
• Intercompany trade for division-to-division transactions
• Consolidation configured for corporate reporting
• Governance model (CoE) for what's standardized and what's divisional
• Phased rollout plan accounting for divisional readiness

The structure is boring on purpose. The innovation happens inside divisions within the framework, not in the framework itself.