CRM With Accounting Integration: Link Deals to Invoices and Payments

Coding Liquids tutorial cover featuring Sagnik Bhattacharya for CRM With Accounting Integration: Link Deals to Invoices and Payments.
Coding Liquids tutorial cover featuring Sagnik Bhattacharya for CRM With Accounting Integration: Link Deals to Invoices and Payments.

Connect your CRM to Xero or QuickBooks with the CRM's own integration if it creates invoices, or with a connector such as Zapier if it only syncs contacts. Map customer, line items, amounts and dates, create draft invoices when a deal is marked won, and test with one real-looking deal before switching it on.

The part people skip is the matching rule. Software has to decide which customer in your accounts a deal belongs to, and when it cannot decide, it either quietly creates a second customer or fails without much fuss. Preventing both, and checking afterwards that neither has happened, matters more than which tool you pick.

Follow me on Instagram@sagnikteaches

What the link should do, and what it should leave alone

Write the job down in one sentence before you open any settings: "When a deal moves to Won, a draft invoice appears in the accounts for that customer, with the agreed line items, and the deal shows the invoice number and whether it has been paid." Everything else is optional. Each extra thing you sync (quotes, notes, tasks, payments in both directions) is another place for the two systems to disagree.

Connect on LinkedInSagnik Bhattacharya

It helps to decide which system owns which data. A sensible split for a service business: the CRM owns people, companies, deal stages and the agreed scope; the accounting package owns invoices, tax treatment, bank matching and payment status. The link carries a small set of fields from the first to the second, and one status field back. If both systems can edit the same field, you will eventually overwrite something.

Subscribe on YouTube@sagnikteaches

Four things the link should never do on its own

  • Send an invoice to the client. Drafts only, at least at first.
  • Change a customer's name or billing address in the accounts when someone edits the CRM record. Accountants dislike history changing underneath them.
  • Create new products or tax codes in the accounts. Map to the ones that exist.
  • Delete anything in either system.
The Complete Excel Course with AI Integration thumbnail

The Complete Excel Course with AI Integration

From formulas and pivot tables to Power Query, DAX, VBA and AI with Copilot, ChatGPT and Claude — hands-on from the first lesson.

By Sagnik Bhattacharya and Virginia Thorn, Primetime Emmy Award winner

Buy now

Native integration or connector: how to choose

There are three routes, and the right one depends on how much your deals vary.

RouteGood whenWatch for
The CRM's own integration with the accounting packageDeals use standard products and prices; you want invoice status shown on the dealIt may need a particular CRM tier, may be limited to some regions or account types, and usually expects one billing contact per customer
A marketplace app built by a third partyThe native one lacks something you need, such as custom field mapping or creating an invoice at a particular stageSeparate subscription, another vendor to trust with financial data, requirements that differ per app
A connector such as Zapier or MakeYour CRM has no good native link, or you need a rule the native one lacksTask usage and plan limits, no built-in error handling unless you add it, and you own the maintenance

Start with the native route, because it is the one the CRM vendor supports. As one example, HubSpot's knowledge base describes QuickBooks Online workflow actions, including "Create a QuickBooks invoice", which can run when a deal reaches a chosen stage. Its requirements are instructive for any CRM. Line items must be associated with the deal, and each must match a product in QuickBooks; if no match is found, no invoice is created, unless you set the action's "Create a product in QuickBooks if it doesn't exist?" option to Yes, which is safer left at No. The deal's contact must be eligible under your contact sync settings, or the action fails. An invoice created from a deal-based workflow is associated with that deal. HubSpot also says these workflow actions are available only to customers in particular countries and suggests consulting your accounting team before connecting, so confirm both on its current articles before planning around them.

Notice what that tells you about the general case. Line items on the deal matter, so your team has to add products to deals rather than just typing an amount. Product matching matters, so the names or codes in the two systems must line up. Contact eligibility matters, so the billing contact has to exist and pass the sync rules before the deal is won. Whatever CRM you use, ask the same three questions of its integration: what must be on the deal, how it matches products, and how it matches the customer.

HubSpot's set-up article for the same integration adds three details worth copying into your own plan. First, QuickBooks needs each customer's display name to be unique, so the first contact synced from a company takes the company's name and later contacts from that company fail to sync; HubSpot's advice is to keep one contact per company as the billing contact. Second, some edits cannot be made in QuickBooks to an invoice created in HubSpot, including adding or removing line items and changing prices, so corrections go back through the CRM. Third, changes travel from HubSpot to QuickBooks within a few minutes but from QuickBooks to HubSpot every 30 minutes, with a Sync now button when you cannot wait. Other CRMs have their own versions of these rules, and the integration's help article is where you find them.

When a connector earns its place

If you go the connector route, check the plan arithmetic first. On Zapier's free plan, only two-step Zaps are available and there are 100 tasks a month; Professional starts at $29.99 a month billed monthly, or $19.99 on annual billing, for 750 tasks. Zapier counts a task when it successfully completes a unit of work; triggers and its built-in filter steps do not count, and failed actions are not charged. So a Zap that looks up a customer, creates an invoice and writes a note back uses up to three tasks per won deal, and its three action steps already rule out the free plan. A business closing 40 deals a month uses about 120 tasks, well inside the smallest paid tier. Prices change, so confirm on Zapier's plans page.

Check your accounting plan before you build

A link that creates invoices is no use if the plan limits invoices. Xero's list prices in USD are Early $27, Growing $59 and Established $97 a month. Early allows 20 invoices and five bills, and Xero's footnote says the invoice limit applies to both approving and sending invoices, and that transactions initiated by app partners may count towards it. That second point is the one to notice, because your CRM link is exactly such an app. A firm that raises 35 invoices a month needs Growing before the automation goes live, not after the limit stops someone approving invoice number 21. QuickBooks Online lists Simple Start at $38, Essentials $85, Plus $140 and Advanced $340 a month. QuickBooks also has a $0 Free plan, but it sends two invoices a month unless you qualify for and turn on QuickBooks Payments, so it is a poor base for an automated deal-to-invoice link. Both vendors run introductory discounts on paid plans, so treat the figures as list prices and check the current page.

Also check the tax and product set-up in the accounts. The sync can only choose from the tax rates, income accounts and items that already exist. If your accountant has two income accounts for "consulting" and "installation", the integration needs a rule for which one a line goes to.

Field mapping that survives real deals

Mapping is the list of "this CRM field goes into that accounting field". Do it on paper first. Here is a filled-in example for a service business, illustrative only.

CRM fieldAccounting fieldRule
Company nameCustomer / contact nameMatch on existing customer first; create only if no match
Billing email on the companyCustomer emailUsed as the matching key, so it must be filled in before a deal can be won
Deal line itemsInvoice linesEach CRM product maps to one accounting item
Deal close dateInvoice dateDraft takes the close date; accounts can change it
Payment terms (property on the company)Due dateDefault 14 days if empty
Deal ownerInvoice referenceLets the bookkeeper ask the right person
Purchase order numberInvoice referenceRequired field on the deal for corporate clients
(from accounts) Invoice number and statusDeal propertiesRead-only in the CRM

Two rows matter more than the rest. The matching key, because it determines duplicates. And the "required before Won" fields, because an automation cannot invent a billing email. The simplest fix is in the CRM itself: make billing email, payment terms and at least one line item required before a deal can move to Won. Most CRMs support stage-gating like this, and it turns a silent sync failure into a visible prompt for the salesperson.

A worked example: a signage company's install jobs

Illustration: a signage company with six staff sells fabricated signs plus installation. Deals sit in a CRM with stages Enquiry, Quoted, Won and Installed. Before the link, the office manager retyped each won deal into Xero, around 25 a month at roughly ten minutes each, so about four hours a month, plus the occasional wrong amount because a revised quote had not been reflected.

The set-up they choose:

  1. Products first. They create three items in both systems with the same names: "Fabricated sign", "Installation (per visit)", "Permit handling". Each maps to one income account.
  2. Required fields. A deal cannot enter Won without a billing email, payment terms of 14 or 30 days, and at least one line item.
  3. Trigger. Moving a deal to Won creates a draft invoice in Xero for the deposit, 50% of the total. When the deal moves to Installed, a second draft for the balance appears.
  4. Write-back. The invoice number shows on the deal, and its status (draft, awaiting payment, paid) updates on the integration's own schedule, which may be every few minutes in one direction and every half hour in the other.

The numbers on a typical job: a fabricated sign at $1,800, installation at $450, permit handling at $120, total $2,370. The deposit draft is $1,185 and the balance draft is $1,185. The bookkeeper reviews drafts once each morning, which takes two minutes for a batch of five, and approves. At 25 jobs a month that is 50 drafts, roughly one to two hours of review, against four hours of retyping, and wrong amounts disappear because the invoice is built from the deal's line items. The saving is modest in hours and larger in trust: the invoice number sits on the deal, so the sales lead can answer "has the client been billed?" without asking.

Run a test invoice before anything is switched on

Never test with a real client. Create a test customer in both systems and follow this routine.

  1. Create a deal with two line items and a billing email you control. Move it to Won. Confirm that a draft appears within a few minutes and that it is attached to the customer you expected, not a new one.
  2. Check the draft line by line against the deal: item, quantity, unit price, tax rate, income account, date, due date, reference.
  3. Edit the deal's amount after the draft exists. See what happens: most links do not update an existing invoice, which is what you want, but you should know.
  4. Move the deal to Won a second time (drag it out and back). Confirm it does not create a second invoice. If it does, add a filter or a "has invoice number" condition.
  5. Approve the draft, record a small payment against it, and watch the status come back to the deal.
  6. Void the test records in the accounts rather than deleting them, unless your accountant says otherwise.

If you want a general method for trialling automation safely, piloting in shadow mode covers the same idea of running alongside the manual process before replacing it.

Three realistic failures and how they show up

  • The duplicate customer. The CRM holds the company as "[Name] Fabrication Ltd"; the accounts hold "[Name] Fabrication" without the "Ltd". No match, so a second customer appears and the old one's unpaid history is split. You spot it as a new customer record with only one invoice. Fix with a pre-launch clean-up (see cleaning customer records first) and by matching on email or an ID property rather than name.
  • The wrong contact. A deal lists the site manager first and the finance contact second. The invoice goes to the site manager's email. Fix by designating a billing contact role and mapping that one.
  • The silent stall. A connector run errors because an item name changed, and nobody notices for a week. Add an error alert (most connectors can email you on failure) and a Monday check that compares the count of Won deals with the count of new drafts.

Payments coming back to the CRM

Native integrations usually show invoice and payment status against the deal, but check where the data lands. HubSpot's QuickBooks app, for example, does not write to the Accounting deal property group, and HubSpot recommends building reports and workflows on the invoice object instead. Once you know where status lives, you can build useful CRM views: "Won, unpaid more than 14 days" for the owner, and a task for the salesperson to nudge a late payer. If you want the chaser wording drafted, invoices, proposals and chasers for freelancers has examples that adapt to any service business.

Partial payments are where simple links give up. If clients pay deposits, check how the integration reports a part-paid invoice: some mark the deal as paid when any payment arrives. Payments that cover several invoices are another weak spot: HubSpot documents that a single QuickBooks payment applied to more than one invoice does not sync back to HubSpot, so a client who settles deposit and balance in one transfer can look unpaid in the CRM. Test it with a deliberate part-payment, using the deposit-and-balance split from the signage example, so you see what the deal shows after the first $1,185 arrives and before the second.

A second example: a heating and cooling contractor's service plans

Not every deal is a one-off. Illustration: an HVAC contractor sells annual maintenance plans at $480 a year, billed in two instalments of $240 in March and September. A one-off "deal won, draft invoice" rule fits badly, because the second instalment is not a new deal.

Two sensible ways to handle it. The first is to keep the CRM deal as the sale only, and let the accounting package own the schedule: set up a repeating invoice in Xero or a recurring one in QuickBooks from the won deal (check that your plan includes it), which the bookkeeper sets up once. The second is to have the link create two drafts at the Won stage with different due dates, which is simpler but means a cancelled plan leaves a draft to void. For a contractor with 150 plans, the first approach is better, because renewals and price rises then happen in one place. Recurring agreements in HVAC accounting software covers that side in more depth.

The lesson generalises: decide for each deal type whether the invoice is a single event, a deposit and balance, or a schedule, and write the rule next to the mapping table. Three deal types, three rules, one page.

A quick sum to justify the effort

Take your own numbers: deals won a month, minutes to retype each, hourly cost of whoever does it, and a rough count of billing mistakes a quarter. Say 30 deals at 12 minutes is six hours a month. At $30 an hour that is $180 a month, or $2,160 a year, before counting a single missed invoice. If one deal a quarter was never billed because the retyping got forgotten and the average job is $2,370, that is far larger than the time saving. Compare it with a connector at $19.99 to $29.99 a month and a few hours of set-up.

Keeping it honest after launch

A monthly ten-minute check is enough. Count Won deals in the CRM, count new invoices created through the link, and list any difference. Scan the customer list for new entries created by the integration. Compare a sample of three invoices with their deals. Record the result in a shared note so that whoever covers for the bookkeeper knows how it works.

Also write down who gets the failure alerts and what they do. An integration without an owner works until the first change: a renamed product, a new tax rate, a CRM field somebody deletes during a tidy-up. Put the mapping table from earlier in a shared document, and update it whenever either system's product list changes.

If AI features are involved later, such as drafting the cover email that goes with an approved invoice, keep them downstream of the numbers. The amounts and lines come from the deal; the AI only writes words. Accounting data is the last place for a guess. For the wider chain this link sits in, connecting quotes, invoices and payments shows where AI helps between the quote and the payment and where it should stay out.

Deciding whether to build it yourself

A native sync is an afternoon's work. A connector with filters, lookups and error handling is a day or two, and the real cost is not the build but the upkeep. If your deal types are many (different tax treatments, multiple currencies, retainers with schedules), the cost of getting it wrong grows, and so does the case for having someone map it with you. If you would rather do that mapping with someone who has done it before, that is what my AI implementation consultation covers.

For a small firm with one or two standard deal types, the plain version above is usually plenty: required fields, draft invoices, one matching key, a test, a monthly check.

Questions owners ask before linking CRM and accounts

Should a won deal create a draft invoice or a sent one?

Create a draft. A draft lets someone check the amount, tax treatment, dates and customer before the client sees it. Once the error rate on drafts has stayed near zero for a couple of months, you can consider approving automatically for small, standard deals only.

Can I link a CRM to accounting software without paying for a connector?

Often yes. Many CRMs list a native Xero or QuickBooks integration in their app marketplace, though it may need a particular CRM tier and some features are limited to certain regions. Check the listing's requirements and any charge first, because the native route sometimes covers contacts only, not invoices.

What happens if the client's name differs between systems?

Syncs match on a name, email or ID, and when nothing matches, some create a new customer while others stop with an error. Decide one matching field up front, clean the obvious duplicates first, and review the first few invoices for unexpected new customer records or failed runs.

Do payments flow back into the CRM?

Only if the integration or connector supports a return path. Native options often show payment status on the deal; connectors need a second automation that triggers on payment. Test it with a real small payment, not an assumption.

Further reads

Sources: HubSpot knowledge base articles on QuickBooks Online workflow actions and on connecting HubSpot and QuickBooks Online; Xero pricing (USD) and Early plan pages; QuickBooks Online pricing and Free plan pages; Zapier pricing page.

Want deals to reach your accounts without retyping?

On a 1:1 call we'll map how a won deal becomes an invoice in your business today, decide whether your CRM's own sync is enough, and pick the first handover to automate.

Book a 1:1 call with me