# SAP Dynamics 365 integration

*SAP → Dynamics 365*

**In short:** A SAP to Dynamics 365 integration keeps SAP the system of record for finance and logistics while Dynamics 365 stays the front office for sales. Master data - business partners, materials, prices, credit status - flows from SAP (via OData services, IDocs, or BAPIs) into Dataverse accounts, contacts, products, and price lists. Quotes and orders created in Dynamics flow back into SAP as sales orders, and billing documents return as invoice status. Done properly it is not a one-off data load: it is a delta-driven, idempotent pipeline that reconciles SAP org structure, currencies, and units of measure against the Dataverse model so neither side drifts.

## What a SAP to Dynamics 365 integration actually does

SAP is where the money and the logistics live: the business partner master, the material master, pricing conditions, credit limits, the sales orders that drive delivery and billing. Dynamics 365 is where the sales team lives: accounts, contacts, opportunities, quotes, and the day-to-day pipeline in Dataverse. Left unconnected, the two describe the same customers and the same products in two different languages, and someone re-keys the difference by hand.

A SAP to Dynamics 365 integration closes that gap in both directions. Master data flows out of SAP so sales always quote against real customers, real materials, and current prices. Quotes and orders flow back into SAP so the front office does not become a parallel record that finance has to reconcile later. SAP stays the system of record; Dynamics stays the system of engagement; the pipeline keeps them honest.

## What data moves

| SAP object / event | Becomes in Dynamics 365 | Notes |
| --- | --- | --- |
| Business partner / customer master (DEBMAS, API_BUSINESS_PARTNER) | Account + contacts | SAP BP number written to a Dataverse alternate key |
| Material master (MATMAS, API_PRODUCT_SRV) | Product | Base unit of measure mapped to Dataverse unit group |
| Pricing conditions / price list | Price list (pricelevel) + price list items | Per currency and sales area; condition types resolved to net price |
| Credit limit / block status | Account field / status flag | Lets sales see a blocked customer before quoting |
| Quote / order created in Dynamics | Sales order (ORDERS, API_SALES_ORDER_SRV) | Mapped to correct sales org, distribution channel, division |
| Billing document / invoice (VBRK) | Invoice + status | Payment and clearing status returned for visibility |
| Delivery / ATP confirmation | Order line status | Confirmed quantity and date pushed back to the Dynamics order |

The exact object set, direction, and field mapping are agreed once and encoded in the pipeline. After that, nobody maps a customer number to a GUID by hand.

## The details that break naive syncs

A point-to-point script or a generic connector template gets you the happy path and leaves the expensive edges exposed:

- **Identity and the Business Partner model.** S/4HANA unified customer and vendor into the Business Partner; classic ECC did not. Matching a SAP customer number to a Dynamics account by name is how you create duplicates. The business key has to be the anchor, stored as a Dataverse alternate key, with a defined rule for records born on either side.
- **SAP org structure has no Dynamics equivalent.** Sales organisation, distribution channel, division, and company code decide how an order is processed in SAP. Dynamics knows none of them. An order created in the CRM that does not carry the right org assignment is rejected at the door.
- **Currencies and units of measure.** SAP stores amounts against a currency with its own decimal handling, and units of measure as internal codes that are not the ISO codes Dataverse expects. Prices are per sales area and currency. Get the unit or the decimal shift wrong and quantities and totals are quietly off.
- **Delta, not full reload.** Re-pushing the whole material master every night is slow and destructive. SAP change pointers or OData delta tokens tell you what changed; Dynamics change tracking does the same coming back. Without deltas you either move everything or miss updates.
- **Dataverse service protection limits.** Dynamics 365 throttles by request count and execution time per user. A naive loop that fires one call per record hits the limit and stalls mid-load. Writes have to be batched through the Web API and backed off correctly.
- **Partial failure and ordering.** An order references a customer and materials that must already exist in Dynamics. One bad record in a batch must not fail the rest, and a retry must not double-post the ones that already succeeded.

## How we build and run it

We treat this as a pipeline, not a migration. SAP objects are pulled or received as deltas - OData with delta tokens, IDoc distribution, or BAPI calls depending on the object and your landscape - validated against a schema, transformed into the agreed Dataverse model, and written through the Dynamics 365 Web API in correctly sized batches. Orders and quotes flow the other way into SAP under the right org assignment.

The pipeline is idempotent: every record carries a stable business key, so a retry, a replay, or two overlapping runs never create a duplicate or overwrite a newer value with a stale one. It runs on cloud-native, fully EU-hosted infrastructure, so business-partner and order data never leaves the EU, which keeps the DPA/AVV and your GDPR obligations clean.

Then we keep it running. Monitoring, alerting, incident response, and - critically - watching for SAP API releases and Microsoft's Dataverse limit changes are our responsibility under contract. You get a named owner and an SLA, not a script somebody has to babysit.

## When this integration is worth building

If a handful of accounts move between the two systems and someone re-keys the odd order, a manual process is genuinely fine and we will tell you so. The integration earns its place when the master data volume makes re-keying error-prone, when sales need live prices and credit status before they quote, when orders created in Dynamics have to land in SAP under strict org rules, or when finance is spending each close reconciling two records that should have been one all along.

## Frequently asked questions

### Which SAP interface do you use - IDoc, BAPI, or OData?

Whichever fits the object and your landscape. For S/4HANA we prefer the released OData services (API_BUSINESS_PARTNER, API_PRODUCT_SRV, API_SALES_ORDER_SRV) because they are stable and support delta handling. For classic ECC or where a customer already runs IDoc distribution, we consume DEBMAS, MATMAS, and ORDERS IDocs, or call BAPIs over RFC. We agree the interface per object up front so we are not fighting your Basis team's constraints later.

### How do you match a SAP customer to a Dynamics 365 account?

The SAP customer or business partner number is the anchor. We write it to a Dataverse alternate key on the account so every later update targets the right record by business key, not by a fuzzy name match. New accounts created first in Dynamics get a staging state until SAP assigns the real BP number, then the keys are linked. This is the single most important design decision and the thing generic connectors skip.

### Does the integration handle SAP sales org, distribution channel, and company code?

Yes. Dynamics 365 has no native concept of the SD organisational structure, so sales organisation, distribution channel, division, and company code have to be carried as fields or encoded into the mapping. We agree the target model with you - usually a combination of Dataverse fields and business-unit scoping - so an order created in Dynamics lands in SAP under the correct org assignment and does not get rejected.

### How do you keep the two systems in sync without duplicate or lost records?

The pipeline is delta-driven and idempotent. SAP change pointers or OData delta tokens tell us what actually changed; Dynamics change tracking does the same in the other direction. Every record carries a stable business key, so a retry, a replay, or an overlapping run never creates a duplicate or overwrites a newer value with an older one. Partial failures in a batch are isolated and retried, not silently dropped.

### Who operates it after go-live, and where does the data run?

We do. The pipeline runs on cloud-native, fully EU-hosted infrastructure that we monitor around the clock. If SAP releases a new API version, or Microsoft changes a Dataverse throttling limit, that is our problem to fix under contract - not a surprise your team discovers when orders stop flowing. You get a named owner, alerting, incident response, and an SLA, plus a DPA/AVV covering the data that moves.

## Related integrations

- [Dynamics 365 ↔ Salesforce](https://seamless.engineering/integrations/dynamics-365-salesforce/): Dynamics 365 Salesforce integration
- [SAP ↔ Salesforce](https://seamless.engineering/integrations/sap-salesforce/): SAP Salesforce integration
- [Dynamics 365 ↔ Slack](https://seamless.engineering/integrations/dynamics-365-slack/): Dynamics 365 Slack integration
- [monday.com ↔ SAP](https://seamless.engineering/integrations/monday-sap/): monday.com SAP integration
- [WooCommerce ↔ SAP](https://seamless.engineering/integrations/woocommerce-sap/): WooCommerce SAP integration
- [Business Central ↔ HubSpot](https://seamless.engineering/integrations/business-central-hubspot/): Business Central HubSpot integration

## Browse by system

- [All SAP integrations](https://seamless.engineering/integrations/sap/)
- [All Dynamics 365 integrations](https://seamless.engineering/integrations/dynamics-365/)

## Request a scoping call

Need this integration built and permanently operated? Tell us which systems connect and what data has to move. Fixed-price scoping quote within 48 hours.

- Email: hello@seamless.engineering
- Contact form: https://seamless.engineering/#contact