Acumatica and Wise integration

What moves between them

The main flow runs from Acumatica into Wise. ml-connector reads approved Acumatica AP payments and their vendors, creates or reuses a matching Wise recipient, gets a quote, creates the transfer, and funds it from the chosen Wise balance. Status then flows back from Wise into Acumatica: as each transfer reaches outgoing_payment_sent or fails, the connector updates the related Acumatica payment and posts the Wise fee and any FX difference as a GL journal against the accounts you map. Balance statement lines are read for reconciliation. Wise holds no ledger, so the chart of accounts stays in Acumatica and ml-connector never writes accounting records into Wise.

How ml-connector handles it

ml-connector stores both credential sets encrypted, sends the Wise bearer token on every request and refreshes it before its 12-hour expiry, and refreshes the Acumatica OAuth token when a call returns 401. On the Acumatica side it accepts the full instance URL and the exact endpoint version per customer, since a version mismatch returns 404, and wraps every field value in the required value object so reads and writes do not fail with a 400. Vendors are mapped to Wise recipients first, and because Wise recipients are immutable, a changed vendor bank detail is handled by creating a fresh recipient rather than editing one. Each payment runs the mandatory Wise sequence, quote then recipient then transfer then fund, and the connector sets customerTransactionId from the Acumatica payment reference and a BullMQ jobId so a retried run never sends the same money twice. A fresh quote is taken if an earlier one passes its expirationTime. Wise transfer state-change webhooks arrive signed with RSA-SHA256, so each event is verified before processing and the resource is re-fetched from Wise rather than trusted from the payload; a scheduled poll on Acumatica LastModifiedDateTime and on the Wise transfer list backfills anything a webhook missed. Both sides return HTTP 429 under load, so ml-connector honors Retry-After and backs off with jitter, and every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized importer of around 200 staff runs Acumatica Cloud ERP for purchasing, AP, and accounting, and pays overseas suppliers in several currencies. Before the integration, an AP clerk approved each bill in Acumatica, then rebuilt the payment by hand in the Wise dashboard, copying the IBAN and amount and guessing at the FX, after which someone keyed the Wise fee and the settled rate back into Acumatica where the bank balance rarely tied out. With Acumatica and Wise connected, an approved payment creates the Wise recipient and transfer automatically, funds it from the right currency balance, and posts the confirmed status, fee, and FX difference back to Acumatica. The double entry is gone and month-end close starts from payments that already reconcile.

What you can do

• •Turn approved Acumatica AP payments into funded Wise transfers through the required quote, recipient, transfer, and fund sequence.
• •Mirror Acumatica vendors as Wise recipients, recreating a recipient when bank details change since Wise recipients are immutable.
• •Post each Wise transfer status, processing fee, and FX difference back into Acumatica as updated payments and GL journals.
• •Authenticate Wise with its OAuth bearer token and profile id, and Acumatica with its OAuth token on the version-locked instance URL.
• •Set a customerTransactionId and jobId so a retry never double-pays, verify Wise webhook signatures, and keep a full audit trail with error replay.

Questions

Which direction does data move between Acumatica and Wise?

Mostly Acumatica into Wise, with status coming back. Approved AP payments and their vendors move from Acumatica into Wise as recipients and funded transfers. Transfer status, fees, and FX differences then flow back into Acumatica as updated payments and GL journals. Wise has no chart of accounts, so the ledger stays in Acumatica and ml-connector never writes accounting records into Wise.

How does the integration stop a retry from paying a vendor twice?

Every Wise transfer is created with a customerTransactionId derived from the Acumatica payment reference, and Wise deduplicates on that value, so a repeated request returns the original transfer instead of a new one. ml-connector also tags the job with a BullMQ jobId for its own dedup. Because Acumatica has no native idempotency key, the connector checks payment status before acting so an already-sent payment is not re-queued.

How are Wise transfer outcomes and fees reflected in Acumatica?

Wise sends transfer state-change webhooks signed with RSA-SHA256, which ml-connector verifies and then confirms by re-fetching the transfer from the Wise API. When a transfer reaches outgoing_payment_sent or fails, the linked Acumatica payment is updated, and the Wise fee and any exchange-rate difference are posted as a GL journal against the accounts you map. A scheduled poll on the Wise transfer list and on Acumatica LastModifiedDateTime backfills anything a webhook missed.