Most businesses that run a CRM alongside accounting software have someone who keeps two browser tabs open all day — the CRM in one, the accounting software in the other — retyping the same customer name into both. Sometimes that is ten minutes at the end of the day. Sometimes it is a half-time job nobody ever put in a budget.
The question that follows is always: what would it cost to make these two systems talk to each other? It depends on which of three levels you need — and you can work that out in twenty minutes, on your own numbers, before you call anyone.
Start with what the manual process already costs
People shop for an integration without ever pricing the problem it solves. Before you open a vendor page, run three numbers.
1. The keystroke cost. Count the records re-typed each week — customers, invoices, payments, status changes — and time yourself doing five of them honestly, including finding the record and switching tabs. Multiply by a loaded hourly cost: salary plus payroll tax plus benefits, not the wage. Placeholders to show the shape, not anyone’s real numbers: 40 records a week at 4 minutes each is about 139 hours a year, or roughly $3,900 at a $28 loaded rate.
2. The error cost. Skip the industry averages. Pull the last hundred records that exist in both systems, compare five fields on each, and count how many carry at least one mismatch. That is your real error rate. Then price one mismatch: an invoice mailed to a stale address, a rate updated in the CRM but not in QuickBooks, a duplicate customer record that quietly splits a year of revenue reporting in half.
3. The invoicing lag. This one dwarfs the other two and almost nobody counts it. Measure the average days between “work is done” and “invoice is sent,” then multiply average monthly invoiced revenue by (lag days ÷ 30). Made-up numbers again, same shape: six days of lag on $120,000 a month is roughly $24,000 sitting in the gap between a CRM record and an accounting entry — not once, but continuously.
Level 1: check whether the integration already exists
Before anyone builds anything, spend twenty minutes on the vendor marketplaces: Salesforce has AppExchange, HubSpot has its App Marketplace, Xero has the Xero App Store, NetSuite has SuiteApp. Common pairings are well covered — HubSpot and QuickBooks Online have had a first-party sync for years, and Intuit ships a Salesforce connector with its higher-tier QuickBooks Online plan.
A native connector is the right answer when it fits, and the test is narrow: it syncs the objects you care about, in the direction you care about, with a field mapping you can live with as-is. They handle the obvious flows well — closed-won opportunity becomes invoice, recorded payment marks the deal paid.
Where they stop is field mapping and conditional logic. Most expose a fixed set of mappable fields, so if your logic lives in three custom fields and a picklist you invented, the connector ignores them. And they rarely let you say “except when.” Every business has an except-when.
Level 2: Zapier or Make, for flows that stay simple
Zapier and Make are good products for simple flows. If your flow is “when a deal is marked closed-won in HubSpot, create a draft invoice in Xero,” and there is exactly one path through it, build that in Zapier this afternoon and stop reading.
Both price by volume — Zapier by task, Make by operation — so the bill scales with record count, not with the difficulty of the logic. A flow touching 200 records a month is cheap; the same flow at 40,000 is a line item you notice. And triggers are not all instant: where an app supports a real webhook trigger things happen in seconds, and where it does not, the platform polls on an interval and your “real-time” sync is really a “within a few minutes, usually” sync. Of the two, Make handles branching and error routes considerably better, so if your logic is still linear it is often the right step before custom code.
Where no-code actually breaks
Five things tend to break no-code integrations.
- Multi-step conditional logic. The first “if” is easy; the fourth is the problem. “If the deal is over $10,000 and the customer is on net-30 and this is a renewal and they are tax-exempt, use this account code” becomes a tree of branches nobody can read, test, or safely change six months later. In code it is fifteen lines with a test around them.
- Volume. Two ceilings arrive at once: the per-task bill, and the API rate limits underneath. Salesforce allocates daily API requests by license count, QuickBooks Online throttles per company, Xero publishes per-minute and per-day caps per tenant, NetSuite governs concurrency. A no-code platform firing one call per record walks into those walls; a custom integration batches, queues, and uses bulk endpoints.
- Error handling and retries. When a sync fails at 2am — expired token, vendor outage, one record with a malformed tax ID — what happens next? Zapier retries some failures and eventually switches the Zap off and emails somebody. If that somebody is a shared inbox, the sync is down for a week before anyone notices. What you want instead: retry with backoff, quarantine the one bad record rather than halting the run, alert a human who is on the hook, and make it trivial to replay just the failures.
- Anything needing an audit trail. Once accounting is involved, someone will ask who created this invoice, when, from which CRM record, and what the field looked like before. No-code run histories are organized by run, not by your invoice number, and kept for a window that depends on your plan. A custom integration writes a log row per record — source ID, destination ID, timestamp, payload, outcome — so you answer in one query.
- Field mapping that changes. The mapping is never finished. Sales adds a field, accounting splits a revenue code, a customer changes the columns in the file they send you. In a no-code chain each change means someone clicking through the builder, remembering conventions that live only in their head. You want that mapping written down once, in a form you can read, diff, and roll back.
Level 3: what a custom integration actually involves
The part people expect is the code. The part that decides the cost is everything around it:
- A field-mapping document — every object, field, direction, transformation rule, and what to do when a value is missing. This is usually where departments find they disagree about the mapping.
- Authentication that survives: OAuth with real refresh-token handling, credentials in environment configuration rather than pasted into a UI, and an alert when a token stops refreshing.
- The sync engine — webhook receivers for what has to be fast, scheduled jobs for nightly reconciliation, a queue between them so a slow third-party API never blocks anything else.
- Idempotency — the same event will arrive twice, and if the second arrival creates a second invoice you have a machine for generating awkward phone calls.
- Error handling, retries, quarantine, alerting — plus a log table, which gives you the audit trail for free.
- The historical backfill: reconciling what already exists on both sides, often the hardest part of this kind of work.
What drives the cost, roughly in order:
- One-way or two-way. Two-way is more than twice the work: you inherit conflict resolution and loop prevention, because A updates B, which fires a webhook back into A.
- Object count. Customers only is small. Add invoices, payments, credit memos, products, and tax codes and it is six projects with dependencies.
- Data quality today. Three versions of the same customer get reconciled before the first sync runs, and that clean-up can be larger than the build.
- Sandbox availability. Salesforce and NetSuite have one. Testing against live accounting data is slow, careful work, and careful is billable.
- Latency and history. A nightly batch is straightforward; sub-minute delivery is different engineering; four years of back-history is different again.
I price this hourly with a clear estimate up front: thirty minutes on a call to understand the problem, then within a week a written summary of what I would build, in what order, with an hours estimate you can budget against. Longer relationships move to a retainer.
The question nobody asks: what happens when the vendor changes their API
This is the difference between an integration that lasts and one that becomes an emergency, and it rarely comes up in the sales conversation.
APIs change, and the changes are not hypothetical. HubSpot retired API-key authentication in favor of private apps and OAuth, and every integration built on a key had to be reworked. Intuit moved QuickBooks Online from OAuth 1.0a to OAuth 2.0 with a hard cutoff. Salesforce retires older API versions on a published schedule, so an integration pinned to an old one eventually stops being supported. None of these were surprises — all were announced well in advance, by email, to a developer address.
Which raises the real question: who reads that email at your company?
If the answer is nobody, the notice arrives, gets filed, and eleven months later invoices stop syncing on a Tuesday morning. The maintenance arrangement matters more than the build, and it should cover three things: the developer contact on file is someone who reads it, the sync alerts you when it fails, and there is a standing agreement about who does the work when a vendor forces a change.
There is a smaller, more frequent version too — a customer changes their file format. Handled well, it sounds like this, from a client of mine in Tempe:
Joey stepped in and revamped our daily business flow. He migrated us to our own server, automated the daily file generation, and stays on top of it whenever our customer’s format changes. Years in, I don’t think about our infrastructure anymore — which is exactly what I wanted.
— Thomas Harty, Star Graphics Inc.
How I would decide
Run the three numbers first; if the total is small, re-keying may honestly be fine. If a native connector covers your objects, direction, and fields, use it. If the flow is linear and low-volume, build it in Zapier or Make. And if any of the five break points apply, custom is the option that stops the bleeding.
That third level is the kind of work I take on, including the migration into it: taking brittle no-code chains and turning them into something your own team can see, test, and own.
If you have a copy-paste workflow you are tired of, the integration and automation page has more on how I approach this. If you would rather just describe the problem, the Get in touch button below opens the contact form — the first conversation is thirty minutes on a call, no deck attached. I’ll usually reply within a day.