Disclosure: I build StatementXL, a bank statement PDF-to-Excel converter, and this story was written with the assistance of an AI writing program. I reviewed and edited it. The examples are generic and contain no customer data.

A clean spreadsheet is not evidence

PDF was designed to present a document the same way everywhere (that's the job of the ISO 32000 specification). It wasn't designed to carry data. A statement page is mostly characters placed at coordinates, and a "table" is usually just words that happen to line up.

So every converter makes a chain of guesses. Which line is the header? Where does one column end and the next begin? Is this line a new transaction, or the second line of the previous description? Most of the guesses are right and some aren't. The output looks equally tidy either way.

That's the real cost for a bookkeeper. If you can't tell which rows are wrong, you check all of them. The converter has saved you typing, but not review time, and review is the expensive part.

What "wrong" usually looks like

The failures I see fall into a handful of patterns:

• Shifted columns. A deposit lands under "Balance", or a date and an amount end up in one cell.
• Broken descriptions. A wrapped payee name becomes two transactions, or a watermark word ("COPY") gets mixed into the description.
• Missing pieces. A row has an amount but no recognisable date, or a date but no amount.
• Things that aren't transactions. Repeated page headers, page totals and opening-balance lines get treated as real entries.

None of these are exotic. Statements vary by bank, by year and sometimes by branch, and these errors come with that.

Flag the row, not the file

The approach I settled on is to check each extracted row against what its columns claim to contain, and then give it a label:

• Is the value in the date column a real calendar date, or just digits in a date-like shape?
• Is there a description?
• Is there an amount-shaped value in an amount column? If not, is there one sitting in a different column? "Amount found in the wrong column" is a far more useful message than "amount missing".

Each row then gets one of three labels: OK (no issue detected), DISCREPANCY (the evidence conflicts) or UNVERIFIABLE (key evidence is missing). Each row also keeps the page it came from, so the reviewer can go straight to the right place in the PDF.

Data-quality tools work along similar lines. Libraries such as Great Expectations state explicit, checkable expectations about the data instead of giving one overall pass/fail. Showing uncertainty row by row is usually cheaper than chasing a perfect extractor.

Two rules that matter as much as the checks

1. "OK" means "no issue detected", nothing more. A row can have a valid date, a description and an amount and still be the wrong transaction. If the label claimed more than the checks can prove, people would stop looking, and in bookkeeping the mistakes nobody looks for are the expensive ones.
2. Never silently drop a suspicious row. If a line has text and an amount but doesn't fit the table, keep it and flag it. A truncated statement is the worst failure, because nobody goes looking for a transaction they don't know exists.

Scans, AI and where the file goes

Scanned statements are a different problem. There's no text layer, so coordinate-based parsing has nothing to read. The common answer is to send the file to an AI model.

That can work, but it changes the privacy picture, and I think tools should say so plainly. In StatementXL the regular parser runs first for everyone. Only on the Professional and Enterprise plans, and only when regular parsing fails, can an AI fallback be used. In that case the complete PDF goes to a third-party AI parsing provider. The site itself doesn't keep a stored history of PDFs, extracted transactions or spreadsheets, but that promise doesn't cover the AI provider, which has its own processing terms. A bank statement holds names, account numbers and a month of transactions, so users deserve to know exactly when it leaves the system.

If you're building or choosing a converter

• Measure review time, not extraction rate. A table that is almost entirely right but hides its errors can cost more than a less accurate one that flags them.
• Keep the source location on every row. A page reference is cheap and saves the reviewer real minutes.
• Prefer specific errors. "Amount in the wrong column" tells you what to do. "Low confidence" doesn't.
• Be precise about privacy. "We don't store your files" and "a third party may process your file" can both be true. Say both.

Further reading

• pdfplumber, the open-source library I use for word-level PDF extraction.
• The StatementXL source code on GitHub (MIT licensed).

If you'd like to see the row labels on one of your own statements, StatementXL has a small free daily quota. I'm especially interested in statement layouts that break it.

This post walks through the coordinate-based fallback I use in a bank statement → Excel converter, and the checks that decide when to use it.

When to fall back

I always try border/line-based detection first, because when it works it's precise. But I don't trust its output blindly. The trigger for the coordinate fallback is a simple sanity check on the result: if the header claims separate date and amount columns, but the detected cells show dates and currency values collapsed together, the table is rejected and rebuilt.

That one check catches most of the "it parsed, but it's wrong" cases.

Step 1: words → lines

Using pdfplumber's word extraction, each word comes with x0, x1, top and bottom. Words whose vertical positions are close enough are grouped into one visual line, then sorted left to right.

Before this, watermark glyphs are removed. Diagonal "COPY"-style stamps are often real text and would otherwise land in the middle of a line. They're detected by character style, relative size, rotation and page coverage rather than by matching specific strings.

Step 2: find the header line

A header candidate is a line whose words score well against known header vocabulary — date, description/details/memo, debit/credit/amount, balance — in several languages (the current list includes English, German and Chinese terms). The best-scoring line becomes the header; lines above it (account details, addresses, statement period) are skipped until data starts.

Step 3: anchors

Each header word (or cluster of nearby header words, e.g. "Transaction" + "Date") becomes a column anchor with a horizontal span. Clustering matters: without it, a two-word header becomes two columns and every row shifts by one.

Step 4: assign words to anchors

For every data line, each word is assigned to the anchor it overlaps most, or the nearest one. Amounts are usually right-aligned under their header, descriptions left-aligned, so "nearest" has to consider the word's span, not just its left edge.

Step 5: clean up the rows

The reconstructed rows still contain noise:

• Repeated header lines on later pages are dropped.
• Page numbers and section-end markers stop or skip parsing.
• Summary and opening-balance rows are excluded from transactions.
• Continuation lines — rows with text only in the description column — are appended to the previous transaction's description.

Every surviving row keeps its source page and row number, so it can be traced back to the PDF.

Step 6: don't hide what didn't fit

Some lines contain text and an amount but don't align with any sensible column assignment. It's tempting to drop them. I keep them and mark them as unverifiable instead, because silently truncating a statement is the worst possible failure for anyone doing bookkeeping.

After reconstruction, every row goes through validation (real calendar date? non-empty description? amount-shaped value in an amount column, or in the wrong column?) and gets one of three labels: OK, DISCREPANCY or UNVERIFIABLE. The person reviewing the spreadsheet only needs to look at the last two.

Trade-offs

• Coordinate reconstruction is more forgiving of borderless layouts but more sensitive to uneven column alignment.
• Header vocabulary is a maintenance cost; new layouts sometimes need new terms.
• None of this works on scans — there are no word coordinates without a text layer.

If you'd like to see the output on a real statement, the converter is live at bankstatementconverter.xyz. I'd love to hear about layouts where this approach falls apart. The code is open source (MIT) on GitHub.