Extraction Accuracy Benchmark — How to Measure It Properly

This piece is about method, not marketing. We're not going to quote you a headline percentage, because a percentage without a defined statement set, a defined error rule and a date means nothing — and we'd rather show you how to judge any converter, including ours, than ask you to take a number on faith.

What "accuracy" actually means

People say "how accurate is it?" as if accuracy were one quantity. It isn't. For bank-statement conversion there are three honest levels, and they answer different questions.

Field-level accuracy asks: of all the individual cells — each date, each description, each amount — how many came across correctly? This is the most granular measure and the most flattering. A statement can score very high at the field level and still be unusable, because the errors that matter aren't evenly distributed. One wrong digit in an amount column outweighs a hundred correct dates.

Transaction-level accuracy asks: how many whole transactions are correct in every field? A transaction with the right date, right description and a misread amount counts as a failure here, not a partial pass. This is closer to what a bookkeeper cares about, because a transaction is the unit you actually post.

Balance-reconciliation accuracy asks one yes/no question per statement: does the extracted data reconcile? Opening balance, plus the sum of every credit and debit, should land exactly on the closing balance. This is the level that catches the failures the other two can miss — specifically, a transaction that was dropped entirely. A missing row leaves no wrong cell to count; the spreadsheet just has fewer lines than the PDF, and only the maths reveals it.

A benchmark worth the name reports all three. Field accuracy shows the converter's raw reading quality. Transaction accuracy shows usable output. Reconciliation shows completeness — the thing most users assume and almost nobody verifies.

Reconciliation as the ground truth

Here's the wedge, and it's a genuine one. Most accuracy claims need a human-checked "correct answer" to score against — somebody has to type out the true statement by hand so the tool's output can be compared to it. That's slow, it's subjective at the edges, and it doesn't scale past a handful of files.

The running balance gives you an objective answer key that ships inside every statement. Banks print a balance after each transaction, or at least an opening and closing figure. That sequence is the bank's own arithmetic. If you extract the transactions and the maths doesn't close, you have proof — not a guess — that the extraction is incomplete or wrong, without anyone hand-keying a reference copy.

Export Bank Statement runs this check on every conversion. It rebuilds the running balance from the extracted lines and compares it against the figures on the statement. When they agree, every transaction is accounted for. When they don't, the statement is flagged so you can look before you trust it. That's the difference between "the file looks fine" and "the file is provably complete."

Two honest caveats, because the method has limits and pretending otherwise would undercut the point:

• Reconciliation proves completeness and amount integrity. It does not prove every description is perfect — a merchant name read as "AMZN Mktp" instead of "Amazon" still reconciles, because the maths only sees amounts. Description quality needs its own check.
• Two errors can cancel. A transaction read 10 too high and another read 10 too low will still balance. It's rare, and rarer still on a long statement, but a benchmark should acknowledge it rather than claim reconciliation is infallible.

So reconciliation isn't the whole story. It's the strongest single objective signal, and it's the one that catches the most dangerous error — silent data loss.

How to design a fair benchmark

If you're testing converters yourself, or reading someone else's benchmark, these are the things that separate a real measurement from a marketing figure.

Notice what's not on that list: a single number to memorise. A figure like "98%" is meaningless until you know 98% of *what*, measured *how*, on *which* statements, *when*. The honest output of a benchmark is a small table, not a billboard stat.

What actually affects accuracy

Accuracy isn't a fixed property of a converter. It's a property of the converter *and* the statement you feed it. The same tool will read one statement perfectly and stumble on the next. These are the factors that move the needle, in rough order of impact.

Text PDF versus scanned image. A text-based PDF carries the characters as data — the converter reads them directly, and accuracy is usually high. A scanned or photographed statement is a picture; it has to go through OCR, which infers characters from pixels. Anything that degrades the image — skew, shadow, low resolution, a phone photo at an angle — degrades the read. This single distinction explains most of the gap between "flawless" and "needs checking", which is exactly why a benchmark must report the two separately.

Layout complexity. Some banks print clean, well-separated columns. Others merge debit and credit into one column with a sign, wrap long descriptions onto a second line, or print the date only on the first transaction of each day. Each quirk is a chance for the parser to misalign a row. We've covered the specific patterns in common extraction errors across banks — the short version is that the bank's format predicts the error far better than the converter does.

Multi-page statements. Long statements repeat headers and footers, sometimes carry a subtotal across the page break, and occasionally split a single transaction across two pages. Page boundaries are where rows get dropped or duplicated. This is also where reconciliation earns its keep: a transaction lost at a page break won't show up as a wrong cell, but it will break the closing balance every time.

Number formatting. Decimal commas versus decimal points, thousands separators, currency symbols inside the cell, trailing "CR"/"DR" markers — any of these can be misparsed, turning 1,234.56 into 1.23 or flipping a sign. These show up as amount errors, and they're the ones the reconciliation check is built to catch.

For a deeper look at the failure modes themselves, see common PDF extraction errors.

Where the product fits — and where it stops

Export Bank Statement converts bank-statement PDFs to clean Excel and CSV, reads scanned statements via OCR, and runs the running-balance reconciliation on every file so you know whether the output is complete. It also exports in the native bank-import CSV format for Xero, QuickBooks and Zoho Books.

The honest boundary: it does not push transactions into your accounting software through a live bank-feed API — that route needs partner certification we don't claim. The workflow is convert, check it reconciles, then import the CSV. You stay in control of what lands in your ledger, and you import data you've already seen verified rather than trusting an opaque sync.

CTA: Test it on your own toughest statement — convert a bank statement and watch it reconcile. The reconciliation result tells you, per file, whether anything went missing.