Microsoft Dynamics GP and Tradeshift integration

What moves between them

The main flow is Tradeshift into Microsoft Dynamics GP. Invoices and credit notes from Tradeshift are polled at a cadence tied to your invoice receipt window and written into GP as unposted Payables Invoices, mapped to GP vendors by the supplier's network identifier and allocated to GL accounts based on line-item UBL tags and your mapping table. Purchase orders can flow the opposite direction from GP into Tradeshift so suppliers on the network see the authoritative PO in both systems and can match it against their own received goods.

How ml-connector handles it

ml-connector stores the Windows domain credentials for GP and the OAuth 1.0a consumer key, secret, token, and token secret for Tradeshift in encrypted form. It translates the UBL 2.0/2.2 XML document structure from Tradeshift into GP's relational Payables Invoice schema, matching Tradeshift supplier identifiers to GP vendor numbers, and extracting line-item GL accounts from UBL coding segments or your preconfigured mapping. Because both systems require the caller to manage stateful document references (GP requires unique document numbers, Tradeshift requires unique identifiers), ml-connector tracks document state and avoids duplicate postings on retry. It polls Tradeshift on a schedule you define, validates that the GP fiscal period and GL accounts exist before writing, and surfaces any UBL parse errors or vendor lookup failures in the audit log so you can correct the source document or mapping before resubmitting.

A real-world example

A mid-sized manufacturing company sources raw materials from a global supplier network connected through Tradeshift, and uses Microsoft Dynamics GP for on-premises payables and GL accounting. Before the integration, the AP team received supplier invoices through Tradeshift, downloaded them as PDF or XML files, manually re-keyed the vendor name, amount, and GL account into GP, and then manually verified the invoice was paid. The payables aging report in GP fell days behind the reality of what had been invoiced in Tradeshift, and disputes over invoice status required the AP team to check two systems. With Tradeshift and GP connected, each supplier invoice from the network appears as an unposted invoice in GP within minutes, pre-populated with the vendor, amount, and GL accounts from Tradeshift and your mapping table. The AP team reviews and posts it in GP with a single click, and the payables aging is always current.

What you can do

• •Read invoices and credit notes from Tradeshift and write them into Microsoft Dynamics GP as unposted Payables Invoices with vendor and GL account mapping.
• •Match Tradeshift suppliers to Microsoft Dynamics GP vendor numbers using the supplier's network identifier and a configurable lookup table.
• •Extract GL account and cost center allocation from UBL line-item details and your preconfigured mapping rules.
• •Bridge Microsoft Dynamics GP's Windows domain authentication with Tradeshift's OAuth 1.0a server-to-server credentials, storing both encrypted.
• •Poll Tradeshift on a schedule tied to your invoice receipt cycle, validate fiscal periods and GL accounts exist in GP before posting, and replay failed documents via the audit log.

Questions

What is the direction of data flow between Microsoft Dynamics GP and Tradeshift?

The primary flow is Tradeshift into Microsoft Dynamics GP. Invoices and credit notes from Tradeshift are polled and written into GP as unposted Payables Invoices, mapped to the correct vendors and GL accounts. Purchase orders can also flow from GP back to Tradeshift so suppliers on the network see the authoritative record in both systems.

How does ml-connector handle the difference between GP's relational schema and Tradeshift's XML document format?

ml-connector parses the UBL 2.0/2.2 XML structure from Tradeshift and maps it into GP's Payables Invoice schema. Supplier identifiers are matched to GP vendors, and line-item GL accounts are extracted from UBL coding segments or your preconfigured mapping table. If a vendor or GL account is not found, the document is logged for review rather than failing silently.

What happens when a Microsoft Dynamics GP fiscal period is closed or a GL account is invalid?

ml-connector validates the GL account and fiscal period before attempting to write an invoice into GP. If either is invalid or closed, the document is flagged in the audit log with the specific validation error, so you can correct the mapping or open the fiscal period and resubmit without losing the document.