How does ml-connector handle EDI trading partner codes that do not match any NAV vendor?

When an inbound EDI document names a trading partner code that is not found in NAV's vendor master, ml-connector logs the record with full context (transaction ID, EDI sender, line items) and holds it in a failed-records queue. An operator reviews the queue, adds the missing vendor to NAV, and replays the transaction from ml-connector's audit log.

Does ml-connector need to handle NAV's 3-day webhook subscription expiry?

NAV webhook subscriptions expire after 3 days and must be renewed before expiry. Because NAV does not include purchase orders in its standard webhook entity list, ml-connector polls the purchase order endpoint on your schedule instead, avoiding the renewal overhead. Invoices are available via webhook, but polling on a unified schedule simplifies the architecture.

What happens if an EDI line item code does not match any NAV item?

ml-connector checks the item code against NAV's item master before posting. If the item is not found, the line is logged with the trading partner, PO number, and item code, and the transaction is held for review. Once the item is added to NAV, the transaction is replayed automatically via ml-connector's audit trail.

Microsoft Dynamics NAVStedi

Microsoft Dynamics NAV and Stedi integration

Small and mid-size manufacturers and distributors use Microsoft Dynamics NAV for procurement and finance, and rely on EDI to receive orders and invoices from trading partners via Stedi. Translating EDI into NAV by hand creates manual entry delays and invoice matching errors. With Microsoft Dynamics NAV and Stedi connected, inbound purchase orders and invoices flow automatically from your trading partners into NAV's journals, matched to the correct vendors and line items, so your procurement pipeline moves without re-keying and your accounts payable closes faster.

How Microsoft Dynamics NAV works

Microsoft Dynamics NAV (Business Central online or on-premises) exposes purchase orders, purchase invoices, vendors, customers, items, accounts, dimensions, and general ledger entries through OData v4 REST or legacy SOAP web services, with a tenant-specific base URL. Authentication uses OAuth 2.0 client credentials via Microsoft Entra ID for Business Central online, or Basic auth with a web service access key for legacy on-premises deployments. NAV supports both webhooks (3-day subscription expiry, ~30-second batching) and polling, though purchase orders are not in the standard webhook entity list. GL accounts are read-only in the standard API, and all posted GL entries are immutable.

How Stedi works

Stedi is an EDI translation platform that parses inbound X12 documents (850 Purchase Orders, 810 Invoices, 856 Advance Shipment Notices) from trading partners via SFTP, FTPS, or AS2 and converts them to JSON. Stedi exposes a REST API authenticated with a static API Key in the Authorization header (no OAuth, no expiry). Outbound API writes require an Idempotency-Key header for 24-hour deduplication, and webhook endpoints must respond within 5 seconds. Stedi is a translation platform, not a system of record; it does not store vendors or invoices itself.

What moves between them

Inbound EDI documents (primarily 850 Purchase Orders and 810 Invoices) flow from Stedi into Microsoft Dynamics NAV. ml-connector subscribes to Stedi's transaction.processed webhook, receives the parsed JSON for each EDI transaction, maps the trading partner code to a NAV vendor, maps line items to NAV inventory items, and posts the transaction as a purchase order or vendor invoice into NAV's purchase journal on a configurable schedule. The flow is one-directional (Stedi to NAV); NAV does not send data back to Stedi.

How ml-connector handles it

ml-connector stores both the Stedi API Key and NAV's OAuth 2.0 client credentials encrypted, refreshes NAV's bearer token when needed, and renews the OAuth 2.0 token before expiry. On the Stedi side, it attaches an Idempotency-Key to every write request so duplicate webhook deliveries do not create duplicate NAV invoices. Before posting to NAV, it queries the vendor master to find the NAV vendor code that matches the EDI sender, and queries the item master to map EDI line item codes to NAV items. If a vendor or item is not found, the transaction is logged with full context and held in a failed-records queue for manual review. NAV webhooks for purchase orders are not available (they are outside the standard webhook entity list), so ml-connector polls NAV's purchase order endpoint on your schedule. Every record carries a full audit trail and can be replayed if a downstream journal post fails.

A real-world example

A mid-sized distributor receives purchase orders and invoices from 40+ trading partners via EDI in X12 format. The partners route documents through a Stedi account, which translates them to JSON. Before the integration, a data entry clerk downloaded EDI files from Stedi, manually mapped trading partner codes to NAV vendor numbers, looked up item codes in a spreadsheet, and typed invoice line items into NAV's purchase journal every morning. With Microsoft Dynamics NAV and Stedi connected, each inbound order and invoice is translated to JSON by Stedi, automatically mapped to the correct vendor and items in NAV, and posted to the purchase journal overnight. The data entry role shifts from manual entry to exception handling (only vendor or item mismatches require review), and invoice-to-PO matching is faster because vendors and line items already exist in the NAV master.

What you can do

Translate Stedi's parsed EDI 850 Purchase Orders and 810 Invoices into NAV purchase orders and vendor invoices.
Map trading partner EDI codes to Microsoft Dynamics NAV vendor master records.
Map EDI line item product codes to NAV inventory items, respecting NAV item dimensions and units of measure.
Authenticate Stedi with API Key and Microsoft Dynamics NAV with OAuth 2.0 client credentials, handling token refresh and Stedi's Idempotency-Key deduplication.
Poll NAV on a schedule and queue failed vendor or item mappings for manual review, with full audit and replay capability.

Questions

How does ml-connector handle EDI trading partner codes that do not match any NAV vendor?: When an inbound EDI document names a trading partner code that is not found in NAV's vendor master, ml-connector logs the record with full context (transaction ID, EDI sender, line items) and holds it in a failed-records queue. An operator reviews the queue, adds the missing vendor to NAV, and replays the transaction from ml-connector's audit log.
Does ml-connector need to handle NAV's 3-day webhook subscription expiry?: NAV webhook subscriptions expire after 3 days and must be renewed before expiry. Because NAV does not include purchase orders in its standard webhook entity list, ml-connector polls the purchase order endpoint on your schedule instead, avoiding the renewal overhead. Invoices are available via webhook, but polling on a unified schedule simplifies the architecture.
What happens if an EDI line item code does not match any NAV item?: ml-connector checks the item code against NAV's item master before posting. If the item is not found, the line is logged with the trading partner, PO number, and item code, and the transaction is held for review. Once the item is added to NAV, the transaction is replayed automatically via ml-connector's audit trail.

Connect Microsoft Dynamics NAV and Stedi

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started