Microsoft Dynamics 365 Business Central and IBM Sterling integration

What moves between them

Documents move in both directions. From Business Central, ml-connector reads posted sales invoices and sales order acknowledgments and builds the matching 810 invoice and 855 acknowledgment EDI documents, then creates a Sterling document and a mailbox message so Sterling can translate and deliver them to the trading partner. Inbound, ml-connector polls Sterling mailboxes for 850 purchase orders and 820 remittance advice that partners send, extracts the payload, and writes purchase orders and payment records into Business Central. Vendor and customer master data and items are read from Business Central to resolve partner identifiers. The cadence is a scheduled poll on each side, tied to how often partners exchange files.

How ml-connector handles it

ml-connector stores both credential sets encrypted and runs two auth paths at once: an Entra ID OAuth2 client-credentials token for Business Central, refreshed when a call returns 401, and Basic or OAuth2 against the customer Sterling Liberty host and port, which must be supplied because there is no shared Sterling URL and the API account cannot be a super-user. Sales invoices and orders are read from Business Central using an OData lastModifiedDateTime filter for delta sync, since purchaseOrders raise no webhook and Business Central notifications carry no payload. Outbound documents follow the Sterling two-step contract: a document is POSTed first to get a documentId, then a mailbox message references it, because the EDI content cannot be inlined. Inbound files are found by polling the mailbox messages API by path and extracting the payload, then mapped from partner identifiers to Business Central vendor and customer numbers. Business Central rate limits return HTTP 429 and Sterling throttling is set by the Liberty JVM, so ml-connector backs off and retries, dedupes on documentId and document number, and keeps a full audit trail with replay on any failed post.

A real-world example

A mid-sized consumer goods supplier with around three hundred staff runs Microsoft Dynamics 365 Business Central for finance, purchasing, and sales, and uses IBM Sterling to trade EDI with the large retailers it ships to. Before the integration, a coordinator exported each retailer order from Sterling and keyed it into Business Central as a sales order, then re-typed the posted invoice back into Sterling as an 810 by hand, which was slow and caused chargebacks when totals did not match. With Business Central and Sterling connected, inbound 850 orders land as Business Central sales orders automatically and posted invoices flow out as 810 documents through the right mailbox, so the manual re-keying and the mismatch chargebacks are gone.

What you can do

• •Turn posted Business Central sales invoices into outbound 810 EDI documents routed through Sterling mailboxes.
• •Write inbound 850 purchase orders and 820 remittance from Sterling mailboxes back into Business Central.
• •Bridge Entra ID OAuth2 for Business Central with Sterling Basic or OAuth2 against your Liberty host and port.
• •Poll both sides on a schedule, since Business Central notifications carry no payload and Sterling has no webhooks.
• •Dedupe on document identifiers and keep a full audit trail with replay on every record.

Questions

Which direction does data move between Microsoft Dynamics 365 Business Central and IBM Sterling?

Both directions. Posted sales invoices and order acknowledgments leave Business Central as 810 and 855 EDI documents through Sterling mailboxes, and inbound 850 purchase orders and 820 remittance from partners are written back into Business Central. Master data such as vendors, customers, and items is read from Business Central to resolve partner identifiers.

Why does the integration poll instead of using webhooks?

IBM Sterling has no outbound webhooks at the REST layer, so new mailbox files are found by polling. Business Central does support change subscriptions, but a notification carries only a change signal and not the data, expires after three days, and is never raised for purchaseOrders. ml-connector therefore reads both sides on a schedule using an OData lastModifiedDateTime filter for delta sync.

What does IBM Sterling need on its side to connect?

Because Sterling runs on the customer host rather than a shared cloud URL, ml-connector needs the Liberty host and HTTPS port plus a dedicated API account that is not a super-user, since super-user accounts are rejected by the REST API. Network access through a VPN or firewall is usually required. Uploading an EDI payload also follows the two-step pattern of creating a document first, then a mailbox message that references its documentId.