QAD and Tradeshift integration

What moves between them

The main flow runs from Tradeshift into QAD. ml-connector polls the Tradeshift inbox for new and changed supplier invoices and credit notes, parses each UBL XML document, and posts it into QAD as a supplier invoice or credit, matched against the QAD purchase order and goods receipt it references. In the other direction, QAD purchase orders are sent to Tradeshift as UBL order documents so suppliers see the same orders on the network. Trading partner records on Tradeshift are aligned with QAD suppliers so each inbound invoice maps to a known supplier. Cadence is a polling schedule you set, since neither QAD cloud nor a server-side Tradeshift connector offers a simple push.

How ml-connector handles it

ml-connector stores both credential sets encrypted and signs every Tradeshift request with OAuth 1.0a using a proper signing library rather than hand-rolled code, attaching the X-Tradeshift-TenantId header on each call. On the QAD side it accepts the full tenant URL per customer, since QAD publishes no shared base address, and validates entity paths against that instance. Inbound supplier invoices and credit notes arrive as UBL XML, so the connector parses fields such as the invoice ID, issue date, currency, supplier party, line items, and tax totals, then maps them to the QAD supplier invoice document. Because QAD runs three-way match, an inbound invoice is held until its purchase order receipt has posted, so it does not fail the match. Polling uses the changedAfter timestamp for incremental sync and pages until the result is empty, since the default page size is not documented. The caller-supplied document UUID acts as the Tradeshift idempotency key, so resubmitting the same order is safe, and QAD writes carry a BullMQ job id for dedup. Tradeshift does not publish rate limit numbers, so ml-connector backs off and retries on HTTP 429. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized contract manufacturer runs QAD Adaptive ERP for procurement and accounts payable and asks its larger suppliers to send invoices over the Tradeshift network. Before the integration, an AP clerk opened the Tradeshift portal each day, downloaded invoice documents, and typed them into QAD by hand, then chased down which purchase order and receipt each one belonged to before it could be approved. With QAD and Tradeshift connected, inbound supplier invoices and credit notes flow into QAD automatically, already matched against the referencing purchase order and goods receipt, and QAD orders go back out to the network. The manual portal download and re-keying step is gone, and invoices that fail the three-way match are the only ones a person has to look at.

What you can do

• •Pull supplier invoices and credit notes off the Tradeshift network and post them into QAD as AP invoices.
• •Match each inbound Tradeshift invoice to its QAD purchase order and goods receipt for three-way match.
• •Send QAD purchase orders out to Tradeshift as UBL order documents so suppliers see the same orders.
• •Parse and generate Tradeshift UBL XML and sign every request with OAuth 1.0a plus the tenant ID header.
• •Poll the Tradeshift document list on a schedule you set, with retries and a full audit trail on every record.

Questions

Which direction does data move between QAD and Tradeshift?

The main flow is Tradeshift into QAD. Supplier invoices and credit notes are pulled from the Tradeshift network and posted into QAD as AP documents, while QAD purchase orders are sent out to Tradeshift. Trading partner records are aligned with QAD suppliers so each inbound invoice maps to a known supplier.

How does the integration handle Tradeshift UBL XML and OAuth 1.0a?

Tradeshift exchanges invoices, credit notes, and orders as UBL XML, not JSON, so ml-connector parses inbound documents and generates outbound ones in UBL. Own-account access uses OAuth 1.0a, which signs each request, so the connector uses a real OAuth 1.0a signing library and attaches the required X-Tradeshift-TenantId header on every call.

Does the integration work without webhooks from either system?

Yes. Tradeshift has no traditional webhooks for a server-side connector, and QAD cloud is pull-only, so ml-connector polls instead. It queries the Tradeshift document list with a changedAfter timestamp for incremental sync and pages until the results are empty, on a schedule you control.