Microsoft Dynamics 365 Business Central and Plaid integration

What moves between them

The primary flow runs from Plaid into Microsoft Dynamics 365 Business Central. ml-connector pulls cleared bank transactions and current balances from Plaid and uses them to reconcile against customer payment journals on the receivables side and vendor payment journal lines on the payables side, leaving the Business Central ledger as the system of record. Where ACH payment initiation is enabled, the flow also runs the other way: an approved Business Central vendor payment is submitted through Plaid Transfer, and the settled transfer status is written back to Business Central as a posted vendor payment. Plaid has no invoices, vendors, or GL accounts to receive, so reference data and accounting entries stay in Business Central, and the cadence follows your reconciliation schedule.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Business Central side it requests an OAuth2 client-credentials token from Microsoft Entra ID against the customer's tenant ID, targets the stored environment name in the URL, and reads incrementally with an OData $filter on lastModifiedDateTime, following @odata.nextLink pages. On the Plaid side it sends the client ID and secret on every POST and uses the per-user Item access token captured from Plaid Link, because bank connections cannot be bulk imported. Transactions are read with the Plaid cursor sync, applying added, modified, and removed records in order, and a verified SYNC_UPDATES_AVAILABLE webhook triggers an early pull; Plaid webhooks are validated by fetching the ES256 JWK before processing. Plaid bank accounts are mapped to Business Central GL cash accounts first so every match lands on a valid account, and the BC number field is used as the business key to avoid duplicate posts. For ACH initiation, ml-connector follows Plaid's authorize-then-create sequence, sends an idempotency key, and truncates the ACH description to ten characters; transfer status is treated as event-driven through TRANSFER_EVENTS_UPDATE rather than polling. A 500 on transfer creation is verified against transfer events before any retry, since the transfer may already exist. Plaid 429 and shared institution rate limits and Business Central HTTP 429 throttling are handled with exponential backoff, and every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized professional services firm of about 200 staff runs Microsoft Dynamics 365 Business Central for finance, billing, and the general ledger, and holds its operating and payroll accounts at two banks. Before the integration, a bookkeeper downloaded bank statements each morning and ticked them off by hand against the customer payments and vendor payments recorded in Business Central, and unmatched items lingered until month-end close. With Business Central and Plaid connected, cleared bank transactions flow in from Plaid daily and match automatically against the customer and vendor payments already in the ledger, so exceptions surface the same day instead of at close. When ACH initiation is enabled, approved vendor payments are sent through Plaid Transfer and the settled status posts straight back to the Business Central vendor payment record.

What you can do

• •Pull cleared bank transactions and balances from Plaid and reconcile them against Business Central customer payment journals and vendor payment journal lines.
• •Map Plaid bank accounts to Business Central GL cash accounts so every match lands on a valid account.
• •Initiate approved Business Central vendor payments through Plaid Transfer and write the settled status back as a posted vendor payment.
• •Bridge the Business Central OAuth2 client-credentials token from Microsoft Entra ID with Plaid's client ID, secret, and a per-user Item access token from Plaid Link.
• •Read transactions through the Plaid cursor sync and read Business Central incrementally with an OData delta filter, since BC webhooks carry no payload and expire every three days.

Questions

Which direction does data move between Microsoft Dynamics 365 Business Central and Plaid?

The main flow is Plaid into Business Central: cleared bank transactions and balances are read from Plaid and matched against customer payments and vendor payments in Business Central. When ACH initiation is enabled, payments also flow the other way, with an approved Business Central vendor payment sent through Plaid Transfer and its settled status written back. Plaid has no invoices, vendors, or GL accounts, so accounting entries stay in Business Central.

Can Plaid send invoices or purchase orders into Business Central?

No. Plaid is a bank-data network, not an ERP, and it has no invoice, purchase order, vendor, or GL account objects. What it provides is linked bank accounts, balances, bank-level transactions, ACH and routing numbers, and ACH or wire transfer initiation. ml-connector uses that bank activity to reconcile and pay against the invoices and payments that already live in Business Central.

How does the integration handle authentication and Business Central webhooks?

ml-connector requests a Business Central OAuth2 client-credentials token from Microsoft Entra ID and targets the customer's environment URL, while on the Plaid side it sends the client ID and secret on every POST and uses a per-user Item access token captured through Plaid Link. Plaid pushes JWT-signed webhooks that are verified against the ES256 JWK before use. Business Central webhooks carry no payload and expire every three days, so the connector renews subscriptions proactively and reads incrementally with an OData filter on lastModifiedDateTime.