A typical service business keeps three records of the same customer. The appointment lives in a calendar, the deal lives in the CRM and the invoice lives in QuickBooks. Somebody copies details between them, usually at the end of a long day, and the copies drift apart.
A good integration removes the copying. It also removes a quieter cost: the minutes spent checking whether an invoice was paid before chasing a customer who already paid it.
What a QuickBooks CRM integration should do
A QuickBooks CRM integration is a set of automatic flows that keep customer, sales and payment records consistent between QuickBooks Online and the systems your team works in every day. For most service businesses, four flows deliver most of the value:
- Won deal to customer. When a deal is won in the CRM, find the matching customer in QuickBooks or create one, then store the QuickBooks customer ID on the CRM record.
- Completed job to invoice. When a job is marked complete, draft the invoice in QuickBooks with the agreed line items.
- Payment to pipeline. When a payment is recorded in QuickBooks, mark the deal as paid in the CRM and stop any reminder sequence.
- Booking to activity. When an appointment is booked or moved, update the calendar and log the activity on the CRM contact.
Notice the order of operations in the first flow: search, then create. Most duplicate-customer problems come from integrations that create first and ask questions later.
Decide which system owns each field
Two-way sync sounds like the safe choice. In practice, it is where most conflicts start, because two systems both believe they hold the true version of an address or a price. Decide ownership field by field before anyone writes code.
| Data | System of record | Copied to | Direction |
|---|---|---|---|
| Contact name, phone, email | CRM | QuickBooks | One way |
| Billing address and tax settings | QuickBooks | CRM, read-only | One way |
| Invoices, payments, balances | QuickBooks | CRM, read-only | One way |
| Appointments | Calendar or booking system | CRM | One way |
| Deal stage and notes | CRM | Not copied | None |
Reserve true two-way sync for the rare fields both teams genuinely edit, and write down which side wins a tie.
Webhooks, polling and the API meter you cannot see
An integration learns about changes in one of two ways. Polling asks QuickBooks "anything new?" on a timer. Webhooks let the other system tell you when something changed. Polling is simpler to build and wasteful to run, and with QuickBooks the waste is now metered.
Under Intuit's App Partner Program, calls that write data into QuickBooks, such as creating invoices or customers, are classed as Core and are neither metered nor charged. Calls that read data out, such as querying accounts, company information or reports, are classed as CorePlus and are metered. The free Builder tier includes 500,000 CorePlus calls a month, and calls above that are blocked; the paid Silver tier costs US$300 a month.
Here is why that matters, as an illustrative example. An integration that polls five record types every 30 seconds makes 2 calls a minute per type: 14,400 calls a day, or 432,000 calls in a 30-day month (5 x 2 x 60 x 24 x 30). That spends most of the free allowance asking a question whose answer is usually "no". Intuit meters only successful calls, but a poll that finds nothing new is still a successful call. An integration that reacts to change notifications and then reads only the changed record uses a small fraction of the allowance.
Calendars have their own housekeeping. Google's Calendar API can push change notifications to your server, but its documentation notes there is no automatic way to renew a notification channel: when one nears expiry, your integration must replace it. An integration without a scheduled renewal job works perfectly for a while, then goes quiet.
What per-task pricing looks like at your volume
Per-task automation tools are often the right place to start. Zapier counts each successful action step as a task, while triggers, filters and steps that error do not count. Make bills in credits, with one credit per operation by default for standard apps. Both models are fair at low volume. The question is what happens as you grow.
An illustrative example: each won job runs four actions (find or create the customer, create the invoice, update the deal, send a confirmation). At 300 jobs a month, that is 1,200 tasks. Add calendar syncing at two actions per booking for 400 bookings, another 800 tasks, for 2,000 tasks a month. Price that on your tool's current plans, then price it again at double the volume. If the second number makes you wince, an owned integration deserves a look. We compare the main tools in detail in n8n vs Zapier vs Make vs custom automation.
How to build it in five steps
- Map the flows on one page. For each flow, write the trigger, the records touched, the owner of each field and what should happen on failure.
- Clean the data first. Merge duplicate customers in both systems and pick one matching key, usually the email address or a stored QuickBooks customer ID.
- Ship the smallest valuable flow. Payment recorded, deal updated is a good first flow: low risk and immediately useful.
- Make every step safe to repeat. Store external IDs on each record, so a retried event updates the existing invoice instead of creating a second one. Retry temporary failures automatically and send permanent ones to a named person.
- Watch it. A short daily summary of failed syncs, renewed calendar channels and API usage catches problems before customers do.
Two housekeeping rules apply whoever builds it. First, connect QuickBooks, the CRM and the calendar through accounts the business owns, not a contractor's personal login, so access survives a change of supplier. Second, give the integration only the access it needs, keep its credentials encrypted, and log every write it makes, so your bookkeeper can trace any figure back to the event that created it.
OWNIT builds these as owned integrations: the code, the logic and the accounts are yours, there are no per-task fees, and error alerts are part of the build rather than an add-on.
When an owned integration isn't worth it
- A maintained native connector already covers your flows. Check your CRM's app marketplace first. If a connector handles your four flows at your volume, use it.
- Volume is low. A few hundred tasks a month on a per-task tool usually costs less than building and hosting anything.
- The process is still changing. If your quoting or invoicing steps change monthly, prototype in a visual tool until they settle.
- Nobody will watch the alerts. Any integration, owned or rented, fails silently without an owner. Assign one before you automate.
If you want a second opinion on your stack, OWNIT maps flows like these on a free 30-minute strategy call. See how our integrations service works.
Frequently asked questions
Does QuickBooks Online charge for API access?
Under Intuit's App Partner Program, calls that write data into QuickBooks are not metered, while calls that read data out, called CorePlus, are. The free Builder tier includes 500,000 CorePlus calls a month and blocks calls above that; the paid Silver tier costs US$300 a month. An integration that reads only the records that changed uses far fewer calls than one polling on a timer.
Should my CRM or QuickBooks be the source of truth for customer data?
Split it by field. The CRM usually owns contact details, deal stage and notes, because sales and service teams edit them daily. QuickBooks should own billing addresses, tax settings, invoices and payments, because those must match your books. Copy each field one way from its owner, and keep two-way sync for the few fields both teams genuinely edit.
Can Zapier connect QuickBooks to my CRM?
Yes, for straightforward flows. Zapier counts each successful action step as a task, so cost grows with volume and with the number of steps in each flow. It suits low volumes well. As volume grows, or when you need retries, duplicate protection and audit logs, an owned integration often becomes cheaper to run and easier to trust.
How do I stop an integration from creating duplicate customers in QuickBooks?
Search before you create, using one matching key such as the email address. When a match is found or a new customer is created, store the QuickBooks customer ID on the CRM record and use it for every later update. Design each step so it can be retried safely, and review a weekly report of possible duplicates.
Sources
Written by The OWNIT Editorial Desk and reviewed against public sources. General information, not legal or financial advice. Spotted an error? Email hello@ownit24.com and we will correct it.
