Microsoft Dynamics NAV and Tradeshift integration

What moves between them

The main flow runs from Tradeshift into Microsoft Dynamics NAV. ml-connector polls Tradeshift for newly changed invoices and credit notes, parses the UBL 2.0 XML, and creates vendor invoice records in NAV linked to the corresponding suppliers and purchase orders. GL postings flow automatically into NAV's general ledger, allocated to the cost centers specified in the document line items. Supplier and cost center reference data sync in both directions to keep the two systems aligned. Because NAV's GL is write-only for posted entries, ml-connector never writes financial entries back to Tradeshift.

How ml-connector handles it

ml-connector stores OAuth credentials for both systems encrypted and refreshes them when either returns a 401. On the Tradeshift side it polls with a changedAfter timestamp to fetch only newly changed documents since the last run, avoiding redundant API calls. UBL XML documents are parsed line by line; each line maps to a NAV vendor invoice line with the corresponding GL account, cost center, and amount. Supplier profiles from Tradeshift are matched against NAV vendor codes using a configurable lookup field so invoices land on the correct vendor. Cost centers embedded in the UBL document are validated against NAV's dimension table before GL posting begins. If a GL entry fails to post (due to a missing cost center, locked period, or closed GL account), ml-connector marks the record for replay so it can be retried once the blocking condition is fixed. The full audit trail is kept in both systems and can be queried to trace any invoice from arrival in Tradeshift through posting in NAV.

A real-world example

A mid-sized manufacturing company buys from dozens of suppliers on the Tradeshift network and receives invoices electronically in UBL format. Before the integration, the AP team downloaded invoices from Tradeshift, manually re-entered invoice details into Dynamics NAV, and then posted GL entries to the correct cost centers and departments. Month-end close required chasing variances between what was received and what had actually posted. With Microsoft Dynamics NAV and Tradeshift connected, each invoice arrives from the network and automatically becomes a NAV vendor invoice matched to the right PO and supplier, and GL posting happens on schedule without manual intervention. The AP team now spends its time on vendor disputes and cash flow rather than data entry.

What you can do

• •Pull invoices and credit notes from Tradeshift, parse the UBL XML, and create vendor invoices in Dynamics NAV matched to suppliers and purchase orders.
• •Post invoice GL entries into NAV's general ledger allocated to the correct cost centers and expense accounts.
• •Keep supplier and cost center reference data synchronized between Tradeshift and NAV in both directions.
• •Authenticate Tradeshift with OAuth 1.0a and Dynamics NAV with OAuth 2.0, refreshing credentials and handling rate limits on both sides.
• •Audit every invoice from arrival through GL posting and replay failed GL entries if downstream posting failures occur.

Questions

How does ml-connector handle the difference between Tradeshift's UBL XML documents and Dynamics NAV's OData vendor invoice structure?

ml-connector parses the UBL 2.0 and 2.2 XML from Tradeshift line by line and maps each line item to a NAV vendor invoice line with the corresponding GL account, amount, and tax. Supplier profiles are matched using configurable lookup fields so each invoice links to the correct vendor record in NAV. Cost centers embedded in the UBL are validated against NAV dimensions before posting.

What happens if a Dynamics NAV GL posting fails after an invoice arrives from Tradeshift?

ml-connector tracks the posting failure, records the reason in the audit trail, and marks the record for replay. Once the blocking condition is fixed (for example, a cost center is created, a GL period is reopened, or an account is unlocked), the record can be retried and the GL entry will post correctly. The full chain from invoice arrival through successful posting is logged for reconciliation.

Does ml-connector require both systems to support webhooks, or can it poll instead?

Tradeshift provides only polling (no traditional webhooks), and ml-connector polls with a changedAfter timestamp to fetch newly changed documents on a schedule you control. Microsoft Dynamics NAV supports webhooks for many entities, but because Tradeshift cannot push notifications, ml-connector polls NAV for supplier and dimension updates as needed to keep reference data in sync.