Which direction does data move between Deltek and BigCommerce?

The main flow is BigCommerce into Deltek. Paid orders post into Deltek as AR invoices, while order transactions and refunds post as cash receipts and journal entries, and customers are aligned with Deltek firms. Deltek is the accounting system of record, so ml-connector does not write financial entries back into BigCommerce.

How does the integration handle BigCommerce webhooks that only contain an order id?

BigCommerce webhook payloads are stubs that carry only the resource type and id. ml-connector verifies the X-BC-Signature HMAC against the client secret, then calls the BigCommerce REST API to fetch the full order, transaction, or refund before posting it. A scheduled poll backfills any event the webhook stream missed.

Does Deltek's lack of an idempotency key risk duplicate invoices?

Deltek Vantagepoint has no native idempotency key header, so ml-connector queries Deltek by order number before posting and skips the write if the AR invoice already exists. Combined with BullMQ job dedup on the BigCommerce webhook, a replayed event does not create a duplicate invoice in the ledger.

DeltekBigCommerce

Deltek and BigCommerce integration

Deltek Vantagepoint runs project accounting and finance. BigCommerce runs the online store: orders, payments, refunds, and customers. Connecting the two moves store revenue into the ledger without re-keying. Paid BigCommerce orders post into Deltek as AR invoices against the matching client firm and project, the captured payments and refunds become cash receipts and journal entries, and storefront customers stay aligned with Deltek firms. ml-connector handles the very different authentication and data models on each side and moves the records on the cadence you set.

How Deltek works

Deltek Vantagepoint exposes firms, contacts, employees, projects, AR invoices, AP invoices, journal entries, cash receipts, and GL accounts through a REST JSON API on a tenant-specific https://{company}.deltekfirst.com/{company}/api/ URL, so there is no shared hostname. It authenticates with OAuth2 password grant, returning a bearer token sent on every request, and the password grant must be explicitly enabled in the customer instance. Reads use page-based pagination and there is no native idempotency key, so the caller checks for an existing record before posting. Webhooks are workflow-driven and carry no HMAC signature, so accounting data is read by polling. The older Costpoint product is SOAP and preprocessor based instead.

How BigCommerce works

BigCommerce is an e-commerce platform, not an ERP, so it has no native vendor, purchase order, or GL account objects. It exposes orders, order transactions, refunds, customers, and the product catalog through its REST Management API, with order CRUD on v2 and transactions and refunds on v3, keyed to a store hash in the URL. Every call carries a static X-Auth-Token access token rather than a bearer prefix, and order transactions are read-only and system generated. BigCommerce pushes order, customer, and product events by webhook, signed with HMAC-SHA256 in the X-BC-Signature header, but each payload is a stub holding only the resource type and id, so the full record is fetched with a follow-up REST call. v2 and v3 are both active and both needed.

What moves between them

The main flow runs from BigCommerce into Deltek. ml-connector reads paid and updated BigCommerce orders and posts them into Deltek Vantagepoint as AR invoices, mapped to the matching client firm and project, with the line totals and tax carried onto the invoice. Order transactions and refunds flow the same direction and post as cash receipts and journal entries so settled payments and returns land in the ledger. Storefront customers are aligned with Deltek firms so each order references a client that already exists. New order, customer, and refund webhooks trigger the work as it happens, and a scheduled poll backfills anything a webhook missed. Deltek is the system of record for accounting, so financial entries are never written back into BigCommerce.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the BigCommerce side it sends the store-hash access token in the X-Auth-Token header, and on the Deltek side it accepts the full tenant URL per customer, since Deltek publishes no shared base address, and refreshes the OAuth2 bearer token when a call returns 401. When a BigCommerce order, customer, or refund webhook arrives, it verifies the X-BC-Signature HMAC against the client secret, then calls the REST API to pull the full record because the webhook payload carries only the resource id. Customers and projects are mapped first, so every AR invoice references a Deltek firm and project that already exists, and order totals, tax, and shipping map onto invoice and journal lines because BigCommerce has no GL accounts of its own. Before posting an invoice ml-connector queries Deltek by order number, since Deltek has no idempotency key, so a replayed webhook does not create a duplicate. BigCommerce rate limits return HTTP 429 with reset headers, so the connector backs off and retries, and because Deltek cloud has no signed webhooks it polls accounting data on a schedule. Refunds on a single order are processed sequentially, since BigCommerce does not allow concurrent refunds on one order. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized professional services firm with about 120 staff runs Deltek Vantagepoint for project accounting and sells templates, training seats, and support plans through a BigCommerce store. Before the integration, a bookkeeper exported the store's orders and refunds each week and re-entered the revenue and customer details into Deltek by hand, which delayed billing and left storefront customers out of step with the client firms in the ledger. With Deltek and BigCommerce connected, each paid order posts into Deltek as an AR invoice tied to the right client and project, payments and refunds post as cash receipts and journal entries, and customer records stay aligned. The weekly re-keying step is gone and revenue reaches the ledger the day the order is placed.

What you can do

Post paid BigCommerce orders into Deltek Vantagepoint as AR invoices against the matching client firm and project.
Record BigCommerce order transactions and refunds in Deltek as cash receipts and journal entries.
Keep BigCommerce customers aligned with Deltek firms so every order references an existing client.
Verify each BigCommerce X-BC-Signature webhook and fetch the full order from the REST API before posting.
Bridge the BigCommerce store-hash access token and the Deltek tenant OAuth2 token, with retries and a full audit trail.

Questions

Which direction does data move between Deltek and BigCommerce?: The main flow is BigCommerce into Deltek. Paid orders post into Deltek as AR invoices, while order transactions and refunds post as cash receipts and journal entries, and customers are aligned with Deltek firms. Deltek is the accounting system of record, so ml-connector does not write financial entries back into BigCommerce.
How does the integration handle BigCommerce webhooks that only contain an order id?: BigCommerce webhook payloads are stubs that carry only the resource type and id. ml-connector verifies the X-BC-Signature HMAC against the client secret, then calls the BigCommerce REST API to fetch the full order, transaction, or refund before posting it. A scheduled poll backfills any event the webhook stream missed.
Does Deltek's lack of an idempotency key risk duplicate invoices?: Deltek Vantagepoint has no native idempotency key header, so ml-connector queries Deltek by order number before posting and skips the write if the AR invoice already exists. Combined with BullMQ job dedup on the BigCommerce webhook, a replayed event does not create a duplicate invoice in the ledger.

Connect Deltek and BigCommerce

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started