Acumatica and Tradeshift integration

What moves between them

Purchase orders flow from Acumatica out to the Tradeshift network. When a PO is open in Acumatica, ml-connector builds the matching UBL order document and delivers it to the supplier through Tradeshift. Supplier invoices flow the other direction: ml-connector reads new UBL invoices from the Tradeshift inbox, maps them to the originating vendor and purchase order, and creates AP bills in Acumatica ready for matching and release. Credit notes follow the same inbound path. Because neither side pushes a signed event, the cadence is a scheduled poll on both ends rather than real-time triggers.

How ml-connector handles it

ml-connector stores both credential sets encrypted and signs every Tradeshift request with OAuth 1.0a HMAC-SHA1 while sending the X-Tradeshift-TenantId header, and it requests Acumatica OAuth 2.0 tokens against the customer's version-locked instance URL, refreshing the token when a call returns 401. The format bridge is the core of the work: outbound Acumatica purchase order JSON is rendered as UBL order XML, and inbound UBL invoice XML is parsed into a wrapped-value Acumatica Bill, with vendor and PO matched so the bill posts against the right vendor and AP account. Inbound documents are read by polling the Tradeshift list with changedAfter and a saved high-water mark, since Tradeshift has no simple webhook, and Acumatica changes are read by polling LastModifiedDateTime for the same reason. The caller-supplied document UUID makes Tradeshift writes idempotent, and on the Acumatica side ml-connector checks for an existing record by VendorRef before creating a bill, so a retry after a timeout does not produce a duplicate. Acumatica returns HTTP 429 when the per-minute license limit is hit and Tradeshift throttles without published limits, so ml-connector backs off with jitter and retries. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized distributor with around 300 staff runs Acumatica for finance and procurement and is told by several large retail customers that all trading must move onto the Tradeshift network. Before the integration, buyers emailed purchase orders as PDFs and the AP team keyed every returning supplier invoice into Acumatica by hand, which slowed approvals and let mismatches slip through. With Acumatica and Tradeshift connected, approved purchase orders reach suppliers on Tradeshift automatically, and the UBL invoices that come back become Acumatica bills already linked to the original order. AP shifts from typing invoices to reviewing exceptions, and the company meets its customers' network requirement without changing how it runs its ledger.

What you can do

• •Send approved Acumatica purchase orders to suppliers on the Tradeshift network as UBL order documents.
• •Turn inbound Tradeshift UBL invoices and credit notes into Acumatica AP bills, matched to the originating vendor and purchase order.
• •Convert between Acumatica wrapped-value JSON and Tradeshift UBL 2.0 and 2.2 XML in both directions.
• •Bridge Acumatica OAuth 2.0 on its version-locked URL and Tradeshift OAuth 1.0a request signing with the required tenant header.
• •Poll both sides on a schedule with idempotent writes, retries, and a full audit trail on every document.

Questions

Which records move between Acumatica and Tradeshift, and in which direction?

Purchase orders move from Acumatica out to suppliers on Tradeshift, and supplier invoices and credit notes move from Tradeshift back into Acumatica as AP bills. Inbound bills are matched to the originating vendor and purchase order before they are created. The cadence is a scheduled poll on both sides, since neither system pushes a signed event a server connector can rely on.

How does the integration deal with Acumatica JSON versus Tradeshift UBL XML?

The two systems do not share a format, so ml-connector converts between them. Outbound Acumatica purchase order JSON is rendered as UBL order XML for Tradeshift, and inbound UBL invoice XML is parsed back into a wrapped-value Acumatica Bill. The correct documentProfileId is set on each Tradeshift document, and Acumatica field values are wrapped as value objects so the ERP accepts them.

Why does the connection poll instead of using webhooks?

Tradeshift has no traditional webhook for a server-side connector; its event stream needs app registration and protobuf, so the practical path is polling the document list with changedAfter. Acumatica can push notifications but without a signed payload, so it is read by polling LastModifiedDateTime. ml-connector stores a high-water mark on each side and uses idempotency keys so repeated polls and retries never create duplicates.