Accounting · QuickBooks Online
A customer should not be created three times, and a successful API call should not be mistaken for reconciled books. ALCA can connect QuickBooks Online with your CRM, quoting, dispatch or internal systems around the records and controls your business needs.
See the example workflowThis page covers the QuickBooks Online Accounting API. QuickBooks Desktop uses a different integration approach and needs a separate assessment. Company features, app requirements and customer authorization determine the available Online scope.
What could connect
A reviewed vendor invoice normally becomes a QuickBooks Bill, not the customer Invoice used in the sales example below. Match the vendor, validate the purchase and obtain the required authorization before a separately scoped payable write. Payment release is another control.
An approved customer or order in the CRM can initiate a QuickBooks customer and the agreed estimate or invoice process. Separate the sales milestone from the accounting approval; a won deal is not automatically ready to bill.
A custom estimator or operational database can propose customer references and invoice lines using mapped QuickBooks items. Keep commercial calculations and finance-approved item, account and tax configuration distinct.
A completed service job or fulfilled order can become a billing candidate. QuickBooks can return invoice and payment information to the operating system so the team sees what is billable, outstanding or held for review.
Assess customers, invoices, payments, estimates, items and vendor records as separate object scopes. Product or inventory behavior depends on enabled QuickBooks features. Recording an accounting payment is different from charging a card through a payments API.
Choose the right approach
Check the connector offered by your CRM, store or scheduling product. If its customer matching, invoice creation, item mapping and payment handling cover the process, keep it and define who resolves its exceptions.
Zapier, Make or another supported connector may handle a small set of standard records and straightforward rules. Test what happens when a record already exists, the customer disconnects access or only one step in the flow succeeds.
Custom engineering is useful when records cross several internal systems, invoice creation requires approval, financial identities must be reconciled, or an existing connector cannot express the mapping. It creates an operating responsibility as well as a connection.
Compare other platforms in the integration directory. For delivery scope and hiring an engineering team, see API Integration Services.
Feasibility first
Intuit OAuth connects the app to a QuickBooks Online company identified by realmId. Use the accounting scope for accounting data and maintain separate authorization and identity mappings per company. Do not assume one company’s token or record ID applies to another.
An Intuit developer app and sandbox support development. Confirm current production app requirements and the customer’s authorized connection before release. Sandbox credentials and data are not production credentials or proof of every enabled accounting feature.
QuickBooks records have Id and SyncToken values. The first identifies the target record; the second supports concurrency checks. On an update conflict, re-read the entity and apply the agreed ownership rule instead of overwriting the accounting change.
Use supported webhook subscriptions and reconciliation reads. Intuit’s current sample includes CloudEvents; confirm the format enabled for the app and validate signatures against the raw payload. Throttle by company under current limits rather than promising an unrestricted sync rate.
Technical scope checked against the official vendor references below. Production access is confirmed with your account administrator before implementation.
Follow the data
An approved quote, completed job or billing action creates an outbound operation with a stable source key.
Use the selected realmId and stored customer mapping. Ambiguous matches wait for review.
Check required lines, mapped items, currency, tax treatment and the chosen invoice owner.
Persist the logical operation and a QuickBooks requestid where supported, then submit the approved record.
Save the returned entity Id, revision and processing outcome. A timeout stays uncertain until checked.
Compare target records and balances with the intended handoff; expose corrections and approved accounting status to operations.
Records & rules
QuickBooks field names are grounded in Intuit’s maintained SDK models and examples; custom-system fields are illustrative. This is a mapping discussion, not a complete invoice payload or accounting policy. Validate the target company’s API schema before writing.
| Source object / field | Destination object / field | Direction | Trigger | Ownership, validation & conflict rule |
|---|---|---|---|---|
| CRM · customer_id (example) | Integration ledger → Customer.Id | Identity mapping, per realmId | Customer approval / first sync | Store both IDs. Review uncertain matches before create; names and email addresses are secondary clues. |
| CRM · billing_name (example) | Customer.DisplayName | CRM → QuickBooks, by agreement | Approved customer create/change | Validate the target name and ownership. Do not rename an accounting customer from an unreviewed sales edit. |
| Approved order · mapped customer + items (examples) | Invoice.CustomerRef / Line[].SalesItemLineDetail.ItemRef | Operations → QuickBooks | Billing approval | Use QuickBooks customer/item IDs and approved line amounts. Persist the operation key before posting. |
| QuickBooks · Invoice.Id / Balance | Operations · accounting_invoice_id / open_balance (examples) | QuickBooks → operations | Supported event + scheduled reconciliation | QuickBooks owns the balance. Read the current invoice after relevant payments, credits or corrections. |
| QuickBooks · Payment.Id / Line.LinkedTxn | Operations · payment allocation view (example) | QuickBooks → operations | Payment change / reconciliation | Represent allocations and partial payments; a payment event alone does not mean every invoice is paid. |
On smaller screens, swipe the table or focus it and use the arrow keys.
The CRM can own prospecting status and the operational system can own job progress. QuickBooks should own the posted accounting record and its balance. Decide separately whether approved billing contact changes travel from the CRM or from accounting.
Keep a company-scoped source-to-target mapping and a separate logical operation key. Intuit supports requestid for idempotent requests; use the same key for a retry of the same operation. SyncToken is a revision value, not a duplicate-prevention key.
Compare expected customer and invoice references, amounts and open balances with QuickBooks. Report missing, rejected and mismatched records separately. A confirmed write can still have the wrong customer or item mapping, which transport success will not catch.
Choose a historical cutoff and map customers/items before dependent transactions. Deduplicate against records already present, account for changes during the import and obtain approval of counts and financial totals before enabling normal operation.
When something breaks
Do not create a new operation just because the response was lost. Check the stored identity and idempotency outcome, then retry or reconcile the original operation without generating another invoice.
A stale SyncToken means the integration’s copy is outdated. Re-read, preserve finance-owned fields and send conflicting proposed edits for review. Repeated blind retries will not fix a business conflict.
Return allocation and current balance information instead of a single optimistic paid flag. Match each payment to the relevant invoice references and reconcile later credits, voids and corrections under the agreed finance policy.
A CRM deletion should not automatically delete or void an accounting transaction. Queue a review. If the connection is revoked, stop the affected company’s jobs, request reconnection and reconcile the gap before resuming.
For timeouts, rate limits and temporary server errors, use a bounded queue with backoff and jitter. Respect vendor retry guidance. Reuse a request identifier where supported and check uncertain writes before creating again.
Invalid records, missing permissions, expired authorization and ownership conflicts need a fix or review. Route exhausted retries to a failed-record queue with a reason, owner and controlled replay action.
Duplicate or delayed events must not double-post work. Compare intended records with destination state on a schedule; monitor queue age, last successful sync and unresolved differences. An HTTP 200 is only one check.
Security by design
Use the vendor’s supported authorization flow and least-privilege permissions. Keep credentials in encrypted server-side secret storage, rotate or reconnect them through a documented process, and separate test from production access.
Validate webhook authenticity using the vendor’s supported mechanism before accepting events. Minimize copied personal and financial data. Redact tokens and sensitive payloads from logs, restrict replay tools by role, and retain an audit trail of changes and operator actions.
From discovery to operation
A proposed integration project follows ALCA’s discovery, design, build and launch approach. The exact scope and ongoing support responsibilities are agreed before delivery.
01
Walk through the current process. Confirm customer authorization, account products, API access and existing connectors using representative records. Deliver a feasibility decision before promising the connection.
02
Agree record ownership, company boundaries, fields, triggers, conflict rules, authentication and success criteria. Identify what requires human approval and what should never synchronize.
03
Build the narrowest useful flow, then test duplicates, unavailable APIs, revoked access, invalid data and replay. Use vendor sandboxes where available; otherwise agree an isolated, authorized test approach.
04
Reconcile historical backfill separately, release in controlled stages and monitor actual outcomes. Hand over mappings, credentials ownership, operating instructions and a maintenance plan for vendor changes.
Buyer questions
Yes, a design can include writes to QuickBooks and a return of accounting data where the API supports them. We still assign one owner per field. For example, operations can propose approved invoices while QuickBooks owns payment application and outstanding balance.
Each Online company needs its own authorization and company-scoped mappings. We define legal-entity routing before any write and prevent records or credentials from crossing company boundaries.
That is the purpose of this platform page. We assess the custom CRM’s API or database interface and agree the customer, order and accounting-status contract. The Salesforce pairing page covers that specific two-platform workflow.
We implement the rules approved by your accounting team and verify them in the target company. Taxes, credits, refunds, voiding and currency behavior are explicit scope decisions, not values inferred from a generic CRM event.
Your wider operation
Sales → accounting · Workflow pairing
Turn an approved sales handoff into accounting records, then return the status your sales team needs.
Explore the workflowConstruction · Platform
Project records, internal dashboards and accounting handoffs with clear company and project permissions.
Explore the workflowTechnical references
Reviewed September 9, 2026. These references establish platform capabilities and constraints; they do not establish access for your account or a vendor relationship with ALCA. Designs and mappings on this page are illustrative, not client case studies.
Customer authorization, accounting scope and company connections.
Developer account and sandbox setup.
CustomerRef, invoice line/item references, updates and supported field shapes.
Customer, Vendor, Item, Estimate, Invoice, Payment, Id and SyncToken model definitions. Validate feature-specific availability in the target company.
Request IDs and retry-safe writes. Older operational guidance; current numeric limits are deliberately not asserted here.
Current event format, OAuth and change-data reconciliation example.
Vendor-provided HMAC verification of the raw webhook payload.
Map your workflow
Tell us the two systems, what needs to move and where the current process breaks. If you know the approximate record volume and sync direction, include them. “Not sure yet” is a useful starting point.
Map your QuickBooks connectionUse ALCA’s existing project brief. No credentials or customer records needed.