Holding companies often consolidate many legacy ERPs onto one D365 platform. Each division brings its own processes, chart of accounts, and fiscal calendar. Corporate finance wants consolidated reporting and some shared standards.
Architects sit in the middle. The job is to balance division autonomy with corporate consistency. No single mold fits every division. Separate environments per division do not work either.
Two common mistakes
Mistake 1: Multiple tenants, one per division
This isolates divisions. It also kills the consolidation story.
Every cross-division integration becomes middleware work. Corporate reporting turns into a data-warehouse project on top of Dynamics. M&A gets exponentially harder.
This path looks autonomous. It is actually siloed.
Mistake 2: Single legal entity with financial dimensions only
Divisions are split using financial dimensions, with no legal-entity separation. It breaks fast.
It breaks when divisions have:
- Different fiscal calendars (quarterly vs monthly close)
- Different statutory obligations
- Different audit cycles
Financial dimensions are powerful. They are not a substitute for legal-entity boundaries.
The structure that fits real-world diversity
Use multiple legal entities (LEs) in a single environment. Layer organizational hierarchies and ledger configurations on top.
Core components:
- One LE per division. Or one LE per country-and-division pair for multi-country divisions. Fiscal calendar, chart of accounts, and closing cycle stay per-LE.
- Shared chart of accounts at the framework level where it fits, with LE-specific overrides for accounts that differ.
- Ledger configuration per LE. Accounting currency, reporting currency, posting layers, exchange rate types.
- Organizational hierarchies for corporate reporting (division → business unit → cost center) that cut across LEs.
- Financial dimensions for reporting cuts that cross LE boundaries (product family, channel, geography).
- Cross-company data sharing for master data shared by divisions: vendors, customers, product master for shared categories.
Each division runs its close on its own calendar with its own chart. Corporate rolls everything up via consolidation and organizational hierarchies.
Chart of accounts design
Chart of accounts is usually the biggest design debate. Three patterns work.
Pattern A: Common chart with LE-specific exceptions
A corporate-level COA defines shared accounts. Each LE adds its own accounts for unique needs.
Good fit: companies where divisions share most accounting conventions.
Pattern B: Division-specific charts mapped to a consolidation chart
Each division keeps its own COA. Mapping rules translate to a consolidation COA at rollup time.
Good fit: highly diverse divisions where a common chart would break divisional finance.
Pattern C: Hybrid
A core COA is mandatory (revenue, COGS, major expense categories). Divisions add detail below the mandatory level.
Good fit: mid-diversity groups. Often the right answer.
The choice is not technical. It is 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 the fiscal calendar per LE. Close on each calendar's own schedule. Consolidation handles alignment when calendars differ.
One gotcha: consolidation uses the period-end rate of each source LE. If three divisions close on different days, the consolidated date is the latest close plus alignment logic.
Document this for the CFO before go-live. A surprise in month 2 is unpleasant.
Process standardization vs divisional freedom
The architecture supports both. Document the line clearly.
Standardized at corporate level:
- Global master data framework, even with some division-specific dimensions.
- Posting profile conventions for vendors, customers, products.
- Approval workflow scaffolding (divisions fill in their own rules).
- Period-close sequence and corporate consolidation schedule.
- Security model foundation.
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 systems:
- Standard consolidation supports "manual consolidation". Import divisional trial balances via DMF.
- BYOD or Export to Data Lake from D365 combines with legacy extracts in a data warehouse for Power BI reporting.
- Intercompany across the D365 and legacy boundary runs via data-entity-based integrations. Wait for the legacy side to migrate.
The intermediate state is uncomfortable. It is also 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 set up for division-to-division transactions.
- Consolidation configured for corporate reporting.
- Governance model (CoE) for what is standardized and what is divisional.
- Phased rollout plan accounting for divisional readiness.
The structure is boring on purpose. Innovation happens inside divisions within the framework. The framework itself should stay stable.
