Deltek and Tradeshift integration

What moves between them

The inbound flow runs from Tradeshift into Deltek. ml-connector polls the Tradeshift inbox for new supplier invoices and credit notes, reads each UBL XML document, and posts it as a Deltek AP invoice record mapped to the matching vendor firm, project, and GL account. The outbound flow runs from Deltek into Tradeshift: purchase orders and vendor firm records move out to suppliers as UBL XML order documents, so partners on the network have current order and supplier data. Vendor and trading-partner identities are aligned in both directions so every invoice resolves to a valid Deltek firm. Cadence follows your AP cycle, typically every few minutes to a few times a day.

How ml-connector handles it

ml-connector stores both credential sets encrypted and bridges two unlike auth schemes: it runs the Deltek OAuth 2.0 password grant and refreshes the bearer token when a call returns 401, while signing every Tradeshift request with OAuth 1.0a and attaching the required X-Tradeshift-TenantId header. It accepts the full Deltek tenant URL per customer because Deltek publishes no shared base address. The hard part is format translation: Tradeshift documents are UBL XML, so ml-connector parses fields like the invoice ID, issue date, monetary totals, lines, and supplier party out of UBL and maps them onto Deltek AP invoice fields, and builds UBL order documents from Deltek purchase orders for the outbound direction. Because neither side offers plain webhooks, it polls the Tradeshift inbox using a changedAfter timestamp and polls Deltek on the same schedule. Suppliers are matched first, by tax id or name, so each invoice lands on an existing Deltek firm. Tradeshift writes use a caller-supplied UUID as the idempotency key to prevent duplicates, and because Deltek has no idempotency header, ml-connector checks for an existing invoice number before posting. Where the Vantagepoint instance routes AP invoices through an approval workflow, invoices are created in the expected draft or posted state. Rate limits trigger backoff and retry, and every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A regional architecture and engineering firm with about 300 staff runs Deltek Vantagepoint for project accounting and asks its subcontractors and material vendors to bill through Tradeshift. Before the integration, an AP clerk opened each supplier invoice in Tradeshift, then keyed the vendor, amount, project, and GL account into Deltek by hand, which was slow and produced posting errors that surfaced during month-end close. With Deltek and Tradeshift connected, each invoice that arrives in the Tradeshift inbox is read from its UBL document and posted into Deltek against the right vendor firm and project automatically, and purchase orders raised in Deltek are delivered to suppliers on the network. The clerk reviews exceptions instead of typing every invoice, and close starts with AP already reconciled.

What you can do

• •Convert supplier invoices and credit notes from Tradeshift UBL XML into Deltek AP invoice records against the right vendor and project.
• •Push purchase orders and vendor firm records from Deltek out to suppliers on the Tradeshift network.
• •Match suppliers across both systems by tax id or name so every invoice lands on a valid Deltek firm.
• •Bridge Deltek OAuth 2.0 with the signed OAuth 1.0a and tenant id header that Tradeshift requires.
• •Poll the Tradeshift inbox on your AP schedule, with duplicate checks, retries, and a full audit trail on every record.

Questions

Which direction does data move between Deltek and Tradeshift?

The main flow is Tradeshift into Deltek, where supplier invoices and credit notes from the Tradeshift inbox become Deltek AP invoice records. Purchase orders and vendor records move the other way, from Deltek out to suppliers on Tradeshift. Vendor and trading-partner identities are aligned in both directions so each invoice resolves to a valid Deltek firm.

How does the integration handle Tradeshift UBL XML and the OAuth difference?

Tradeshift sends and receives documents as UBL 2.0 and 2.2 XML, not JSON, so ml-connector parses the UBL fields and maps them onto Deltek AP invoice fields, and builds UBL order documents for the outbound flow. It also bridges the two auth schemes, running Deltek OAuth 2.0 while signing every Tradeshift call with OAuth 1.0a and attaching the required tenant id header.

How are new invoices detected without webhooks, and how are duplicates avoided?

Neither side offers plain outbound webhooks, so ml-connector polls the Tradeshift inbox using a changedAfter timestamp and polls Deltek on the same schedule tied to your AP cycle. Duplicates are prevented by writing Tradeshift documents under a caller-supplied UUID and, because Deltek has no idempotency header, by checking for an existing invoice number before posting into Deltek.