Integrating Dynamics 365 with SAP S/4HANA: two-tier ERP patterns

Two-tier ERP is the arrangement where a group runs SAP S/4HANA at headquarters and something lighter in its subsidiaries, plants, or newly acquired businesses. Dynamics 365 Finance and Supply Chain Management, and increasingly Business Central, are the usual candidates for that second tier. The integration between the tiers is what makes the arrangement work, and it is where most of the effort goes.

What two-tier actually means

The group ledger, consolidation, treasury, and often central procurement live in SAP. The subsidiary runs its day-to-day operations in Dynamics 365: local sales, purchasing, inventory, and its own statutory ledger. The integration moves a small, well-defined set of data between them. If you find yourself designing a real-time replication of every transaction into SAP, you have not designed a two-tier landscape; you have designed a very expensive way of running SAP twice.

The data that crosses the boundary

Financial results upwards. Trial balances or summarised journal lines, mapped from the subsidiary's chart of accounts to the group chart, on a monthly or weekly cadence. This is the one integration every two-tier landscape has, and it is batch by nature. Nobody consolidates in real time.

Master data downwards. Group-managed customers, vendors, and items pushed from SAP to the subsidiary so that intercompany trading uses the same identifiers. Whether SAP or Dynamics 365 owns which master data needs a written decision per entity type; "SAP owns everything" is common and usually wrong for local-only vendors.

Intercompany transactions both ways. A purchase order in the subsidiary becomes a sales order in SAP, and the invoice flows back. This is the integration that looks simple on a whiteboard and is not. Pricing, tax, currency, and partial deliveries all need explicit handling.

Reference data downwards. Exchange rates, group cost centres, reporting dimensions. Low volume, high annoyance when they drift.

SAP-side interfaces

You will be talking to one of these:

• OData services on S/4HANA (the SAP Gateway APIs). The most approachable option and the one the Power Platform SAP ERP connector and most iPaaS tools use. Coverage is broad but not complete.
• IDocs for classic asynchronous document exchange. Old, robust, and still the backbone of many SAP integrations. Good for orders and invoices; painful to debug without SAP-side skills.
• BAPIs / RFCs for synchronous function calls. Powerful, requires RFC connectivity and an on-premises data gateway or equivalent when S/4HANA is not internet-exposed.
• SAP Integration Suite (formerly CPI) as SAP's own middleware. If the group already runs it, expect the SAP team to insist it sits in the middle.

The Dynamics 365 side is easier: data entities and the OData endpoint in F&O (see custom services and OData in F&O), or API pages in Business Central.

Choosing the middle layer

Something should sit between the two ERPs. Direct point-to-point calls between SAP and Dynamics 365 are brittle and put SAP credentials in places the SAP team will not like.

For groups with an SAP Integration Suite investment, use it. For groups with an Azure-first posture, Logic Apps or Azure Functions plus Service Bus is the natural fit (see Logic Apps with Dynamics 365 and Azure Service Bus with Dataverse). For groups that already own Boomi or MuleSoft, use that. The technology matters less than having one place where mappings, retries, and logs live.

The Power Platform SAP ERP connector deserves a mention because it is tempting: it lets a Power Automate flow call a BAPI directly. It works for low-volume tasks like looking up an SAP vendor from a Dynamics 365 form. It is not a platform for financial postings.

Chart of accounts mapping

This is the design decision that outlives everything else. The subsidiary needs a local chart for statutory reporting and a mapping to the group chart for consolidation. In F&O, financial dimensions and a mapping table handle this well; in Business Central, a dedicated mapping table in an extension is the usual approach. Do the mapping in the middle layer or in Dynamics 365 before extraction, not inside SAP, so the SAP team receives clean group-chart postings and does not need to know the subsidiary's structure.

Intercompany in practice

The order-to-invoice loop between tiers is where projects overrun. Settle these before building:

• Which system generates the intercompany document number, and does the other system store it as a reference?
• What happens on a partial delivery from SAP against a subsidiary purchase order?
• Whose price list wins, and how are transfer-pricing adjustments posted?
• Is tax calculated in the seller's system only, with the buyer trusting the invoice?

Answers that involve "the finance team will fix it manually at month end" are acceptable for launch and a problem by year two.

What stalls two-tier projects

The SAP team and the Dynamics 365 team having different change calendars. SAP release cycles are slow and heavily governed; Dynamics 365 updates arrive monthly. Interface contracts need versioning and a test environment on both sides that actually match production.

Master data governance being unowned. If nobody owns the group vendor list, both systems will accumulate duplicates and the intercompany matching will decay.

Underestimating SAP access. Getting a service user with the right authorisations on S/4HANA, in a group where SAP security is tightly controlled, can take longer than building the integration.

Stability verdict

Financial-results-up and master-data-down are mature, well-understood patterns and you should expect them to run unattended once live. Automated intercompany order-to-invoice is achievable but is a proper project with SAP-side involvement, not a connector you switch on. If you are still deciding whether the second tier should be Dynamics 365 at all, read Dynamics 365 vs SAP first.