QuickBooks Desktop and Zuora integration

What moves between them

Customer master data flows from QuickBooks Desktop into Zuora whenever a customer is created or modified in QuickBooks Desktop; ml-connector polls QuickBooks Desktop on the QBWC interval (every 5-15 minutes by default) to detect new or changed customers. Invoices created in Zuora flow back into QuickBooks Desktop as invoice records, mapped to the matching QuickBooks Desktop customer. Payments received in Zuora (for electronic payments) trigger a webhook to ml-connector, which then posts the payment into QuickBooks Desktop as a ReceivePayment transaction. The direction is asymmetric: customer and invoice metadata moves from QuickBooks Desktop to Zuora (pull via polling), while payment confirmations move from Zuora to QuickBooks Desktop (push via webhook).

How ml-connector handles it

ml-connector stores both credential sets encrypted and handles the multi-leg authentication on each poll cycle: on the QuickBooks Desktop side, it calls your SOAP endpoint with the QBWC username and password, receives a session ticket, and uses that ticket for all queries in that cycle until the session expires; on the Zuora side, it refreshes the OAuth bearer token when it expires (every hour) and presents it on each request. Because QuickBooks Desktop is polling-only, ml-connector accepts the QBWC interval from the customer's configuration and syncs on that schedule; Zuora webhooks are handled asynchronously so payment events can be processed as they occur without waiting for the next poll cycle. QuickBooks Desktop requires the current EditSequence (version counter) on update operations, so ml-connector re-queries the record before modifying to prevent conflicts with concurrent edits. QBXML requests timeout after approximately 60 seconds, so large customer or invoice queries are paginated. Zuora rate limits at 50,000 requests per minute in production, and ml-connector respects that by batching updates and backing off on 429 responses. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-market SaaS company manages billing through Zuora and accounting through QuickBooks Desktop running on a Windows machine in the office. Before the integration, the finance team exported new customer records from Zuora each week and manually entered them into QuickBooks Desktop, then ran monthly reconciliation between the Zuora invoice register and QuickBooks Desktop to find gaps and duplicates. With Zuora and QuickBooks Desktop connected, new customers in Zuora automatically appear in QuickBooks Desktop on the next QBWC poll cycle, invoices created in Zuora post directly into QuickBooks Desktop accounts receivable, and payment notifications from Zuora update customer balances in real time. The weekly manual customer entry is eliminated, and month-end reconciliation is automatic.

What you can do

• •Sync customer accounts from QuickBooks Desktop into Zuora whenever they are created or modified, detected via polling on the QBWC interval.
• •Post invoices created in Zuora back into QuickBooks Desktop as invoice transactions, mapped to the correct customer.
• •Receive payment notifications from Zuora webhooks and record payments in QuickBooks Desktop as ReceivePayment transactions.
• •Handle QBXML session-token authentication on QuickBooks Desktop and OAuth 2.0 on Zuora, with automatic token refresh.
• •Detect changes via QuickBooks Desktop ModifiedDateRangeFilter queries, respect EditSequence versioning on updates, and provide a full audit trail on every record.

Questions

Which direction does data move between QuickBooks Desktop and Zuora?

Customer accounts move from QuickBooks Desktop into Zuora via polling on the QBWC interval. Invoices created in Zuora post into QuickBooks Desktop as sales transactions. Payments received in Zuora (electronic payments) trigger webhooks that record the payment in QuickBooks Desktop as a ReceivePayment. The flow is asymmetric: pull from QuickBooks Desktop on a schedule, push from Zuora in real time.

What makes the SOAP polling architecture different from a typical REST webhook integration?

QuickBooks Desktop has no webhook capability; instead, a customer-hosted QBWC Windows agent periodically polls your remote SOAP service, and you must return session-token authenticated queries. ml-connector accepts the QBWC interval (minimum 1 minute, typical 5-15 minutes) from the customer's setup and detects changes using ModifiedDateRangeFilter so only new or modified records are processed. Every poll cycle requires a fresh session-token handshake via the SOAP authenticate() method.

How does ml-connector handle concurrent edits in QuickBooks Desktop?

QuickBooks Desktop uses EditSequence (a version counter on each record) to prevent concurrent modifications. ml-connector re-queries the record immediately before updating to obtain the current EditSequence, sends that in the modify request, and if the sequence has changed (because another user edited it), the request fails and ml-connector backs off and retries. This ensures edits do not overwrite each other.