Why connect at all
Retyping sales, invoices and payments into QuickBooks is slow and introduces errors that are found at month end, when they are most expensive to fix. An integration built on the QuickBooks Online API posts those records as they happen, in the accounts your accountant chose, and tells you when something does not fit.
Off-the-shelf connectors are the right answer for many companies, and we will say so. A custom integration earns its cost when your data does not fit a connector's assumptions: several entities, unusual tax treatment, fees and payouts that must land in specific accounts, or a system no connector supports.
The three levels
| Level | What moves | Typical use |
|---|---|---|
| One-way | Records flow from your system into QuickBooks only | A store or field app posting sales, invoices or job costs |
| Two-way | Records flow both ways and are kept in step | Customers and invoices edited in either place, payments recorded in QuickBooks flowing back |
| Several systems or entities | Several sources, several companies or currencies | A group with more than one company file, or a store, a CRM and an ERP together |
Decide the mapping with your accountant
The hardest part of an accounting integration is not the code. It is agreeing, field by field, where each record lands: which income account a product posts to, how discounts and fees are recorded, which tax codes apply where, and what happens to refunds and partial payments. Your accountant should sign that mapping off before the build starts, because changing it later means reposting history.
- Products and services to items, and items to income accounts.
- Customers to customers, with one rule for which side wins when both change.
- Payment processor fees and payouts to their own accounts, so deposits reconcile.
- Tax codes by province, state or country, as your accountant applies them.
- Refunds, credit notes and partial payments, each with its own treatment.
What makes two-way sync hard
One-way sync has one source of truth. Two-way sync has two, and every field needs a rule for which wins when both change. Changes are picked up through webhooks as they happen, with a regular catch-up pass, because a missed notification must never mean a missed record.
Every write must be safe to repeat: if the same invoice is sent twice, it must be recorded once. And the API limits how fast an app may call it per company, so a large backfill is planned rather than fired all at once.
Errors, queues and the reconciliation screen
Some records will not sync: a deleted customer, a closed period, a tax code that does not exist in that company. A good integration never drops them silently. It holds them in a queue, retries what can be retried, and shows the rest on a screen with the reason, so someone can fix them before month end rather than discovering them during it.
Several companies, several currencies
Groups often run one QuickBooks Online company per legal entity. An integration that serves them has to route each record to the right company, keep inter-company transactions in step on both sides, and record foreign currency the way your accountant wants: at the rate on the day, at a monthly rate, or as the payment processor settled it.
Each company is connected separately through OAuth, so someone with the right access in each company approves the connection, and the integration keeps working when a person leaves. Plan that access early: it is the step most often forgotten until the week of go-live.
If you are still on QuickBooks Desktop
We build on QuickBooks Online and its API. If your books are on Desktop, the usual path is to move to Online first, then check the history: opening balances, open invoices and bills, and the last closed periods, line by line against the old file. Integrating after the move is simpler than integrating twice.
A move is also a good moment to clean up: retire unused items and accounts, merge duplicate customers, and agree the mapping once, with your accountant, for everything that will flow in afterwards.
Testing and going live
An accounting integration is tested against the books, not only against the code. The sandbox company is loaded with a realistic month of data, the integration runs, and your accountant reconciles it the way they would reconcile a real month: bank deposits against payouts, receivables against invoices, tax collected against sales. Only when that month closes cleanly does the integration point at your live company.
Go-live is best at the start of a period, with a clear cut-over: everything before that date entered the old way, everything after it through the integration. For the first weeks, someone checks the error queue daily, and the mapping is adjusted while the volumes are still small.
After that, the work is ordinary maintenance: the API changes from time to time, your products and tax rules change, and the integration should change with them. A support plan with a response time covers that, or your own team can take it on with the handover documents.
What it costs, worked out now
The two worked examples below are priced by our estimator from the rate card in force when you open this page: a one-way sync from a small web app, and a two-way sync with a reconciliation dashboard. Your QuickBooks subscription is separate, and Intuit may charge for heavy use of its API; the estimate lists what applies.
Worked example, priced now
One-way sync from your app into QuickBooks Online
Sales and invoices posted as they happen, with an error queue.
- Build
- ≈ US$38,500 to US$58,800, delivered within 17 weeksCAD 54,800 to 83,800
Prices in your currency are estimates from today's Bank of Canada rate. All invoicing is in CAD or USD.
How it is paid
- Deposit 30%
- CAD 16,440 to 25,140
- Discovery 4.4%
- CAD 2,411.20 to 3,687.20
- Data mapping and sandbox connection 3.3%
- CAD 1,808.40 to 2,765.40
- Design approved 4.4%
- CAD 2,411.20 to 3,687.20
- Core features 13.2%
- CAD 7,233.60 to 11,061.60
- Full build 8.8%
- CAD 4,822.40 to 7,374.40
- Sync built and reconciled in sandbox 10%
- CAD 5,480 to 8,380
- Testing and fixes 4.4%
- CAD 2,411.20 to 3,687.20
- Launch 4.4%
- CAD 2,411.20 to 3,687.20
- Live cutover 3.3%
- CAD 1,808.40 to 2,765.40
- Hypercare 3.8%
- CAD 2,082.40 to 3,184.40
- Holdback, 30 days after launch (10%)
- CAD 5,480 to 8,380
Running it
- Hosting
- ≈ US$176 a monthCAD 250 a month
- Support
- ≈ US$1,000 a monthCAD 1,425 a month
Worked example, priced now
Two-way sync with a reconciliation dashboard
Customers, invoices and payments kept in step both ways, with a dashboard of what did not sync and why.
- Build
- ≈ US$54,600 to US$83,400, delivered within 19 weeksCAD 77,700 to 118,800
Prices in your currency are estimates from today's Bank of Canada rate. All invoicing is in CAD or USD.
Estimated effort by role
- Development
- 307 to 470 h
- Backend developer
- 58 to 88 h
- Senior backend developer
- 55 to 84 h
- Project manager
- 50 to 76 h
- QA engineer
- 40 to 61 h
- Frontend developer
- 38 to 58 h
- Junior backend developer
- 29 to 44 h
- Software architect
- 26 to 40 h
- Senior engineer
- 23 to 35 h
- Senior frontend developer
- 23 to 35 h
- Product designer
- 20 to 30 h
- Junior frontend developer
- 15 to 23 h
- Senior product designer
- 13 to 20 h
- DevOps engineer
- 11 to 17 h
- Technical writer
- 7 to 11 h
How it is paid
- Deposit 30%
- CAD 23,310 to 35,640
- Discovery 3.3%
- CAD 2,564.10 to 3,920.40
- Data mapping and sandbox connection 4.9%
- CAD 3,807.30 to 5,821.20
- Design approved 3.3%
- CAD 2,564.10 to 3,920.40
- Core features 10%
- CAD 7,770 to 11,880
- Full build 6.7%
- CAD 5,205.90 to 7,959.60
- Sync built and reconciled in sandbox 14.8%
- CAD 11,499.60 to 17,582.40
- Testing and fixes 3.3%
- CAD 2,564.10 to 3,920.40
- Launch 3.3%
- CAD 2,564.10 to 3,920.40
- Live cutover 4.9%
- CAD 3,807.30 to 5,821.20
- Hypercare 5.5%
- CAD 4,273.50 to 6,534.00
- Holdback, 30 days after launch (10%)
- CAD 7,770 to 11,880
Running it
- Hosting
- ≈ US$176 a monthCAD 250 a month
- Support
- ≈ US$2,500 a monthCAD 3,565 a month
What to ask before you start
- 01
Would a ready-made connector do?
If one fits your data, use it. Custom work is for when it does not.
- 02
Who signs off the mapping?
Your accountant, in writing, before the build.
- 03
Which side wins?
For two-way sync, a rule per field, agreed up front.
- 04
How are errors seen and fixed?
A queue and a screen, not an email nobody reads.
- 05
Who owns it after launch?
Someone has to watch the queue. Decide who before go-live.