EDI with Business Central

By Emil Björk · Microsoft business apps consultant, Gothenburg

How EDI integration works with Business Central — direct EDI vendors, AppSource connectors, document mapping, and the trade partner setup.

Reviewed May 20262 min read · 410 wordsPublished
On this page (7)

EDI — Electronic Data Interchange — remains the backbone of B2B trading between manufacturers, distributors, and retailers. Business Central doesn't ship EDI capability out of the box, but the integration story is well-established and based on a small number of patterns.

The shape of EDI

Trading partners exchange structured business documents — purchase orders (850), order acknowledgments (855), advance ship notices / ASNs (856), invoices (810) in the American X12 format, or ORDERS, ORDRSP, DESADV, INVOIC in EDIFACT. Documents travel over AS2, SFTP, VAN, or AS4 transport. Each trading partner has slightly different requirements; standardised on paper, varied in practice.

The Business Central path

Three real options.

  1. AppSource EDI connectors. Several ISVs publish packaged EDI modules — Lanham EDI, EDICOM for BC, Pagero, TIE Kinetix, others — that install into Business Central and provide a configuration UI for partner setup, message mapping, document send/receive, and audit. The most common pattern for SMBs. The connector handles transport, parsing, mapping, and integration with BC's sales/purchase document objects.

  2. External EDI service providers. Use a dedicated EDI service (SPS Commerce, OpenText GXS, IBM Sterling, TrueCommerce) that handles transport and translation, and integrate to BC via a lightweight bridge — typically file drops, REST API, or an ISV connector. Common when the trading partners require an established EDI provider, or when the volume is too high for in-platform processing.

  3. Custom integration. Write AL code or a Logic Apps workflow that translates EDI documents to BC records. Cheap to start, painful to maintain across hundreds of partner-specific variations. Rarely the right answer beyond a very small footprint.

Trading partner setup

For each partner, the EDI module captures: the trading partner's EDI identifier (DUNS, GLN, custom code), the document types exchanged (PO, ASN, Invoice), the maps from partner format to BC document fields, sequence number ranges, time-of-day expectations, and acknowledgment requirements.

Inbound POs

A partner sends an 850/ORDERS. The EDI module receives it, validates, and creates a sales order in BC with the partner as the customer. Item-number mapping (partner's part number → BC item number) is critical and partner-specific. Errors stage for review.

Outbound ASNs and Invoices

When BC posts a shipment, the EDI module generates an 856/DESADV and sends it; same for invoices.

Compliance

Retail and automotive partners often impose chargebacks for late or malformed EDI — slipped ASNs after shipment, missing fields, incorrect GTINs. Monitoring and exception handling are non-negotiable.

Operational reality

EDI is unglamorous infrastructure. Budget for ongoing partner onboarding and map maintenance — every partner is a small project.

Further reading

Related guides

Browse every guide in Integrations or just Data movement.

Was this helpful?

Signals which guides land and which need work. No account, no comment box — corrections go through the contact page.

Spot something wrong or want a topic covered? Send a correction or a topic request — both are welcome.