Deltek and WooCommerce integration

What moves between them

The main flow runs from WooCommerce into Deltek. When an order reaches a paid or completed status, ml-connector reads the full order and posts it into Deltek as an AR invoice against the mapped project and client firm, carrying line items, taxes, and totals. The WooCommerce customer is created or matched as a Deltek client firm so the invoice has a valid owner. WooCommerce refunds flow the same direction and post as offsetting credit entries in Deltek. Product and price reference data is aligned so each invoice line points at an item Deltek recognizes, and the cadence is event-driven on order webhooks with a scheduled poll as a safety net.

How ml-connector handles it

ml-connector stores both credential sets encrypted. It presents the WooCommerce Consumer Key and Secret as HTTP Basic on every store call, and on the Deltek side it accepts the full tenant URL per customer, runs the OAuth2 password grant, and refreshes the bearer token when a call returns 401. WooCommerce order webhooks are verified by recomputing the base64 HMAC-SHA256 of the raw body and comparing it to the X-WC-Webhook-Signature header, rejecting any mismatch. Because Deltek has no signed webhook, changes there are read by polling on your schedule. Customers map to Deltek client firms and store products map to invoice line items before any posting, so every AR invoice references a firm and project that already exist. Deltek has no idempotency key, so ml-connector checks for an existing invoice by order number before creating one. It also watches for a WooCommerce webhook that has auto-disabled after five failures, and applies automatic retries, a full audit trail, and error replay on every record.

A real-world example

A regional design and engineering consultancy of about 80 people sells fixed-price report packages and template products through a WooCommerce storefront, while running Deltek Vantagepoint for project accounting and client billing. Before the integration, a bookkeeper exported store orders each week and hand-entered them as AR invoices in Deltek, matching each buyer to a client record and chasing refunds that never made it into the ledger. With Deltek and WooCommerce connected, each paid order posts itself as an AR invoice against the right project the moment it completes, new buyers become client firms automatically, and refunds post as credits. The weekly export is gone and store revenue reconciles against the project ledger on its own.

What you can do

• •Post completed WooCommerce orders into Deltek as AR invoices against the mapped project and client firm.
• •Create or match a Deltek client firm from each WooCommerce customer so invoices have a valid owner.
• •Reflect WooCommerce refunds as offsetting credit entries in Deltek.
• •Verify signed WooCommerce order webhooks and poll Deltek on a schedule you control.
• •Check for an existing invoice by order number before posting, with retries and a full audit trail on every record.

Questions

Which direction does data move between Deltek and WooCommerce?

The main flow is WooCommerce into Deltek. Paid orders post as AR invoices, customers become Deltek client firms, and refunds post as offsetting credits. Reference data such as products and projects is aligned so each invoice line lands on an item and firm Deltek recognizes.

How does the integration know when a new order is placed?

WooCommerce sends an outbound webhook on order events, signed with a base64 HMAC-SHA256 of the raw body in the X-WC-Webhook-Signature header. ml-connector recomputes that hash and rejects any mismatch before processing. A scheduled poll also runs as a safety net, since WooCommerce auto-disables a webhook after five consecutive failed deliveries.

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

Deltek Vantagepoint does not offer an idempotency header, so duplicate prevention is handled by the connector. Before posting an order, ml-connector queries Deltek for an existing AR invoice carrying that order number and only creates one if none is found. Combined with error replay, this keeps a retried delivery from producing a second invoice.