Deltek and ServiceNow integration

What moves between them

The main flow runs from ServiceNow into Deltek. ml-connector reads vendors, purchase orders, and approved AP invoices from the ServiceNow Source-to-Pay tables and creates or updates the matching firms, AP invoices, and journal entries in Deltek. Once Deltek posts or pays an invoice, the status moves back into ServiceNow so the originating request reflects the ledger outcome. GL accounts and cost centers are aligned in both directions so every posted line references an account that already exists in Deltek. Cadence is a scheduled poll, typically every few minutes for invoices and less often for vendor and account master data.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the ServiceNow side it requests an OAuth2 client credentials token and refreshes it before the thirty-minute expiry, and it filters Table API reads by sys_updated_on so each cycle only pulls records changed since the last run. On the Deltek side it accepts the full tenant URL per customer, since Deltek publishes no shared hostname, and uses the OAuth2 password grant, which requires the Allow Password Grant Type setting to be enabled in Vantagepoint. Neither system has a usable signed webhook, so the integration is poll-based in both directions. Vendors and GL accounts are mapped first, so every AP invoice posts against a Deltek firm and account that already exist. Because neither side offers an idempotency key, ml-connector checks for an existing record by invoice number before posting in Deltek and queries by the external id before writing in ServiceNow, which prevents duplicates on retry. ServiceNow 429 responses are retried after the Retry-After delay, and the Deltek client secret is treated as one-time since regenerating it breaks the connection.

A real-world example

A four-hundred-person engineering and consulting firm runs Deltek Vantagepoint for project accounting and uses ServiceNow to manage purchasing and accounts payable requests across its offices. Before the integration, approved purchase orders and supplier invoices lived in ServiceNow while the finance team re-entered each vendor and each invoice into Deltek by hand, which delayed postings and left requesters with no view of payment status. With Deltek and ServiceNow connected, approved invoices flow into the Deltek ledger automatically against the right project and GL account, and the posted and paid status returns to ServiceNow. The duplicate entry step is gone and month-end close starts with AP already in agreement.

What you can do

• •Create and update Deltek firms from ServiceNow vendor and supplier records.
• •Post approved ServiceNow purchase orders and AP invoices into Deltek as invoices and journal entries.
• •Return posted and paid status from Deltek back to the originating ServiceNow record.
• •Map ServiceNow GL accounts and cost centers to Deltek accounts so postings stay valid.
• •Poll both systems on a schedule, refresh OAuth2 tokens, and prevent duplicate postings on retry.

Questions

Which direction does data move between Deltek and ServiceNow?

The main flow is ServiceNow into Deltek. Vendors, purchase orders, and approved AP invoices move from ServiceNow into Deltek as firms, invoices, and journal entries. Posted and paid status flows back into ServiceNow, and GL accounts and cost centers are aligned in both directions so postings reference valid accounts.

Does this integration use webhooks or polling?

It uses polling on both sides. Deltek webhooks are workflow-driven with no signed payload, and ServiceNow has no registerable webhook system. ml-connector reads ServiceNow Table API records filtered by sys_updated_on on a schedule and reads Deltek with page-based pagination, so changes are picked up reliably without depending on a push.

What does each system need to be set up first?

The ServiceNow instance needs the licensed Source-to-Pay modules and an OAuth2 client credentials application, since the procurement and AP tables do not exist on a base instance. Deltek needs the Allow Password Grant Type setting enabled and a generated client id and secret. Because neither system has an idempotency key, ml-connector checks for an existing record before each write to prevent duplicates.