Microsoft Dynamics GP and Plaid integration

What moves between them

The main flow is outbound from Microsoft Dynamics GP to Plaid. ml-connector reads GP payables invoices, vendors, and GL accounts on a polling schedule that respects GP fiscal period open/closed status and the posted/unposted transaction constraint. When a payable is due and a corresponding vendor exists in Plaid, ml-connector constructs an ACH transfer request using the Plaid transfer initiation endpoint, supplying an idempotency key to prevent duplicate transfers if a network call must be retried. Inbound, ml-connector receives Plaid webhooks on transfer events and transaction syncs, validates each webhook signature, and optionally logs the event or updates GP payment status if bidirectional sync is configured. Because GP is read-mostly, the primary direction is GP to Plaid.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Microsoft Dynamics GP side, it accepts the full SBA or SOAP endpoint URL per customer and the Windows domain account username and password, using Kerberos or NTLM to authenticate each call. On the Plaid side, it stores the client_id and secret and manages the three-step Plaid Link token exchange (link/token/create, user completes the Link flow, item/public_token/exchange) to obtain the per-user access token required for bank operations. Because GP has no webhooks, ml-connector polls SBA REST or SOAP with ModifiedDate filters on a customer-defined schedule, respecting the constraint that write operations only work on unposted transactions and that fiscal periods must be open. For each due payable, it constructs a Plaid transfer request with account validation, an ACH description up to 10 characters, and an idempotency key; if Plaid returns 429 rate limit, ml-connector backs off exponentially. Inbound webhook payloads from Plaid (transfer status, transaction syncs) are verified using the JWT signature with ES256 algorithm and checked against the iat claim (must be within 5 minutes); only valid signatures are processed. Transfer amounts that would exceed GP GL account balances or bank limits are rejected with a clear error logged to the audit trail.

A real-world example

A regional distribution company runs Microsoft Dynamics GP on-premises for AP, inventory, and GL across two warehouses and a head office. Twice a week, the AP team generates a payables report from GP, reviews it, and manually initiates ACH transfers from their bank to dozens of vendors, cross-checking vendor bank routing numbers and amounts by hand. With Microsoft Dynamics GP and Plaid connected, each due payable in GP is validated against the GL account balance and the vendor's Plaid profile, and qualifying payments are queued for automatic ACH transfer using Plaid's idempotent transfer API. Manual AP processing drops from hours to minutes; vendors receive predictable payment schedules; and the audit trail shows every transfer decision, approval, and settlement without re-keying.

What you can do

• •Read GL accounts, vendors, and payables from Microsoft Dynamics GP with ModifiedDate filters, respecting fiscal period opens and unposted transaction constraints.
• •Initiate ACH transfers to Plaid for due payables, using vendor bank details and GL account validation to prevent overpayment.
• •Manage the Plaid Link three-step token exchange so users can securely grant bank access without sharing credentials.
• •Verify inbound Plaid webhook signatures (JWT ES256) and process transfer events, transaction syncs, and item errors with full audit logging.
• •Retry failed transfers with idempotency keys, back off on Plaid 429 rate limits, and maintain a complete record of every payment decision.

Questions

How does ml-connector authenticate to Microsoft Dynamics GP and Plaid?

Microsoft Dynamics GP uses Windows Authentication (Kerberos or NTLM) tied to Active Directory. ml-connector stores a Windows domain account username and password encrypted and presents it on each SBA REST or SOAP call. Plaid uses client_id and secret; ml-connector stores both encrypted and supplies them as PLAID-CLIENT-ID and PLAID-SECRET headers. User-specific bank access is granted via the three-step Plaid Link flow, which generates a per-user token that persists until revoked.

Does the integration push or pull data from Microsoft Dynamics GP?

Microsoft Dynamics GP does not support webhooks, so ml-connector polls the SBA REST or SOAP endpoint with ModifiedDate filters on a customer-defined schedule, respecting fiscal period open/closed status and the constraint that write operations work only on unposted transactions. Plaid, conversely, supports webhooks for transfer events, transaction syncs, and item errors; ml-connector registers a webhook endpoint to receive and validate inbound events using JWT ES256 signature verification.

What happens if a Plaid transfer fails or is rate-limited?

ml-connector assigns each transfer an idempotency key valid for 48 hours, so a retried call with the same key does not create a duplicate transaction in your bank account. If Plaid returns HTTP 429 (rate limit), ml-connector backs off exponentially and retries. If the transfer is ultimately rejected (invalid account, insufficient balance, etc.), the error is logged to the audit trail with the payable reference, GL account, and vendor so the AP team can investigate and manually resolve.