A common bookkeeping situation: a client's bank only lets them download statements as PDFs, and you need the transactions in a spreadsheet or in accounting software. This walkthrough covers that case: how to tell whether the PDF can be converted, how to convert it, and how to prove that nothing was dropped before you import it.

Step 1: Check that the PDF has a text layer

A scanned or photographed statement is only a picture of the page, with no text layer. StatementHaul doesn't do OCR, so scanned statements can't be converted. The free PDF check runs in your browser and shows whether the PDF has a text layer, how many pages it has and how much text each page holds. If it says mixed, some pages have text and others don't, for example a scanned page added to an electronic statement.

Step 2: Convert it

1. Drop the statement PDF into StatementHaul. The conversion runs in your browser.
2. Download a CSV for a spreadsheet, or a .qbo file if you use QuickBooks.

Step 3: The balance check (opening + credits - debits = closing)

Before you import, the totals have to tie out: opening balance plus credits minus debits must equal the closing balance printed on the statement. StatementHaul does this for you. If it doesn't tie out, you see the difference and the first row where it breaks.

Step 4: Page carry-forward on multi-page statements

Where the statement has a running balance column, StatementHaul also checks every row and each page, and flags the exact row where the numbers stop adding up. In our local tests, a synthetic 2-page statement with 46 rows (opening 8,421.17, closing 34,775.64) reconciled with a difference of 0.00 and both pages passed. A tampered copy of the same statement still parsed all 46 rows but came back as a mismatch: off by 10.00, first problem at row 11, page 1 failing and page 2 passing. So you know which page to look at, not just that something is wrong.

Step 5: What to do on a mismatch

Another real local run: demo_slip_row5.pdf is an 8-row synthetic test statement (opening 2,500.00, closing 3,132.86) with one row altered. The parser read all 8 rows, but the check reported a mismatch of 10.00 with the first problem at row 5.

• Open the PDF at the flagged row and compare it with the CSV line.
• On a first reconciliation, a mismatch is often an incorrect opening balance, so check that first.
• Don't import the file until it ties out. A file that's off by 10.00 imports without complaint and only shows up later in reconciliation.

Limits, honestly

• No scanned or image-only PDFs (no OCR).
• The parser is generic, and it hasn't been tested on most real banks' current statement layouts. Always look at the balance result.

Price

5 statements a month free; statements that don't balance aren't counted. After that, $9 for 10 statements or $29 for 100. Convert a statement or check a PDF first.

Test figures above are from synthetic test statements in our own test suite, not client data. Not affiliated with any bank or with Intuit/QuickBooks.

You can catch all of that before importing with one piece of arithmetic the statement already gives you.

The math

Every bank statement prints an opening balance and a closing balance. Most also print a running balance after each transaction. Two things must hold:

1. Overall: opening + total credits − total debits = closing
2. Row by row: previous balance + this row's credit − this row's debit = this row's printed balance

The overall check tells you whether something is wrong. The row-by-row check tells you where. The first row where your computed balance stops matching the printed one is where the conversion went wrong. Every row after it will also be off by the same amount, so ignore those and look at the first one.

A few rules that save time:

• Work in cents. Round to 2 decimals before comparing, because floating-point sums like 0.1 + 0.2 aren't exactly 0.3.
• Treat the Debit and Credit columns as amounts without a sign. Some banks print debits as (15.00) or -15.00. If you then subtract that, you subtract a negative and the debit gets added. We hit exactly this bug while testing the script below.
• If the statement has no running balance column, you can still do the overall check. It just won't pinpoint the row.
• The size of the difference is a clue. A difference that equals one transaction usually means a missing or duplicated row. A difference of twice a transaction means its sign is flipped. A difference divisible by 9 often means two digits were swapped.

Option 1: Excel or Google Sheets

Lay out the converted data as A Date, B Description, C Credit, D Debit, E Balance (as printed), with headers in row 1. Put the statement's opening balance in J1 and its closing balance in J2.

In F2 (the computed running balance), then fill down:

=ROUND($J$1+SUM($C$2:C2)-SUM($D$2:D2),2)

In G2 (the check), then fill down:

=IF(E2="","",IF(ROUND(E2,2)=F2,"ok","BREAK"))

First broken row (anywhere outside column G):

=IFERROR(MATCH("BREAK",G:G,0),"none")

Overall check:

=IF(ROUND(J1+SUM(C:C)-SUM(D:D),2)=ROUND(J2,2),"ok","OFF")

We tested these formulas with LibreOffice Calc on a 4-row sample where rent of 950.00 had been mis-keyed as 590.00. Row 3 showed BREAK, the first-break cell returned 3, and the overall check returned OFF. If your debits are printed with minus signs or parentheses, wrap C and D in ABS() or clean them first.

Option 2: A free Python script

No libraries needed, only the Python 3 standard library. It uses Decimal, so there are no floating-point surprises. It reads a CSV with columns Date,Description,Credit,Debit,Balance (Balance is optional). It understands 1,200.00, $950.00 and (15.00), and it stops at the first row that breaks.

#!/usr/bin/env python3
"""Flag the first row where a converted bank statement stops balancing.
Usage: python3 check_balance.py statement.csv OPENING CLOSING
CSV columns: Date,Description,Credit,Debit,Balance (Balance optional)."""
import csv, sys
from decimal import Decimal, InvalidOperation

def money(s):
    s = (s or "").strip().replace(",", "").replace("$", "")
    if s.startswith("(") and s.endswith(")"):
        s = "-" + s[1:-1]
    return Decimal(s) if s else Decimal("0")

def main(path, opening, closing):
    run = money(opening)
    with open(path, newline="", encoding="utf-8-sig") as f:
        for n, row in enumerate(csv.DictReader(f), start=2):  # line 1 = header
            try:
                # Debit/Credit columns are magnitudes; banks sometimes print debits as (15.00)
                run += abs(money(row.get("Credit"))) - abs(money(row.get("Debit")))
                printed = (row.get("Balance") or "").strip()
                if printed and money(printed) != run:
                    print(f"FIRST BREAK at CSV line {n} ({row.get('Date')} {row.get('Description')}): "
                          f"expected {run:,.2f}, statement shows {money(printed):,.2f}, off by {money(printed) - run}")
                    return 1
            except InvalidOperation:
                print(f"Line {n}: unreadable amount {row}")
                return 1
    if run != money(closing):
        print(f"Rows all chain, but computed closing {run} != statement closing {money(closing)} "
              f"(off by {money(closing) - run}): a row is probably missing.")
        return 1
    print(f"OK: opening {money(opening)} + credits - debits = closing {run}")
    return 0

if __name__ == "__main__":
    if len(sys.argv) != 4:
        sys.exit(__doc__)
    sys.exit(main(*sys.argv[1:]))

Run it:

python3 check_balance.py october.csv 5000.00 5545.45

It exits with code 0 when the file balances and 1 when it doesn't, so you can also run it over a folder of files in a shell loop.

What we tested

We built a 4-transaction sample (opening 5,000.00, closing 5,545.45) and four broken variants:

That is the full extent of our testing: a small synthetic sample, not real bank files. Check the column names and date format of your own export before relying on it.

Then import, then reconcile

Once the file balances:

1. Make sure it meets QuickBooks Online's upload rules. Either 3 columns (Date, Description, Amount) or 4 (Date, Description, Credit, Debit), English, 350 KB or less, with dates in one format. Drop the Balance column from the import copy. See Intuit's Manually upload transactions into QuickBooks Online.
2. Upload it, then match and categorize the transactions under Bank transactions.
3. Reconcile using the same statement's ending balance and date, and aim for a Difference of $0.00. See Reconcile an account in QuickBooks Online and the overview Learn the reconcile workflow in QuickBooks Online. That overview also reminds you to confirm that the opening balance matches the statement for that day.

Because you balanced the file before importing, any difference left at reconciliation comes from the books (timing, duplicates, manual entries), not from the conversion.

Disclosure: This tutorial was written by StatementHaul, a bank-statement PDF converter that runs this same opening + credits − debits = closing check automatically on every statement before you export. 5 statements a month are free. The script and formulas above are free to use without it. This article was drafted with AI assistance and the script was tested by the StatementHaul team.