Guides

How to Check a Converted Bank Statement Is Correct

A converted statement is a claim: these rows are what the statement says. Like any claim, it should be checked before it is used — for taxes, for a loan, for a client's books. The good news: a bank statement carries its own proof inside it, and checking takes minutes once you know the moves. This guide gives the full routine, from the one-line test that catches most errors to the spot checks that catch the rest.

Check 1: The balance equation (the big one)

Every statement prints an opening balance and a closing balance. Between them sits every transaction. So:

Opening balance + total money in − total money out = closing balance.

If your converted rows satisfy this equation to the cent, the set of rows is complete and the totals are right. It does not prove every single row is perfect — two errors could cancel out, though that is rare — but it rules out the common disasters: missing rows, doubled rows, flipped signs. When you convert with StatementConverter, this check runs automatically and the result is printed on the result page and in the Excel Summary sheet. If you converted anywhere else, run it by hand: add the credit column, add the debit column, and do the sum. Thirty seconds, no excuses.

Check 2: Section totals

Many statements print subtotals: total deposits, total checks, total fees, per-section totals on sectioned layouts like Chase's. Each subtotal is a mini-equation for one slice of the statement. Compare every printed subtotal with the sum of the matching rows in your file. When Check 1 fails, Check 2 is how you localise: the slice whose subtotal disagrees is the slice that holds the bad row. When Check 1 passes, Check 2 passing too makes a cancelling-error pair very unlikely.

Check 3: The running-balance scan

If the statement prints a Balance column, your file has a lie detector built into every row. Read down the converted table. Each row's balance should be the row above it, plus money in, minus money out — exactly that row's amount, no more, no less. You do not need to verify all of them. Scan for the row where the jump looks wrong: a balance that falls after a deposit, a jump bigger than the row's amount. That row — or the one just above it — is where a misread lives. This scan is also the fastest way to find the problem when a statement does not balance: the first break in the chain is the neighbourhood of the error.

Check 4: First row, last row, biggest row

Three spot checks catch what totals cannot:

• First and last rows: page-boundary rows are where readers stumble. Compare the first transaction of the statement and the last one against the PDF, character by character.
• The biggest money-in and biggest money-out rows: a digit error in a small row costs cents; in the salary or the tax payment it costs real money. Verify the two or three largest amounts against the PDF.
• Row count: many statements state how many deposits or checks the period had ('6 deposits, 20 checks' in a summary). Count your rows by type and compare. A count mismatch with matching totals means something subtle — two rows merged, or one split.

Check 5: The description sanity pass

Totals prove amounts. They say nothing about text. Give the Description column one fast read, looking for: descriptions that end mid-word (a column cut too narrow), descriptions swapped between neighbouring rows, and account numbers or page furniture ('Page 2 of 4', the bank's phone number) that wandered into a row. None of these break the balance; all of them break searches later, when someone filters by a payee name that is spelled two ways. Fix text in the result editor before downloading — the file you keep should be the file you checked.

What 'checked' should look like when you file it

A checked conversion leaves evidence. Ideally the file itself carries it: our Excel download includes a Summary sheet with the balances and the check result for exactly this reason. However you convert, keep three things together: the original PDF, the converted file, and a note of the check result (even 'reconciled 2026-11-04' in the file name or a notes column). Months later, that trio answers every question an auditor, a lender or a tax preparer can ask. US tax rules expect records that support the numbers in a return — the IRS guidance in our sources explains what counts and how long to keep it.

And a boundary worth stating: this routine checks the conversion against the statement. It does not check the statement against reality. If the bank itself printed a wrong row — rare, but it happens — your converted file will faithfully reproduce it and still reconcile. That is the bank's error to fix, and your checked file plus the PDF is exactly the evidence you would take to them.

The habit, in one paragraph

Run the equation. Compare the section totals. Scan the balance chain. Eyeball the first, last and biggest rows, then read the descriptions once. Five checks, about five minutes, and a converted statement stops being a hope and becomes a record. Do it for your own books, do it for clients, do it for the one statement in the batch of twenty that 'looked fine'. The errors are never in the statements you check twice. They are in the ones you almost did.

Check 6: Dates and order

Totals cannot see dates at all — a statement can reconcile perfectly with every row in the wrong month. So give the Date column its own pass. Look for: a row dated outside the statement period (a January row inside the February file usually means two statements overlapped); dates in the wrong order inside a section; and the classic swap, day and month trading places — 03/04 read as March 4 instead of 3 April. Statements from the UK and most other countries print day first, US statements month first, and a converted file standardises on the ISO form (2026-04-03) precisely so the swap cannot hide. If your file's dates came from anywhere else, sort the Date column and read the top and bottom rows: they should be the statement's first and last days.

Order matters for a quieter reason too. When statements are merged — see the batch workflow — one file whose dates drift will interleave its rows into the wrong month, and every equation still passes. The date pass is the only check that sees it.

Raise the stakes, raise the care

Not every statement deserves the same five minutes. Match the depth of checking to what rides on the file. A statement feeding your own monthly books: the five checks are plenty. A statement going to a lender with a loan application: add a comparison of the converted totals against the PDF summary page, printed and ticked by hand. A statement in a dispute or an audit: check every row against the PDF, amounts and text both, and keep the working notes. The cost of checking grows in small steps; the cost of a wrong number grows in cliffs — a declined loan, a wrong tax return, a fee dispute lost for want of one row.

There is one more situation that deserves full care: the first statement you ever convert from a new bank or a new client. Layouts vary — sectioned, combined, debits-only — and the first file is where you learn which kind you are holding. Our bank pages describe the layouts we have met, bank by bank. After the first clean file, later months from the same bank earn the fast routine.

A five-minute example

A March statement, 58 rows. Check 1 passes — the file reconciles. Check 2: the statement prints 'Total deposits 6 — $9,310.44'. The file's credits sum to $9,310.44 but count 7 rows. Totals agree; counts do not. Check 3's scan finds it: a deposit of $1,200 was split at a page break into two rows, $700 and $500 — same total, wrong rows, and the split would have poisoned a per-payment report. The fix takes a minute in the editor: merge the two rows back into one $1,200 deposit with the full description, save, and every check passes — this time including the count. That is why the routine has five checks and not one: each one sees a different kind of wrong.

Checking someone else's conversion

Often the file arrives from someone else — a client, a junior, another tool. Reviewing it is the same craft, run in a different order. Ask for three things: the PDF, the converted file, and the check result (if the tool gave one). Then re-run Check 1 yourself from the file's own numbers; never take 'it reconciled' on faith when the underlying rows are in front of you. Follow with the count check against the statement's summary, and the first/last/biggest spot checks. If the file fails anywhere, send it back with the specific failure — 'February is off by $120.00, equal to the rent row' teaches more and fixes faster than 'please re-check'. Checking is a conversation about specific rows, and the routine makes you specific.

If the sender cannot produce the PDF, treat the file as unverified no matter how clean it looks, and say so in writing. An unverifiable spreadsheet is a draft, not a record — a distinction that matters the first time a number in it is relied on by a bank, a buyer or a court.

Your evidence kit, per statement

• The original PDF, unchanged, named by bank, account and month.
• The converted file you actually used — not a later re-export.
• The check result: reconciled, or the difference and its explanation.
• A one-line note of any row you edited by hand, and why.
• The date you checked it. Checks age; a file checked in March and edited in May is a May file now.

Five small artefacts, and any future question about the statement — from a tax preparer, a lender, or yourself in two years — can be answered in minutes. That, more than the arithmetic, is what 'checked' buys.

The 60-second version

Short on time? This is the routine compressed to its bones. Confirm the file reconciles (equation). Compare one section total. Read the first and last rows against the PDF. Glance at the biggest deposit and the biggest payment. Done. Sixty seconds buys you protection against the errors that actually happen — the missing row, the doubled row, the flipped sign, the boundary stumble. The full five checks are for files that matter more or smell wrong; the 60-second version is for every file, every time, no exceptions. Any checker will tell you the same secret: frequency beats depth. A light check applied to all hundred statements catches more than a deep check applied to ten.

Make the routine a reflex and it stops feeling like work. The people who never get bitten by statement errors are not luckier than everyone else; they are the ones whose hands run the equation before their eyes trust the table. Five checks, sixty seconds in the short form, five minutes in the long one — and every statement you touch becomes the kind of record that ends arguments instead of starting them.

Sources and further reading

• What is a bank reconciliation? — University of Central Florida (graduate studies guide, PDF)
• What kind of records should I keep? — Internal Revenue Service (IRS)
• Regulation E, §1005.9: what a periodic statement must show — Consumer Financial Protection Bureau

More guides

How to Convert a Bank Statement PDF to CSV · How to Convert a Bank Statement PDF to Excel · How to Import Bank Statements into QuickBooks (QBO Files) · OFX vs. QBO vs. QIF: Which Format Should You Download? · Why a Converted Bank Statement Does Not Balance — and How to Fix It · Scanned vs. Digital Bank Statements: Why One Converts and the Other Does Not · How to Convert a Password-Protected Bank Statement PDF · How to Convert Many Bank Statements at Once (and Merge Them Cleanly) · Is It Safe to Convert Bank Statements Online? A Privacy Checklist