Salesforce and QuickBooks, one customer record.
Sales closes the deal, finance issues the invoice, and somewhere between them the same customer exists twice under slightly different names. That is the problem worth solving first.
Why the stock connector isn’t the end of it.
Salesforce models the pursuit of revenue: accounts, opportunities, stages, forecasts. QuickBooks models money that has actually moved: customers, invoices, payments, aging. They overlap on exactly one entity — the customer — and disagree about almost everything else.
Most integration projects here start by asking which connector to buy and end up rebuilding six months later, because nobody decided which system owns the customer record. That decision governs deduplication, naming, address handling, and what happens when a rep edits an account after finance has invoiced it.
Where it breaks.
Each of these is something we have had to unpick on live systems.
Two systems, two customer records
Salesforce Accounts and QuickBooks Customers are created by different people at different times under different conventions. Without a single owner and a matching key, you accumulate duplicates that nobody notices until a statement goes to the wrong entity or revenue is attributed to the wrong parent.
Opportunity to invoice is not one-to-one
A closed-won opportunity might be one invoice, a deposit plus a balance, a milestone schedule, or a subscription. Connectors that assume one opportunity equals one invoice force your commercial model to fit the tool, which is backwards.
Payment status never reaches sales
Reps and account managers routinely have no idea whether an invoice was paid, so they chase renewals against unpaid accounts and finance chases collections without the relationship context. Pushing payment and aging status back to the Account is usually the highest-value half of the integration and the half most often skipped.
Desktop and Online are different projects
QuickBooks Online has a REST API that supports near-real-time sync. Desktop and Enterprise require the Web Connector or a bridge, run on a schedule, and depend on a machine being available. The architecture, the latency and the failure modes all differ, so the version you run is the first thing to establish.
Products and tax codes rarely line up
Salesforce Products and Price Books are built for selling; QuickBooks Items are built for accounting, with income accounts and tax codes attached. Line items will not transfer meaningfully until that mapping exists, and it is genuinely tedious work that no connector can infer for you.
How we approach it.
We start with a short discovery that produces one artefact: a field-level map of which system owns each fact, and what happens on conflict. It is unglamorous, it takes a few days, and it prevents the rebuild that follows from skipping it.
Then we implement the direction that carries the value. Customer and invoice creation flows one way; payment and aging status flows back. Bidirectional sync of the same field is avoided unless there is a genuine reason, because it introduces conflicts that have no correct automatic resolution.
Everything runs with an audit trail. When a record fails to sync, it lands in a queue somebody owns rather than disappearing — the difference between an integration your finance team trusts and one they work around.
Questions people actually ask.
Usually Salesforce, because the record is created there first during the sales process. The important part is that it is decided explicitly and enforced. The failure mode is not choosing wrong, it is having no answer and letting both systems create records independently.
For a straightforward pipeline with simple invoicing, often yes. It becomes limiting when your commercial model does not fit one-opportunity-one-invoice, when you are on QuickBooks Desktop, or when you need payment status flowing back into Salesforce in a form reps actually see.
With QuickBooks Online, close to it — event-driven within seconds. With Desktop you are working on a schedule through the Web Connector, so realistic expectations are minutes to hours depending on frequency and whether the host machine is running.
Backfill is a separate project from ongoing sync and should be scoped separately. It surfaces every duplicate and naming inconsistency accumulated over the years, which is valuable but not something to discover midway through a go-live.