Enterprise Integration

Multi-ERP Integration Patterns: Connecting Dynamics 365 Across the Enterprise (2026)

Multi-ERP environments require strategic master data governance, architectural pattern selection, and modern integration platforms to achieve real-time visibility and financial consolidation across Dynamics 365 and heterogeneous legacy systems.

Last updated: March 15, 202618 min read12 sections
Quick Reference
Multi-Company Growth
78% of enterprises report operating 2+ ERP instances due to M&A, regional autonomy, and legacy system retention (2025–2026)
Business Central Native Support
Multi-company functionality built into Business Central eliminates need for external consolidation layers for single-platform scenarios
Finance & Operations Legal Entities
F&O supports unlimited legal entities and operating units with native consolidation and intercompany elimination engines
Integration Cost Factor
Master data MDM + integration middleware typically accounts for 20–35% of multi-ERP total cost of ownership
Real-Time Data Sync
Modern iPaaS platforms (Azure, MuleSoft, Workato) enable sub-minute synchronization for high-velocity transactional data
Golden Record Management
Centralized MDM platforms reduce duplicate customers/vendors by 40–60% vs. point-to-point integration approaches

Introduction: The Multi-ERP Reality

Multi-ERP environments are no longer edge cases—they are the norm. Organizations accumulate multiple ERP instances through mergers & acquisitions, spin-offs, regional deployments, and legacy system retention. For Dynamics 365 adopters, this means operating Business Central and Finance & Operations instances alongside SAP, NetSuite, legacy mainframe systems, and niche vertical solutions.

Unlike single-ERP greenfield implementations, multi-ERP integration demands a different architectural mindset: federated master data governance, asynchronous event-driven patterns, and reconciliation-first financial reporting. This section explores the patterns, technologies, and governance models that make multi-ERP landscapes operational.

Why Multi-ERP Environments Exist

1. Mergers & Acquisitions (M&A)

The primary driver: two organizations merge with incompatible ERP platforms and business models. Post-acquisition integration typically follows a timeline:

  • Years 0–2: Run both systems in parallel (highest integration cost)
  • Years 2–4: Selective data consolidation; key functions (AR, AP, GL) unified; operations remain separate
  • Years 4+: Full system rationalization or permanent federation if divisional autonomy justifies continued separation

2. Regional & Divisional Autonomy

Global organizations often maintain separate ERP instances per region or business unit to preserve local accounting standards, supply chain models, and reporting requirements. A multinational manufacturing firm, for example, may operate D365 F&O for the EMEA division and legacy SAP R/3 for APAC, with Business Central for smaller subsidiaries.

3. Legacy System Retention

High-cost legacy system replacement is often deferred for non-critical functions. A manufacturing company running mainframe MRP for raw materials might adopt Dynamics 365 Supply Chain Management for finished goods logistics while maintaining the legacy system for supplier networks.

4. Specialized Vertical Solutions

Certain industries require niche solutions: healthcare systems use separate revenue cycle management (RCM) systems, utilities operate asset-heavy GIS/SCADA systems, and pharmaceutical companies deploy specialized inventory controls that D365 cannot fully replace.

5. Third-Party Marketplace Platforms

E-commerce platforms (Shopify, Magento), subscription billing systems (Zuora), and order management systems (OMS) operate as separate systems of record, requiring persistent data flows to and from Dynamics.

Native Multi-Company & Multi-Entity Support

Business Central Multi-Company Architecture

Dynamics 365 Business Central includes native multi-company support, allowing a single deployment to manage 100+ companies with complete data isolation and unified master data:

  • Data Isolation: Each company maintains separate GL, AR, AP, inventory, and operational data
  • Shared Masters: Vendors, customers, items, and dimensions can be created as global records accessible across companies
  • Intercompany Transactions: Two-way intercompany sales and purchase documents automatically balance across entities with automatic GL posting
  • Consolidation Companies: Purpose-built consolidation entities receive intercompany eliminations and eliminate redundant balance-sheet accounts
  • Currency Handling: Multi-currency support with real-time or fixed exchange rates per company

Use Case: A mid-market B2B distributor with 12 regional companies can operate all within a single Business Central instance. Sales from Company A to Company B automatically post intercompany revenue on both sides; a consolidation company eliminates intercompany gains, producing accurate consolidated financials monthly.

Finance & Operations Multi-Entity & Operating Unit Model

Finance & Operations takes a more granular approach through legal entities and operating units:

  • Legal Entities: Tax-reporting entities with independent GL accounts, tax IDs, and regulatory compliance boundaries
  • Operating Units: Cost centers, profit centers, and responsibility centers that can span multiple legal entities
  • Organizational Hierarchies: Unlimited hierarchies map reporting lines, profit-center allocations, and consolidation rollups
  • Intercompany Transactions: Full subledger and GL settlement with automatic intercompany billing and receivable reconciliation
  • Elimination Journals: Advanced consolidation with rule-based intercompany transaction elimination (e.g., downstream profits on inventory)

Use Case: A global industrial manufacturer maintains 40 legal entities (one per country) and 200+ operating units (factories, distribution centers). Finance & Operations consolidation engine eliminates intercompany sales, consolidates foreign currency gains/losses, and produces GAAP-compliant consolidated financials for SEC reporting.

Choosing Between Single-Platform vs. Cross-Platform Integration

Scenario Approach Rationale
Single BC instance, 1–50 companies Native multi-company No external integration required; full GL visibility and intercompany automation
Single F&O instance, 1–200 legal entities Native multi-entity Unlimited scaling; advanced consolidation and hierarchy management
BC + F&O federation Master data sync + transaction consolidation Separate entities require nightly GL extraction and consolidation reporting
D365 + SAP or NetSuite iPaaS + data warehouse consolidation Legacy systems demand high-touch integration patterns and eventual migration roadmap
D365 + 3+ heterogeneous systems Enterprise service bus (ESB) or hub-and-spoke Scalable, governance-driven architecture with centralized master data

Integration Architecture Patterns

Pattern 1: Hub-and-Spoke (Master Data Hub)

A centralized master data platform (MDM) serves as the single source of truth for customer, vendor, and product records. Each ERP spoke consumes and publishes changes asynchronously.

Implementation:

  • Central MDM platform (Informatica, Talend, SAP Master Data Governance, or custom Azure Data Factory)
  • Each ERP has a data layer adapter (e.g., Dynamics Customer Service integration for D365)
  • Bi-directional event streams: MDM → ERP (new customer creation) and ERP → MDM (customer attribute updates)
  • Reconciliation and conflict resolution rules for data quality

Pros: Single source of truth; easier onboarding of new systems; mature governance model.

Cons: Higher initial investment; requires dedicated MDM team; latency between spokes.

Pattern 2: Point-to-Point Integration

Direct connections between ERP instances without a central hub. Common in smaller multi-ERP environments or transitional post-M&A scenarios.

Implementation:

  • Direct iPaaS connectors (e.g., Azure Logic Apps, MuleSoft, Workato) between source and target systems
  • Scheduled data flows (e.g., nightly customer sync from SAP to Business Central)
  • Transformation rules embedded in iPaaS middleware

Pros: Simple to implement; low overhead for 2–3 system pairs; quick ROI.

Cons: Data inconsistency risk (each pair has different transformation rules); difficult to scale beyond 5–6 systems; maintenance burden grows exponentially.

Pattern 3: Enterprise Service Bus (ESB)

A message-oriented middleware that decouples ERPs through standardized events and canonical data models.

Implementation:

  • Azure Service Bus or Apache Kafka for event streaming
  • Event schema definitions (e.g., CustomerCreated, PurchaseOrderSubmitted)
  • Each ERP publishes and consumes events without direct coupling
  • Dead-letter queues and replay mechanisms for reliability

Pros: Highly scalable; loose coupling; easier to add/retire systems; strong audit trails.

Cons: Requires event-driven mindset; more operational complexity; eventual consistency model.

Pattern 4: Modern iPaaS (Integration Platform as a Service)

Cloud-native integration platforms like MuleSoft, Workato, Boomi, and Azure Integration Services provide visual workflow builders, pre-built connectors, and managed middleware.

Typical Architecture:

  • iPaaS connects source ERP (Dynamics, SAP, legacy) to target ERP
  • Data transformation, enrichment, and validation rules applied mid-flight
  • Error handling and reconciliation workflows
  • API-first design enables real-time or batch syncs

Market Trends (2026):

  • MuleSoft Anypoint: Market leader for complex integrations; strong Salesforce ecosystem
  • Workato: Rapid deployment for SMB/mid-market; strong pre-built connectors for D365
  • Boomi: Mature platform; strong in manufacturing; acquired by Vista Equity (2023)
  • Azure Integration Services: Azure Logic Apps, Data Factory, Event Hubs; best for Microsoft-centric stacks

Master Data Management (MDM) Across ERPs

Customer & Vendor Master Synchronization

Customer and vendor records are often the highest-volume sync requirement. Challenges include:

  • Duplicate Detection: Same customer entity appears in multiple ERPs with different names, tax IDs, or hierarchies. ML-driven fuzzy matching reduces manual effort.
  • Attribute Mapping: Field names and data types differ across systems (e.g., D365 Credit Limit vs. SAP Credit Exposure). Transformation rules maintain semantic equivalence.
  • Hierarchical Relationships: Parent-child relationships (corporate HQ to regional subsidiaries) require flattening/unflattening across systems.
  • Change Data Capture (CDC): Efficient sync depends on identifying only changed records (via timestamps, transaction logs, or change data streams) rather than full daily extracts.

Best Practice Implementation:

  1. Establish a "customer golden record" in MDM with unified attributes and hierarchy
  2. Implement CDC from each ERP source to detect new/changed customers in real-time
  3. Apply deduplication rules in MDM (fuzzy matching, domain-based scoring)
  4. Publish validated changes back to each ERP via API
  5. Daily reconciliation reports highlight discrepancies for human review

Product Master & Item Master Harmony

Products are often more standardized than customers, but multi-ERP environments still face challenges:

  • SKU Proliferation: Same physical product may have different SKU codes in D365, SAP, and legacy systems, making supply chain visibility difficult.
  • Attribute Differences: Business Central tracks Base Unit of Measure while F&O uses Inventory Unit and Sales Unit separately.
  • Pricing Variants: Different pricing models (tiered, volume-based, customer-specific) require centralized price management separate from item masters.

Solution Pattern: Central product MDM (e.g., Informatica, SAP Master Data Governance) maintains a single product golden record with cross-reference tables mapping system-specific SKUs. Nightly batch sync publishes product attributes to each ERP.

Chart of Accounts Harmonization

For financial consolidation, ERPs must share a unified chart of accounts structure:

  • Business Central and F&O use hierarchical GL account structures; legacy systems may use flat accounts
  • Multi-currency translations require consistent elimination accounts and consolidation rules
  • Segment codes (cost center, profit center, project) must map consistently across systems

Implementation: Define a standard GL account structure in a master reference; create mapping tables in the consolidation database that translate local GL codes to consolidated GL codes.

Financial Consolidation Across Multiple ERPs

Multi-Currency Consolidation

When subsidiaries operate in different currencies, consolidation requires:

  • Transaction-Level Exchange Rates: Record invoice currency and exchange rate at transaction time, not post-close
  • Balance Sheet Translation: Period-end rates for assets/liabilities; historical rates for equity; average rates for P&L
  • Foreign Exchange (FX) Gains/Losses: Realized gains on payments; unrealized gains on open balances; translation adjustments on intercompany balances

D365 Support: Finance & Operations native consolidation automates multi-currency translation with configurable accounting rules per legal entity and consolidation company.

Intercompany Elimination & Reconciliation

Removing intercompany transactions is the core complexity:

  • Sales Elimination: Company A sold $1M to Company B; this revenue is eliminated and replaced with cost of goods sold impact
  • Downstream Profit Elimination: Company A sold inventory to Company B; if B still holds that inventory, the intercompany profit must be eliminated
  • Intercompany Payables/Receivables Elimination: Company A has an AR of $500k from Company B; Company B has an AP of $500k to Company A; both eliminated
  • Dividend Elimination: Company A declared a dividend to parent; eliminated from consolidated P&L

F&O Consolidation Engine: Supports rule-based elimination with tolerance thresholds; flags out-of-balance intercompany transactions for resolution before final consolidation.

Sub-Ledger Reconciliation

Before consolidation, AR, AP, and intercompany subledgers must reconcile to GL:

  • Extract AR aging from each ERP
  • Cross-check against GL AR control account balance
  • Identify and resolve reconciling items (in-transit invoices, timing differences)
  • Repeat for AP and intercompany accounts

Automation: Extract subledger data to consolidation database; run SQL reconciliation queries to identify discrepancies; flag exceptions for Finance team resolution.

Unified Reporting Across Multiple ERPs

Data Warehouse Consolidation Architecture

Rather than real-time GL consolidation, many organizations extract GL data from all ERPs into a centralized data warehouse nightly:

  • ERP GL Extract: Daily GL journal export from Business Central, F&O, SAP, and legacy systems
  • Data Lake Staging: Raw data loaded to Azure Data Lake or Snowflake (schema-on-read)
  • Transform Layer: Consolidation logic applies (account mapping, FX translation, intercompany elimination) to produce standardized GL
  • Reporting Layer: Power BI and Excel feed from consolidated GL; consistent KPI definitions across all business units

Microsoft Fabric Data Integration

In 2026, Microsoft Fabric offers unified data and analytics on Azure:

  • Lakehouse ingests GL data from Dynamics instances via native connectors
  • Delta Lake and OneLake provide ACID transactions and versioning
  • T-SQL queries and Python notebooks transform GL to consolidation format
  • Direct connection to Power BI for real-time dashboard updates

Power BI Data Models for Consolidation Reporting

A typical Power BI consolidation model includes:

  • GL Fact Table: GL account, legal entity, cost center, period, currency, debit/credit amounts
  • Account Dimension: GL account code, description, account type (asset, liability, equity, revenue, expense), hierarchy level
  • Entity Dimension: Legal entity, subsidiary name, country, currency, consolidation method (full, equity, cost)
  • Time Dimension: Period, fiscal year, quarter (for period-to-date and year-to-date calculations)
  • Elimination Table: Pre-calculated elimination GL entries loaded post-consolidation logic

This approach enables 100ms dashboard response times on 50+ million GL rows.

Data Quality & Governance Challenges

Duplicate Detection & Golden Record Management

Multi-ERP environments inherit duplicate customer, vendor, and product records:

  • Fuzzy Matching: ML algorithms (Levenshtein distance, phonetic encoding) identify likely duplicates with 85–95% accuracy
  • Manual Review Workflow: Flagged duplicates routed to Data Stewards for confirmation and merge
  • Golden Record Creation: Selected attributes (e.g., most recent address) consolidated into single authoritative record
  • Historical Tracking: Maintain audit trail of merge decisions and attribute lineage for compliance

Industry Standard Tools: Informatica, Talend, Ataccama, and Collibra offer AI-powered duplicate detection with 70–80% reduction in manual effort vs. rules-based approaches.

Data Governance & Stewardship

Multi-ERP success requires disciplined governance:

  • Data Ownership: Assign domain stewards (e.g., Customer Steward, Product Steward) accountable for master data quality
  • Business Rules Registry: Document transformation rules, account mapping, and elimination logic in centralized repository
  • Change Control: Any modification to master data structures or consolidation rules requires approval and version control
  • Data Quality SLAs: Define acceptable error rates (e.g., 99% customer master accuracy) and monitor daily

Reconciliation & Variance Analysis

Monthly close process requires reconciliation layers:

  • GL to AR/AP Reconciliation: Control account balance matches aging report detail
  • Intercompany Reconciliation: Company A revenue to Company B expense matches (net of timing)
  • Consolidation Variance Report: Explains all adjustments between pre-consolidated and post-consolidated GL
  • Period-to-Period Variance: Flags unusual fluctuations in account balances month-to-month

Automated variance reports reduce manual investigation time by 40–50%.

Technology Stack & Platform Options

Azure Integration Services Ecosystem

Best for: Microsoft-centric organizations already using Office 365, Dynamics 365, and Azure.

  • Logic Apps: Visual workflow builder for iPaaS; native Dynamics 365 connectors; event-triggered or scheduled
  • Data Factory: Visual ETL pipeline designer; supports 100+ data sources; scheduling and error handling built-in
  • API Management: RESTful API facade for legacy system access; rate limiting and versioning
  • Event Hubs & Service Bus: Message broker for asynchronous, event-driven architecture
  • Synapse Analytics: Unified data warehouse; SQL, Spark, and Python for consolidation queries

Cost Model: Pay-per-execution; typical mid-market multi-ERP setup: $3k–$8k/month.

MuleSoft Anypoint Platform

Best for: Enterprise-scale integrations; complex transformation logic; strong Salesforce ecosystem.

  • Pre-built connectors for 1,000+ applications (including D365, SAP, NetSuite)
  • Advanced integration patterns: request-reply, publish-subscribe, content-based routing
  • API design and governance; analytics and monitoring dashboards
  • Managed cloud and on-premise deployment options

Cost Model: Subscription per vCore; typical cost: $5k–$15k/month for mid-market.

Workato iPaaS

Best for: SMB and mid-market; rapid deployment; 400+ native connectors; strong Dynamics 365 support.

  • Visual workflow builder with conditional logic and error handling
  • Pre-built recipes (templates) for common scenarios (customer sync, GL consolidation)
  • Real-time and batch execution modes
  • Community-driven connector development

Cost Model: Subscription per task volume; typical cost: $2k–$6k/month for mid-market.

Dell Boomi Integration Cloud

Best for: Manufacturing and supply chain; strong ERP integration heritage; acquired by Vista Equity (2023).

  • Atom-based execution (lightweight cloud connector); deployed on-premise or cloud
  • AtomSphere cloud integration platform; Boomi Suggest AI for mapping optimization
  • Strong connector ecosystem for legacy systems (mainframe, EDI)

Cost Model: Subscription per Atom and transaction volume; typical cost: $4k–$10k/month.

SAP Integration Suite

Best for: SAP-centric environments; multi-cloud strategies.

  • Cloud Integration Capability (CIC) for cloud-to-cloud integration
  • Process Integration and Intelligent Routing Engine (PIRE) for complex workflows
  • Strong SAP ecosystem and governance tooling

Integration Governance & Operations

Integration Center of Excellence (CoE)

Successful multi-ERP environments establish a dedicated Integration CoE:

  • Governance Role: Approves new integrations; enforces standards and naming conventions; maintains integration registry
  • Architecture Role: Owns integration architecture roadmap; evaluates new tools and platforms; manages technical debt
  • Operations Role: Monitors live integrations; manages incident response; provides 24/7 support
  • Enablement Role: Trains business users on integration capabilities; documents best practices

Typical Team Size: 3–5 FTE for mid-market; 8–15 FTE for enterprise.

Integration Monitoring & SLA Management

Operational discipline requires:

  • SLA Definitions: E.g., customer master sync must complete within 30 minutes; 99.5% uptime target
  • Monitoring Dashboards: Real-time pipeline status, error rates, latency metrics
  • Alert Escalation: Automatic escalation when SLA thresholds breached (e.g., pipeline running >45 min)
  • Root Cause Analysis: Post-incident reviews capture lessons learned and prevent recurrence
  • Quarterly Business Reviews: Integration CoE reports to Finance/Operations leadership on integration health and roadmap

Error Handling & Reconciliation Patterns

Dead-Letter Queue (DLQ) Pattern:

When a transaction fails to process (e.g., customer does not exist in target), it is routed to a DLQ for manual investigation and replay:

  1. Async integration fails; transaction moved to DLQ
  2. Integration CoE reviews DLQ daily; identifies root cause (missing parent customer, invalid data, target system down)
  3. Once resolved, transaction replayed from DLQ
  4. Success metrics track DLQ drain time and root cause distribution

Version Control & Deployment Automation

Treat integrations as code:

  • Store all iPaaS workflow definitions, transformation rules, and mapping tables in Git
  • Implement CI/CD for integration changes: Dev → UAT → Production promotion
  • Automated testing suite validates transformation logic and error handling
  • Audit trail captures who deployed what changes when

Real-World Case Study: Multi-ERP Consolidation (2025–2026)

Scenario: A $2B global industrial manufacturing company acquired a regional competitor, creating a multi-ERP landscape with Finance & Operations (EMEA), Business Central (Americas), and legacy SAP R/3 (legacy division).

Integration Roadmap

  • Phase 1 (Months 1–3): Establish central GL consolidation in Azure Synapse; extract GL daily from all systems; manual elimination adjustments
  • Phase 2 (Months 4–6): Deploy Workato to sync customer and vendor masters from MDM to all ERPs; reduce duplicate customer records by 50%
  • Phase 3 (Months 7–12): Automate F&O consolidation engine to handle multi-currency translation and intercompany elimination; retire manual journal uploads
  • Phase 4 (Months 13–18): Migrate legacy SAP R/3 processes to Azure Data Factory; consolidate legacy data to F&O GL

Outcomes (18-Month Horizon)

  • Monthly GL consolidation process compressed from 8 days to 2 days (75% reduction)
  • Customer master data quality improved from 82% to 96% accuracy (reduced duplicate entries from 2,100 to 800)
  • Real-time Power BI dashboard provides visibility across all three ERPs to C-suite
  • Integration CoE established; 6 FTE team owns integration roadmap
  • Total cost of ownership: $25M (D365 licenses, Workato, Azure Synapse, professional services) vs. $45M for traditional system consolidation

Multi-ERP Integration Best Practices (2026)

  1. Start with Master Data Governance: Invest in MDM before deploying transactional integrations. Clean master data is non-negotiable.
  2. Adopt Event-Driven Architecture: Decouple systems via asynchronous events (not real-time API calls) to reduce tight coupling and improve resilience.
  3. Establish a Single Source of Truth: Each master data domain (customer, vendor, product, GL) must have one authoritative owner and system.
  4. Implement Reconciliation Layers: Never trust integrations end-to-end; build reconciliation controls that flag mismatches daily.
  5. Version Control Everything: Store integration workflows, transformation logic, and configuration in Git; implement CI/CD for deployments.
  6. Monitor SLAs Religiously: Define, track, and escalate integration SLA breaches within hours, not days.
  7. Plan for Eventual Consistency: Accept that real-time sync across multiple ERPs is often not feasible; design for sub-hourly consistency instead.
  8. Build Integration CoE Early: Establish governance and operational discipline before integrations become sprawling and unmaintainable.
  9. Use Modern iPaaS, Not Custom Middleware: Avoid custom code for integrations; leverage managed iPaaS platforms with strong vendor support.
  10. Migrate Legacy Systems on a Defined Timeline: Don't let multi-ERP become permanent; establish a rationalization roadmap with target dates.

Frequently Asked Questions

Business Central uses <strong>multi-company</strong> architecture: a single deployment manages multiple independent companies with shared master data. Finance &amp; Operations uses <strong>multi-entity</strong> architecture with legal entities and operating units, supporting more granular organizational structures and advanced consolidation rules. Choose multi-company for simplicity (SMB/mid-market); choose multi-entity for complex hierarchies and regulatory requirements (large enterprises).

Consolidation is ideal but often impractical due to: (1) Legacy system replacement cost and risk; (2) Regional regulatory requirements (e.g., local GL structures); (3) Business unit autonomy preferences; (4) Specialized vertical solutions not replaceable by D365; (5) Post-M&amp;A integration timelines (parallel run for 2–4 years is common). Multi-ERP is often a temporary state, but "temporary" can last 5–10 years.

Implement a centralized Master Data Management (MDM) platform as the single source of truth. Use change data capture (CDC) to detect updates in source ERPs; apply deduplication and fuzzy matching to reduce duplicates by 40–60%; publish validated records back via iPaaS. Reconciliation reports flagging discrepancies enable Data Stewards to resolve exceptions daily. Golden record attributes (most authoritative source per field) ensure consistent data quality.

Extract GL data nightly to a cloud data warehouse (Azure Synapse, Snowflake); apply consolidation logic in T-SQL or Python (account mapping, FX translation, intercompany elimination). This approach consolidates 50+ million GL rows in 30 minutes vs. 8 hours with manual journal uploads. Power BI connects directly to consolidated GL for real-time reporting. Trade-off: nightly batch vs. intra-day visibility, but acceptable for most monthly-close workflows.

No single best choice; evaluate by use case: (1) <strong>Azure Logic Apps</strong>: Best for Microsoft-native stacks (D365, Office 365, Azure); native connectors, lowest latency. (2) <strong>Workato</strong>: Fastest deployment for SMB/mid-market; strong D365 connectors; 400+ pre-built recipes. (3) <strong>MuleSoft</strong>: Enterprise-grade; mature SAP ecosystem; complex transformation logic. (4) <strong>Boomi</strong>: Strong legacy system support (mainframe, EDI); manufacturing heritage. Total cost of ownership and time-to-value vary; pilot 2–3 options for your use case.

Finance &amp; Operations consolidation engine supports automated multi-currency translation per accounting standard (e.g., ASC 830 for GAAP, IAS 21 for IFRS): transaction date rates for actual transactions; period-end rates for assets/liabilities; average rates for P&amp;L. Unrealized FX gains/losses computed and posted automatically to elimination journal. Define accounting rules per legal entity so translation adjusts for local requirements. Manual entry is rare; system-driven is preferred for audit trail.

A golden record is a single authoritative version of a master data entity (e.g., one customer record) created by merging duplicate or conflicting records from multiple source systems. Each field of the golden record comes from the most authoritative source: e.g., address from the ERP where last updated, credit rating from credit bureau, contact info from CRM. Golden records enable consistent customer/vendor treatment across all ERPs and reduce data quality issues by 40–60%.

Depends on scope and legacy system complexity: (1) <strong>BC to BC multi-company:</strong> 3–6 months (leverage native functionality). (2) <strong>BC + F&amp;O federation:</strong> 6–12 months (GL consolidation, master data sync). (3) <strong>D365 + SAP + legacy systems:</strong> 12–24 months (full MDM, ESB, complex transformations). Plan for 30–50% of effort on data quality and cleansing, not integration technology itself.

Previous
Dual Write &amp; Virtual Entities in Dynamics 365: The Complete Guide (2026)
Next
M&amp;A ERP Consolidation: The Dynamics 365 Playbook for Mergers &amp; Acquisitions (2026)

Related Reading