Microsoft Dynamics NAV and Cleo integration

What moves between them

The main flow is NAV to Cleo (outbound). Purchase orders and purchase invoices created in NAV are read via OData polling and translated into EDI 850 (PO) and 810 (invoice) documents, then written to Cleo's REST API where they are queued for transmission to suppliers. Inbound EDI from suppliers (856 shipment notices, 810 invoices, 820 payment remittances) is polled from Cleo's REST folders, parsed, and posted back into NAV as purchase receipts and vendor invoices, mapped to the correct vendor and item dimensions. The sync runs on a schedule that aligns with procurement cycles (typically daily for order transmission, every 4 hours for inbound receipts).

How ml-connector handles it

ml-connector stores NAV tenant URL, Entra ID credentials, and Cleo OAuth username/password encrypted, and refreshes the Cleo Bearer token before expiry. On the NAV side it uses OData polling to read purchase orders and invoices, since NAV webhooks for purchase orders are not in the standard push list. For Cleo, it polls the REST API on a fixed schedule to watch for inbound EDI files from partners. The translation layer maps NAV vendors and items to Cleo trading partners and product codes via a lookup table maintained in the NAV dimensions system, and converts NAV purchase order fields (item, qty, date, vendor) into EDI 850 format that Cleo understands. Inbound EDI is parsed (OCR if PDF-based, structured if JSON/XML), matched to NAV vendors and items via the same lookup, and posted as purchase receipts via NAV's OData journals endpoint, creating the matching GL postings. Every EDI document carries a Cleo transmission ID and NAV journal ID in an audit table, so a failed inbound receipt can be replayed without duplication.

A real-world example

A mid-market food distributor runs Microsoft Dynamics NAV for procurement, warehouse, and finance. The company sources from 50+ suppliers and ships to 200+ retail locations. Before the integration, purchase orders were created in NAV, then manually exported and emailed as PDF or EDI 850 to suppliers, and inbound shipment notices from suppliers arrived as EDI 856 documents that had to be manually re-keyed into NAV's goods receipt journal. With Cleo and NAV connected, every PO created in NAV is automatically translated to EDI 850 and transmitted to the supplier through Cleo in real time. When the supplier ships, their 856 is pulled from Cleo and posted as a NAV goods receipt in the same warehouse batch, triggering the item receipt and the matching payable automatically. Month-end invoice reconciliation is complete because every supplier invoice EDI has been posted to NAV the day it arrived.

What you can do

• •Translate purchase orders from Microsoft Dynamics NAV into EDI 850 transactions and route them through Cleo Integration Cloud to suppliers.
• •Parse inbound EDI 856 shipment notices and 810 vendor invoices from Cleo and post them as purchase receipts and vendor bills into NAV.
• •Map NAV vendors and items to Cleo trading partners and product codes using NAV's dimensions system.
• •Authenticate NAV with OAuth 2.0 via Microsoft Entra ID and Cleo with OAuth 2.0 password grant, refreshing tokens automatically.
• •Poll NAV and Cleo on a procurement schedule with a full audit trail on every EDI document and NAV journal entry.

Questions

Which direction does data move between Microsoft Dynamics NAV and Cleo?

The primary flow is NAV to Cleo: purchase orders and invoices from NAV are translated into EDI and sent to suppliers via Cleo. The return flow is Cleo to NAV: inbound EDI shipment notices and vendor invoices are parsed and posted as NAV purchase receipts and bills. Reference data like vendors and items are mapped in both directions using NAV dimensions.

How does the integration handle NAV's OData webhooks if they expire after 3 days?

ml-connector uses polling instead of relying on NAV webhooks for purchase orders, since purchase orders are not in NAV's standard webhook entity list. For other entities like purchase invoices, ml-connector can use either polling or webhook renewal logic, but polling is more reliable and does not require managing subscription expiry.

What does the audit trail track for EDI documents?

Every EDI document (inbound or outbound) is logged with its Cleo transmission ID, the NAV source record (PO, invoice, or receipt), the mapping used (vendor and item lookup), and any transformation errors. If an inbound receipt fails to post to NAV due to a missing item or vendor, the document is quarantined and can be replayed once the dimension is added.