IFS Cloud and Plaid integration

What moves between them

Payment data flows from IFS Cloud into Plaid. ml-connector reads IFS payment proposals (containing vendor bank details, amount, and GL reference) and initiates ACH or wire transfers through Plaid. As transfers post to the bank and Plaid confirms status via webhook, ml-connector reads the transaction from Plaid and writes a reconciliation entry back into IFS's VoucherSet to mark the payment as cleared. GL dimension mapping ensures transfer amounts are posted to the correct IFS cost center and expense account. The mapping is controlled by configuration and can be refreshed between runs.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For IFS, it exchanges client credentials for an OAuth 2.0 bearer token, refreshing when the token approaches expiry. For Plaid, it holds the client credentials and validates incoming webhook signatures using JWT verification (checking algorithm is ES256, that the iat claim is within 5 minutes of now, and that the request body SHA-256 matches the claim). Before executing a transfer, ml-connector queries IFS VoucherSet and Plaid's linked Items to confirm the vendor's bank account is linked in Plaid. It then initiates a transfer with an idempotency key derived from the IFS payment proposal ID, guaranteeing that retries do not duplicate the ACH or wire. On transfer completion, Plaid's webhook notifies ml-connector of the status, and ml-connector polls IFS to locate the matching voucher, then writes a reconciliation code into IFS VoucherSet to mark the payment as executed. The integration respects IFS's 1000-request-per-minute rate limit and uses exponential backoff on 429 responses. ETag headers are captured on all IFS reads before any mutation to prevent concurrency conflicts.

A real-world example

A mid-sized distribution company runs IFS Cloud for procurement, invoicing, and GL management, with daily supplier invoices totaling 50-200 payments. The AP team previously batched invoices in IFS, exported the vendor bank account details and amounts to a spreadsheet, and manually initiated ACH transfers from a separate banking portal. With IFS and Plaid connected, each approved invoice in IFS can trigger an automatic ACH initiation through Plaid to the vendor's registered bank account. As Plaid confirms the transfer posted to the bank, the payment is marked in IFS, and month-end reconciliation is automatic.

What you can do

• •Read payment proposals and vouchers from IFS Cloud, extract vendor bank details, and initiate ACH or wire transfers through Plaid.
• •Map IFS cost centers and GL accounts to Plaid transfer descriptions to maintain GL reconciliation.
• •Validate that each vendor's bank account is linked in Plaid before attempting a transfer, and use idempotency keys to prevent duplicate payments on retry.
• •Receive Plaid webhook notifications of transfer status (pending, posted, failed) and write reconciliation codes back into IFS VoucherSet.
• •Handle OAuth 2.0 token refresh on IFS, JWT signature verification on Plaid webhooks, rate limiting on both systems, and a full audit trail of every payment from proposal to bank posting.

Questions

What happens if a vendor's bank account is not linked in Plaid?

Before initiating a transfer, ml-connector checks that the vendor's account exists as a linked Item in Plaid. If the bank account is not linked, the transfer is blocked, and the payment proposal remains open in IFS with an audit entry explaining why. The AP team then links the bank account in Plaid (via Plaid Link) and the flow retries.

How does ml-connector prevent duplicate ACH payments if a transfer request is retried?

Every transfer is initiated with an idempotency key derived from the IFS payment proposal ID. If a network error occurs and the same proposal is processed again, Plaid recognizes the duplicate idempotency key and returns the existing transfer instead of creating a new one, guaranteeing exactly-once payment.

How is data reconciled between IFS and Plaid after a payment posts?

When Plaid's webhook confirms a transfer has posted, ml-connector queries IFS to find the matching payment proposal (by GL reference or vendor account) and writes a reconciliation voucher or status code into IFS VoucherSet. This closes the payment loop in IFS and ensures the GL reflects the actual bank posting.