Acumatica and Coupa integration

What moves between them

The main flow runs from Coupa into Acumatica. ml-connector reads approved supplier invoices from Coupa and posts them into Acumatica as AP bills against the matching vendor, carrying the vendor reference, amount, currency, and line detail, and it brings Coupa purchase orders into Acumatica as purchase orders so receipts and bills can match. Suppliers are aligned so every Coupa invoice resolves to an existing Acumatica vendor. After Acumatica releases an AP payment against a bill, the paid status returns to Coupa as a supplier invoice payment so buyers see settlement. Acumatica stays the system of record for AP and the general ledger, so ml-connector posts financial documents only into Acumatica and never writes GL entries into Coupa.

How ml-connector handles it

ml-connector stores both credential sets encrypted and pins the Acumatica endpoint version per customer, since the version in the URL must match the ERP release exactly or every call returns 404, and it wraps all Acumatica field values in the required value objects. On the Coupa side it requests an OAuth 2.0 client-credentials token from the instance oauth2/token endpoint, caches it per instance and client until shortly before expiry, refreshes once on a 401, and sends the X-Coupa-API-Version header on every call. It reads the Coupa invoices endpoint filtered to approved status so unapproved documents never reach AP. Suppliers and GL accounts are mapped first so each invoice posts to an existing vendor and valid account, and the Coupa PO number is carried onto the Acumatica bill so it can match its purchase order. Inbound Coupa webhooks are accepted only after the X-Coupa-Signature HMAC is verified, and because Acumatica cloud push is not guaranteed the connector polls Acumatica payments on LastModifiedDateTime with $top and $skip paging and a stored high-water mark. Acumatica returns HTTP 429 under license-tier limits and Coupa rate-limits with 429 as well, so ml-connector backs off and retries, and it dedupes on the Coupa invoice number and vendor reference so a retried post never creates two AP bills.

A real-world example

A mid-sized facilities services company runs Acumatica for accounting and accounts payable and uses Coupa for procurement and invoice approvals across several regional branches. Before the integration, the AP team pulled approved invoices out of Coupa and keyed them into Acumatica as bills one by one, then later went back into Coupa to mark which ones had been paid, which delayed close and left suppliers asking about payment status. With Acumatica and Coupa connected, each approved Coupa invoice posts into Acumatica AP automatically against its vendor and purchase order, and the paid status flows back to Coupa after Acumatica cuts the payment. The double entry is gone, invoices reach the ledger the same day they clear approval, and buyers see settlement without asking AP.

What you can do

• •Post approved Coupa supplier invoices into Acumatica as AP bills against the matching vendor and purchase order.
• •Bring Coupa purchase orders into Acumatica so receipts and bills can match against them.
• •Return Acumatica AP payment status to Coupa as supplier invoice payments so buyers see settlement.
• •Keep Coupa suppliers aligned with Acumatica vendors and map GL accounts so each invoice posts to a valid account.
• •Bridge Coupa OAuth client-credentials with Acumatica OAuth and version-locked endpoints, with retries and a full audit trail.

Questions

Which direction does data move between Acumatica and Coupa?

The main flow is Coupa into Acumatica. Approved supplier invoices and purchase orders move from Coupa into Acumatica as AP bills and purchase orders, while paid status returns to Coupa as supplier invoice payments. Acumatica stays the system of record for accounts payable and the general ledger, so ml-connector writes financial documents only into Acumatica.

How does ml-connector handle Coupa OAuth and Acumatica's version-locked endpoints?

It requests an OAuth 2.0 client-credentials token from the Coupa oauth2/token endpoint, caches it per instance until shortly before expiry, refreshes once on a 401, and sends the X-Coupa-API-Version header on every call. On the Acumatica side it pins the endpoint version per customer because a mismatched version in the URL returns 404, and it wraps every Acumatica field value in the required value object.

Does the integration use webhooks or polling?

It uses both, matched to each system. ml-connector verifies the X-Coupa-Signature HMAC on inbound Coupa invoice and payment webhooks before acting, and it polls Acumatica payments on LastModifiedDateTime with $top and $skip paging since Acumatica cloud push is not guaranteed. Invoices are deduped on the Coupa invoice number and vendor reference so a retried delivery never posts a duplicate AP bill.