Integrating Non-Dynamics ERPs with Dynamics 365 [2026]

Common Multi-ERP Scenarios

M&A with Retained ERP

A company acquires a subsidiary running SAP or Oracle. The decision is made to integrate their financials into D365 (the new group standard) rather than migrate them immediately. This is the most common scenario. The subsidiary continues running its legacy ERP for operational needs (supply chain, manufacturing, fixed assets) while GL transactions are consolidated into D365 for group reporting and statutory consolidation.

Regional or Divisional ERP Separation

A global organization might operate SAP in Europe, NetSuite in North America, and Oracle in Asia-Pacific. These divisions operate autonomously with separate P&L accountability. D365 is introduced as the new group consolidation platform, requiring integration with all three legacy systems.

Phased Cloud Migration

An organization with on-premises SAP or Oracle is migrating to the cloud gradually. D365 is deployed first for new operations or regions; legacy ERP is migrated in subsequent waves. During transition, both systems run in parallel, requiring integration to prevent data fragmentation.

Best-of-Breed Functional Architecture

Some organizations deliberately choose different ERPs for different functions. A company might use NetSuite for subscription billing and revenue recognition, Oracle for supply chain, and D365 F&O for consolidated financials and consolidation. This hybrid architecture requires master data coordination and GL consolidation across all three.

Each scenario demands integration, but the urgency and complexity differ. M&A integration is often immediate and business-critical. Phased migration allows for longer timelines. Best-of-breed requires long-term commitment to integration governance.

Core Integration Challenges

Data Model and Chart of Account Differences

SAP, Oracle, and Dynamics 365 structure GL accounts differently. SAP uses a 10-character GL account with associated cost center and profit center. Oracle uses ledger sets and balancing segments. D365 uses GL accounts with dimensions (cost centers, departments, projects). When consolidating, each GL line must be mapped from source ERP structure to D365 structure.

Example: SAP account 400000 (Sales Revenue) with cost center 1000 must be mapped to D365 account 40100 (Sales Revenue) with cost center dimension = 10. If the source ERP has 500 GL accounts and D365 has 800, the mapping is not 1-to-1. Some source accounts consolidate to one D365 account; others split across multiple D365 accounts based on dimensions.

Build a mapping table that translates source accounts to D365 accounts and defines dimension values. Store this in a centralized location (Dataverse, MDM platform, or integration tool) so that mapping changes are applied consistently across all integration jobs.

Master Data Duplication and Synchronization

When multiple ERPs coexist, customer and vendor records can diverge. SAP might have a customer registered as "Acme Corp USA"; D365 might have "Acme Corporation US". Without synchronization, the same customer is treated as multiple entities, breaking down analytics and customer relationship visibility.

The solution is a master data hub (MDM): a centralized repository where customer, vendor, and product data is created and maintained. Both the legacy ERP and D365 read from it. If customers are created in the legacy ERP (e.g., because salespeople are trained on that system), a dual-write plugin syncs new customers to the MDM and then to D365. If customers are created in D365, they flow back to the MDM and, if needed, to the legacy ERP.

Matching algorithms are essential to prevent duplicates. When a new customer is created in the source ERP, the matching algorithm checks the MDM for existing records with similar names, tax IDs, or addresses. If a match is found with high confidence (>95%), it reuses the existing record. If confidence is low, it flags for human review.

Real-Time vs. Batch Integration

Master data is typically synced in near-real-time (within minutes). GL transactions are typically integrated in batch (daily or weekly). Why the difference?

Master data changes rarely and benefit from immediate propagation. If a customer's address changes in SAP, D365 should reflect it within minutes to ensure that all new orders use correct shipping addresses.

GL transactions, by contrast, require reconciliation, conflict resolution, and audit review. Posting GL from SAP to D365 in real-time means that any error in mapping or timing creates an immediate imbalance in D365. Batch integration allows a reconciliation window: extract, validate, map, reconcile, then post. If discrepancies are found, they can be investigated and corrected before posting to the consolidated GL.

Dimension and Hierarchy Alignment

Dimensions (cost centers, departments, profit centers) are structural elements that determine how GL transactions are organized for reporting. SAP and D365 may have different dimension structures. SAP might have cost centers 1000-9999; D365 might have cost centers 01-99 with projects as a separate dimension.

When integrating, you must establish a mapping between SAP cost centers and D365 cost centers. If SAP cost center 1000 (Manufacturing) should roll up to D365 cost center 10 (Manufacturing), define that mapping. If SAP profit centers don't have a D365 equivalent, decide: post all transactions to a default cost center, or split them across D365 cost centers based on a formula.

Document dimension hierarchies in both systems and their mappings. Power BI reports should show GL balances by D365 dimension, making it easy to verify that SAP transactions are correctly mapped.

Integration Platforms and Technologies

MuleSoft (Salesforce)

MuleSoft is an industry-leading iPaaS (integration platform as a service) with pre-built connectors for SAP, Oracle, NetSuite, and D365. Its strengths: excellent data mapping UI, error handling, audit trails, and scalability. You define integration flows in a visual builder, map GL accounts through UI, and MuleSoft generates the integration code. For enterprises with complex multi-ERP landscapes, MuleSoft often becomes the central nervous system.

Trade-offs: Higher licensing cost ($50k-$150k+ annually for enterprise). Vendor lock-in. Requires training and dedicated resources to maintain.

Boomi (Dell)

Boomi is a competitor to MuleSoft with similar capabilities: pre-built connectors, visual mapping, cloud-native. Slightly lower cost than MuleSoft, strong in mid-market. If you have 2-3 ERPs and moderate complexity, Boomi is often a good choice.

Informatica

Informatica specializes in data integration and MDM. If you need to build a master data hub in addition to GL consolidation, Informatica is a strong choice. It offers data quality, matching, and stewardship features that MuleSoft or Boomi may lack. Higher cost and steeper learning curve than competitors.

Azure Data Factory + Logic Apps

For organizations in the Microsoft ecosystem, Azure Data Factory (ADF) is a low-cost, high-control option. ADF is a cloud ETL service where you define pipelines that extract from SAP/Oracle, transform, and load into D365. Logic Apps orchestrate workflows and error handling. Advantage: deep integration with D365 and Azure services, lower cost, full code control. Disadvantage: requires Azure expertise, less pre-built connectors than MuleSoft, heavier on custom development.

For a company with strong Azure engineering, this is often the best choice. For organizations without that expertise, iPaaS is lower-risk.

Custom APIs and Middleware

If you have in-house development expertise and your integration is relatively simple (2 systems, straightforward GL consolidation), custom APIs are viable. Build an API that reads GL from the source ERP, applies mapping logic, and posts to D365 via D365 OData APIs. Host it in Azure Functions or an on-premises middleware server.

Trade-offs: Lowest licensing cost but highest development cost. Requires long-term maintenance. Often becomes a liability when the original developers leave. Good only if your organization has a committed integration team.

Master Data Governance and Golden Record

In multi-ERP environments, master data governance is non-negotiable. Establish clear ownership: who creates customers? Who creates GL accounts? Who resolves conflicts when the same customer is created in two systems?

Implement a golden record approach:

1. Single Source of Truth: Dataverse, a dedicated MDM platform, or an integration platform serves as the golden record. All customers, vendors, and products are created here first.
2. Synchronization from Golden Record: D365 and legacy ERPs read from the golden record. When a customer is created, it flows automatically to both systems.
3. Change Notification: When a customer is updated in D365 or the source ERP, the change is reflected in the golden record and propagated to the peer system.
4. Conflict Resolution: If both systems attempt to modify a customer simultaneously, a conflict rule (last write wins, or requires human review) is applied.
5. Regular Reconciliation: Weekly reports identify customer records that exist in one system but not the other, or where attributes differ.

The golden record approach requires disciplined processes. Sales teams must be trained to create customers in the golden record (or the designated system that flows to it). If rogue customer creation happens in D365 or SAP outside the golden record, it creates friction and reconciliation work.

GL Consolidation Workflow

A typical GL consolidation process:

1. Extraction: Daily or weekly, extract GL transactions from the source ERP. Create a staging table that includes source GL account, amount, cost center, and transaction ID.
2. Validation: Check that all GL accounts in the staging table have corresponding mappings in the mapping table. Alert on unmapped accounts.
3. Transformation: Look up the mapping for each GL transaction and translate it to D365 GL account, dimensions, and cost center.
4. Reconciliation: Compare the transformed GL total to the source ERP GL total. They should match. If they don't, investigate differences (excluded accounts, filtered transactions) before posting.
5. Posting: Post the transformed GL to D365 via API. D365 posts to a consolidation GL or subsidiary entity ledger.
6. Reconciliation (Post-Posting): After posting, verify that D365 GL matches expected balances. Run a reconciliation report comparing source ERP GL to D365 GL by account and cost center.

Build automation for steps 1-5. Reserve step 6 (reconciliation) for human review. Any variances larger than a threshold should be escalated to controllers for investigation.

Intercompany Settlement and Elimination

If the legacy ERP and D365 are separate legal entities that transact with each other (e.g., legacy ERP subsidiary sells to D365 parent), intercompany balances must be settled and eliminated at consolidation.

The process mirrors what happens in multi-subsidiary D365 consolidation:

1. Legacy ERP records a sale to a special "intercompany customer" (the D365 entity).
2. D365 records a corresponding purchase from a special "intercompany vendor" (the legacy ERP entity).
3. A reconciliation job matches the intercompany invoice and purchase by amount and date.
4. Matched pairs are flagged for elimination; unmatched items are escalated for manual review.
5. In consolidation reporting (combining both entities into a single profit & loss), intercompany revenue and COGS are eliminated.

Timing differences are common. The legacy ERP recognizes revenue when goods ship; D365 recognizes it when the invoice is posted. A daily reconciliation process that bridges these differences prevents month-end bottlenecks.

Best Practices for Multi-ERP Integration Success

Start with Master Data: Before attempting GL consolidation, lock down master data synchronization. Test that a customer created in one system appears in the peer system within acceptable latency.

Build Reconciliation Early: Implement reconciliation reports before live integration. Use them to validate mappings and catch issues in test environments.

Document Everything: Maintain detailed documentation of GL mappings, dimension mappings, conflict resolution rules, and integration workflows. This becomes your source of truth for audits and troubleshooting.

Assign Dedicated Ownership: Integration success requires ongoing human oversight. Assign a team (finance operations, shared services, or IT) to own daily/weekly reconciliation and exception management.

Phase by Complexity: Start with simple GL (revenue, expenses). Integrate complex accounts (intercompany, eliminations) after proving the pattern.

Plan for Cutover: When transitioning from source ERP to D365 as the primary system, run both in parallel for 2-4 weeks. Use this period to validate that all GL is correctly integrated and to investigate variances.

Build Error Handling and Alerting: Integration jobs will fail: APIs timeout, mappings are incomplete, source data is corrupt. Build error handling that logs failures with enough detail for debugging, and alert teams immediately so they can investigate same-day.

Multi-ERP integration is operationally complex but strategically necessary for large enterprises. Invest in the right platform (MuleSoft, Boomi, or Azure), establish clear master data governance, and dedicate a team to ongoing reconciliation. The alternative—manually consolidating GL from multiple ERP systems each month—is unsustainable and error-prone.