QuickBooks Integration Services
QuickBooks integrations fail on accounting, not on code. Which account a transaction posts to, how tax is applied, and how a customer is matched are decisions your bookkeeper must make before a developer writes anything.
Discuss your projectStart with the mapping, not the API
The first deliverable on any QuickBooks project is a mapping document agreed with whoever owns your books. Which income account does each product or service post to? Which tax code applies, and does it vary by customer or by jurisdiction? Are you using classes or locations to track departments, and must every transaction carry one? Are customers matched by name, by email, or by an identifier your own system holds?
None of those are technical questions, and all of them determine what the integration does. Build first and you will produce a month of transactions posted to the wrong accounts, which your accountant then has to unpick — considerably more expensive than the conversation would have been.
The other decision worth making early is whether your integration creates posted transactions or drafts awaiting approval. Drafts are slower for your team and far safer while the integration is new. Most clients start with drafts and move to automatic posting once a few weeks have reconciled cleanly.
What we build
Invoices and sales receipts
Created from orders or jobs in your own system, with line items mapped to the right accounts and tax applied by the rules your bookkeeper set.
Payment reconciliation
Payments recorded against the right invoice, including partial payments and the case where one payment settles several invoices.
Bills and expenses
Supplier bills created from approved purchase orders or from extracted invoice data, which pairs naturally with document extraction.
Customer and item sync
With an explicit matching rule, so you do not accumulate three versions of the same customer. Your own ID stored on the QuickBooks record is the reliable way to do this.
Journal entries
For summarised postings where you do not want every individual transaction in the ledger — often the right answer at high volume, and a decision to make with your accountant.
Reporting data out
Pulling financial data into your own dashboards, so revenue and margin reporting draws on the ledger rather than on a parallel calculation.
The technical details that cause real problems
These are specific to the QuickBooks API and account for most of the support calls on an otherwise working integration.
- SyncToken. Every record carries one, and an update must send the current value or it is rejected. This is optimistic locking, and it means you must read before you write rather than caching a record and updating it later.
- Sparse updates. Send a partial record without marking the update as sparse and QuickBooks will clear the fields you omitted. A genuinely destructive default worth knowing about.
- Refresh token expiry. OAuth refresh tokens expire after a period of disuse, so an integration that is idle over a quiet season can lose its authorisation silently. We alert on token age rather than discovering it when a sync fails.
- Request throttling per company file, which means bulk operations need batching and pacing rather than a loop.
- Sandbox differences. The sandbox is useful and does not behave identically to production, particularly around tax, so final verification happens against a real file with drafts rather than posted transactions.
- Deleting is not deleting. Most records are voided or made inactive rather than removed, which your reconciliation logic has to account for.
Common questions
Related in Web Development
Tell us what you need
Describe the problem and we will come back with scope, timeline, and a rate. No obligation to proceed.
Get in touch