Microsoft Dynamics 365 Business Central and Procurify integration

What moves between them

The main flow runs from Procurify into Microsoft Dynamics 365 Business Central. ml-connector reads approved AP bills from Procurify and creates matching purchase invoices in Business Central, each line coded to the GL account that maps from the Procurify account code. Vendor records sync so a vendor approved in Procurify exists in Business Central before its bill posts. Account codes and the Business Central chart of accounts are reconciled so every bill line lands on a valid account. Cadence is a scheduled poll of Procurify, since it pushes no events; the Business Central write side is driven by what the poll finds.

How ml-connector handles it

ml-connector stores both credential sets encrypted and runs two separate OAuth2 client-credentials flows: one against Entra ID for the Business Central token, one against the Procurify subdomain for its 24-hour token, which it caches and refreshes before expiry while always sending the X-Procurify-Client header. Because Procurify has no webhooks, it polls bills and order items on your schedule rather than waiting for a push, walking Procurify's page-number pagination and Business Central's OData nextLink tokens. Procurify account codes are mapped to Business Central GL accounts first, and vendors are matched by Procurify external_id against the Business Central vendor number so a bill never posts against a missing vendor or account. Created purchase invoices stay as drafts in Business Central until the bound post action runs, which keeps an unverified bill out of the posted ledger. Business Central rate limits and Procurify timeouts both surface as throttling, so writes carry a stable job id and back off with retries, and every record has a full audit trail and can be replayed.

A real-world example

A 250-person biotech company runs Procurify for purchase requests and AP approvals across several lab departments and uses Microsoft Dynamics 365 Business Central as its accounting system. Before the integration, the AP clerk approved bills in Procurify and then re-typed each one into Business Central as a purchase invoice, matching the vendor and GL account by hand, which was slow and produced miscoded lines that surfaced at month-end. With Procurify and Business Central connected, each approved bill flows into Business Central as a draft purchase invoice already coded to the mapped GL account and tied to the right vendor, so the clerk reviews and posts instead of re-keying, and the department coding stays consistent.

What you can do

• •Create Business Central purchase invoices from approved Procurify AP bills, coded to the mapped GL accounts.
• •Keep vendors consistent across Procurify and Business Central so bills never post against a missing vendor.
• •Map Procurify account codes to the Business Central chart of accounts so every bill line lands on a valid account.
• •Authenticate Procurify with its 24-hour subdomain token and Business Central with Entra ID OAuth2 client credentials.
• •Poll Procurify on a schedule, with stable job ids, retries, and a full audit trail on every record.

Questions

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

The main flow is Procurify into Business Central. Approved AP bills and vendor records move from Procurify into Business Central, while account codes and the chart of accounts are aligned so bills post to valid accounts. Procurify owns the approval workflow, so ml-connector reads approved spend rather than writing approvals back into Procurify.

Does the integration use webhooks or polling?

It uses polling on the Procurify side, because Procurify's API does not support webhooks. ml-connector queries bills and order items on the schedule you set, using Procurify's last_modified and date-range filters where they exist. Business Central does support subscription webhooks, but its purchase order resource is not webhook-enabled, so a scheduled poll is the reliable path for this pair.

How are vendors and account codes kept from creating mismatched invoices?

ml-connector maps Procurify account codes to Business Central GL accounts and matches vendors by Procurify external_id against the Business Central vendor number before any bill is written. A purchase invoice is created as a draft and only posted by the bound post action, so a bill with a missing vendor or unmapped account is caught for review instead of landing miscoded in the posted ledger.