Acumatica and Plaid integration

What moves between them

The main flow runs from Plaid into Acumatica. ml-connector pulls bank transactions and current and available balances from Plaid and posts them into Acumatica as the feed for bank reconciliation against the matching GL cash accounts. Account-and-routing numbers from Plaid Auth flow the same direction to populate vendor ACH payment instructions in Acumatica, so payments go out on verified bank details. Plaid holds no vendors, invoices, or GL accounts, so those master and document records are never written back to Plaid. Transactions sync on Plaid's webhook signal, while balances and routing data are pulled on the schedule you set.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Plaid side it sends the client_id and secret on every POST and uses the per-user access token returned from the Plaid Link exchange for each connected bank, since the token is per user and not a single system credential. On the Acumatica side it requests and refreshes an OAuth 2.0 bearer token, or holds a cookie session, against the version-locked tenant URL, and it wraps every field value in the {value: ...} form Acumatica requires. Plaid transactions are asynchronous, so ml-connector waits for the INITIAL_UPDATE and SYNC_UPDATES_AVAILABLE webhooks and then calls /transactions/sync with a stored cursor to collect adds, modifies, and removes, rather than polling right after a bank is linked. Each Plaid webhook is verified with its ES256 JWT, fetching the rotating JWK by the kid in the header. Cash accounts are mapped first so every imported transaction lands on a real Acumatica account, and ml-connector dedupes on the Plaid transaction_id before posting so a re-read does not double-book. Plaid returns HTTP 429 against per-Item and per-client limits and Acumatica throttles by license tier, so calls back off and retry with jitter, and every record carries a full audit trail and can be replayed if an Acumatica write fails.

A real-world example

A regional construction-supply distributor of roughly 120 staff runs Acumatica Cloud ERP for purchasing, accounts payable, and the general ledger, and banks across three operating accounts. Before the integration, an accountant downloaded bank statements each morning, keyed deposits and card charges into Acumatica, and matched them to bills by hand, which left cash a day or two behind and stalled month-end close. With Acumatica and Plaid connected, bank transactions and balances flow in continuously and post against the right cash accounts, and verified routing numbers fill in vendor ACH details so payments do not bounce. The manual statement download is gone and reconciliation keeps pace with the bank.

What you can do

• •Feed Plaid bank transactions into Acumatica as the source for reconciling GL cash accounts.
• •Pull current and available balances from Plaid to keep Acumatica cash positions current.
• •Populate Acumatica vendor ACH payment instructions from Plaid Auth account-and-routing numbers.
• •Bridge Plaid client_id, secret, and per-user access tokens with Acumatica OAuth 2.0 on its version-locked tenant URL.
• •Sync transactions on Plaid webhooks with transaction_id dedup, retries, and a full audit trail on every record.

Questions

Which direction does data move between Acumatica and Plaid?

The main flow is Plaid into Acumatica. Bank transactions, balances, and account-and-routing numbers move from Plaid into Acumatica to drive cash reconciliation and vendor ACH setup. Plaid has no vendors, invoices, purchase orders, or GL accounts, so those records stay in Acumatica and are never written back to Plaid.

Does Plaid push transactions, or does ml-connector poll for them?

Plaid transactions are asynchronous, so ml-connector subscribes to webhooks rather than polling right after a bank is linked. It waits for the INITIAL_UPDATE and SYNC_UPDATES_AVAILABLE signals, then calls /transactions/sync with a stored cursor to collect added, modified, and removed records. Balances and routing data are pulled on the schedule you set.

How does the integration handle Plaid's per-user access tokens and POST-only API?

Every Plaid bank connection is an Item with its own long-lived access token created through the Plaid Link flow, so ml-connector stores each token encrypted per customer alongside the shared client_id and secret. All Plaid endpoints are HTTP POST with JSON bodies, including reads, so ml-connector never assumes GET semantics. Webhooks are verified with their ES256 JWT, fetching the rotating public key by the kid in the header.