Troubleshooting
A balanced statement CSV can still be wrong
Two wrong amounts can cancel each other out in a statement CSV. Running balances help you see what the closing total hides, though neither check replaces reconciling your books.
By AnyStatement
Published , 8 min read
A closing total doesn't tell you whether each row is right. Keep the original file and compare its opening and closing balances with the statement, calculating computed minus printed. With printed running balances, you can find the first mismatch and any later errors that cancel it. Zero doesn't prove correct rows or a genuine document.
You can try the four fictional examples below in the free statement balance checker, or check your CSV locally. It doesn't require an upload, account or email.
The CSV and the books need different checks
Here we're checking one bank or credit card statement's extracted transactions against its printed balances. That's a technical review, not an accounting opinion. The QuickBooks links use US help for the named Online or Desktop product, whose menus aren't interchangeable.
These checks answer different questions. Statement arithmetic compares opening balance plus rows with closing balance, but zero doesn't prove every row correct. Reconciliation compares your books with the statement; it doesn't establish document authenticity. That needs independent source evidence beyond this calculator's CSV rows and two balances.
If the CSV disagrees with the PDF, look at extraction or editing first. If only the books differ, look in the ledger instead. Reconverting the PDF won't fix a transaction changed in your bookkeeping system.
Intuit's QuickBooks Online troubleshooting page, updated August 25, 2026, defines reconciliation as comparing specific QuickBooks transactions with the bank statement. It lists incorrect ending balances, uncleared transactions, and missing or duplicate entries as causes, none of which requires an unbalanced statement CSV.
The statement supplies the balances and row order
The statement heading identifies the account, currency and period you're checking. Take its opening and closing balances independently of the CSV total, because using a calculated closing balance as the printed one makes the test circular.
Work on a copy so the downloaded original stays intact. You can map either a signed amount column or separate debit and credit columns. Genuine fees, interest, refunds and adjustments belong in the calculation, but page subtotals and repeated headings don't. Record why you exclude anything so that decision can be reviewed.
For a bank account, money received is positive and money paid is negative. On an amount-owed card basis, purchases and interest increase debt, while payments and refunds reduce it. That's different from the negative-debt balances in another export, so choose a basis before calculating rather than mixing them. The credit card sign guide explains both perspectives.
Decimal separators and precision need checking without rounding, and a missing amount is unknown, not zero. For a forward running-balance check, reverse a newest-first file into the statement's posting order. An automatic date sort won't establish order within a day when dates are equal, and transaction dates may differ from posting order.
What a clean March statement looks like
This USD checking statement for March 2026 is fictional, not a customer document. It's the same six-row example as our CSV review checklist, with an opening balance of 2,400.00 and a printed closing balance of 2,365.05.
| Transaction | Description | Signed amount | Printed balance |
|---|---|---|---|
| 1 | Client invoice deposit | +1,200.00 | 3,600.00 |
| 2 | Rent | -1,150.00 | 2,450.00 |
| 3 | Office supplies | -86.45 | 2,363.55 |
| 4 | Refund received | +42.50 | 2,406.05 |
| 5 | Software subscription | -29.00 | 2,377.05 |
| 6 | Monthly service fee | -12.00 | 2,365.05 |
Inflows total 1,242.50 and outflows total 1,277.45. That gives a net movement of -34.95, so 2,400.00 - 34.95 = 2,365.05. Computed minus printed closing is 0.00, and each printed running balance equals the preceding balance plus that transaction.
We can say the file was read, its selected values passed format checks and its arithmetic agreed. Those are separate results, not a blanket “verified.” Neither balance nor transaction count checks a merchant name or proves the document came from the bank, so those limits belong beside the results.
A missing fee and a flipped sign look different
The Missing fee file in the checker's example selector ends after transaction 5. Its calculated closing is 2,377.05, or 12.00 above the printed closing. Every supplied running-balance link agrees because the missing fee is at the end.
That's why “all rows passed” would be misleading. The rows agree locally but don't reach the stated closing, so compare the final page and any fee or interest section with the export. You can't highlight a missing -12.00 row in a file that doesn't contain it.
In Refund sign flipped, transaction 4 is -42.50 instead of +42.50. Computed closing falls to 2,280.05, giving a signed difference of -85.00. Half its magnitude is 42.50, which makes that refund a sign-flip candidate because reversing a transaction changes the total by twice its magnitude.
| Input | Computed closing | Computed minus printed |
|---|---|---|
| Clean six rows | 2,365.05 | 0.00 |
| Fee omitted | 2,377.05 | +12.00 |
| Refund sign reversed | 2,280.05 | -85.00 |
An amount matching the magnitude of the difference, or half the difference, gives you somewhere to look. It doesn't tell you what to correct: two unrelated errors or a wrong opening or closing balance can leave the same residual. Check the statement before changing a matching amount.
A mismatch can disappear without being fixed
In Offsetting 18.00 errors, supplies are wrongly -68.45 instead of -86.45, overstating the balance by 18.00. The subscription is wrongly -47.00 instead of -29.00, understating it by 18.00. Together they have zero net effect, but both errors are still there.
| Transaction | Calculated balance | Printed balance | Difference |
|---|---|---|---|
| 2: before the errors | 2,450.00 | 2,450.00 | 0.00 |
| 3: supplies misread | 2,381.55 | 2,363.55 | +18.00 |
| 4: refund unchanged | 2,424.05 | 2,406.05 | +18.00 |
| 5: subscription misread | 2,377.05 | 2,377.05 | 0.00 |
| 6: fee unchanged | 2,365.05 | 2,365.05 | 0.00 |
A local link compares previous printed balance + this amount with this printed balance. That check breaks at transactions 3 and 5, while transaction 4's link agrees because its amount is correct.
The cumulative path instead compares opening balance + every amount so far with this printed balance. It disagrees at transactions 3 and 4, then agrees at transaction 5. That leaves an exact two-row disagreement span.
The CSV's one-line header puts those rows at source lines 4 and 5, with agreement restored at source line 6. These are physical CSV lines, not PDF references. Line breaks in quoted descriptions can shift the numbering further.
Start with the first broken local link and its preceding printed balance: the amount, balance, preceding balance or row sequence could be wrong. Check every later broken link too, even after a return to zero. Separate inflow and outflow totals would miss these errors because both amounts are outflows and their changes cancel.
If a running balance is absent, mark it as unavailable evidence rather than a match. An unknown previous balance blocks the next local check. You can still carry a cumulative total through known amounts, but you can't claim a match or an exact return to agreement at a blank balance.
Divisibility by 9 is a hint, not a diagnosis
Swapped digits can leave a difference divisible by 9. Here, 86.45 minus 68.45 is 18.00: in cents, that's 1,800, divisible by 9. This integer test works at other fixed decimal precisions too, not just for dollars.
Moving digits between decimal positions changes their contribution by multiples of 9 because powers of 10 have remainder 1 when divided by 9. But that reasoning doesn't work backwards. A missing 18.00 fee gives the same clue without any swapped digits.
The checker shows this note only for a nonzero closing residual divisible by 9 in the selected scaled units, not the offsetting example's zero closing difference. It can narrow your search, but it can't identify the cause or justify swapping digits until the total works.
When only the books disagree
Correct extraction doesn't complete reconciliation. The OJP FMSC bank reconciliation guide compares statements with the general ledger and explains deposits in transit, outstanding checks, interest and bank charges. We use its comparison method, not the grant-specific compliance requirements.
In this second fictional example, the statement still closes at 2,365.05. The books include a 300.00 deposit not yet at the bank and a 125.00 uncleared check. They show 2,552.05 but haven't recorded the 12.00 service fee.
| Side | Explained movements | Adjusted balance |
|---|---|---|
| Bank: 2,365.05 | +300.00 deposit; -125.00 check | 2,540.05 |
| Books: 2,552.05 | -12.00 known service fee | 2,540.05 |
The 300.00 and 125.00 are timing differences, so they don't belong in the CSV as invented statement transactions. The 12.00 fee has statement evidence and needs appropriate recording in the books. That's a known omission, not an unexplained number added to force agreement.
For a previously reconciled QuickBooks Online account, Intuit's beginning-balance guidance, updated September 1, 2026, lists changed, deleted, voided, moved or unreconciled transactions. It describes the Reconcile Discrepancy Report and checking history before correcting anything, because an intentional change shouldn't be automatically reversed.
For current-period differences, follow Intuit's August 25, 2026 ending-balance guidance: check entered balances and dates, then actual transactions. Multiple book payments may match one combined bank deposit, so correct reconciliation doesn't require equal row counts across systems.
Explain the difference rather than forcing a match
Reaching zero isn't a correction unless the source supports it. Until then, keep the discrepancy rather than inventing a CSV adjustment, replacing a printed balance with a calculated one or deleting a plausible candidate.
Intuit's Desktop troubleshooting page, updated August 5, 2026, warns that reconciliation adjustments don't fix errors and can cause problems after the underlying error is corrected. It advises involving your accountant, not forcing a match. The newer Online guidance also recommends resolving differences and consulting your accountant before accepting an adjustment.
Once you have a supported correction, record the error, its source evidence and the before-and-after values. Then recalculate the closing equation and every available running-balance link to see the effect. If you still can't explain the difference, hand it over as unresolved rather than clearing the file.
Give the next person enough to review your work
For someone else to review your work, keep the original statement and export with the identified working copy, account, currency and period. Your note needs the printed opening and closing balances, sign basis, separators and posting order. It should account for every page and unresolved row, including fee and interest sections.
To show where the arithmetic disagreed, save the closing residual, first broken local link and cumulative mismatch spans, including returns to zero. Record source-backed corrections and rerun checks without invented adjustments, keeping ledger timing differences and historical changes separate from extraction errors.
The balance checker downloads an exception report with settings, source lines and original versus interpreted amounts. If required values or conventions remain unresolved, its diagnostics are explicitly incomplete, not a checked result. Your source evidence and decision belong in the statement review log, because the calculator can't make that judgment.
If you're starting with a PDF, first look for a bank-native export or prepare the rows manually. You can also use AnyStatement to extract reviewable data from the PDF. That separate upload workflow can help you inspect numbers, but it doesn't replace the ledger comparison or establish authenticity.
What we checked, and what we didn't
On October 17, 2026, we opened the linked Intuit Online and Desktop pages and OJP FMSC guide. We also independently recalculated every example with Python's Decimal arithmetic, covering running balances, the missing fee, doubled sign error, offsetting span and separate timing differences.
We compared the checker's diagnostics with an independent Python Decimal checker on 800 randomized synthetic statements with omitted and duplicated rows, reversed signs, digit swaps, offsetting errors and wrong opening balances. We ran every built-in example in the browser, checked a 10,000-row file and inspected downloaded reports. These checks weren't an accuracy study across banks. We didn't import examples into a live accounting account, test vendor reconciliation features or authenticate any statement.