Microsoft Dynamics 365 F&O and Procurify integration

What moves between them

The main flow runs from Procurify into Microsoft Dynamics 365 F&O. ml-connector reads approved bills from the Procurify accounts payable endpoint and creates vendor invoice headers and lines in D365 F&O, mapped to the matching vendor account and financial dimensions. Approved purchase orders flow the same direction so the commitments staff raised in Procurify exist in D365. Vendors are aligned, with the Procurify external_id field tying each record to its D365 VendorAccountNumber, and account codes are reconciled against D365 MainAccounts so every bill line posts to a valid GL account. The cadence is polling-driven on the Procurify side, on the schedule you set for new and modified spend.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For Procurify it caches the 24-hour client-credentials token and sends the X-Procurify-Client api header on every call; for Microsoft Dynamics 365 F&O it requests an Entra ID bearer token against the environment-host scope and refreshes it when a call returns 401. Because Procurify has no webhooks, the connector polls the modified-date filters to pick up new approved bills and purchase orders rather than waiting for a push. Procurify account codes map to D365 MainAccounts and vendors map by external_id to VendorAccountNumber, so each invoice line lands on a valid GL account and dimension string in the format D365 expects. The connector writes the D365 vendor invoice header before its lines, and only before posting, since posted invoices are read-only over OData. D365 uses natural keys rather than an idempotency header, so a duplicate InvoiceNumber would error; ml-connector dedupes on the bill identifier before writing. It honors D365 Retry-After on HTTP 429 and backs off on Procurify timeouts, since aggressive polling can trigger access suspension there. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized engineering services firm with around 300 staff runs Microsoft Dynamics 365 F&O for finance and uses Procurify so project managers can raise purchase requests and approve supplier bills against budgets. Before the integration, an AP clerk exported approved bills from Procurify each week and keyed them into D365 as vendor invoices, matching vendors and GL codes by hand and often discovering a bill coded to an account that did not exist in the ledger. With the two systems connected, each approved Procurify bill becomes a D365 vendor invoice automatically, coded to the mapped main account and dimensions, and vendors stay aligned by external_id. The clerk reviews exceptions instead of re-typing every invoice, and month-end close starts with AP already in the ledger.

What you can do

• •Create Microsoft Dynamics 365 F&O vendor invoices from approved Procurify accounts payable bills.
• •Sync approved Procurify purchase orders into D365 purchase order headers and lines.
• •Keep vendors aligned across both systems, tying Procurify external_id to the D365 VendorAccountNumber.
• •Reconcile Procurify account codes against D365 MainAccounts so every bill line posts to a valid GL account.
• •Poll Procurify modified-date filters on a schedule, with retries and a full audit trail on every record.

Questions

Which direction does data move between Microsoft Dynamics 365 F&O and Procurify?

The main flow is Procurify into D365 F&O. Approved bills and purchase orders move from Procurify into Dynamics, where they become vendor invoices and purchase orders. Vendors and account codes are aligned across both sides so each invoice line maps to a valid D365 vendor and main account.

Does the integration use webhooks or polling?

On the Procurify side it uses polling, because Procurify's API does not support webhooks. ml-connector queries the modified-date filters such as last_modified and dateModified on the schedule you set to pick up new approved bills and purchase orders. Dynamics 365 F&O can emit Business Events over HTTPS, but those payloads are stubs, so full records are read back over OData.

How does ml-connector avoid creating duplicate invoices in Dynamics?

Dynamics 365 F&O uses natural keys rather than an idempotency header, so creating the same InvoiceNumber twice would raise a duplicate-key error. ml-connector dedupes on the Procurify bill identifier before writing and creates the vendor invoice header before its lines. It only writes invoices that are not yet posted, since posted invoices are read-only over OData.