Bi-Directional Salesforce–QuickBooks & Xero Integration for Automated Finance Ops
- Automatic
- Invoice creation on Closed-Won
- 100%
- Manual re-keying eliminated
- 0
- Failed transactions unaccounted for
Salesforce products used
- Sales Cloud
- Salesforce Platform
- Platform Events
Technologies used
- REST APIs
- OAuth 2.0
- QuickBooks Online API
- Xero API
- Queueable Apex
- Named Credentials
- Custom Metadata
Business Problem
Every Closed-Won opportunity triggered the same ritual: someone in finance opened QuickBooks or Xero and re-typed what sales had already entered in Salesforce — customer, products, pricing, terms. Days of latency between closing and invoicing stretched cash collection. Transposition errors created invoice disputes. And because payment status lived only in the accounting system, sales teams chased customers who had already paid. Two systems, one business process, zero connection.
Technical Challenge
Accounting integrations punish sloppy engineering more than almost any other kind, because every failure is money:
- Duplicates are financial incidents. A retried sync that creates a second invoice isn't a bug — it's a customer relations problem and a books-reconciliation problem. Every write had to be idempotent by design.
- Two accounting platforms, one contract. QuickBooks Online and Xero expose different APIs, auth flows, and data quirks; the integration needed one internal contract with platform-specific adapters, not two parallel codebases.
- OAuth 2.0 lifecycle management. Token refresh, revocation, and re-authorization had to be handled invisibly — an integration that stops syncing because a token silently expired is an integration nobody trusts.
- Bulk and asynchronous by default. Quarter-end close means bursts of opportunities; the pipeline had to absorb spikes without hitting governor limits or rate limits on either side.
Solution Architecture
- Event-driven core: Closed-Won opportunities publish Platform Events; subscribers hand work to Queueable Apex jobs for asynchronous, bulk-safe processing with chaining for large volumes — no synchronous callouts in the save path, no user ever waiting on an external API.
- Idempotent write contract: every outbound transaction carries a deterministic external reference derived from the Salesforce record; replays and retries update rather than duplicate. Reconciliation-safe by construction.
- Bi-directional synchronization: customers, products, pricing, and invoices flow outward; payment and invoice status flow back into Salesforce, giving sales real-time visibility into what's actually been paid.
- Adapter architecture behind a single internal interface, with QuickBooks Online and Xero implementations — adding a third accounting platform is a new adapter, not a rebuild.
- OAuth 2.0 via Named Credentials with automatic token refresh, and Custom Metadata-driven configuration for endpoints, mappings, and retry policies — adjustable without deployments.
- Failure engineering: structured error logging, categorized failure types, automatic retry with backoff for transient errors, and a review queue for permanent ones. Every failed transaction is visible, attributable, and replayable — nothing disappears.
Business Impact
Invoices now exist in the accounting system the moment a deal closes — the multi-day re-keying pipeline is gone entirely, along with its transposition errors. Payment status flowing back into Salesforce ended the era of sales chasing paid customers. Finance trusts the numbers because the idempotent design makes duplicates structurally impossible, and the error ledger means the rare failed transaction is a queue item, not a mystery discovered at month-end reconciliation. The adapter architecture has already paid for itself: supporting both QuickBooks and Xero customers required configuration, not new engineering.
Facing a similar problem?
We'll walk you through how we'd approach it — the plan is free, whether or not you hire us.