Deltek and Zuora integration

What moves between them

The flow runs from Zuora into Deltek. ml-connector reads posted Zuora invoices and writes them into Deltek as AR invoices against the matching client firm, posts electronic payments as Deltek cash receipts, and records credit memos as Deltek journal entries or invoice adjustments. Customer accounts are aligned so each Zuora billing account maps to a Deltek client firm before any financial record is posted. Zuora callout notifications trigger the work as invoices post and payments clear, and a scheduled poll of Zuora backfills anything a callout missed. Zuora is the source of truth for billing, so ml-connector does not write ledger entries back into Zuora.

How ml-connector handles it

ml-connector stores both credential sets encrypted and runs two separate OAuth2 flows: a client-credentials token for Zuora that it caches and reuses until shortly before the one-hour expiry, and a password-grant token for Deltek that it refreshes when a call returns 401. It captures each customer's full tenant URL on both sides, since Zuora is multi-region and Deltek is one host per company, and validates entity paths against the live instances. Zuora callouts arrive with an HMAC signature and only the event object ID, so each notification is verified and then used to fetch the full invoice, payment, or credit memo from Zuora before mapping. Client firms and GL accounts are mapped first, so every AR invoice and cash receipt lands on a valid Deltek firm and account. Because Deltek has no usable event feed for this data and no idempotency key, ml-connector queries Deltek by invoice number before posting to avoid duplicates and polls Deltek to confirm each record was accepted. Posting an AR invoice may enter an approval workflow on the Deltek instance, so status is checked rather than assumed. Payment notifications fire only for electronic Zuora payments, so external payments are picked up by the scheduled poll. Every record carries a full audit trail and can be replayed if a Deltek post fails.

A real-world example

A mid-sized professional services firm of about two hundred staff runs Deltek Vantagepoint for project accounting and bills a growing book of managed-service retainers through Zuora. Before the integration, the finance team exported Zuora invoice and payment registers each month and keyed the totals into Deltek by hand, then spent the first days of close reconciling collected cash against the revenue accounts and chasing differences between the billing system and the ledger. With Deltek and Zuora connected, each posted invoice becomes a Deltek AR invoice and each cleared payment becomes a cash receipt automatically, mapped to the right client firm and accounts. Month-end close starts with revenue and cash already reconciled, and the manual re-keying step is gone.

What you can do

• •Post Zuora invoices into Deltek as AR invoices against the matching client firm and accounts.
• •Record electronic Zuora payments as Deltek cash receipts and credit memos as Deltek journal entries.
• •Keep Deltek client firms aligned with Zuora billing accounts so every posting lands on a valid firm.
• •Run both OAuth2 flows, caching the Zuora client-credentials token and refreshing the Deltek password-grant token on 401.
• •React to HMAC-signed Zuora callouts and poll Deltek to confirm posting, with retries and a full audit trail on every record.

Questions

Which direction does data move between Deltek and Zuora?

The flow is Zuora into Deltek. Posted invoices, electronic payments, and credit memos move from Zuora into Deltek as AR invoices, cash receipts, and journal entries, while billing accounts are matched to Deltek client firms. Zuora is the source of truth for billing, so ml-connector does not write ledger entries back into Zuora.

How does the integration use Zuora callouts and handle Deltek's lack of webhooks?

Zuora callout notifications fire on events like Invoice Posted and Payment Processed, signed with HMAC and carrying only the object ID. ml-connector verifies each callout, fetches the full record back from Zuora, then writes it into Deltek. Because Deltek has no usable event feed for this data, it is read by a scheduled poll that also backfills anything a callout missed.

How are duplicate postings prevented when Deltek has no idempotency key?

Deltek Vantagepoint does not offer an idempotency header, so ml-connector queries Deltek by invoice number before posting and only creates a record that does not already exist. On the Zuora side it uses the idempotency-key header on POST requests, and payment notifications fire only for electronic payments, so external payments are picked up by the scheduled poll instead.