Microsoft Dynamics 365 Business Central and Tradeshift integration

What moves between them

Inbound, ml-connector polls the Tradeshift inbox for new supplier invoices and credit notes, parses the UBL XML, and creates them in Microsoft Dynamics 365 Business Central as purchase invoice drafts mapped to the matching vendor, line items, and dimensions. Outbound, Business Central purchase orders are converted to UBL and sent to Tradeshift so suppliers receive them on the network, and vendor records flow the same direction so every document resolves to a real trading partner. Both directions run on a polling schedule you set. The general ledger and chart of accounts stay in Business Central, since Tradeshift has none, so ml-connector never writes ledger entries to Tradeshift.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Business Central side it requests an Entra ID OAuth 2.0 bearer token with the client-credentials grant, refreshes it before expiry, and builds the base URL from the stored environment name. On the Tradeshift side it signs each request with OAuth 1.0a HMAC-SHA1 and attaches the X-Tradeshift-TenantId header that Tradeshift rejects calls without. The core work is format translation: inbound Tradeshift documents are UBL XML and must be parsed into the JSON fields Business Central expects, while outbound purchase orders are converted from JSON to UBL before the PUT. Vendors are matched first so an inbound invoice attaches to an existing Business Central vendor rather than creating a duplicate. Created purchase invoices are drafts until the Microsoft.NAV.post action runs, so posting stays an explicit, auditable step. Neither system offers a usable push for this pair, so both are polled, Business Central with a lastModifiedDateTime filter and Tradeshift with changedAfter; Business Central purchase orders have no webhook at all. Idempotency comes from the caller-supplied UUID on Tradeshift PUTs and from deduping on the Business Central document number plus a BullMQ jobId, which prevents a re-read invoice from being booked twice. Each record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized contract manufacturer with around 400 staff runs Microsoft Dynamics 365 Business Central for finance and purchasing and is required by several large customers to trade through Tradeshift. Before the integration, an AP clerk opened each supplier invoice in the Tradeshift inbox, read the values off the screen, and keyed them into Business Central as a purchase invoice, which was slow and produced mismatched vendor names and the occasional transposed amount. Purchase orders raised in Business Central were also re-entered into Tradeshift by hand so suppliers could see them. With Microsoft Dynamics 365 Business Central and Tradeshift connected, inbound invoices arrive as draft purchase invoices attached to the right vendor within the polling window, and outbound purchase orders post to the network automatically. The clerk reviews and posts rather than retypes, and the two systems stay in agreement.

What you can do

• •Pull supplier invoices and credit notes from the Tradeshift inbox and create them as purchase invoice drafts in Microsoft Dynamics 365 Business Central.
• •Send Business Central purchase orders to Tradeshift as UBL documents so suppliers receive them on the network.
• •Match Tradeshift documents to existing Business Central vendors so inbound invoices attach without creating duplicates.
• •Bridge Entra ID OAuth 2.0 on the Business Central side and OAuth 1.0a signing plus the tenant header on the Tradeshift side, translating OData JSON and UBL XML each way.
• •Poll both systems on a schedule with UUID and document-number dedup, retries, and a full audit trail on every record.

Questions

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

It runs both ways. Supplier invoices and credit notes move from the Tradeshift inbox into Business Central as purchase invoice drafts, while purchase orders and vendor records move from Business Central out to Tradeshift. Tradeshift has no general ledger, so the chart of accounts stays in Business Central and ml-connector never writes ledger entries to Tradeshift.

How does the integration handle Tradeshift documents being UBL XML rather than JSON?

Tradeshift exchanges invoices, orders, and credit notes as UBL 2.0 and 2.2 XML, while Business Central uses OData JSON. ml-connector parses inbound UBL into the JSON fields Business Central expects and converts outbound purchase orders from JSON to UBL before sending them. The documentProfileId on each Tradeshift document tells the connector which document type and mapping to apply.

Do these systems push changes, or does ml-connector poll?

It polls both sides, because neither offers a usable push for this pair. Tradeshift has no traditional webhooks, so the connector reads the document list with a changedAfter timestamp, and Business Central purchase orders are not webhook-enabled, so they are read with a lastModifiedDateTime filter. Business Central webhooks elsewhere are change signals that carry no data and expire every three days, so polling is the reliable approach.