Deltek and Tipalti integration

What moves between them

The primary flow runs Deltek into Tipalti. ml-connector reads vendor firms and approved AP invoices from Deltek Vantagepoint and upserts them into Tipalti as payees and bills, mapped to Tipalti GL account codes, so Tipalti can pay them globally. GL accounts and tax codes are aligned in both directions so invoice lines land on codes that exist on each side. Payment results flow back from Tipalti into Deltek: when Tipalti reports a payment completed or failed, ml-connector writes a payment transaction and the matching journal entry into Deltek and marks the bill closed. Cadence is scheduled polling for invoices and vendors, while Tipalti payment IPNs trigger the writeback as soon as money moves.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For Deltek it requests an OAuth2 password-grant token against the customer tenant URL and refreshes it when a call returns 401. For Tipalti SOAP it computes the HMAC-SHA256 key from the exact payer name, idap, and timestamp on every call, and for the Procurement REST endpoints it sends OAuth2 or the x-api-key. The payer name must match Tipalti exactly or the signature fails silently, so it is validated at setup. Because Deltek has no accounting webhooks, vendors and AP invoices are polled with page and pagesize, while Tipalti payment IPNs are verified by recomputing the HMAC and then drive the payment writeback. GL accounts and tax codes are mapped first so every invoice line carries a valid code on both sides. Since Deltek has no idempotency key, ml-connector queries by invoice number before posting a payment, and Tipalti SOAP upserts are idempotent by nature. SOAP reads are kept under the 250-record cap and run as timestamp-incremental pulls, and Procurement REST PO reads respect the slow once-per-ten-minutes guidance. Edge cases are handled directly: updating a payee address in Tipalti forces the payee to re-confirm their payment method, so address changes are pushed deliberately, and the Deltek API user is given full field visibility because hidden fields return zero rather than an error. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A 300-person engineering and architecture firm runs Deltek Vantagepoint for projects, billing, and the general ledger, and pays subcontractors and overseas consultants through Tipalti. Before the integration, accounts payable approved bills in Deltek, then re-keyed each vendor and invoice into Tipalti to run the payment, and later typed the cleared payments back into Deltek so projects showed the true cost. With Deltek and Tipalti connected, approved AP invoices move into Tipalti automatically against the right GL codes, Tipalti pays them in the correct currency and method, and each completed payment posts back into Deltek as a payment transaction tied to the project. The double entry and the month-end chase to match payments to bills are gone.

What you can do

• •Push Deltek Vantagepoint vendor firms into Tipalti as payees, keeping master data aligned.
• •Send approved Deltek AP invoices into Tipalti as bills, coded to matching Tipalti GL accounts.
• •Write completed and failed Tipalti payments back into Deltek as payment transactions and journal entries.
• •Bridge Deltek OAuth2 tenant login with Tipalti HMAC-SHA256 SOAP signing and Procurement REST auth.
• •Act on Tipalti payment IPNs in real time while polling Deltek invoices on the schedule you set.

Questions

Which direction does data move between Deltek and Tipalti?

Both directions, with different jobs. Vendor firms and approved AP invoices move from Deltek Vantagepoint into Tipalti so payments can run, while completed and failed payment results move from Tipalti back into Deltek as payment transactions and journal entries. GL accounts and tax codes are aligned in both directions so invoice lines land on valid codes.

How does the integration handle Tipalti's two API families and signing?

Tipalti splits work across a SOAP API and a Procurement REST API with different auth. ml-connector computes the HMAC-SHA256 key from the exact payer name, payee id, and timestamp for SOAP calls, and uses OAuth2 or the static x-api-key for Procurement REST. The payer name must match exactly or the signature fails silently, so it is checked at setup.

Why does the integration poll Deltek instead of using webhooks?

Deltek Vantagepoint webhooks only fire on hub record saves such as firms and projects and carry no HMAC signature, so they do not cover accounting transactions. ml-connector therefore polls vendors and AP invoices on a schedule using page and pagesize parameters. Tipalti payment IPNs are used for the reverse flow and trigger the payment writeback into Deltek as soon as money moves.