Integrating Business Central with Dynamics 365 Finance & Operations [2026]

Why Organizations Choose Dual BC-F&O Architectures

The decision to integrate BC and F&O rather than consolidate into a single system typically reflects one of four drivers:

Acquisition Integration: A company acquired on Business Central remains on BC to avoid disrupting its operations while the parent company's consolidated reporting occurs in F&O. This is the most common scenario in private equity roll-ups and bolt-on M&A.

Regulatory or Accounting Separation: Subsidiaries in jurisdictions with strict local GAAP, transfer pricing, or statutory reporting requirements may need their own accounting ledgers. BC provides lighter-weight, locally managed accounting while F&O centralizes group-level IFRS consolidation.

Operational Autonomy: Regional divisions, business units, or manufacturing plants may operate with significant financial independence. BC's user interface and workflows appeal to finance teams that want familiar, straightforward accounting software rather than F&O's complexity.

Legacy System Dependencies: Older implementations may lack the budget or organizational readiness to migrate from BC to F&O. Dual-system operation becomes a transitional or permanent state.

Each driver shapes integration strategy. Acquired entities often prioritize minimal change (use existing BC, sync GL to parent F&O). Regulatory separation demands that BC maintains its own statutory GL while F&O consolidates. Transitional states suggest a phased migration path.

Core Integration Patterns

Master Data Synchronization

Customer, vendor, product, and GL account data must be consistent across systems. The most reliable approach uses Dataverse as a system of record for master entities. BC and F&O both read from Dataverse for customer/vendor/product creation, ensuring that downstream transactions reference aligned IDs. For GL accounts, a centralized chart of accounts in Dataverse is mapped to both systems' native GL structures through configuration.

Dual-write plugins between BC and Dataverse can operate bidirectionally for low-change-frequency entities like products and customers. However, if BC makes frequent changes to customer data (address, payment terms) that F&O doesn't need in real-time, unidirectional sync from BC to Dataverse may be simpler. Always establish a source-of-truth rule: if both systems can modify an entity (e.g., vendor), define which is authoritative or implement conflict resolution logic.

GL Transaction Flow and Consolidation

General ledger transactions flow primarily one direction: BC to F&O. BC records day-to-day GL postings (sales, expenses, payroll); a scheduled integration job (daily or weekly) extracts GL transactions from BC and posts them to F&O in a consolidation GL or subsidiary entity ledger.

The integration must map BC's chart of accounts to F&O's accounts. A simple 1-1 mapping works for basic accounts; complex scenarios require GL mapping tables that translate BC accounts and dimensions to F&O accounts and cost centers. For example, BC account 4100 (Sales Revenue) might map to F&O account 40100 posted to cost center 10 (subsidiary identifier).

Dataverse can store this mapping configuration, allowing changes without code deployment. An Azure Logic App reads BC GL batches, looks up mappings in Dataverse, and posts to F&O via the OData API. This pattern scales to multiple BC instances without custom code per subsidiary.

Intercompany Elimination

When BC and F&O entities transact with each other (BC subsidiary sells to F&O parent, for example), intercompany balances must be eliminated at consolidation. F&O's native intercompany elimination module works within F&O but not across to external BC. Custom elimination logic is required:

BC records a sale to a special "intercompany customer" representing the F&O parent. F&O receives a corresponding purchase from the BC subsidiary. A scheduled reconciliation identifies matching pairs (by amount, date, product) and flags them for elimination. Unmatched items (timing differences, exchange variance) are logged for manual review. F&O's elimination GL accounts (e.g., Intercompany Revenue, Intercompany COGS) accumulate these balances, which are then zeroed out in consolidation reporting.

Timing differences are the most common pain point. BC might recognize revenue when goods ship; F&O might recognize it when an invoice posts. Daily reconciliation scripts that bridge timing differences prevent month-end reconciliation chaos.

Technology Stack and Integration Approaches

Dataverse + Dual-Write

Dataverse provides a neutral data hub. Dual-write plugins synchronize customer, vendor, and product data bidirectionally. This approach is low-code, scalable to many BC instances, and provides Dataverse as a potential future system of record if the organization later consolidates on-premises or cloud applications.

Limitations: Dual-write does not handle GL transactions or intercompany elimination; those require separate integration logic. If BC and F&O attempt to modify the same entity simultaneously, conflict resolution rules must be explicit.

Azure Integration Services (Logic Apps + API)

Custom integration using Azure Logic Apps or Azure Functions connects BC APIs to F&O APIs. This approach is flexible and works at any scale. Logic Apps poll BC for new GL transactions, apply mapping rules, and post to F&O. For high-volume transactional data, direct API-to-API integration via Azure Data Factory is more efficient.

This approach requires expertise in BC and F&O APIs, mapping logic, and error handling. Build in reconciliation checkpoints: count source records in BC, count posted records in F&O, log and alert on mismatches.

Third-Party iPaaS (MuleSoft, Boomi, Informatica)

Enterprise integration platforms offer pre-built connectors for BC and F&O, reducing custom development. They excel at complex transformations, error handling, and audit trails. For organizations with multiple ERP integration projects, iPaaS can amortize cost across many use cases.

Cost trade-off: iPaaS licensing is higher than Azure DIY solutions but lower than building custom integration frameworks in-house. If you anticipate long-term multi-system integration, iPaaS often wins.

Managing Data Conflicts and Reconciliation

In any dual-system landscape, conflicts are inevitable. BC and F&O may calculate GL balances differently due to dimension structures, posting logic, or timing. Establish clear reconciliation:

1. Daily GL Reconciliation: Compare BC GL total by account/dimension to F&O GL total by mapped account/cost center. Alert on variances > threshold.
2. Intercompany Matching: Daily or weekly matching of intercompany invoices and receipts; escalate unmatched items to controllers for investigation.
3. Master Data Audit: Weekly reports of customer/vendor/product creations or changes in each system; verify they are reflected in Dataverse and the peer system.
4. Integration Log Review: Weekly review of integration job logs for errors, retries, or skipped records. Failures require immediate root-cause investigation.

Assign ownership: a shared services center or consolidation team should own reconciliation. Provide them dashboards (Power BI fed by Dataverse and reconciliation tables) showing real-time sync status, variance summaries, and action items.

Common Pitfalls and Workarounds

GL Account Alignment Breaks: When BC adds a new GL account that is not mapped to F&O, transactions post to F&O's "suspense" account. Prevent this by enforcing GL account creation in Dataverse first, with automatic propagation to both systems.

Dimension Mismatch: BC uses dimensions (e.g., Department); F&O uses cost centers. Mapping requires a translation table. If BC dimension values change (Department renamed), corresponding F&O cost centers must be updated. Use Dataverse as the source of truth for dimension values.

Dual-Write Sync Lag: Dataverse dual-write syncs typically complete within seconds to minutes, not real-time. If BC and F&O users expect immediate visibility of master data changes across systems, set expectations: "Expect up to 5-minute delay in the peer system."

Intercompany Timing Differences: BC may post sales revenue on shipment; F&O may recognize it on invoice. These differences don't reconcile automatically. Implement a monthly cutoff process where finance teams manually adjust for known timing items (goods in transit, pending invoices).

Audit Trail Fragmentation: GL posting in BC is audited in BC; F&O posts are audited in F&O. Integration logs are separate. To reconstruct a complete transaction history, you must correlate across three logs: BC transaction log, integration job log, and F&O GL posting log. Implement a unified transaction ID (e.g., BC batch ID + sequence) that appears in all three logs.

When to Consolidate Instead

If integration complexity becomes unmanageable—if you have more than 3 BC instances feeding F&O, or if intercompany transactions represent >30% of BC GL volume—consolidation to F&O may be more cost-effective. A phased BC-to-F&O migration, completed over 12-18 months, often costs less than maintaining a fragile dual-system integration indefinitely.

Consider consolidation if:

• Your subsidiary BC instances have low transactional complexity (mainly GL posting, no manufacturing or project accounting).
• Audit and compliance requirements do not mandate local GAAP separation.
• Your organization is stable (no more acquisitions expected); consolidation is simpler than managing new BC instances.

Consolidation is not appropriate if:

• Subsidiaries operate under distinct regulatory regimes (e.g., European subsidiary under IFRS, US parent under GAAP).
• BC instances handle operational workflows (manufacturing BOMs, job costing, advanced inventory) that are unrelated to financial consolidation.
• Your organization has committed to BC as a long-term platform for SMB operations.

Implementation Best Practices

Start with Master Data: Before touching GL or transactions, implement robust master data synchronization. Test that customer and GL account creation in one system is reflected in the other within acceptable latency.

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

Phase by Complexity: Integrate simple GL accounts (revenue, expenses) before complex ones (intercompany, eliminations). Prove the pattern before scaling.

Dedicate a Reconciliation Team: Integration success depends on human oversight. Assign controllers or finance shared services to own daily/weekly reconciliation and variance investigation.

Document Mapping Rules: Maintain a living document of all BC-to-F&O GL mappings, dimension mappings, and conflict resolution rules. This document is your source of truth for training, audits, and troubleshooting.

BC and F&O integration is a long-term operational commitment. Design it for maintainability and clarity, not for elegant code or minimal configuration. Your successors will thank you.