QuickBooks Online reconciliation won't balance to zero: the accepted four-step fix

A familiar wall for QuickBooks Online users: the monthly reconciliation is almost done, and the difference line still refuses to settle at zero. The accepted answer to this problem, published by Intuit for the UK edition of the product, treats the mismatch as a screening drill. Four steps run in a fixed order. Each one rules out a whole class of error before you start hunting through individual entries.

What causes a reconciliation to end out of balance?

The answer names three causes. Someone typed a wrong ending balance when the reconciliation was started. Entries sit in the books that the bank has not cleared yet. Or entries are missing from the books, or duplicated in them. The first is a data-entry slip. The second is often not an error at all, because banks clear items on their own schedule. The third is where genuine mistakes usually hide.

Step 1: confirm the beginning balance you inherited

The beginning balance is not something you type. QuickBooks Online carries it forward from the ending balance of the previous reconciliation. If that figure no longer matches the closing balance on last month’s statement, something changed after that reconciliation closed. Intuit puts this check first because a wrong inherited balance contaminates everything that follows.

An already-reconciled entry was edited, deleted, or unreconciled. Open the reconciliation history for the account and compare closing balances period by period. The spot where the carried figure shifts points to the month the change happened. Restore that entry to its original amount, or re-enter it, then reconcile it again in the period it belongs to. The inherited balance should now agree with the statement, and you can move on.

Step 2: check the ending balance you typed

This one is a straight typo hunt. From the Accounting menu, open Reconcile and choose Edit info for the account. Compare the ending balance and the ending date against the statement itself, not against memory. A single mistyped digit, or a stale ending date, throws every later comparison off. Correct the figures and save, and the working difference recalculates against the new amount.

Step 3: combine payments the way the bank did

Banks often merge several payments into a single line on the statement. If those same payments sit as separate entries in the books, nothing will match one-to-one. The tell is arithmetic: one statement line equals the sum of several book entries. The fix is to route those payments through Undeposited Funds and record a single bank deposit, so both sides show one combined amount.

Step 4: mark off everything that already matches

With balances verified and combined deposits merged, return to the statement and tick each entry that matches the books. This is elimination, not investigation. Every confirmed item comes off the suspect list. What remains is where the problem lives: an unticked amount, a duplicate, or a booked figure that differs from the bank’s. Duplicates often share the same date, payee, and amount, so the doubled line stands out once everything else is ticked. Items the bank genuinely has not cleared should stay unticked. They belong to a later statement and are not errors.

Does the order of the steps matter?

Yes, and the sequence is the point. Step one validates the balance you inherited, step two the balance you typed, step three the grouping of deposits, and step four the individual entries. Each step narrows the field for the next. Reversing the order sends you scanning a transaction list that may never have been the problem. A mismatch caused by a typo in the ending balance looks identical, on screen, to one caused by a missing payment.

Keeping the difference at zero next month

Two habits keep this problem rare. Reconcile on the statement’s own schedule, so uncleared items never age beyond one cycle. And treat reconciled entries as closed: the moment one is edited after its closing date, the next beginning balance moves, with no warning on screen. We would add one caution here. An adjustment entry can force a zero, but it buries the cause rather than removing it. The zero difference at the end is a checksum across every input. Verify the inputs in the order the accepted answer gives, and the checksum takes care of itself.