You have a folder of statement documents, a deadline, and a shortlist of ways to turn one into the other. Output formats and price are usually where the comparison starts, and they do matter, particularly if a specific import format is the only one your ledger accepts. They are just not what separates a good conversion from a bad one. What separates them is whether the rows you get back are all of the rows, and whether anything in the process is capable of telling you.
Before you evaluate anything, check what the bank will give you directly. If online banking offers a CSV, OFX or QBO download covering the period you need, take it: a file the bank generated is cleaner than anything read off a printed page. The reason a converter is on your shortlist at all is that the export usually falls short somewhere. Download windows are commonly capped at ninety days or eighteen months while the statement archive runs back years. Raw exports frequently omit the running balance, which is the figure you would reconcile against. Descriptions arrive truncated. A closed account often offers no export at all. Whatever the export cannot cover, you are converting statement documents, and the criteria below are how to judge that.
Most conversion failures are not dramatic. They are one missing transaction in a hundred and forty, a description split across two rows, a debit that arrived without its minus sign. Every one of those passes a visual scan and fails a reconciliation. So the criteria below are ordered by how much work they save you after the file lands, not by how they look on a feature list.
The criterion that decides it: arithmetic reconciliation
A bank statement is one of the few documents that carries the means to check itself. It prints an opening balance, a closing balance, and every movement between them. Take the opening figure, add every credit, subtract every debit, and you should land exactly on the closing figure.
Be precise about what landing proves, because that precision is what makes the criterion worth anything. It is not proof that the file is right. It does not verify a single date or description, and two errors that offset each other exactly will pass it. What it gives you is the strongest automatic check this document supports, and it catches the error class that costs the most: a wrong digit in an amount changes a total, and a changed total breaks the chain arithmetically. When the chain breaks, the difference is frequently the precise value of what went missing, which turns a hunt into a lookup.
So the first question about any converter is whether it runs that test and reports the result. Not whether it produces a spreadsheet: everything produces a spreadsheet. Whether it produces a verdict.
Generic table extraction does not attempt this, and that is not a criticism of any particular tool. It is a description of the category: software that finds a grid on a page and writes out cells has no opening balance to start from and no closing balance to check against, so completeness is not a question it is built to answer. Running balance verification on every statement, row by row against the statement's own figures, is the difference between a file you can file and a file you have to audit. Where a statement genuinely has no running balance column, ask what the converter checks instead, because something has to stand in: a stated transaction count, a section total, or a period total you can compare against.
See the verdict, not just the rows
Can it read the documents you actually receive
The statements that consume your time are never the clean ones. Judge a converter on the difficult half of your folder.
- Scanned and photographed pages. A statement that has been printed and rescanned, faxed, or captured on a phone holds an image, not text, so anything relying on a text layer finds nothing at all. How often these turn up depends on your clients and your period, but older records and closed accounts are where they concentrate, and they are exactly the documents you cannot go back to the bank for. Knowing whether a statement is scanned or text based tells you which half of the problem you are buying for, and a converter that handles only one half will send you back to manual entry for the slower half.
- Multi page tables with repeating headers. Real statements run to many pages, and each page reprints the column headers, often with an account summary block and a carried forward balance line. A converter that treats each page independently delivers those repeated headers as transaction rows. On a twelve page statement that is a junk line or several per page to find and remove, and they are the rows most likely to survive a visual check because they look like part of the document.
- Wrapped description lines. A payee that runs past the column width prints on a second line. Weak extraction emits it as an extra row carrying description text and an empty date, amount and balance. Nothing about that row is obviously wrong until the reconciliation fails, and rejoining them by hand is slow because there is no visual rule that distinguishes a continuation from a genuine transaction.
- Debit and credit column pairs. Many statements print debits and credits in separate columns, using parentheses, or CR and DR suffixes, rather than signed numbers. The converter has to resolve that into a consistent sign convention. If it does not, the totals are wrong in a way that looks entirely plausible. Resolving amounts that land as text with brackets or CR and DR suffixes is work the output should have done for you.
There is a related question worth asking early: how much configuring is expected of you. If each bank requires a template, column mapping, or a saved layout, then every new client is setup work, and every statement redesign by that bank is the setup work again. Layout detection that identifies the issuing bank and its column structure automatically is what makes the second statement as fast as the first.
Does it tell you when it is uncertain
A converter that never reports a problem might be accurate, or it might not be checking. From the outside those look identical, because both produce a file that appears finished. The difference is auditability, and auditability is what you need when someone asks how you know.
The useful behaviour is flagging: a row the engine could not read confidently is marked for review rather than filled in with a guess. This matters most on scans, where optical character recognition can misread a printed digit and a 3 becomes an 8. That error does not look like an error. It looks like a transaction for eighty pounds instead of thirty. You could still catch it by reading the row against the original page, and on a handful of statements that is a fine control. At volume the check that actually runs every time is a running balance that stops adding up.
What happens to the file afterwards
The last criterion is not about accuracy. A bank statement carries account numbers and a full transaction history, and you are answerable for it if it belongs to a client. Ask for a stated retention period in hours or days, an explicit position on whether uploads are used to train or improve anything, and a named route for deletion. Vague wording about files being removed regularly is not a policy. The five handling checks worth running on any converter, free or paid come down to questions you should be able to answer in a sentence when a client asks.
How to run the evaluation in one sitting
- 1
Pick a statement you already know
Use a period you have reconciled before, so you know the correct row count and the correct closing balance. - 2
Convert it and check the arithmetic first
Before looking at anything else, run opening balance plus credits minus debits and compare with the printed closing figure. - 3
Count the rows
Compare the number of rows against the number of transactions printed on the statement. A converter that drops a page usually says nothing. - 4
Inspect a wrapped description and a debit
Find a transaction with a long payee and confirm it occupies one row. Confirm a debit carries the correct sign. - 5
Repeat with a scanned statement
Run the same tests on a scan or a photograph. This is where the difference between converters is largest.
The full method for verifying a converted bank statement is worth running on any output, at least until a converter has earned the assumption. What you are really choosing between is tools that hand you rows and tools that hand you rows plus a defensible answer to the only question that matters at the end of a period: is this all of it. A file that cannot answer that is not finished work, it is a draft you have not checked yet.
Frequently asked questions
How do I pick a bank statement converter?
Judge it on whether it checks its own output. The decisive criterion is arithmetic: does the converted file reconcile from the statement's opening balance through every row to its printed closing balance, and does the tool tell you when it does not. Formats and price matter too, particularly if your ledger accepts only one import format, but neither tells you whether the rows are right.
What is the most important feature in a statement converter?
Running balance verification. A converter that checks each row against the one before it, and the whole file against the statement's own opening and closing figures, catches the failure that costs the most: an amount read wrongly or a row dropped, both of which break the arithmetic. It does not verify dates or descriptions, and offsetting errors can slip through, but without it you are trusting an extraction you have no way to audit except by rekeying it.
How do I test a converter before I trust it with client work?
Run one statement you already know the answer for. Compare the row count against the transactions on the page, check the first and last balances, and confirm the sign convention on a debit and a credit. Then run a scanned statement, because that is where most conversions quietly fall apart.
Does it matter whether the converter handles scanned statements?
Yes, unless you are certain every statement you will ever process is text based. Scans and phone photographs turn up regularly from closed accounts, older periods and clients who print and rescan, and those are the documents you cannot go back to the bank for. A converter that cannot read them sends you to manual entry for exactly the ones that take longest.
Should a converter ever refuse to give me a file?
Yes. A converter that flags an uncertain row instead of handing it over silently is doing the more useful thing. Silent output is not evidence of accuracy either way, and a wrong number that looks confident costs more than one you were told to review.