Reconcile CRM Invoices With QuickBooks: 3 Numbers

You do not reconcile CRM invoices with QuickBooks by making two numbers match. You reconcile by proving why three numbers are different.

That reframing is the whole job. Most owners open their field service software, see $412,000 invoiced for the month, open QuickBooks, see $381,000 of revenue, and conclude something is broken. Usually nothing is. The two systems measure different things on purpose, and a third number, what the bank actually received, is different again for reasons that are also legitimate.

Get that wrong and you spend every month hunting a difference that is supposed to exist, then give up and plug it. Get it right and the same work takes under an hour and doubles as a theft-and-leakage control.

The short answer

Build a bridge, in this order, once a month:

1. Start with total invoiced in the CRM for the period.
2. Subtract sales tax, which was never your revenue.
3. Subtract deposits and prepayments for work you have not performed.
4. That should equal QuickBooks revenue on the profit and loss.
5. From revenue, subtract the change in accounts receivable, subtract processor fees and financing fees, and add customer deposits collected.
6. That should equal total bank deposits for the period.

Every line is a number you can pull from a report. If all six tie, your books are right. If one does not, you have narrowed a vague mismatch down to a single named item, which is a five-minute investigation instead of a week.

Why the two systems are supposed to disagree

Your CRM records the face value of work. It counts everything the crew closed out: labour, materials, the sales tax on top, the annual maintenance plan sold in January, the financed job. That total is the number owners quote on the phone. It is not revenue in any accounting sense.

QuickBooks is supposed to hold earned revenue, and two things come out before the CRM total becomes that.

Sales tax was never yours. It belongs to the state or province and it should sit in Sales Tax Payable, a liability, not in an income account. If your CRM total includes tax and your P&L excludes it, the systems differ by exactly your tax collected, and both are right.

Money collected in advance is a liability. If a customer pays a 50% deposit on a $12,000 install, or buys a twelve-month maintenance plan, you hold their money without having earned it. A bookkeeping guide from Lend A Hand Accounting states the rule plainly: when a customer pays a deposit before work begins, it is recorded as a liability because the business has not yet earned the revenue. Your CRM has no concept of this and will happily show the full amount as invoiced.

Their point about that example is the one worth internalising: roughly $28,300 of merchant and dealer fees were real expenses that appeared nowhere in the profit and loss. That is not a rounding issue. That is a fifth of a technician's annual wage, invisible, every year, because nobody built the bridge.

The third number: what the bank actually received

Revenue and cash are different again, and the gap here is where most contractors lose the thread.

Receivable timing. You invoiced $412,000 but collected $370,000, because $42,000 is still outstanding. That is not a mismatch, it is accounts receivable doing its job. The reconciling item is the change in your A/R balance across the month, not the balance itself.

Processor fees arrive pre-deducted. A customer pays $772.50 and the bank shows $749.80. The QuickBooks community has threads asking why a processing fee changes the deposit amount going back to at least 2017, and the mechanism has not changed since: the processor withholds its fee and remits the net. If you record the $749.80 as your sale, you understate revenue by $22.70 and understate expenses by the same, and the original invoice sits in A/R forever because nothing ever paid it in full.

Card payouts are batches, not invoices. Money from Jobber, Housecall Pro or ServiceTitan does not arrive invoice by invoice. It arrives as a settled batch covering many payments with fees deducted, and expecting it to match any single invoice is itself a common source of confusion, as Kantivo's Jobber troubleshooting guide puts it. It matches the sum of the payments inside it, less the fee.

Financing eats a fee too. If you offer consumer financing on bigger installs, the lender remits less than the ticket. That dealer fee is a genuine cost of sale and the one contractors most often never book at all, because the money never shows up to be noticed.

The reconciling items, in a table

Pull each of these from a report rather than estimating it.

If you can fill every row from a source document, the bridge closes. If you are guessing at a row, that row is where your problem lives.

The real culprit is usually the bank feed, not the sync

Here is the part almost nobody writes about, and it explains more broken contractor files than every sync error combined.

Two incompatible bookkeeping methods are running in your QuickBooks file at the same time. A widely upvoted post in r/Bookkeeping, with over 120 upvotes and 60 comments, names them well: entry-centric bookkeeping, where you record the invoice and payment first and the bank statement later confirms what you already entered, and bank-feed-centric bookkeeping, where you look at what hit the bank, categorise it, and you are done. The author's argument is that QuickBooks Online fuses the two and pretends that is normal, and the consequence for the user is blunt: "You'll double-enter revenue. You'll double-enter expenses. You'll match things that aren't matches."

Now notice what your CRM is. It is aggressively entry-centric. It creates the invoice, records the payment against it, and pushes both into QuickBooks. The transaction is fully recorded before a single dollar reaches your bank.

Then the deposit lands, the bank feed offers to add it as income, and somebody clicks Add.

That is the whole failure. Revenue is now counted twice, the original payment never clears out of Undeposited Funds, and the balance sheet overstates cash. Steady, an accounting firm writing for field service companies, gives an illustrative version: the software reports $310,000 of invoiced work while QuickBooks reports $326,000 of revenue, and the reviewer traces the $16,000 difference to processor deposits added from the bank feed as sales when the invoices were already recorded. Their conclusion is worth repeating: marking the bank account reconciled would not have resolved the revenue error.

The rule that prevents all of it: decide which system creates deposits and hold the line. If the CRM's payout sync builds the deposit, the bank feed must only ever match it, never add it. Kantivo's guide reaches the same conclusion from the error side, noting that when a bank feed matches an incoming deposit before the payout sync arrives, those payments are already committed elsewhere and the payout has nothing left to group.

What a growing Undeposited Funds balance is telling you

Undeposited Funds is the holding account where a recorded payment waits until a deposit groups it and moves it to the bank account. In a healthy file it rises during the month and returns to roughly zero. It should behave like a hallway, not a room.

When it only ever grows, payments are being recorded but never banked in the file, which is the signature of the bank feed problem above. The scale this reaches is startling. A contractor who took over a family janitorial business posted in r/QuickBooks about inheriting over $1 million in Undeposited Funds because the previous office manager used QuickBooks only for invoicing. A bookkeeper taking over a 15-year-old business described almost $3 million of false undeposited funds plus ten years of false past dues, for the same reason: the owner made invoices, mailed them, and never recorded that anyone paid. The top-voted reply on that thread, at 46 upvotes, was "Better off starting fresh with a new set of books that you can keep under control." Another put it more sharply: "If that's all he used it for then you don't have a set of books."

That is the destination if you never build the bridge. It does not self-correct, and nothing forces the issue until a lender asks for financials or a buyer starts diligence, which is the worst possible moment to discover that two years of books need restating.

Four plugs that hide the answer instead of finding it

Every one of these appears in real threads from real bookkeepers, and every one converts a solvable problem into a permanent one.

Plugging the difference to Cash Short/Over. A newly qualified accountant posting in r/Accounting discovered a previous owner had reconciled by pushing every non-matching daily deposit into Cash Short/Over. From the outside, Undeposited Funds looked like it was being cleared regularly. It was, by absorbing every day's variance into an expense account.

Year-end adjusting entries to make it jive. A bookkeeper in r/Bookkeeping inherited a client whose previous accountant simply made entries at year end so the numbers agreed. The underlying workflow problem, deposits that did not match what the system said was collected, ran untouched all year.

Zeroing Undeposited Funds with a journal entry. Tempting, and it does make the balance sheet look right. It also destroys your only record of which payments were never banked. Work the deposits first. As one commenter reasoned about the $3 million case, if customers paid and the money never reached the business account, somebody took it out, and that needs recording as what it actually was.

Treating the net processor deposit as your sale. The quiet one, because nothing errors and the bank still reconciles. You permanently understate both revenue and expenses, lose sight of what card processing costs you, and leave paid invoices open in A/R.

Run the sync clean first, in dependency order

The bridge only works on top of a clean sync, and sync errors are not independent of each other. Records travel to QuickBooks in a fixed order: customers, then products and services, then invoices, then payments and refunds, then payouts. One blocked customer at the top produces a growing tail of unrelated-looking failures beneath it, each with its own message.

So a list of thirty errors is usually not thirty problems. Read the whole list before touching anything, notice how many trace to the same few customers, fix those, and most of the rest clear themselves.

Two specifics generate enormous noise, both documented in Jobber's own sync help pages and both generalising to every field service integration.

Create an explicit 0% tax code. Zero tax is not the same as no tax rate. If a 0% code has never been created in QuickBooks, every non-taxable invoice fails, which presents as the baffling symptom that some job types sync and others never do.

Read the warnings column, not just the errors. If a tax rate an invoice needs was made inactive rather than deleted, QuickBooks may proceed using a different rate. The invoice syncs successfully, with the wrong tax on it, and raises a warning rather than an error. Rounding differences behave the same way. Errors stop things and get attention. Warnings let things through slightly wrong, which is much harder to find later.

For the deeper diagnosis of records that arrive twice or come back after deletion, we covered the three root causes of QuickBooks CRM sync problems separately. If you are still choosing an integration, the eight tests in our guide to a CRM that syncs with QuickBooks two way will save you this article entirely.

The monthly procedure, in one page

Weekly, ten minutes:

• Open the sync activity list. Clear errors earliest-first, customers before invoices before payments.
• Check that Undeposited Funds came back down after the week's deposits.
• Do not click Add on any bank feed line that looks like a card payout. Match it or leave it.

Monthly, under an hour:

1. Cut off operations. Confirm every completed job is invoiced. Unbilled completed work is the one gap that does not appear anywhere on the bridge, because neither system knows about it.
2. Pull the CRM invoiced total for the period.
3. Subtract sales tax and deposits or deferred plan revenue. Compare to the P&L. Investigate the difference before going further.
4. Pull the processor statement. Reconcile gross payments, fees, refunds and chargebacks to the deposits that hit the bank.
5. Check the A/R Aging Summary. Opening balance plus invoiced minus collected should equal the closing balance.
6. Confirm Undeposited Funds is near zero, and that anything remaining is identifiable with an expected clearing date. Steady's close guidance puts this well: do not accept "it has always been there" as support.
7. Only now reconcile the bank account. It is the last step, not the first.
8. Write down what did not tie and carry it on a list. An unexplained item that survives two months is a process defect, not a one-off.

When the reconciliation is telling you something worse

Treat a persistent, unexplained gap between collected and banked as a control finding, not a bookkeeping annoyance.

The chain from CRM to QuickBooks to bank is the only place cash leakage is visible in a service business. A technician collecting a cheque that never gets turned in, a discount applied after the fact, a job closed out and never invoiced, a refund issued without approval: none of these look like anything on your P&L. They look like a number that will not tie.

That is why the plugs are so damaging. Cash Short/Over does not just hide a bookkeeping error, it hides the one signal you have. If the bridge closes cleanly every month, an anomaly stands out immediately. If you plug it every month, it never will.

When the seam is the software, not the process

Most of this is fixable with discipline. Half an hour on reference data, one decision about who owns deposits, and a weekly ten minutes keeps the queue empty.

But a perfectly healthy sync still will not answer the question you actually have. Your crews think in jobs. Work is quoted as a job, scheduled as a job, argued about as a job. That identity thins out when invoices become ledger entries, which is why "what did the Kowalski install actually earn after materials and the sub" gets answered in a spreadsheet rather than from the accounts. If that is your real question, job costing in QuickBooks Online is the structure to add.

The honest trigger for building something custom is not revenue. It is when you can name the same reconciling item failing every month for six months and no setting in either product fixes it, because the two systems disagree about what a job is. At that point you are paying a bookkeeper to be middleware.

The bottom line

Stop trying to make your CRM total equal your QuickBooks revenue. They are not the same measurement and they never will be.

Build the bridge instead. Sales tax out, deposits out, and you have revenue. Receivable timing out, processor fees out, financing fees out, and you have cash. Six lines, once a month, from reports you already have.

The difference between a contractor whose books are trusted and one whose books get rebuilt at tax time is not sophistication. It is that one of them can point at every number in that list and say where it came from.

Sources

• FinTruction, ServiceTitan QuickBooks Cleanup, illustrative worked month reconciling invoiced revenue, P&L and bank deposits
• Steady, Month-End Close Process for Field-Service Businesses, on processor deposits double-counted from the bank feed
• Kantivo, Jobber Not Syncing to QuickBooks, on sync dependency order, payout batching and deposit ownership, drawing on Jobber's published help documentation
• Lend A Hand Accounting, A Practical Guide to Accounts Receivable in QuickBooks Online, on customer deposits as a liability
• QuickBooks Community threads on processing fees changing deposit amounts, from 2017 onward
• r/QuickBooks, on seven-figure false Undeposited Funds balances; r/Bookkeeping, on the entry-centric versus bank-feed-centric split; r/Accounting, on variances plugged to Cash Short/Over