Microsoft Dynamics 365

EDIFACT integration for Dynamics 365 without putting EDI logic in your ERP.

Connect Dynamics 365 with trading partners while keeping partner-specific EDIFACT rules outside your ERP integration layer. CleanEDI provides the boundary between external EDI and your business systems.

Discuss your D365 integrationSee all integrations

Keep the ERP focused on the business.

Dynamics 365 should deal with purchase orders, invoices, shipments and business processes. Trading-partner EDI syntax and implementation detail belong at the integration boundary.

Trading partners
ORDERSDESADVINVOICPartner variants
EDIFACT · partner rules · AS2 / SFTP
EDIFACT
CleanEDI
integration boundary
JSON / API
Dynamics 365
Sales / PurchaseOrdersInvoicesShipments
Business data · OData / APIs
Your ERP model stays clean

Typical D365 trading-partner flows.

01

Orders inbound

Trading partner sends ORDERS → CleanEDI parses and normalises → D365 receives business data.

02

Invoices outbound

D365 sends an invoice business object → CleanEDI generates the partner-specific INVOIC → partner receives EDIFACT.

03

Shipments outbound

D365 sends shipment data → CleanEDI applies partner requirements → partner receives DESADV.

04

Acknowledgements

Functional and application acknowledgements can be handled at the EDI boundary instead of becoming custom ERP logic.

A cleaner D365 integration surface.

CleanEDI absorbs the external complexity so your ERP integration remains understandable, maintainable and under your control.

Keep EDIFACT out of D365 integration code

EDIFACT segments, qualifiers and partner-specific conventions stay outside the ERP-facing application contract.

Use business-oriented data

Your integration layer can work with orders, invoices, shipments and acknowledgements rather than external message syntax.

Isolate partner changes

A partner update should be handled in the EDI boundary instead of creating unnecessary changes in D365 customisations and downstream services.

Use the integration patterns you already have

Connect through APIs, webhooks or messaging patterns around your existing D365 architecture.

What to expect from a D365 integration.

Is there a pre-built D365 connector today?

The underlying EDIFACT platform is live and already handles ORDERS, DESADV, INVOIC, CONTRL and RECADV end to end. The D365-specific data mapping, resolving OData entities, GLN references and legal entity routing, is scoped and built as part of an onboarding engagement rather than a self-serve connector today.

Does this work with both D365 Finance & Operations and Business Central?

Yes, though the delivery path differs. F&O typically receives clean business data through OData entities, while Business Central integrates through its REST API. The EDIFACT boundary CleanEDI provides is the same in both cases, only the ERP-facing delivery method changes.

How is GLN resolution and legal entity routing handled?

Trading partners identify locations and legal entities using GLNs or their own reference codes, which rarely line up cleanly with D365 records. CleanEDI resolves these mappings at the integration boundary so D365 receives orders and invoices already routed to the correct legal entity, rather than requiring custom resolution logic inside the ERP.

We currently use a managed EDI service or VAN for D365. Can CleanEDI replace it?

Many teams start by routing new trading partner connections through CleanEDI while an existing VAN or managed service continues to run, then migrate further connections over time. There is no requirement to cut over everything at once.

Start with one partner and one message flow.

Choose a representative ORDERS, INVOIC or DESADV flow. We can use the real integration scenario to demonstrate how EDIFACT is handled outside D365 and how clean business data reaches your existing integration surface.

Discuss a proof of conceptSee the architecture

Need EDIFACT with Dynamics 365 without the EDI complexity?

Tell us which D365 environment, trading partners and message types you are working with. We can show you where CleanEDI fits and what a focused proof of concept could look like.