HubSpot + QuickBooks Desktop integration

QuickBooks Desktop keeps a company’s books in a single company file on a Windows machine, and every integration has to reach that file where it sits. Intuit’s documentation is plain about the consequence: an application talks to QuickBooks through a request processor over COM, which means the same machine or, configured with care, the same local network. Nothing on the internet can call it directly.

Intuit is also steering new customers elsewhere. In the United States it stopped selling new Desktop Pro Plus, Premier Plus and Mac Plus subscriptions after September 2024, and in Canada Desktop Pro and Premier have not been sold to new subscribers since April 2025. Existing subscribers can renew, Desktop Enterprise is still sold in both countries, and Intuit calls Enterprise its flagship Desktop product. Its 2024 releases were the last annual ones, with continuous updates since.

So the businesses asking are the ones staying: Enterprise users, whose industry editions Intuit lists for contractors, manufacturing and wholesale, retail and nonprofits, and Pro or Premier subscribers who keep renewing. What they want is familiar: the balance, the open orders and the last invoice on the HubSpot company. One decision comes first, though. Will the books stay on Desktop long enough to justify a build, or is the better project a move to QuickBooks Online, where HubSpot publishes its own app?

Six objects cover it, all read with qbXML queries and moved one way into HubSpot. Top-level customers become companies, jobs become a custom job object, customer contacts become contacts, sales orders become deals, invoices land on a custom invoice object and items become products.

Jobs are the part that catches people out. QuickBooks keeps customers, jobs and subjobs in one hierarchical list: a job is a customer with a parent, a sublevel above zero and a full name built from its ancestors, joined by colons. One customer query returns all of them. We split them on the sublevel and associate each job to the company at the top of its parent chain.

Keys are QuickBooks identifiers, never names. Intuit’s own guidance is to key list records on the ListID, which unlike the full name is guaranteed not to change, and every transaction carries a TxnID that QuickBooks assigns and guarantees will stay the same. Invoice and order reference numbers stay as readable labels.

Sales orders exist only in Premier and Enterprise. On Pro, where Intuit says sales orders are not available, estimates take their place.

The runtime is Intuit’s own go-between, the QuickBooks Web Connector. It is a Windows application installed where the company file is saved, and it calls our web service over HTTPS on the schedule the user sets, so nothing on the QuickBooks side opens a port. The service implements the SOAP methods the Web Connector expects: authenticate returns a session ticket, sendRequestXML hands over the next qbXML request, and receiveResponseXML takes the answer.

Each session asks for what changed since the watermark, using FromModifiedDate on lists and ModifiedDateRangeFilter on transactions, and pages with an iterator. Deletions come from ListDeletedQuery and TxnDeletedQuery. The service upserts into HubSpot in batches keyed on ListID and TxnID, then runs the association pass. Polling is the only choice: the SDK’s event notifications reach only a program on the same machine, and only while QuickBooks has the file open on screen.

State lives in the service: a watermark per object, the FileID the Web Connector stored in the company file, and the last restore time. A replay is a request for a modified-date range. A later write back sends CustomerAdd or SalesOrderAdd, and a modify carries the record’s EditSequence, which QuickBooks checks first.

On Desktop every route puts software on the machine that holds the company file, so the real choice is whose software, and how much it can do.

A custom API integration uses the Web Connector Intuit supplies and a service we run. It reads changes, deletions and restores, keys on ListID and TxnID, and can write back through QuickBooks’ own validation.

A managed sync on Skyvia puts Skyvia’s agent on the QuickBooks machine instead. Skyvia documents syncing QuickBooks Desktop with cloud apps, but the agent must run as an application under the same Windows user as QuickBooks, so a session has to stay signed in.

Commercient’s QuickBooks Desktop app is the packaged third route, a third-party sync whose mapping and support stay with Commercient. And if the books are moving to QuickBooks Online anyway, the QuickBooks Online page covers HubSpot’s own app, which may make a Desktop build unnecessary.

1. Scope. We confirm the edition and year, where the company file lives, whether it runs in multi-user mode or with a hosting provider, and whether a move to QuickBooks Online is planned.
2. Architect. We fix the objects, the ListID and TxnID keys, the job mapping, the watermark per object and the Web Connector schedule.
3. Build. The service is built against a not-for-resale copy and a copied company file, with the Web Connector pointed at a test endpoint and a portal allowlist from the first commit.
4. Validate. We compare customer and job counts and open invoice totals with QuickBooks reports, and walk the differences with the bookkeeper.
5. Operate. We alert when a scheduled session does not arrive, keep replay available, and run a full comparison after any restore or long pause.