Microsoft Dynamics NAV and IBM Sterling integration

What moves between them

EDI purchase orders and invoices arrive in IBM Sterling from trading partners via AS2, SFTP, or FTP. ml-connector polls IBM Sterling's mailbox messages on a schedule (typically every 5 minutes), extracts the EDI documents, parses the PO and invoice line items, and posts them into Microsoft Dynamics NAV as purchase orders and purchase invoices. The documents map to NAV vendors by EDI sender ID and to GL accounts by cost center dimension. If EDI remittance or ASN documents arrive, they can be processed into NAV's receipts and payments. No data flows outbound to IBM Sterling from NAV in this configuration, though the integration can be extended to translate NAV sales orders into EDI 850 POs for transmission to customers.

How ml-connector handles it

ml-connector maintains separate OAuth 2.0 sessions to both systems. For NAV, it uses client credentials against Microsoft Entra ID and caches the bearer token per tenant to minimize auth round-trips. For IBM Sterling, it authenticates with the provided host, port, and Basic Auth credentials and polls GET /B2BAPIs/svc/mailboxMessages/ on a schedule. When new EDI documents appear, ml-connector extracts the payload, validates the EDI syntax and trading partner agreement, parses the X12 850 (PO) or 810 (invoice) segments into structured data, and posts into NAV via OData. It validates that each vendor EDI sender ID maps to an existing NAV vendor and that cost centers match NAV dimension values before posting. If validation fails, the document is logged for manual review and not posted to NAV. IBM Sterling's API requires a non-admin user account, and ml-connector verifies this upfront. Because IBM Sterling is on-premises or customer-managed, ml-connector requires network access (VPN or DMZ routing) to the B2Bi host. Retries use exponential backoff if IBM Sterling returns 429 (rate limit) or 5xx errors. Every document carries a full audit trail showing the original EDI, the parsed fields, the mapping decisions, and the NAV posting result.

A real-world example

A mid-sized discrete manufacturer in the automotive supply chain receives purchase orders and invoices from suppliers via EDI through IBM Sterling. The company runs Microsoft Dynamics NAV for procurement, inventory, and accounts payable. Before the integration, the procurement team received EDI files in IBM Sterling, manually extracted the line items, and re-entered them into NAV, a process that took 30 minutes per supplier file and introduced errors when item numbers, quantities, or unit prices mismatched. With the integration, EDI purchase orders and invoices flow from IBM Sterling directly into NAV purchase and GL transactions, mapped to the correct vendors and GL accounts by cost center. The manual re-entry step is eliminated, purchase-to-pay matching is faster, and supplier discrepancies are caught at the data boundary instead of at payment time.

What you can do

• •Extract EDI purchase orders and invoices from IBM Sterling mailbox messages and post them into Microsoft Dynamics NAV as purchase orders and purchase invoices.
• •Map EDI sender IDs to NAV vendors and validate cost center dimensions before posting, rejecting invalid documents for manual review.
• •Validate EDI syntax and trading partner agreements within IBM Sterling before parsing data for NAV.
• •Authenticate NAV via OAuth 2.0 against Microsoft Entra ID and IBM Sterling via Basic Auth or OAuth 2.0 to the customer-managed host and port.
• •Poll IBM Sterling on a schedule with exponential backoff retries and maintain a full audit trail of every EDI document, its translation, and its NAV posting outcome.

Questions

Why does the integration poll IBM Sterling instead of receiving webhooks?

IBM Sterling B2B Integrator does not support outbound webhooks. ml-connector polls the mailbox messages endpoint every 5 minutes (configurable) to detect new EDI documents. This is a common pattern for on-premises B2B platforms and ensures no messages are missed.

What happens if an EDI purchase order fails to map to a NAV vendor or cost center?

ml-connector validates that the EDI sender ID matches an existing NAV vendor and that the cost center dimension exists before posting. If either validation fails, the document is not posted to NAV, logged for manual review, and an alert is sent. This prevents orphaned or incorrectly routed transactions in your GL.

Do purchase orders need to be manually matched in NAV after they are posted?

No. ml-connector posts the purchase order directly into NAV with all line items, item numbers, quantities, and unit prices from the EDI source. NAV receives a fully formed document that can be used immediately for receipt matching and three-way invoice matching without re-keying.