Deltek and Procurify integration

What moves between them

The main flow runs from Procurify into Deltek. As purchase orders and AP bills are approved in Procurify, ml-connector reads them and posts them into Deltek Vantagepoint as AP invoices, each mapped to the matching Deltek vendor firm, project, and GL account. Vendor records move the same direction so the Deltek firm master reflects Procurify vendors and their tax and remittance details. Reference data moves the other way: Deltek firms and GL accounts flow back into Procurify as vendors and account codes, so every requisition is coded to a firm and account that exist in the ledger. The general ledger lives in Deltek, so ml-connector never writes accounting entries back into Procurify.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Procurify side it fetches a client-credentials token, caches it for its 24-hour life, and sends it with the required X-Procurify-Client api header on every call. On the Deltek side it requests an OAuth 2.0 password-grant token against the customer tenant URL and refreshes it when a call returns 401, which depends on the password grant being enabled in Vantagepoint settings and the API user role having full field visibility so fee and amount fields do not read as zero. Procurify vendors are mapped to Deltek firm numbers and Procurify account codes to Deltek GL accounts first, so every AP invoice line lands on a valid firm and account. Because Procurify has no webhooks and Deltek offers only workflow callbacks with no HMAC, ml-connector polls both sides on your schedule: it walks Procurify page-number pages with last_modified and po_created_date filters and reads Deltek by page. Procurify does not create purchase orders directly, so when a request is pushed the other way ml-connector submits it through the requisitions endpoint and lets Procurify generate the PO once it is approved. Deltek has no idempotency key, so before posting an AP invoice ml-connector queries Deltek by invoice number and dedupes on a BullMQ jobId, which avoids double-booking a record when a poll window overlaps. Procurify can suspend access on excessive requests, so calls back off and retry, and every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized environmental engineering firm of roughly 250 staff across three regional offices runs Deltek Vantagepoint for project accounting and the general ledger, and rolled out Procurify so project managers could raise purchase requests and approvals on their own. Before the integration, an AP clerk re-keyed every approved purchase order and supplier bill from Procurify into Deltek by hand, matching each one to the right vendor firm and project, and requisitions in Procurify often picked vendors or account codes that did not match the ledger, so bills bounced back for correction. With Deltek and Procurify connected, approved purchase orders and bills post into Deltek as AP invoices against the correct firm, project, and GL account, and the vendor and account-code lists in Procurify stay in step with finance. The re-keying queue disappears and miscoded requests stop reaching AP.

What you can do

• •Post approved Procurify purchase orders and AP bills into Deltek Vantagepoint as AP invoices against the matching vendor firm, project, and GL account.
• •Keep the Deltek firm master aligned with Procurify vendors and their tax and remittance details.
• •Send Deltek firms and GL accounts back into Procurify as vendors and account codes so every requisition is coded to a valid ledger entry.
• •Authenticate Procurify with its client-credentials token and Deltek with its tenant OAuth 2.0 password grant.
• •Poll both systems on your schedule with backoff, an invoice-number dedup check, retries, and a full audit trail on every record.

Questions

Which direction does data move between Deltek and Procurify?

The main flow is Procurify into Deltek. Approved purchase orders, AP bills, and vendor records move from Procurify into Deltek Vantagepoint, posted as AP invoices and firms against the matching projects and GL accounts. Deltek firms and GL accounts flow back to Procurify as vendors and account codes. The general ledger lives in Deltek, so ml-connector does not write accounting entries back into Procurify.

Does the integration rely on webhooks?

No. Procurify does not support webhooks at all, and Deltek offers only workflow-driven callbacks with no HMAC signature, so ml-connector treats both sides as pull. It walks Procurify page-number pages with last_modified and po_created_date filters and reads Deltek by page, on the schedule you set.

How are duplicate AP invoices avoided when Deltek has no idempotency key?

Deltek provides no idempotency-key header, so before posting an AP invoice ml-connector queries Deltek by invoice number and only creates the record if it is not already there. Each job also runs under a BullMQ jobId for deduplication, so the same approved Procurify bill is not booked twice when sync windows overlap.