HubSpot + QuickBooks Online integration

A QuickBooks Online company file is usually run by one or two people, and everybody else in the business queues up to ask them questions. Has this customer paid. Are they on hold. Did we ever bill for the second phase. The answers sit in QuickBooks, the questions come from sales and service, and the distance between them is a message and a wait.

That is a small problem until the company grows past the point where one person can answer. Then it turns into three visible costs. Sellers discount for an account that is ninety days overdue. Service keeps working for a customer finance has already stopped invoicing. Somebody creates a second customer record because the first one was spelled differently, and the bookkeeper spends a morning merging them back.

Connecting the two systems is less about moving data than about moving the answer to where the question gets asked. Almost every engagement we scope here lands in the same place: finance keeps the ledger, HubSpot gets a read only view of it beside the deal and the company, and the only thing that ever moves the other way is a closed won deal that legitimately creates a customer. That shape is small enough that the packaged app often covers it, which is why this page spends as much time on when not to build as on how.

Five objects cover almost every QuickBooks engagement. The customer becomes a HubSpot company, invoices and payments land as custom objects beside it, items become products, and estimates become deals where quoting genuinely happens in QuickBooks rather than in HubSpot.

Invoices belong on a custom object, not on the deal. A deal is a pipeline record with a stage and a close date, and an invoice is an accounting document with a balance. Forcing one into the other gives you a pipeline full of closed deals that reopen every time finance issues a credit note.

The key is the QuickBooks id, stored in a custom HubSpot property, on every object. Display names are the obvious match key and the wrong one, because bookkeepers rename customers as a matter of routine. Payments key on their own id and associate to the invoice they settle, so a part payment against three invoices resolves correctly instead of landing on whichever one was read first.

The packaged route has no architecture you control. The app authorizes against one company file, syncs the fields it supports on its own schedule, and holds its state where you cannot see it. That is the trade, and for a single company file with a stable mapping it is a good one.

A built service is a webhook queue with a sweep behind it. QuickBooks posts an event when an entity changes, the endpoint verifies it and writes the entity id onto a queue, and a worker reads the full record and upserts it into HubSpot as a batch keyed on the QuickBooks id. Associations run as a separate pass, so a replay is safe.

The sweep is what makes it trustworthy. Once a night the service asks change data capture for everything that moved in the last day and reconciles it against what the queue processed. Webhooks get lost. A watermark sweep behind them turns a silent gap into a logged difference.

The question that decides this one is whether finance data needs to be visible or actionable. If sellers just need to see the invoice and the balance before a call, HubSpot’s own app does that with no service to host and no on-call rotation, and we will tell you so.

It stops being enough at three points. When invoice status has to trigger something, because the app syncs fields rather than firing events. When there is more than one company file, because each one authorizes separately. And when finance needs a field the mapping does not carry. A per-task automation platform is the route we steer away from here: every invoice and payment becomes a billable run, so the bill grows with the ledger while the value does not.

1. Scope. We check how many company files exist, which finance fields sellers need, and whether any workflow has to fire on invoice status. That last answer decides whether the packaged app is enough. Budget 4 to 8 hours of discovery and 8 to 24 hours of setup and validation for the native route.
2. Architect. We agree the field mapping and which side owns the customer record before anything is connected, and we name the trigger that would send this to a build.
3. Build. We install and authorize the app, review the mapping rather than accepting defaults, and wire the HubSpot workflows that use it.
4. Validate. We connect a sandbox or test company first, reconcile customer and invoice counts against a QuickBooks report, and check that nothing writes back what finance owns.
5. Operate. We watch for a sync going quiet, re-check the mapping when the chart of accounts changes, and escalate to a build when the app runs out of room.