The size of a bank reconciliation discrepancy hints at its cause: a missing or doubled row leaves one row’s amount, a flipped sign twice an amount, swapped digits a multiple of 9. In our simulation 28.9% of the multiple-of-9 rule’s fits had another cause. Evidilo checks a statement’s rows against its printed balances; QuickBooks Online checks the books.
Three ways to read a reconciliation discrepancy
Every rule of thumb a bookkeeper uses on a difference comes from what one error does to the total. Take the discrepancy as the statement’s total minus the books’ total, and each kind of error leaves its own shape.
| Error in the books | The discrepancy is | Rule of thumb | Example |
|---|---|---|---|
| A statement row never entered | The row’s amount | Look for a row of that amount | A $64.18 card payment left out: off by $64.18 |
| A row entered twice | The row’s amount, the other way | Look for a row of that amount | A $64.18 payment entered twice: off by $64.18 |
| A row booked in the next month | The row’s amount | Look for a row of that amount | A deposit dated the 30th booked on the 1st |
| A deposit booked as a withdrawal, or the reverse | Twice the row’s amount | Halve it, then look for a row | A $120.00 deposit booked as money out: off by $240.00 |
| Two adjacent digits swapped | A multiple of 9 | Divide by 9; if it goes, suspect a transposition | $83.50 entered as $38.50: off by $45.00 |
The last example shows the trouble already. $45.00 divides by 9, but it is also the amount of an ordinary purchase, and if the statement holds a $45.00 row the first rule fits as well. Each rule is right about the arithmetic of its own error. None of them says the arithmetic belongs only to that error, and that is what we set out to count.
10,000 discrepancies, one error each
We generated monthly statements with a matching set of books, broke the books in one way at a time, and asked each rule what it saw. The statements mix card purchases, bill payments, round transfers, checks, deposits and fixed bank fees; the full list of assumptions is in the dataset. The table below is the small-business scenario, 30 to 80 rows a month, 1,000 cases per error, run on 25 October 2026.
| Error injected | Its own rule fits one row only | Another rule also fits | Clean read |
|---|---|---|---|
| Row missing | 95.3% | 14.0% | 82.3% |
| Row doubled | 95.1% | 11.5% | 85.0% |
| Sign flipped | 95.1% | 13.1% | 83.4% |
| Digits transposed | 4.5% | 1.2% | 4.4% |
| Row booked in the next month | 95.0% | 12.9% | 83.2% |
A clean read is a case where only the right rule fits and it points at exactly one row, the right one. A missing, doubled or flipped row reads cleanly about five times in six. A transposition almost never does, and the reason is in the next section.
Where the rules of thumb overlap
The multiple-of-9 rule is the weakest of the three, because about one amount in nine divides by 9 whatever caused it. It fit 11.4% of the missing rows, and across all five error types, 28.9% of the cases where it fit had no transposition in them. The halving rule named the wrong cause in 8.1% of its fits, rising to 16.2% on the busy account of 150 to 300 rows, where a $100.00 transfer is more likely to sit beside a $50.00 one. The one-row rule named a flipped sign or a transposition as a missing row in 1.2% of its fits.
A transposition is the error the rules handle worst even when they are right. Divisibility by 9 says that two digits swapped somewhere; it does not say where. In the small-business scenario the median statement held 6 rows that one swap of adjacent digits could have turned into the exact discrepancy, and only 4.5% of the cases came down to a single row. On the busy account the median was 23 rows.
One pair the size cannot separate at all: a row left out of the month and a row booked into the next month give the same discrepancy in 100.0% of cases, because they are the same arithmetic. Only the date on the statement settles which one happened.
These rates come from the amounts we generated. A ledger full of round transfers and whole-dollar checks will see more overlaps than ours, one made of card purchases fewer, and the per-rule shares assume the five errors are equally common, which no real set of books promises.
The QuickBooks bank reconciliation discrepancy, in Intuit’s words
QuickBooks Online shows two different numbers that bookkeepers call a discrepancy. At the end of a reconciliation it shows the difference between the statement’s ending balance and the books. Intuit’s page on fixing issues at the end of a reconciliation says “If everything is in place, the difference between the ending balances should be zero,” and lists among the causes “There are missing or duplicate transactions in QuickBooks.” The size rules above apply to this number.
The second number is the beginning balance being off. Intuit’s page on fixing beginning balance issues says “There’s a discrepancy in your beginning balance when something changes on a transaction since a past reconciliation,” and its Reconcile Discrepancy Report “lists what changed, how it affected your balance, and what you can do to fix each item.” That report names the transaction, so there is nothing to infer from the size.
Ruling the statement side in or out
Every rule above ends in the same step: find a row on the statement and compare it with the books. That assumes the statement copy you are reading from is right. When the books were keyed from a PDF or imported from a converted file, a row read wrong on the way in produces a discrepancy that no comparison between the books and that same copy will explain.
Evidilo, a bank statement to accounting import file converter, settles that half of the question before the books come into it. It turns a PDF, a scan or a photo of a statement into a CSV, Excel or QBO file, adds up every row against the opening, closing and daily balances the bank printed, and marks the first day that does not tie out. Evidilo does not reconcile an account and never sees the books. When the converted statement ties out, its rows agree with the bank’s own balances, so the books are the place to look first; what a tied-out statement proves sets out the limits of that.
Working a reconciliation discrepancy in order
- Note the discrepancy with its sign. Statement higher than the books points at a row missing from the books; books higher points at a row entered twice.
- Search the statement for a row of exactly that amount. If one fits, check its date before anything else, since a row booked in the next month looks identical.
- Halve the discrepancy and search again, for a deposit or payment booked the wrong way round.
- If it divides by 9, list the rows where swapping two neighbouring digits gives the discrepancy, and compare each one with the books. Expect several.
- If nothing fits, suspect more than one error, or a statement copy that does not add up to its own balances.
One case sits outside the five rows of the table. A whole statement imported twice doubles every row, and the discrepancy then equals the month’s net movement rather than any one row; why a statement imports into QuickBooks twice covers how that happens and what a per-row id can and cannot do about it.
The date in step 2 is worth reading on the statement itself. On a statement that prints the date once a day and leaves the rows under it blank, a converter has to carry that date down to each row, and a row near the end of the month is where a wrong date moves money between periods.
How was this checked?
On 25 October 2026 we ran a Python 3.11 simulation with a fixed seed: 10,000 generated statements across two scenarios, each paired with books that matched it before one error was injected, and each discrepancy tested against the three rules. The amount assumptions, every rate and the Intuit quotes with their fetch date are in dataset.csv and the JSON beside it. The script check.py reruns the simulation in a few seconds and fails if any number changes.
What bookkeepers ask about a discrepancy’s size
Why is my bank reconciliation off by a multiple of 9?
Often two digits were swapped when a row was entered, but not always. In Evidilo’s simulation 11.4% of missing rows also divided by 9, and 28.9% of the cases where the rule fit had no transposition in them. Check for a row of the exact amount first, then for a flipped sign, and only then hunt for the swapped digits.
What does it mean when the discrepancy is double a transaction?
Usually a deposit was booked as a withdrawal or the reverse. Evidilo’s simulation found the halving rule pointed at the wrong cause in 8.1% of its fits on a small account and 16.2% on a busy one, for example where a missing $100.00 row sits beside a $50.00 one. In QuickBooks Online, open the row you found and look at which side the amount is on.
Can the difference come from the bank statement rather than the books?
Yes, when the statement copy you entered from was read wrong. Evidilo adds up every row of a converted statement against the balances the bank printed and marks the first day that does not tie out, which rules the statement side in or out. It does not reconcile the account; the matching against the books stays in QuickBooks Online or whichever ledger you use.
Why does a reconciliation discrepancy match a transaction that is in the books?
The row may be booked in the wrong month: a row booked into the next period gives exactly the same discrepancy as a missing one. Evidilo converts the statement into a CSV or Excel file, so the rows dated in the last days of the month can be read beside the books. Two rows of the same amount also happen, in 4.7% of missing-row cases on a small account in the simulation.
What is the QuickBooks reconciliation discrepancy report?
Intuit calls it the Reconcile Discrepancy Report: QuickBooks Online opens it when the beginning balance of a reconciliation is off, and it lists reconciled transactions that changed afterwards. Evidilo plays no part in it, since it reads statements rather than ledgers, though a statement converted with Evidilo or with DocuClipper gives you rows to compare against the report. The report names the changed transaction itself, so the size rules matter for the ending difference, not this one.