QuickBooks Desktop and Databricks integration
QuickBooks Desktop stores your financial records locally on Windows. Databricks ingests them into a data warehouse where you can analyze spending, revenue, cash flow, and operational metrics across your entire organization. ml-connector accepts polling requests from the QuickBooks Web Connector agent at your customer's site, translates the SOAP and QBXML protocol into REST calls, and loads the records into Databricks Unity Catalog tables. No manual exports, no spreadsheets, no lag between QuickBooks and your analytics.
What moves between them
The main flow runs from QuickBooks Desktop into Databricks. The customer's QBWC agent polls ml-connector on a regular schedule, and ml-connector fetches the latest vendors, bills, purchase orders, invoices, customers, accounts, and journal entries from QuickBooks since the last sync. Each record is transformed into a row and loaded into a Databricks table in the customer's catalog and schema. Deletions in QuickBooks are tracked and soft-deleted in Databricks. Because QuickBooks is single-company per QBWC session, each customer's integration targets one company file; customers with multiple QuickBooks files require separate QBWC registrations and separate Databricks tables per file.
How ml-connector handles it
ml-connector implements a SOAP server that speaks QBXML. When the customer's QBWC agent calls ml-connector's endpoint, it provides a username and password, and ml-connector returns a session token (GUID) for that polling cycle. ml-connector then builds QBXML query requests using ModifiedDateRangeFilter to fetch only changed records since the last successful sync, paginating large queries to avoid the 60-second QBXML timeout. Before updating any record, ml-connector re-queries to obtain the current EditSequence, preventing collisions if the record has been edited in QuickBooks since the sync began. On the Databricks side, ml-connector obtains a fresh OAuth2 bearer token before each sync (accounting for the 3600-second expiry), authenticates to the customer's workspace, and performs bulk inserts or upserts into the target tables. If any Databricks write fails, ml-connector rolls back the QuickBooks polling cycle, preserving exactly-once semantics. Every QBXML request and response is logged with its full XML payload, and every Databricks table write is recorded in an audit table with timestamp, record count, and outcome.
A real-world example
A mid-sized B2B distributor runs QuickBooks Desktop to manage vendors, purchase orders, and invoices across three warehouses. The finance director needs to analyze spending by vendor, category, and warehouse without exporting QuickBooks reports by hand each month and pasting them into Excel. The operations team wants to see purchase trends and cash flow projections in real-time dashboards. QuickBooks Desktop is closed to direct API access, so the only way forward is the QBWC polling mechanism. With QuickBooks Desktop and Databricks connected, new vendor records, bills, and payments flow automatically into Databricks tables every 10 minutes, the finance team builds SQL views and Looker dashboards on top of the freshly-synced data, and they can answer spending questions without leaving their analytics tool or waiting for month-end close.
What you can do
- Sync QuickBooks Desktop vendors, bills, purchase orders, invoices, customers, and accounts into Databricks tables on a regular schedule.
- Translate SOAP/QBXML polling from the customer's local QBWC agent into REST/OAuth2 calls to Databricks.
- Prevent duplicate records by tracking edit sequences and re-querying before writes, ensuring exactly-once delivery.
- Handle the QBXML 60-second timeout by paginating large queries and the Databricks 3600-second token expiry by refreshing on each sync.
- Log every QBXML request, response, and Databricks write with full audit trails for compliance and troubleshooting.
Questions
- How does ml-connector work with the QuickBooks Web Connector if it is locally installed?
- The customer installs QBWC on their Windows machine running QuickBooks, and configures it to call ml-connector's SOAP endpoint at a regular interval (typically 5 to 15 minutes). ml-connector responds with QBXML requests wrapped in SOAP, and QBWC delivers those requests to the local QuickBooks instance and returns the responses. ml-connector never directly accesses QuickBooks; it always goes through QBWC polling.
- Why do we need to re-query edit sequences before updating records?
- QuickBooks uses an EditSequence field as a version counter on every modifiable object. If two processes edit the same record concurrently, the second edit fails unless it re-queries to get the new EditSequence. ml-connector re-queries before any write to obtain the current sequence, preventing collisions and ensuring no updates are lost.
- What happens to data if the QBWC agent is offline or QuickBooks is not running?
- If QBWC cannot reach ml-connector or if QuickBooks is closed, the polling cycle fails, and ml-connector does not write to Databricks until the next successful cycle. ml-connector logs the failure and alerts the customer to check that QBWC is running and QuickBooks is open and logged in. The next successful poll will fetch all records modified since the last successful sync, ensuring no data is lost.
Related integrations
More QuickBooks Desktop integrations
Other systems that connect to Databricks
Connect QuickBooks Desktop and Databricks
Free to use. Add your credentials, ping your real systems, and see if we fit.
Get started