The pattern is always the same. Orders happen somewhere, payments happen somewhere else, and once a week somebody sits down and types the results into QuickBooks. Everybody knows it is wasteful. Nobody is quite sure whether fixing it is a two-hundred-pound app or a twenty-thousand-pound project.
A QuickBooks integration is usually neither of those, and the answer depends far more on which QuickBooks you run than on which other system you have. That is the first thing worth establishing, because it changes everything that follows.
Measure the re-typing tax first
Before pricing anything, spend twenty minutes counting. Most people discover the number is either much smaller or much larger than the irritation suggested.
- How many records a week actually move by hand? Invoices, payments, customers, bills, stock adjustments. Count them, do not estimate them.
- How long does it take, honestly? Including the finding, the checking, and the bit where someone opens two windows side by side.
- How often is something wrong afterwards? A customer duplicated with a slightly different name, an invoice against the wrong job, a payment applied twice. These corrections usually cost more than the original typing.
- What can you not answer at all? Which customers are profitable, which products actually make money. If answering means exporting two systems and joining them by hand, that is a cost even though nobody spends an hour on it.
If the honest total is one person for two hours a week, you are looking at a connector or an export, not a project. If it is a person most of a day, plus corrections, plus questions you cannot answer, the arithmetic changes.
Desktop and Online are different projects
This is the distinction that catches people out, and it is the reason two businesses get wildly different quotes for what sounds like the same job.
QuickBooks Online is built to be connected to. It has a proper interface for other software to talk to, a large catalogue of ready-made connectors, and most integrations are a matter of authorising an app and mapping your accounts. Work measured in days.
QuickBooks Desktop, including Enterprise, is a different proposition. It runs on a machine rather than in a browser, so anything connecting to it has to reach that machine, usually through a connector service that has to be installed, kept running, and kept updated. Fewer things support it, more of them are one-directional, and someone has to care when the connector stops after a Windows update. Work measured in weeks, and it needs an owner afterwards.
So before asking what a connection costs, answer which one you are on. And if you are on Desktop and considering moving to Online, do that decision first rather than building integrations you would then rebuild.
QuickBooks integration: what connects cleanly and what does not
| What you want to connect | Reality |
|---|---|
| A shop or payment processor feeding sales in | The best-supported case by a distance. Mature connectors exist for the common platforms, and the work is configuration plus deciding how sales are summarised. The argument is usually about whether each order becomes an invoice or the day becomes one entry. |
| Payroll | Well served, and the reason payroll products are recommended so consistently is that the connection is already solved. Buy one that connects rather than building anything. |
| A CRM alongside it | The most-asked question we found, and the most nuanced. Some products are built around QuickBooks and connect deeply; general-purpose ones sync contacts and invoices and little else. Decide which direction matters before choosing, because most only do one well. |
| Stock and inventory | Straightforward for simple counts. Genuinely hard once batches, expiry, serial numbers or stock held elsewhere are involved, because QuickBooks does not model those and no connector can add what is not there. This is the most common reason people end up with a separate inventory system. |
| A job or field-service system | Usually supported for the industries those products serve, and the mapping of jobs to customers and items needs real thought. Expect a workshop, not a wizard. |
| Your own internal tool or spreadsheet | Perfectly possible on Online. On Desktop it is where most of the cost lands. |
| Historical data, brought across | Almost always harder than the ongoing sync, and almost always underestimated. Decide early whether you genuinely need years of history in QuickBooks or whether the old system can stay readable as an archive. |
Connector catalogues change constantly, so treat any specific claim about a named app, including ours, as something to verify before you rely on it.
Where QuickBooks itself is the limit
Sometimes the integration is not the problem. The problem is that QuickBooks does not hold the concept you are trying to send it, and no amount of connecting fixes that.
- It is an accounting system, not an operations system. It knows about invoices, payments and accounts. It does not know about your production schedule, your service history, or which engineer went where.
- Stock is modelled simply. Counts, yes. Batches, expiry, serials, consignment or stock sitting with a customer, not really. If those matter, plan for a separate system that connects rather than for QuickBooks to hold them.
- Custom fields are limited, so information that matters operationally often has nowhere sensible to live and ends up crammed into a description field, which is where reporting goes to die.
- Volume has practical limits, particularly on Desktop. A shop doing thousands of small orders should usually send summarised entries rather than one invoice each, and that decision is easier before you build than after.
The recurring lesson is that the fix is often to stop asking QuickBooks to be the operations system, and to give it the summarised financial result of an operations system that lives elsewhere. That is internal tools work rather than integration work, and it is frequently cheaper.
Decide which system holds the truth
The decision that causes more trouble than any technical problem, and it takes an afternoon rather than a budget.
For every piece of information in both places, one system has to be right. If a customer's address differs between your CRM and QuickBooks, which wins? If an invoice is edited in QuickBooks after it synced, does that flow back? Without an answer, connecting the two does not fix inconsistency, it spreads it faster, and the wrong value now reaches everywhere within a minute.
A related warning worth taking seriously: two-way syncing is far harder than one-way, and most people who ask for it do not need it. One direction is a rule. Two directions is a negotiation that has to be resolved automatically, forever, including the cases nobody thought of. Start one-way, live with it for a month, and add the reverse only if you genuinely miss it.
Our systems do not talk to each other covers the master-system decision in general, and everything there applies here.
What it costs
| Approach | Setup | Ongoing |
|---|---|---|
| A scheduled export into QuickBooks, one direction | $1,500 to $5,000 | Almost nothing |
| An off-the-shelf connector, configured properly | $1,000 to $6,000 | $20 to $200 a month |
| A custom connection with error handling and alerts (Online) | $6,000 to $20,000 | Hosting, plus attention when something changes |
| The same against Desktop | $12,000 to $40,000 | The above, plus keeping the connector service alive |
| Several systems into one place, with reporting on top | $30,000 to $90,000 | 15 to 25 per cent of build a year |
Illustrative ranges from the kind of work we quote, not a price list. The Desktop row is roughly double its Online equivalent for the same outcome, which is the single biggest cost driver in this whole area.
Two things belong in any quote and are frequently missing. First, who is told when it breaks, because connections do break: an interface changes, a credential expires, a required field appears, or unexpected data arrives and the sync stops rather than guessing. A connection that fails silently is worse than none, because everybody has stopped checking. Second, a safe retry, so that rerunning a failed day does not create every invoice twice.
Start with one flow
- Pick the single most re-typed record, usually sales or payments. Not the most interesting, the most repeated.
- Connect it in one direction only. The second flow is much easier once the first has taught you what your data actually looks like.
- Decide the summarisation now. One invoice per order or one entry per day. Changing this later means unpicking everything already sent.
- Run it alongside the manual process for a fortnight and compare. Dull, and it turns a nervous switchover into an uneventful one.
- Then stop doing it by hand, deliberately, and tell everyone it has stopped.
- Reconcile at the end of the first month with whoever owns the books. They will find the thing you missed, and it is much cheaper to find it in month one.
Not for you if
One question that settles most of the scope: which single figure, if it were always right in both systems without anyone touching it, would remove the most arguments? Connect that one, and see whether you still want the rest.