What connects to QuickBooks

QuickBooks Online keeps customers, invoices, payments and the income accounts behind them for many small and growing companies. Deals are won and money is collected elsewhere, so QuickBooks mostly receives data and reports status back.

That defines its integrations. A CRM hands over won deals as invoices against real items and gets payment status back, as in HubSpot and QuickBooks or QuickBooks and Salesforce. A payment provider delivers charges, refunds, disputes and payouts that have to be booked individually so deposits match the bank, see Stripe to QuickBooks. In both directions QuickBooks is the stricter side: it rejects what it cannot resolve, and the pipeline has to prepare records it will accept rather than find out at month-end.

Where QuickBooks integrations break

Customer display names must be unique. QuickBooks requires a unique display name across the company file. Two CRM accounts with the same name, or an existing customer spelled slightly differently, are rejected on write or end up as duplicates that split receivables.
Every invoice line needs a real item. Lines reference an item mapped to an income account. A product that does not exist in QuickBooks fails the invoice, so unknown lines are held and flagged, never posted to a catch-all item.
Currency is fixed per customer. Once a customer has transactions its currency cannot change, and an invoice in another currency is refused. Currency and closed periods are validated before an invoice is attempted.
Updates need care. Every entity carries a version token that must match on update, and an update that is not sparse treats missing fields as blanks. Sparse updates plus re-read-and-retry prevent silently wiped addresses and terms.
Tax behaviour differs by region. A US company calculates sales tax itself and overrides what you send; UK and international companies expect VAT codes and an explicit inclusive or exclusive setting.