Integrations. QuickBooks Online
QuickBooks Online integration that keeps the books and the operation in step.
QuickBooks Online is where the money gets recorded. It's almost never where the work gets recorded. Jobs, quotes, orders and time live in a CRM, an operations system or a spreadsheet, and at the end of the week somebody retypes the result into QuickBooks. Every retype is a chance for the two to disagree. You find out at month end, which is the worst possible time to trace it.
We connect the system where the work happens to QuickBooks Online through Intuit's API. A customer, an invoice or a payment gets entered once and shows up in both places carrying the same reference. QuickBooks stays your accounting system of record. The integration keeps it fed, and it tells you when something didn't match.
What we connect
What gets connected between QuickBooks Online and your other systems?
The flows below are the ones we build most often. The scope for your integration names exactly which of them apply, in which direction, and which system wins when the two disagree.
- Customers and sub-customers, created or matched in QuickBooks when a deal closes or a job opens. We store the QuickBooks ID on your record, so the link survives a rename.
- Invoices raised from a signed quote, a completed milestone or a delivered order. Your products and services map to QuickBooks items, and those items land on the income accounts, classes and locations your accountant set up.
- Payments recorded against the invoice as they arrive. Stripe, QuickBooks Payments, a check keyed in at the office, it doesn't matter which one. The invoice reads the same on both sides.
- Estimates and sales receipts, if your process uses them. A QuickBooks estimate becomes a job in your system, and a counter sale posts as a sales receipt.
- Bills, expenses and time activities tied to a customer or job. Job costing then comes out of one report, not two.
- Balances and paid status pulled back from QuickBooks into your CRM or portal. The people who need to know whether a customer is current can see it there, without a QuickBooks login.
How it works
How does a QuickBooks Online integration work?
QuickBooks Online has a REST API secured with OAuth, and it can send webhooks when a customer, invoice or payment changes. We use both. Webhooks handle the moment-to-moment updates, and a scheduled sweep of changed records catches whatever a webhook missed. When the flow starts on your side, our system writes to QuickBooks directly and stores the returned ID and sync token on your record.
Every write is keyed to a stable reference on your side, so a retry after a timeout can't create a second invoice. QuickBooks' own version check, the sync token, stops us from overwriting an edit a bookkeeper made in the meantime. Failed calls retry with backoff. We stay inside the API's rate limits.
Anything that still fails lands in a queue with its payload attached, and somebody gets an alert. A reconciliation report runs on a schedule and lists the invoices, payments and customers that exist on one side and not the other, or that differ in amount or status. Your bookkeeper can check the integration without reading a line of code. All of it is built against an Intuit sandbox company first, and it points at your live company only after you have signed off the mapping.
The stakes
What does a bad QuickBooks Online integration cost you?
More than the build, because integrations fail without setting off an alarm. Nobody gets a message saying the numbers stopped agreeing. Somebody notices at month end, and then nobody trusts either system until it is proven again. The failures below are the ones worth designing against from the start.
- Duplicate invoices in the ledger. A call times out, the retry posts a second invoice, and now your customer has two bills for one job. Your revenue figure counts the work twice until somebody reconciles the month.
- A mapping mistake sends fee lines, sales tax or discounts to the wrong income account. Nothing errors. The books still balance. The profit and loss report is just wrong, and your accountant finds it during a review or a filing.
- The connection's token expires, or the webhook endpoint starts failing, and the sync stops without setting anything off. Work keeps flowing on your side. QuickBooks stops receiving it. You find out when someone asks why revenue looks light.
The order of work
What happens, in what order, on a QuickBooks Online integration?
In this order, every time. The mapping comes before the code, and the reconciliation comes before we call it done. Nothing here is a date. The sequence is fixed, and the runway is set in your written scope once we have seen your actual data.
- 01
Map the fields first
Before any code, we write the mapping down. Your products and services map to QuickBooks items, items to income accounts, classes and locations per line, plus a written rule for matching a customer. The table names which system wins when a record changes on both sides. Your accountant reads it and corrects it. Nothing about your chart of accounts gets guessed at run time.
- 02
Build in an Intuit sandbox
We register the app in your name and build against an Intuit sandbox company loaded with data shaped like yours. Real item names, your account structure, and the awkward customers with sub-customers hanging off them. OAuth tokens go into a secrets vault from the very first call. Your live company file doesn't get touched at this stage.
- 03
Failure paths before features
The unhappy path gets built first. Every write carries a stable reference from your side, so a retry after a timeout can't post a second invoice. That's idempotency, which just means the same message arriving twice only counts once. QuickBooks sync tokens stop us from overwriting a bookkeeper's edit. We stay inside the rate limits, failed calls back off, and anything still failing lands in a queue with its payload.
- 04
Prove the two sides agree
Then the reconciliation pass runs against a copy of real data. It lists every customer, invoice and payment that exists on one side and not the other, or that differs in amount or status. Your bookkeeper reads that report. Go-live waits until the list is empty, or until every line still on it has a written reason next to it.
- 05
Go live with an alarm
Your QuickBooks administrator authorizes the live connection, and the reconciliation report keeps running on its schedule. A separate monitor watches the sync itself. If webhooks stop arriving, a token expires, or the sweep doesn't finish, a person hears about it that day. A sync that dies quietly is the failure we design against.
Limits
What we will not do
Cheaper to hear now than to discover halfway through. If one of these is what you are actually after, we will say so on the first call rather than take the work.
- We won't write to a live QuickBooks company before the reconciliation report runs clean against sandbox data. A ledger is a bad place to discover a mapping was wrong. The correction is a journal entry somebody has to explain.
- We won't paper over a chart of accounts nobody trusts. If the income accounts, items and classes are already a mess, a sync just makes the mess arrive faster. Your accountant sorts that out first, and we'll say so plainly.
- We won't delete or void anything in QuickBooks automatically, and the integration doesn't get to decide a payment is bad. It flags the mismatch and stops. A person with both sides in front of them makes the correction.
Questions
What people ask about QuickBooks Online integrations
Do you replace QuickBooks Online?
No. QuickBooks stays your accounting system of record, and your accountant keeps working in it exactly as before. What goes away is the retyping between QuickBooks and the system where your work is recorded. If you're on QuickBooks Desktop, the integration path is different, and we'll walk through it on the call.
Which direction does the data flow?
Whichever direction your process needs. Usually customers and invoices flow from your operations system into QuickBooks, and payment status and balances come back the other way. Where a record can change on both sides, the scope says which side wins. The reconciliation report then shows you every case where they disagreed anyway.
What about our chart of accounts, classes, and locations?
They're mapped in the scope before anything gets built. Your products and services map to QuickBooks items, items to income accounts, and classes or locations per line where you use them. The mapping is a table you can read and correct. Nothing gets guessed at run time.
What happens if the integration creates a duplicate or posts something wrong?
Writes are keyed so a retry can't duplicate a record. The reconciliation report is the safety net for everything else, listing mismatches for a person to review. The integration never deletes or voids anything on its own. Corrections happen deliberately, in QuickBooks, by someone who can see both sides.
Do you need our QuickBooks login?
No. Your QuickBooks administrator authorizes the connection on Intuit's own sign-in screen, to an app registered in your name. The tokens that come back live in a secrets vault and never in code. You can revoke the whole thing whenever you want, from the connected apps list inside QuickBooks.
What happens to our data from before go-live?
It stays where it is, and we decide deliberately whether any of it comes across. Most companies start the integration from a cutover date and leave the history in QuickBooks, where the reports already work. Where older records do need linking, we backfill the QuickBooks IDs onto your existing records rather than re-posting the transactions. Re-posting history into a closed period changes numbers your accountant already filed. The backfill runs as a matching pass you review before anything saves.
What happens when Intuit changes the API?
We update the integration, and you own the code either way. Intuit versions its API and announces changes ahead of time, so most updates are routine. A field moves, an endpoint gets a newer version, a scope needs re-consenting. Every failed call is logged with its payload, so a change that does break something shows up as a queued error and an alert. You don't find out from missing invoices. The app is registered in your name and the code sits in your repository, so any competent developer can make the fix. It doesn't have to be us.
What if we change accountants, or move off QuickBooks entirely?
The integration survives a change of accountant. Changing accounting platforms means rebuilding the QuickBooks side. New accountants usually want a different class or account structure, and that's a change to the mapping table, so the code stays where it is. Moving off QuickBooks Online is the bigger job, because another ledger has its own API, its own object names and its own tax handling. The part that matters carries over though. Your own system still holds the customers, jobs and invoices, so the new ledger gets fed from the same place and nobody starts retyping again.
Related
Where this fits
An integration is rarely the whole job. Usually it is one part of a CRM, an operations system, or a client portal that needs QuickBooks Online to agree with it.
Tell us which two systems disagree
Book a strategy call, or send a short note about what gets retyped today and where the numbers stop matching.