Odoo and Tradeshift integration

What moves between them

Purchase orders in Odoo flow into Tradeshift as UBL invoice documents, sent once at creation and updated if Odoo changes the PO. Invoices received in Tradeshift flow back into Odoo as account.move records in the AP module, matched against the originating purchase order. Vendor masters (res.partner) are synchronized from Odoo to Tradeshift to ensure supplier identities match at the document level. The sync runs on a schedule tied to your AP close cycle rather than real-time, with high-water-mark timestamps on both sides to track what has and has not been processed.

How ml-connector handles it

ml-connector stores Odoo's API key encrypted and uses either XML-RPC or JSON-2 (depending on your Odoo version) to poll purchase orders and invoice payment status. For Tradeshift, it manages OAuth 1.0a credentials (consumer_key, consumer_secret, token, token_secret) and constructs the signed Authorization header required by the two-legged flow. When a PO in Odoo is ready to send, ml-connector translates it to UBL 2.0 format with all line items, amounts, delivery address, and payment terms, then POSTs it to Tradeshift tagged with your tenant_id. Incoming Tradeshift invoices are retrieved via the changedAfter filter, decoded from UBL XML, and created in Odoo as AP invoices linked to the matching PO via purchase.order.name or vendor invoice number. Because Odoo line items and UBL line items have different schemas, ml-connector maps Odoo account.move.line (cost center, GL account, tax) to UBL invoice line extensions. All records carry timestamps so both systems remember what was last processed, preventing rework and duplicates.

A real-world example

A mid-sized distribution company runs Odoo for procurement and accounting, and trades with suppliers who are also on the Tradeshift network. Previously, POs were created in Odoo and then manually entered or exported to Tradeshift so suppliers could see them, and incoming supplier invoices from Tradeshift were printed and manually re-entered into Odoo's AP, a common source of late-payment errors and duplicate record problems. With Odoo and Tradeshift integrated, POs automatically appear in Tradeshift the moment they are confirmed in Odoo, and supplier invoices flow back into Odoo's AP module automatically, matched to their originating POs and ready for approval and payment without re-keying.

What you can do

• •Publish Odoo purchase orders to Tradeshift as UBL invoices, and keep suppliers aligned as POs change.
• •Receive Tradeshift invoices back into Odoo as AP invoices, linked to their matching purchase orders.
• •Map Odoo GL accounts and cost centers to UBL line item extensions so invoices land on the correct expenses.
• •Authenticate Odoo with API keys and Tradeshift with OAuth 1.0a, managing both credential sets encrypted.
• •Poll both systems on a schedule with timestamp tracking and a full audit trail on every document conversion.

Questions

Why does ml-connector use polling instead of webhooks?

Odoo does not offer a production-grade webhook system for external integrations; webhooks require Enterprise + Studio or developer mode. Tradeshift also uses polling as the primary integration pattern. ml-connector polls both systems on a schedule aligned with your AP and procurement cycles, using write_date and changedAfter timestamps to fetch only new or changed records.

How does the integration handle UBL document format conversion?

ml-connector translates Odoo purchase orders into valid UBL 2.0 invoice documents with all required elements: supplier and buyer identifiers, line items with amounts and tax, delivery address, and payment terms. When invoices arrive from Tradeshift, ml-connector decodes the UBL XML and maps line extensions (GL account, cost center) back into Odoo's account.move.line structure so the AP invoice lands on the correct ledger accounts.

What happens if a PO is updated in Odoo after it has been sent to Tradeshift?

ml-connector tracks the last successful sync timestamp on each PO. If a PO is modified after the initial send, ml-connector detects the change on the next polling cycle and sends an updated UBL document to Tradeshift. Invoices already received against the original PO remain linked by vendor invoice number and PO reference, preventing duplicate invoicing.