Converted statements do not usually fail obviously. They fail plausibly, the output looks like a statement, the numbers look like money, the dates look like dates, and one figure in the middle is wrong.
That is the dangerous kind of failure, because you have no reason to look. Here are the three ways it happens.
1. Columns shift when a cell is empty
This is the most common and the most damaging. Consider two rows of a statement:
Date Description Debit Credit Balance 01/04/2024 SALARY 3,500.00 13,500.00 05/04/2024 RENT PAYMENT 1,200.00 12,300.00
The first row has four pieces of text; the second has five. The blank debit cell contains nothing at all, there is no empty string in the file, just an absence.
A converter reading each row on its own, left to right, produces:
01/04/2024 | SALARY | 3,500.00 | 13,500.00 | 05/04/2024 | RENT PAYMENT | 1,200.00 | 12,300.00 |
Your salary is now a debit. Nothing about that output looks wrong. Every value is a real number in a real column, and if you are converting twelve months of statements you will not notice.
The fix: establish the column positions across the whole page first, then assign each value to the column it physically sits in, leaving a gap where a cell is empty rather than pulling the next value in.
2. Dates read in the wrong order
03/04/2024 is 3 April in most of the world and 4 March in the United States. A PDF does not record which convention is meant; it stores the characters and nothing else.
A converter that assumes one convention will silently shift transactions by up to eleven months on statements from the other. Your April rent lands in March, your monthly totals are wrong, and the error is invisible because every date is still a valid date.
The fix: read the whole column before deciding. As soon as any date has a value above twelve in the first position, that position must be the day, and the convention is settled for every other row. One unambiguous date resolves all the ambiguous ones, but only if you look at the column rather than the row.
3. Rows quietly dropped or duplicated
Several things cause this. A transaction whose description wraps onto a second line may be read as two rows or as one with the second line lost. A row split across a page break can vanish. A subtotal or a "carried forward" line can be read as a transaction.
A row count does not help, because you would need to know what the count should be, and if you were willing to count the rows in the PDF by hand, you would not need a converter.
The fix: check the running balance. A missing transaction makes the following row's balance wrong by exactly the missing amount, which usually identifies it on sight.
Why accuracy percentages do not help
Converters advertise figures like "99.9% field-level accuracy". Two problems with that.
It is a claim about the vendor's test files, not about yours. Your bank's layout may not be in that set at all, and the statements that break converters are exactly the unusual ones.
And even taken at face value, 99.9% on a statement with 200 rows and 5 fields is one wrong field per statement. On a year of statements that is twelve errors, in a spreadsheet you are about to file a return from, with no indication of where they are.
A percentage is not what you need. What you need is to know whether this file came out right.
The check that actually works
A bank statement is unusual among documents: it contains its own proof. Every row's running balance must equal the row above it, plus that row's credit and minus its debit.
balance(n) = balance(n − 1) + credit(n) − debit(n)
All three failure modes above break that equation. A shifted column breaks it immediately and everywhere. A misread digit breaks it at that row. A dropped transaction breaks it at the next row, by exactly the missing amount.
So the chain can be recomputed after extraction and compared. Hundreds of independent arithmetic checks all passing is not something a corrupted extraction achieves by accident, which makes it a proof rather than an estimate.
The statement converter runs this check on every conversion and reports the result, naming any row that fails. The checking guide covers what to do by hand when your statement has no balance column.