Common PDF Extraction Errors (and How to Catch Them)

That last point is the one people skip. A figure that's off by a single digit won't announce itself — it sits in row 47 looking exactly like the others. Extraction is step one; verification is step two.

Text PDFs vs image PDFs — the error that decides all the others

There are two kinds of PDF, and they fail in completely different ways.

A text PDF (also called digital or native) was generated by software — your bank's system exported it directly. The characters are real, selectable text. If you can highlight a number and copy it, it's a text PDF. These extract cleanly most of the time, because the converter reads actual character data rather than guessing.

An image PDF is a picture — what you get when a statement has been scanned, photographed, or printed and re-scanned. There's no text underneath, just pixels. To pull data out, a converter runs OCR (optical character recognition): it interprets shapes and decides which character each blob of ink is. That's where most serious errors creep in.

Here's the trap: a scanned statement and a native one can look identical on screen. People assume a converter "read" their PDF when it actually guessed at it. If one statement converts perfectly and the next is full of odd numbers, this is usually why. When in doubt, try to select the text — no selection means OCR is doing the work, so check the output harder.

OCR digit misreads: 0, 8, 1, 7 and the usual suspects

When OCR is involved, certain digits get confused again and again, because they share a shape at low resolution or under a heavy font.

• 0 and 8 swap when the loop of the 8 fills in or the 0 picks up noise. 180.00 becomes 100.00, and you've lost eighty pounds without a trace.
• 1 and 7 trade places, especially with continental-style 7s. A 71 payment reads as 11.
• 5 and 6, and 3 and 8, blur together on faxed or low-DPI scans.
• Decimal points disappear on faint scans, turning 1.50 into 150 — a 100× error so large it sneaks past a quick eyeball check.

The reason these matter more than they sound: a misread digit produces a *plausible* number. It's a valid amount, it sits in the right column, and nothing flags it — the error only shows up when the maths stops adding up. (For how reading accuracy varies by statement quality, see how accurate OCR is on bank statements.)

Decimal and thousands separators get swapped

This one bites international users hard. A statement writing one thousand two hundred and thirty as 1.230,50 (common in much of Europe) can be misread by a converter expecting 1,230.50. Flip the separators and 1,230.50 becomes 123,050 — off by a factor of a hundred.

UK, US, Australian, NZ and Irish statements use a full stop for the decimal and a comma for thousands, so this is rarer there — though it still surfaces when a converter strips commas to "clean up" a number and merges 1,200.00 into 120000. The fix: spot-check a few large amounts after conversion, anything in the thousands especially.

Columns collapse into one another

Bank statements are laid out in columns — date, description, money out, money in, balance — but a PDF doesn't store "columns". It stores text at x/y coordinates. A converter has to *infer* the boundaries from spacing, and when the spacing is tight, two columns merge.

The classic version: money-out and money-in collapse, so a debit lands in the credit column, or a balance figure gets stapled to the end of a description. You get rows like `Direct Debit British Gas 89.50` where the 89.50 should have been its own cell. Long merchant names that wrap onto a second line do the same — the wrapped text reads as a separate, amount-less transaction.

You'll spot collapsed columns fast: scan for any row where the amount is blank, or a number sits inside a text field. The good news is it's visible. The bad news is that fixing it by hand across a 12-page statement is exactly the tedious work you converted the PDF to avoid.

Page-break clipping: the transactions that quietly go missing

Multi-page statements are where transactions disappear. At the bottom of each page sits a "carried forward" balance; at the top of the next, a "brought forward" balance and repeated column headers. Weak converters either treat those lines as real transactions (inflating your data) or clip the first or last row of a page (deleting real ones).

A dropped transaction is the most dangerous error of all, because there's nothing in the spreadsheet to look at — you can't eyeball a row that isn't there. A statement can have 119 transactions, your file 118, and every visible number can be correct; it's just incomplete. This is the strongest argument for verifying against the balance rather than trusting the rows you can see.

Negative amounts and parenthesis notation

Banks show money leaving an account several ways: a minus sign (`-45.00`), parentheses (`(45.00)`), a "DR"/"CR" marker, or simply which column it sits in. Extraction errors love this variety.

• Lost minus signs — a leading hyphen gets dropped, so a 45 debit becomes a 45 credit. The amount is right; the direction is wrong, doubling the error in your totals.
• Parentheses misread — `(45.00)` reads as a positive 45.00, or the brackets get pulled in as stray characters.
• CR/DR markers stripped — the number stays, the marker goes, and nothing tells you whether it was in or out.

A sign error is sneaky because the magnitude is correct. Sort by amount and check debits are negative (or in the right column) and credits positive. Better still, let the running-balance check do it — a flipped sign breaks the maths immediately.

The safety net: verify, don't just extract

Every error above shares one feature — the resulting number usually *looks* fine. A misread digit, a swapped separator, a dropped row, a flipped sign: none produce an obviously broken cell. They produce a believable wrong answer. That's why proofreading by eye fails: you're checking whether each number is plausible, when the real question is whether it's *correct*.

One check catches all of it at once. Take the opening balance, add every credit, subtract every debit, and you should land exactly on the closing balance the statement prints. If you do, the transactions reconcile and the extraction held up. If you don't, something was misread, dropped, or flipped — and the gap points you roughly where to look.

This is the check Export Bank Statement runs automatically. When you convert a PDF, it doesn't just extract the rows — it verifies every transaction against the running balance and flags the statement if it doesn't reconcile. So instead of trusting a clean-looking spreadsheet, you get a clear signal that the numbers add up. It works on native and scanned PDFs alike, and exports clean Excel and CSV, including the native bank-import formats for Xero, QuickBooks and Zoho Books.

One honest caveat: the path is convert, then import the CSV. The tool doesn't push transactions into your accounting software via a live bank-feed API — you download the verified file and import it as reconcilable statement lines. (See how to convert PDF bank statements to Excel, and for scans, converting scanned bank statements to Excel.)