The output looks perfect and the total is off by an amount nobody can trace

Conversion errors are quiet. Nothing crashes, nothing is flagged, and the spreadsheet looks exactly like the statement it came from. The failure shows up later as a total that is wrong by an amount nobody can account for — and by then the file has usually been sent somewhere.

The five things that actually go wrong

1. The figures are text, not numbers

The most common failure by a distance. Every character sits in the right cell, but the cells hold text that looks numeric rather than numbers a spreadsheet can add. SUM returns zero, sorting puts 100 before 20, and nothing looks broken.

The check: select the amounts column and read the status bar. Sum and Average mean real numbers. Count alone means text.

2. Negatives came through positive

Statements write negatives as (84.20). Converted carelessly, those parentheses either survive as text or get stripped, leaving a positive 84.20 where a debit belonged. A sign error inside a column of two hundred rows is invisible and doubles the size of the mistake.

The check: find a known debit on the PDF and confirm it is negative in the spreadsheet.

3. Rows are missing

Usually at page boundaries, where a transaction description wraps across the break, or where a mid-statement subtotal interrupts the table. Missing rows are the hardest error to spot because what remains looks complete.

The check: count the transactions on the statement and count the rows in the spreadsheet.

4. Columns merged or split

Statements with separate debit and credit columns sometimes come through merged into one, or a long description overflows and pushes a figure into the neighbouring column. Both produce plausible-looking data in the wrong place.

The check: read the first five rows against the PDF side by side.

5. OCR misread a digit

Only applies to scanned statements. OCR handles words well because it can use surrounding language as context; isolated digits have no such context, so a 3 read as an 8 is entirely possible and reads as a perfectly ordinary figure.

The check: the closing balance, below.

The single check that catches most of it

Take the closing balance printed on the statement. Take the opening balance. Sum the converted transactions. The three should agree.

If they do, four of the five failures above are ruled out at once — missing rows, flipped signs, misread digits and merged figures all break this arithmetic. If they do not agree, the difference is often the error itself, which tells you what to look for.

On accuracy claims

Tools in this market advertise figures like 99% or 99.6% accuracy. Those are measured by the vendor, on documents the vendor chose, and they are not verifiable from outside. They are not necessarily dishonest — a maintained template for a named bank genuinely does perform well on that bank — but they say nothing about the statement in front of you.

A more useful way to read them: they tell you what the tool is optimised for. A tool advertising bank-specific templates will do well on the banks it covers and less well outside them. A tool advertising OCR accuracy is telling you it expects scans.

What this tool does about it

• Amounts arrive as real numbers with their original formatting attached, so $4.50 displays as currency and still adds up.
• Accounting parentheses become genuine negatives rather than text or positive figures.
• Cells that should stay text do — reference numbers, codes, anything containing a letter — because forcing those into numbers destroys them silently.
• Dates are deliberately left as text, since 03/04 is unresolvable from the file alone and a wrong guess is worse than no guess.
• A page with no table returns nothing rather than a sheet of prose chopped into columns.

What it does not do: read scans in one pass, or check the arithmetic for you. The balance check above is still yours to run, and it is worth the sixty seconds.

If the numbers do not reconcile

1. Compare row counts first — missing rows are the most likely cause and the easiest to confirm.
2. Check the sign on every parenthesised amount.
3. Look at the page boundaries, where wrapped descriptions and subtotal rows cause most damage.
4. If it was a scan, re-check any figure with a 3, 5, 6, 8 or 0 in it against the original.
5. If a real table was missed entirely, try the look harder for tables without lines option, which lowers the detection bar.

FAQ

Why is my converted bank statement's total wrong?

Most often the figures came across as text rather than numbers, so nothing adds. After that: negatives that lost their sign, rows dropped at a page boundary, merged columns, or an OCR misread on a scanned statement.

How do I check a converted statement is correct?

Sum the converted transactions and confirm they reconcile the opening balance to the closing balance printed on the statement. That single check rules out missing rows, flipped signs, misread digits and merged figures at once.

Why does SUM return 0?

The column holds text that looks numeric rather than numbers. Select it and read the status bar - if it shows only a Count and no Sum, there are no numbers in it.

Why did a debit come through as a positive number?

Statements write negatives as parentheses, like (84.20). A converter that strips the parentheses without applying the sign leaves a positive figure where a debit belonged - a sign error that is invisible in a long column.

Are 99% accuracy claims real?

They are vendor-measured on vendor-chosen documents and cannot be verified from outside. They mostly tell you what a tool is optimised for - bank-specific templates, or scanned input. Check your own document against its closing balance instead.

Why are rows missing from my converted statement?

Usually at page boundaries, where a description wraps across the break, or where a subtotal row interrupts the table. Count the transactions on the statement against the rows in the spreadsheet to confirm.

Does OCR make errors on numbers?

More than on words. OCR uses surrounding language as context to resolve ambiguous characters, and an isolated digit has none - so a 3 read as an 8 produces a perfectly ordinary-looking figure. Always reconcile a scanned statement.

What happens to my statement?

It is processed and discarded the instant your download is ready - never stored, never queued, and never read by a person.