QuickBooks Desktop and BigCommerce integration

What moves between them

The main flow runs from BigCommerce into QuickBooks Desktop. New and updated BigCommerce orders become QuickBooks Desktop invoices or sales receipts, the ordering shopper is created or matched as a QuickBooks customer, and order transactions and refunds are recorded as received payments and credits against the mapped accounts. Catalog products map to QuickBooks items by SKU so totals land on valid income accounts. The reverse flow keeps the store in step: QuickBooks item prices and on-hand inventory levels are pushed up to the BigCommerce catalog so the storefront does not oversell. Order webhooks trigger the work, and a scheduled Web Connector poll backfills anything a webhook missed.

How ml-connector handles it

ml-connector stores both credential sets encrypted, sends the BigCommerce X-Auth-Token on every REST call, and answers the QuickBooks Web Connector authenticate handshake with a session ticket it validates on each SOAP method. Because the order webhook payload is only a type and id, the connector immediately calls GET on the v2 order, its products, and v3 transactions to assemble the full record before mapping it to a QBXML InvoiceAdd or SalesReceiptAdd. Since QuickBooks Desktop is pull only and QuickBooks must be open, posting is queued and applied on the next Web Connector cycle rather than in real time. Products are matched to QuickBooks items by SKU, and a customer is matched or created first so every invoice line references an item and name that already exist. QBXML has no idempotency key, so the connector queries by RefNumber before adding to avoid duplicate invoices, and re-reads the EditSequence before any update. BigCommerce returns HTTP 429 when its 30-second rate window is exceeded, so calls back off and retry, and every record carries a full audit trail and can be replayed if a post fails.

A real-world example

A mid-sized outdoor gear retailer with about forty staff sells through a BigCommerce store and keeps its books in QuickBooks Desktop Enterprise on an in-office Windows server. Before the integration, a bookkeeper exported the daily order list from BigCommerce and hand-keyed each sale, payment, and refund into QuickBooks, and the warehouse separately edited stock counts in two places, which led to oversells during sales. With QuickBooks Desktop and BigCommerce connected, every store order posts as an invoice with the customer and payment attached on the next Web Connector cycle, refunds record themselves, and QuickBooks on-hand quantities push back to the catalog. The daily re-keying is gone and the storefront stock stays accurate.

What you can do

• •Turn BigCommerce orders into QuickBooks Desktop invoices or sales receipts with the matching customer.
• •Record BigCommerce captured payments and refunds against the correct QuickBooks Desktop accounts.
• •Match BigCommerce catalog products to QuickBooks items by SKU so sales hit valid income accounts.
• •Push QuickBooks item prices and on-hand inventory levels back to the BigCommerce catalog to prevent overselling.
• •Bridge the BigCommerce static API token and the QuickBooks Web Connector SOAP session, with retries and a full audit trail on every record.

Questions

Which direction does data move between QuickBooks Desktop and BigCommerce?

The main flow is BigCommerce into QuickBooks Desktop: orders become invoices or sales receipts, shoppers become customers, and payments and refunds post against the mapped accounts. The reverse flow pushes QuickBooks item prices and on-hand inventory levels back to the BigCommerce catalog. Each side moves the data it owns, so revenue stays in QuickBooks and stock levels stay current in the store.

How does the integration reach QuickBooks Desktop when it has no cloud API or webhooks?

QuickBooks Desktop runs locally, so the QuickBooks Web Connector on the same Windows machine relays QBXML requests to the open company file over SOAP, and ml-connector answers its authenticate handshake with a session ticket. Because there are no QuickBooks webhooks, the connector listens for BigCommerce order webhooks and posts the result on the next Web Connector poll. QuickBooks must be open for the cycle to run, so the sync is near real time rather than instant.

How are duplicate orders and inventory conflicts avoided?

QBXML has no idempotency key, so ml-connector queries QuickBooks by the order RefNumber before adding an invoice and re-reads the EditSequence before any update. BigCommerce order webhooks deliver only a type and id, so the full order is fetched by REST before posting. Inventory pushes use the SKU to target the right catalog product and variant so counts update the correct item.