Do invoices flow from Tradeshift to IFS Cloud, or the other way around?

The primary flow is from Tradeshift into IFS Cloud. Supplier invoices, credit notes, and receipts received on the Tradeshift network are polled and posted into IFS Cloud's AP module. Purchase orders can also flow from IFS Cloud to Tradeshift for visibility to suppliers, and payment confirmation flows back to Tradeshift.

How does ml-connector handle the two different authentication methods?

Tradeshift uses OAuth 1.0a with two-legged signature generation; ml-connector computes the OAuth 1.0a signature header for each Tradeshift request and includes the required X-Tradeshift-TenantId header. IFS Cloud uses OAuth 2.0 Client Credentials; ml-connector obtains the bearer token and refreshes it before expiry (approximately 60 minutes), then includes it on OData API calls.

What happens if an invoice posting fails in IFS Cloud due to a missing cost center or GL account?

ml-connector returns an error and records the failure in the audit trail with the Tradeshift document ID and the IFS Cloud error code. Once the missing cost center or GL account is created in IFS Cloud, the posting can be replayed from the audit trail without re-reading from Tradeshift, so no documents are lost or duplicated.

IFS CloudTradeshift

IFS Cloud and Tradeshift integration

IFS Cloud is your ERP for manufacturing, finance, and procurement. Tradeshift is your B2B network for procuring and settling invoices with suppliers. Connecting the two ensures that supplier invoices received through Tradeshift flow into IFS Cloud's AP module without re-keying, purchase orders placed in IFS Cloud are visible to suppliers on the Tradeshift network, and your general ledger stays current with every invoice and credit note. ml-connector manages the very different document formats and authentication methods on each side and keeps your AP cycle automated.

How IFS Cloud works

IFS Cloud exposes supplier invoices, purchase orders, suppliers, GL accounts, and journal vouchers through OData v4 REST APIs over a tenant-specific base URL. Authentication uses OAuth 2.0 Client Credentials with a token lifetime of approximately 60 minutes. All mutation operations (PATCH, certain POST actions) require an OData ETag header captured from a prior read, enforcing optimistic concurrency control. IFS Cloud recommends keeping query result sets under 5000 elements per request, enforces a rate limit of approximately 1000 requests per minute per tenant, and requires company code configuration for almost every financial entity. There is no built-in webhook API, so invoices and purchase orders are read by polling with modified timestamp filters.

How Tradeshift works

Tradeshift exposes invoices, purchase orders, credit notes, receipts, and remittance advice as UBL 2.0/2.2 XML documents via REST HTTPS. Authentication uses OAuth 1.0a (two-legged for server-to-server integration) with consumer_key, consumer_secret, token, and token_secret per tenant, plus a required X-Tradeshift-TenantId header on every call. Documents are identified by documentProfileId and retrieved with a changedAfter timestamp filter for polling. Tradeshift offers a separate sandbox environment at https://sandbox.tradeshift.com with the same OAuth flow. Documents use UBL XML format with line items embedded; there is no separate GL account or dimension API.

What moves between them

The main flow is from Tradeshift into IFS Cloud. Invoices and credit notes received on the Tradeshift B2B network are polled by ml-connector with a changedAfter filter, parsed from UBL XML, mapped to IFS Cloud GL accounts and cost centers (or supplier invoice entities), and posted as posting proposals or journal entries. Purchase orders created in IFS Cloud can be queried and published to Tradeshift for visibility to suppliers. Remittance advice and payment confirmation flow from IFS Cloud back to Tradeshift to notify suppliers of settlement. The cycle runs on a schedule tied to your AP close calendar.

How ml-connector handles it

ml-connector generates OAuth 1.0a signatures for every Tradeshift request using the consumer and token credentials, and includes the X-Tradeshift-TenantId header on each call. Tradeshift documents arrive as UBL XML; ml-connector parses the line items, invoice header, and reference PO numbers, then queries IFS Cloud's OData API to resolve supplier codes, GL accounts, and cost centers. Before posting into IFS Cloud, it reads the target record (invoice, voucher, or posting proposal) to capture the ETag, then submits the PATCH or POST with that ETag to satisfy concurrency requirements. If the ETag has changed due to a competing update, IFS Cloud returns 412 Precondition Failed; ml-connector re-reads and retries. Tradeshift rate limits return HTTP 429; ml-connector backs off with exponential jitter and retries. Every document is tracked in the audit trail with its Tradeshift document ID and UBL metadata, so failed AP postings can be replayed once the downstream issue (missing cost center, GL account not found) is resolved.

A real-world example

A mid-market manufacturing company runs IFS Cloud for ERP and Tradeshift for procurement and supplier collaboration. Before the integration, the accounts payable team manually collected UBL invoices from Tradeshift, downloaded them as XML, and re-entered line items and coding into IFS Cloud's invoice entry module, a process that took one to two days per payable period and created keying errors. With IFS Cloud and Tradeshift connected, supplier invoices flow automatically from Tradeshift into IFS Cloud's AP module daily, coded to the correct cost centers and GL accounts based on the purchase order reference and supplier profile. The AP team now focuses on approval workflows and payment exceptions instead of data entry. Suppliers see their purchase orders on Tradeshift within minutes of issue, reducing time-to-order and supplier inquiry calls.

What you can do

Automatically post supplier invoices and credit notes from Tradeshift into IFS Cloud's AP module, mapped to the correct GL accounts and cost centers.
Sync purchase orders from IFS Cloud to Tradeshift so suppliers can acknowledge and track orders on the B2B network.
Parse UBL 2.0/2.2 XML documents from Tradeshift and validate GL account and cost center references in IFS Cloud before posting.
Handle OAuth 1.0a signature generation for Tradeshift requests and OAuth 2.0 token refresh for IFS Cloud OData API calls.
Track every invoice and credit note in the audit trail by Tradeshift document ID so failed postings can be retried after downstream issues are resolved.

Questions

Do invoices flow from Tradeshift to IFS Cloud, or the other way around?: The primary flow is from Tradeshift into IFS Cloud. Supplier invoices, credit notes, and receipts received on the Tradeshift network are polled and posted into IFS Cloud's AP module. Purchase orders can also flow from IFS Cloud to Tradeshift for visibility to suppliers, and payment confirmation flows back to Tradeshift.
How does ml-connector handle the two different authentication methods?: Tradeshift uses OAuth 1.0a with two-legged signature generation; ml-connector computes the OAuth 1.0a signature header for each Tradeshift request and includes the required X-Tradeshift-TenantId header. IFS Cloud uses OAuth 2.0 Client Credentials; ml-connector obtains the bearer token and refreshes it before expiry (approximately 60 minutes), then includes it on OData API calls.
What happens if an invoice posting fails in IFS Cloud due to a missing cost center or GL account?: ml-connector returns an error and records the failure in the audit trail with the Tradeshift document ID and the IFS Cloud error code. Once the missing cost center or GL account is created in IFS Cloud, the posting can be replayed from the audit trail without re-reading from Tradeshift, so no documents are lost or duplicated.

Connect IFS Cloud and Tradeshift

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started