Deltek and Avalara integration

What moves between them

The main flow runs from Deltek into Avalara. ml-connector reads new and changed AR invoices from Deltek Vantagepoint and posts each as an AvaTax SalesInvoice transaction, mapping line amounts, item tax codes, and the client ship-to address, then writes the calculated tax amount and rate back onto the Deltek invoice. AP invoices are posted as PurchaseInvoice transactions so consumer use tax is self-assessed and recorded for filing. Returns and credit memos are sent as ReturnInvoice transactions, and committing a Deltek invoice commits the matching AvaTax document. Avalara holds no projects, vendors, or GL accounts, so those stay in Deltek and ml-connector never writes master or ledger data back from AvaTax.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Deltek side it requests a password-grant OAuth 2.0 token against the tenant deltekfirst.com URL per customer and refreshes it before expiry, and it requires the API user role to have full field visibility so amount fields do not return as zero. On the Avalara side it sends HTTP Basic auth built from the account ID and license key, and switches between the production and sandbox base URLs because sandbox credentials are rejected in production. Because Deltek's webhooks are workflow-only and unsigned, ml-connector polls Vantagepoint AR and AP invoices on a schedule rather than relying on a push, paging through the REST results. Each ship-to address is run through the AvaTax address resolve endpoint first, since an unvalidated address fails tax calculation, and the Deltek invoice number is used as the AvaTax document code so a retried invoice updates in place. The createOrAdjust call is used for uncommitted documents, while a committed AvaTax transaction is voided and re-created or adjusted rather than overwritten, because a committed code cannot be reused. AvaTax rate limits return HTTP 429 with no Retry-After header, so ml-connector backs off with jitter and retries, and every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized engineering consultancy with about three hundred staff runs Deltek Vantagepoint for project billing across clients in a dozen states. Before the integration, a billing analyst looked up the right tax rate for each client invoice by hand and keyed it into Vantagepoint, which meant occasional wrong rates, missed economic nexus thresholds, and a stressful manual reconciliation every filing period. With Deltek and Avalara connected, each AR invoice is sent to AvaTax for a destination-based rate as it is raised, the tax is written back onto the Deltek invoice automatically, and purchase invoices are self-assessed for use tax. Filing periods start from AvaTax records that already match the ledger, and the manual rate lookups are gone.

What you can do

• •Post Deltek Vantagepoint AR invoices to Avalara AvaTax as SalesInvoice transactions for destination-based tax calculation.
• •Write the calculated tax amount and rate from AvaTax back onto the matching Deltek invoice.
• •Self-assess consumer use tax on Deltek AP invoices by posting them as AvaTax PurchaseInvoice transactions.
• •Validate each ship-to address against the AvaTax resolve endpoint and use the Deltek invoice number as the document code for safe retries.
• •Bridge Deltek password-grant OAuth to Avalara HTTP Basic auth, with backoff on 429 and a full audit trail on every record.

Questions

Which direction does data move between Deltek and Avalara?

The main flow is Deltek into Avalara. AR invoices, AP invoices, and credit memos move from Deltek to AvaTax as SalesInvoice, PurchaseInvoice, and ReturnInvoice transactions, and the calculated tax is the only thing written back, onto the Deltek invoice. Avalara holds no projects, vendors, or GL accounts, so ml-connector never writes master or ledger data back from AvaTax.

Does Avalara push tax results, or does ml-connector poll Deltek for invoices?

ml-connector polls Deltek, because Deltek's webhooks are workflow-triggered callbacks without an HMAC signature rather than a reliable event stream, and AvaTax does not push events at all. It reads new and changed AR and AP invoices from Vantagepoint on a schedule, sends them to AvaTax, and the calculated tax is returned inline on the CreateTransaction call, so no separate result poll is needed.

How does the integration avoid double-counting tax if an invoice is sent twice?

AvaTax uses the document code on each transaction as its idempotency key, and ml-connector sets that code to the Deltek invoice number. Re-sending an uncommitted invoice updates the same AvaTax document in place through the createOrAdjust call, while a committed document is voided and re-created or adjusted rather than overwritten, since a committed code cannot be reused. That keeps one AvaTax transaction per Deltek invoice even on retries.