Xero and Tradeshift integration

What moves between them

The main flow runs from Tradeshift into Xero. ml-connector polls Tradeshift on a schedule tied to your supplier invoice receipt rhythm, reading newly received invoices and purchase orders in UBL format, then mapping supplier contacts and GL accounts to matching Xero entities before posting the transactions into Xero's accounting ledger. Invoices and purchase orders move one direction only, as Xero is the source of truth for your accounting records.

How ml-connector handles it

ml-connector signs every Tradeshift API request with OAuth 1.0a signature (HMAC-SHA1) using the consumer key, consumer secret, token, and token secret stored encrypted per customer. On the Xero side it refreshes the OAuth2 access token before each request and respects the 60-per-minute rate limit with exponential backoff. It parses the UBL XML documents from Tradeshift, maps supplier network IDs to Xero contact records by name match or stored mapping, identifies the GL account from the line item description, and creates matching invoice or purchase order records in Xero with all line items and tax detail intact. Every Tradeshift document carries a unique document ID that ml-connector stores to prevent duplicate posts if a polling cycle overlaps. If a Xero POST fails due to a missing contact or GL account, the record is held in the audit trail for manual review and retry once the mapping is fixed.

A real-world example

A mid-market distributor runs Xero for accounting and uses Tradeshift to connect with suppliers across multiple regions. Before the integration, the accounts payable team received supplier invoices on Tradeshift, exported them as PDF or XML, manually entered the invoice date, amount, and GL account coding into Xero by hand, and then matched them against purchase orders days later. With Xero and Tradeshift connected, invoices arrive from suppliers on Tradeshift, ml-connector automatically posts them to Xero with the correct GL codes based on stored mappings, and the reconciliation step is nearly eliminated. The team now spends time on exceptions and early payment discounts instead of data re-entry.

What you can do

• •Post supplier invoices from Tradeshift into Xero with full GL account and contact mapping, no re-entry required.
• •Sync purchase orders between Xero and Tradeshift to keep procurement and accounting in agreement.
• •Map Tradeshift supplier network IDs and UBL line items to Xero contacts and GL accounts using configurable rules.
• •Authenticate Tradeshift with OAuth 1.0a HMAC-SHA1 signatures and Xero with OAuth2 tokens, refreshing as needed.
• •Poll Tradeshift on a schedule aligned with your invoice receipt cadence, with duplicate prevention and a full audit trail.

Questions

Which direction do invoices and purchase orders flow between Xero and Tradeshift?

Invoices and purchase orders flow from Tradeshift into Xero. Suppliers send documents through the Tradeshift network, ml-connector pulls them, maps them to Xero contacts and GL accounts, and posts them into Xero's ledger. Xero is the source of truth for accounting records, so ml-connector does not write back to Tradeshift.

How does ml-connector handle Tradeshift's UBL XML format and Xero's REST API?

ml-connector parses the UBL 2.0/2.2 XML documents from Tradeshift, extracting supplier, line items, and amounts, then maps those to Xero's contact and account structure before converting to REST JSON for posting. The mapping is configurable per customer so custom GL account hierarchies and supplier naming conventions are respected.

What happens if a supplier contact or GL account does not exist in Xero when an invoice arrives?

ml-connector holds the invoice record in the audit trail with a status indicating a missing mapping. The AP team can then add the contact or GL account to Xero and trigger a retry through the ml-connector dashboard, or update the mapping rule for future invoices from that supplier.