To connect Salesforce to QuickBooks Online, Xero, Sage Intacct or Business Central, start small. Sync customers and products, turn won deals into invoices or sales orders, and send invoice and payment status back to Salesforce. Let the accounting system own anything that touches the ledger. Then pick a connector type that matches how standard your billing is and who will maintain the sync.
What data usually moves between Salesforce and the accounting system?
Most small and mid-size companies sync six things: customers, products, the billable document, payments, invoice status and a credit or balance summary. Everything else can usually wait for a later phase.
- Accounts to customers: a Salesforce account becomes a customer record in the books, usually when the first deal closes.
- Products to items: item codes, descriptions and list prices, often maintained in accounting and copied into Salesforce price books.
- Won deals to invoices or sales orders: a closed opportunity or accepted quote creates the billing document on the finance side.
- Payments: recorded in accounting, with amount, date and method reflected on the Salesforce invoice record.
- Invoice status: open, overdue, partially paid or paid, visible to the account owner without logging in elsewhere.
- Credit and receivables view: credit holds, open balance and aging buckets shown on the account page.
That last item often pays off first. Reps stop quoting customers who are badly overdue, and account managers spot late invoices before renewal calls.
Which system should own customers, products and invoices?
The accounting system should own anything that posts to the general ledger. Salesforce should own the relationship and the deal up to the moment it becomes billable.
In practice that means invoices, credit memos, payments, tax codes and the chart of accounts never get edited in Salesforce. Billing addresses and tax IDs are the usual argument. Sales wants to fix them on the spot. Finance needs them to match what appears on issued invoices. A workable compromise: Salesforce collects them for new customers, and the books own them after the first invoice. Write that rule down before anyone configures a connector.
Should the sync run in real time or on a schedule?
Very little in accounting needs to be instant. Push won deals promptly, and pull payments and balances on a schedule that matches how often finance posts them.
| Flow | Direction | Reasonable timing | Why |
|---|---|---|---|
| New customer | Salesforce to accounting | When the first deal closes | Avoids filling the books with prospects who never buy |
| Products and prices | Accounting to Salesforce | Daily, or when the catalog changes | Price lists change rarely and reps need consistency |
| Invoice or sales order | Salesforce to accounting | On close or on approval | Billing should start without someone re-keying the deal |
| Payments | Accounting to Salesforce | Hourly to daily | Finance posts in batches, so faster pulls add little |
| Invoice status and balance | Accounting to Salesforce | Daily, plus on-demand refresh | Reps check it before calls, not every minute |
| Credit hold flag | Accounting to Salesforce | Soon after finance sets it | Stops new quotes to customers who should not get them |
If a rep asks for a live balance, a button that fetches the current figure is cheaper than a constant sync.
What connector options exist for each accounting platform?
There are three broad categories: connectors maintained by the accounting vendor, third-party apps from the AgentExchange (formerly AppExchange) or the vendor's app store, and general integration platforms. What exists differs a lot by platform.
- Sage Intacct: Sage lists an Advanced Salesforce integration on its own marketplace, built and supported by Sage Intacct. Per the listing, it brings Salesforce contracts, orders and projects into Intacct to trigger invoicing and revenue recognition.
- Xero: the Xero App Store has a collection of apps that integrate Xero with Salesforce, built by third parties rather than Xero. Listings describe syncing contacts, invoices, payments, products and credit notes.
- QuickBooks Online: we could not find a connector maintained by Intuit currently listed. Intuit community moderators point people to third-party integrator apps found by searching the QuickBooks App Store.
- Business Central: Microsoft's documentation says its built-in CRM integration works only with Dynamics 365 Sales. A Salesforce link therefore needs a third-party app from Microsoft AppSource, an integration platform or custom code.
- NetSuite: our separate NetSuite integration guide covers ownership, tools and failure points for that platform.
Marketplace listings change often, and what an app claims to sync is not proof it handles your edge cases. Confirm current features, supported editions and pricing on each vendor's own listing before you shortlist.
| Category | Good fit when | Watch for |
|---|---|---|
| Vendor-maintained connector | Your process matches the vendor's standard order-to-cash flow | Limited control over mapping, and upgrades follow the vendor's schedule |
| AgentExchange or app-store app | One accounting system, standard objects, a small team | Per-user or per-org licensing, and how much custom field mapping it allows |
| Integration platform (Workato, MuleSoft, Boomi and similar) | Several systems, such as payments, e-commerce or a warehouse, or unusual rules | Someone must own the recipes or flows after go-live |
| Custom code against both APIs | A narrow, stable flow and developers on staff | You own retries, logging, credential rotation and every API change |
Where does data mapping usually go wrong?
Mapping problems cause most failed syncs, and they cluster in six areas. Each needs a written rule before go-live, not a fix after the first month-end close.
- Customer matching: names rarely match exactly between systems. Match on a stored external ID, never on company name, and clean duplicates on both sides before the first load.
- Parent and child accounts: Salesforce may model a holding company with several sites. The books may bill each site, or only the parent. Decide which Salesforce account maps to which bill-to customer.
- Tax: let the accounting system or its tax engine calculate tax. Salesforce should send the ship-to address and a tax-exempt flag, not a tax amount it worked out itself.
- Multi-currency: if you sell in several currencies, confirm both systems have the same currencies enabled. Decide which side's exchange rate wins, and never convert amounts in transit.
- Product codes: Salesforce products and accounting items need one shared key. Bundles, discounts, shipping lines and one-off services are the usual gaps.
- Partial payments and credits: a single invoice can be paid in three instalments, or offset by a credit memo. Show the open balance from accounting rather than recalculating it in Salesforce.
How should sync errors be caught and reconciled?
Assume some records will fail, and make every failure visible to a named person. Then reconcile totals on a schedule, so silent gaps surface before finance closes the month.
Good connectors and integration platforms keep an error log with the record, the field and the rejection reason. Route those errors to a queue someone checks daily, not to an inbox nobody reads. Make each write safe to retry, so a re-sent invoice updates the existing one instead of creating a duplicate.
Reconciliation is a separate control. Once a week, and always before month-end, compare counts and totals between the two systems. Check invoices created per day, payments applied and open balance by customer. A simple report on each side is usually enough to spot a gap. Agree in advance who corrects which side when the numbers disagree.
One of our projects shows why this matters. At a biotech company, an administrator had been shuttling payment records among Salesforce, NetSuite and Stripe by hand. We connected the three systems through MuleSoft, adding automated payment syncing plus error handling. The manual entry stopped entirely.
When does native Salesforce billing make more sense than a connector?
If invoicing is tightly bound to quotes, subscriptions or usage, billing inside Salesforce can be worth evaluating. The accounting system then receives summarized entries rather than every invoice.
Salesforce sells billing capabilities as part of Revenue Cloud. Product names, editions and packaging have changed several times in recent years, so check what your contract can include with your Salesforce account team. Native billing suits companies with recurring contracts, amendments mid-term or usage charges that are awkward to rebuild in accounting software. It is heavier to implement than a connector, and it still needs a general ledger sync. For a company that sends a few hundred straightforward invoices a month, a connector to the existing books is usually the simpler path.
Which approach fits which kind of company?
Company size matters less than billing complexity and the number of systems that touch the customer. Treat each row below as an opening position to test.
| Company profile | Likely accounting system | Sensible starting approach |
|---|---|---|
| Small services firm, simple one-off invoices | QuickBooks Online or Xero | An app-store or AgentExchange app syncing customers, invoices and payment status |
| Growing firm on Intacct with project or contract billing | Sage Intacct | Evaluate Sage's own Salesforce integration first, then fill gaps |
| Microsoft-centred company that chose Salesforce for sales | Business Central | A third-party AppSource app or integration platform; budget time for item and dimension mapping |
| Several systems: payments, e-commerce, inventory | Any | An integration platform, so every flow is monitored in one place |
| Subscriptions, amendments or usage billing driven from quotes | Any | Assess native billing in Salesforce against a connector before committing |
| Inventory, subsidiaries and complex fulfilment | NetSuite or another ERP | Treat it as an ERP project; see the ERP and NetSuite guides |
What mistakes do companies make with accounting integrations?
Most mistakes come from treating the sync as a technical task rather than a finance process change. We see each of these regularly.
- Letting reps edit invoice amounts or payment fields in Salesforce, which then disagree with the books.
- Creating a customer in accounting for every new lead or prospect, then cleaning thousands of empty records later.
- Turning on two-way sync for addresses and names without a rule for which edit wins.
- Leaving finance out of testing, so the first real test is month-end close.
- Picking a connector from a feature list without trying your own messiest invoice in a sandbox.
- Giving the connector an administrator's login, so it breaks when that person leaves.
API usage is a quieter risk. A connector that polls every few minutes for unchanged balances can eat into your Salesforce allocation, as our guide to API limits explains.
What should the first phase of an accounting sync include?
Phase one should remove the most re-keying with the fewest flows. For most companies that means customers, products, won-deal-to-invoice, and invoice status with balance shown back in Salesforce.
- Agree the ownership rules with finance and sales, in writing.
- Clean and match existing customers and products, and store each system's ID on the other.
- Build the won-deal-to-invoice or sales order flow, including tax and currency rules.
- Bring invoice status, open balance and the credit hold flag back to the account page.
- Set up the error queue, a named owner and a weekly reconciliation report.
- Test in sandboxes with real invoices, including a partial payment and a credit memo.
Leave payment collection, dunning, recurring billing and revenue recognition for later phases. Add them once the core sync has run cleanly through a few closes.
As a Salesforce partner since 2017, Abstrakt Solutions plans accounting syncs one flow at a time. We also audit existing connectors that keep failing.
