Workflow pairing · Sales to accounting
The difficult part is not moving a company name. It is deciding when a deal becomes billable, which customer gets the invoice and how accounting changes return to sales. ALCA can design that Salesforce–QuickBooks Online workflow around your approval and record-ownership rules.
See the example workflowThis pairing covers Salesforce and QuickBooks Online. Salesforce API availability, user permissions and custom schema, plus Intuit app requirements and each authorized QuickBooks company, must be verified before implementation.
What could connect
Use the approved Salesforce milestone to prepare customer and line-item data. A finance or operations approval can release the invoice. Closed-won may instead create an estimate, a job or a billing-review task depending on your sales process.
A custom order, milestone or service-delivery object may be a better source than Opportunity. Confirm the actual object and field API names, required fields, relationship model and integration user permissions in your Salesforce org.
Show the QuickBooks invoice reference, current open balance and reconciled payment state in Salesforce. Keep these as accounting-owned fields so a sales edit cannot silently turn an unpaid invoice into a paid one.
A deal may belong to one of several legal entities or require several invoices. Use an approved routing rule and separate authorization for each QuickBooks company. Model an invoice schedule instead of assuming one opportunity always equals one invoice.
Choose the right approach
Evaluate the relevant Salesforce/QuickBooks connector or AppExchange product against your billing model first. Confirm required editions and add-ons, custom-object coverage, invoice ownership, payment allocations and who operates its error queue.
A middleware workflow may fit a simple, single-company handoff with standard fields. Test repeated stage changes, customer duplicates and partial failures. A successful demo of customer creation does not establish safe invoicing.
A custom pairing is justified when approval gates, custom Salesforce objects, multiple accounting companies, invoice schedules or financial reconciliation exceed the existing connector’s supported behavior.
Compare other platforms in the integration directory. For delivery scope and hiring an engineering team, see API Integration Services.
Feasibility first
Salesforce recommends External Client Apps for new integrations; new Connected App creation is restricted from Spring 2026. Choose a supported OAuth flow and an integration principal with the required object, field and record access.
Salesforce API access and sandboxes depend on edition and licensing. Verify the customer org, and use a suitable sandbox or developer environment alongside an Intuit sandbox. Each QuickBooks Online production company requires its own authorized connection.
Salesforce Change Data Capture covers selected standard objects and custom objects, with finite event retention and allocations. Subscribe only where useful, retain replay state and reconcile gaps. Scheduled reads or explicit approval actions are alternatives.
Salesforce API and event allocations and QuickBooks company-level limits constrain throughput independently. Handle bulk backfill separately from daily changes. The queue must survive a delay on either side without posting the same invoice twice.
Technical scope checked against the official vendor references below. Production access is confirmed with your account administrator before implementation.
Follow the data
A lead progresses to an opportunity. An approved milestone, such as closed-won, starts a billing handoff rather than blindly creating an invoice.
Resolve the approved billing account and QuickBooks company. Check the durable Account-to-Customer mapping.
Map approved line items, dates, currency and accounting references. Hold missing data or ambiguous customer matches.
Create an Estimate or Invoice after the required approval, using a persisted logical operation key and target identity.
Reconcile QuickBooks invoice balance and payment allocations after relevant notifications or scheduled reads.
Write only the agreed accounting status fields and references. Suppress self-generated updates from restarting billing.
Records & rules
Illustrative field mapping using standard vendor names where specified. Salesforce fields ending in __c and the billing/allocation objects shown here are proposed custom schema, not fields guaranteed to exist. Invoice lines, required fields and tax mappings are additional customer-specific work.
| Source object / field | Destination object / field | Direction | Trigger | Ownership, validation & conflict rule |
|---|---|---|---|---|
| Salesforce Account · Id | Ledger → QuickBooks Customer.Id | Salesforce → identity ledger | First approved billing handoff | Key by Salesforce org + Account.Id + QuickBooks realmId. Reuse an approved match; ambiguous duplicates require review. |
| Salesforce Account · Name | QuickBooks Customer · DisplayName | Salesforce → QuickBooks, by policy | Approved customer create/update | The name proposes a display value, not an immutable identity. Resolve customer naming conflicts before write. |
| Salesforce Opportunity · AccountId | QuickBooks Invoice · CustomerRef.value | Salesforce → QuickBooks | Billing approval | Resolve AccountId through the stored Customer.Id mapping. Allow an explicit alternate bill-to account where required. |
| Salesforce Opportunity · Id / IsWon | Ledger operation → QuickBooks Estimate.Id or Invoice.Id | Salesforce → QuickBooks | Approved won transition or billing action | IsWon is a trigger candidate controlled by the Salesforce stage model, not an invoice field. Repeated events reuse the source operation; staged billing needs a milestone key. |
| QuickBooks Invoice · Id / Balance | Salesforce billing record · QBO_Invoice_Id__c / Open_Balance__c (examples) | QuickBooks → Salesforce | Accounting change + reconciliation | These Salesforce custom fields must be created or mapped in your org. QuickBooks owns the balance; CRM edits do not flow back. |
| QuickBooks Payment · Id / Line.LinkedTxn | Salesforce payment/allocation object (example) | QuickBooks → Salesforce | Payment change + reconciliation | Keep invoice allocations and unapplied amounts distinct. Do not mark the whole opportunity paid from one partial payment. |
On smaller screens, swipe the table or focus it and use the arrow keys.
Salesforce owns pipeline and commercial intent. QuickBooks owns posted invoice state, payments and open balances. The integration keeps the cross-system identity and delivery ledger. An editable CRM mirror is not a second accounting ledger.
Salesforce Account.Id alone is not enough when an organization bills through several QuickBooks companies. Resolve the legal entity before selecting credentials, customers and items, then retain that realmId with the mapping and audit event.
Choose which pre-approval changes may still alter the proposal and which later changes require a correction workflow. An Opportunity amount change must not overwrite a posted invoice without a finance-approved action.
A sales amount can differ from an invoice total because of taxes, discounts, installments or currency. Map approved item references and amounts, and reconcile invoice/payment allocations rather than copying a single opportunity total.
When something breaks
Check an approved Account-to-Customer mapping before creating. Keep a unique billing-operation identity for each source milestone so a replay or an opportunity reopened and won again does not create an accidental second invoice.
A customer may be created while its invoice fails. Persist each step and resume from the failed dependency. Re-read QuickBooks revisions and Salesforce current state; do not restart the whole workflow as new work.
Treat payment allocation, reversal, voiding and outstanding balance as distinct states. A deleted Salesforce record should create a review task or archive a mirror, not automatically delete a financial transaction.
Finance approves item, tax, currency and correction rules. Establish a historical cutoff, match records already in both systems, load dependencies in order and reconcile totals before live events overlap with the backfill.
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
Where the customer org exposes them to the authorized integration principal, yes. We inspect the actual schema, relationships, required fields, validation rules and event options. A custom billing or order object is often more precise than using every Opportunity update.
Only if that is the approved business rule. Closed-won can prepare an estimate, initiate delivery or open a billing review. Milestone billing or multiple invoices per sale need their own source keys and approval conditions.
Give each synchronized field one owner, record change origin and operation state, and ignore updates generated by the integration when they do not represent new business work. Reconciliation checks the final state independently of event delivery.
Possibly. Salesforce API availability, event allocations, sandbox access and connector add-ons depend on the org and licensing. QuickBooks production app access and each company authorization also need confirmation. We identify those prerequisites during discovery.
Your wider operation
Accounting · Platform
Customers, invoices and payment status with record ownership, duplicate prevention and reconciliation.
Explore the workflowCRM & operations · Platform
Connect contacts, companies and deals to quoting, fulfillment, portals and internal databases.
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.
Current recommendation and Spring 2026 Connected App creation restriction.
Inspect the customer org’s actual objects and fields.
Standard Account.Name and schema-backed field references.
Opportunity fields and StageName-controlled won state.
Enabling Change Data Capture for supported objects.
Finite event retention and replay considerations.
Org-dependent allocations and API usage visibility.
Existing connector features and licensing to compare first.
QuickBooks Customer, Invoice, Estimate and Payment field shapes used in the illustrative mapping.
Company authorization and accounting access.
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 sales-to-accounting handoffUse ALCA’s existing project brief. No credentials or customer records needed.