Microsoft Dynamics GP and Procurify integration

What moves between them

The main flow runs from Procurify into Dynamics GP. New and changed purchase orders, requisitions, and vendor records from Procurify are polled at a cadence tied to your procurement cycle, then written into Dynamics GP's corresponding purchase order and vendor modules as unposted Work transactions, mapped to the correct GP company, cost center, and GL account. Vendor master records flow both directions so the two systems stay aligned on vendor names, addresses, and payment terms. Because Dynamics GP financial records are read-only once posted, ml-connector only writes to unposted transactions and never attempts to modify historical or open records. Requisitions and vendor records from Procurify are also read on demand to validate cost allocations before they are written to Dynamics GP.

How ml-connector handles it

ml-connector stores both credential sets encrypted: the Windows domain account for Dynamics GP and the Procurify OAuth2 client_id and client_secret. On the Procurify side, it exchanges the credentials for a 24-hour bearer token and refreshes it when an API call returns 401. On the Dynamics GP side, it uses the Windows account to authenticate against the customer's SBA REST endpoint at the exact URL and port the customer provides, since Dynamics GP is on-premises with no shared hostname. Because both systems are pull-only, ml-connector polls Procurify for new requisitions and purchase orders using the last_modified and po_created_date filters, then polls Dynamics GP using the ModifiedDate filter to detect changes on the vendor master. Before writing a purchase order or requisition to Dynamics GP, ml-connector validates that the fiscal period is open in GP's calendar and that the target cost center and GL account exist in the GP company database, returning an error if either check fails. Purchase orders and requisitions are written as unposted Work transactions so they can be edited or cancelled before posting. Vendor records are written using the SBA REST endpoint and mapped to the correct GP company and vendor class. Because Dynamics GP has no built-in idempotency mechanism, ml-connector tracks the external document number from Procurify to prevent duplicate vendor or purchase order records. Every record carries a full audit trail with timestamps and source identifiers, and failed writes can be replayed once the blocking validation error is resolved.

A real-world example

A mid-sized manufacturing company runs Dynamics GP on-premises for finance, inventory, and purchasing. The procurement team uses Procurify in the cloud to manage purchase requisitions, vendor relationships, and spending across three plants. Before the integration, the procurement team created requisitions in Procurify and the finance team re-entered approved purchase orders into Dynamics GP by hand, a process that took 2-3 days per week and created frequent mismatches between the two systems on quantities, line items, and GL allocations. With Procurify and Dynamics GP connected, new requisitions and approved purchase orders flow from Procurify into Dynamics GP automatically as unposted transactions, mapped to the correct plant and cost center. Vendor master changes sync both directions. The manual re-keying is eliminated, and the finance team can focus on approval workflows and period-end close instead of data entry.

What you can do

• •Sync new and changed purchase orders from Procurify into Dynamics GP as unposted Work transactions, mapped to the correct company, cost center, and GL account.
• •Keep vendor master records aligned between Procurify and Dynamics GP, syncing vendor names, addresses, payment terms, and vendor classes in both directions.
• •Validate that fiscal periods are open and cost centers exist in Dynamics GP before writing purchase orders, returning errors when validation fails rather than creating bad records.
• •Authenticate Dynamics GP using Windows domain accounts over its on-premises Service Based Architecture endpoint, and Procurify using OAuth2 client credentials, handling token refresh and rotation.
• •Poll both systems on a schedule tied to your procurement cycle with full audit trails, error replay, and duplicate prevention using external document numbers.

Questions

How does ml-connector handle the Windows authentication that Dynamics GP requires?

ml-connector stores the Windows domain account name and password encrypted in the database, then uses it to authenticate against Dynamics GP's on-premises REST Service Based Architecture endpoint at the exact URL and port the customer provides. The Windows account is mapped inside Dynamics GP to a user with the appropriate role-based permissions to read vendors and purchase orders. OAuth2 is not available for Dynamics GP, so this Windows account is the only supported auth method.

What is the difference between polling Procurify and Dynamics GP, and how does ml-connector prevent duplicate records?

Both Procurify and Dynamics GP are pull-only systems with no webhooks or push notifications, so ml-connector polls both on a schedule. Procurify is polled using time-based filters like last_modified and po_created_date, while Dynamics GP is polled using the ModifiedDate filter on its SBA endpoints. Because Dynamics GP has no built-in idempotency mechanism, ml-connector tracks the external document number from Procurify to detect and skip duplicate vendor or purchase order records that might result from a retry or re-run.

Why are purchase orders written as unposted Work transactions, and what happens if a fiscal period is closed?

Dynamics GP only allows write operations on unposted Work transactions; once a transaction is posted, it becomes read-only. Writing as unposted gives the finance team a chance to review and adjust the purchase order before posting it into the GL. If the target fiscal period is closed, ml-connector returns a validation error and does not create the record, allowing you to either open the period or create the transaction in a different period before retrying.