Why the numbers in your converted PDF table land in the wrong column
Almost every PDF converter gets bank statements and invoices subtly wrong in the same way, and the reason is that a PDF has no columns in it at all.
Last checked 2026-09-21.
A PDF does not contain a table
This is the root of it. When you look at a PDF of an invoice you see a grid, but the file contains nothing of the kind. It holds a list of pieces of text, each with a position on the page: put "Rent payment" at this coordinate, put "1,200.00" at that one. There are no rows, no columns, and no cells. The grid exists only in your head.
So every converter has to guess the table back. It looks at where the text sits and works out which pieces belong together. When the guess is good you get a spreadsheet. When it is not, you get something that looks almost right, which is worse than something that looks wrong.
The guess that breaks on money
The obvious way to find columns is to look at where each piece of text starts, and cluster the ones that start in the same place. That works perfectly on a column of names or dates, because those are left-aligned: every entry begins at the same spot.
Money is never left-aligned. Amounts are right-aligned so the decimal points stack up, which means each one starts somewhere different depending on how many digits it has. In a statement running from $4.50 to $12,500.00 the starting positions are spread across half an inch.
Cluster those starting positions and the amount column splits in two. Small amounts go in one, large amounts in the other, and every row has a gap where the other column should be. The total at the bottom of your spreadsheet is then wrong, or there is no total at all because the numbers are not in one column to add.
How to spot it in ten seconds
Before you trust a converted statement, do this:
- Select the amount column and look at the sum your spreadsheet shows in the status bar. If it is obviously too small, some amounts are somewhere else.
- Look for a column that is mostly empty. That is the giveaway: a real column has a value in nearly every row.
- Count the columns against the original PDF. One extra column is the classic symptom.
This is worth doing whatever tool you used, including ours. A converter that produces a file always looks like it worked.
What actually fixes it
Find the columns by the gaps instead of the text. Between one column and the next there is a vertical corridor of blank page, and that corridor is in the same place on every row no matter how the text inside is aligned. Mark the horizontal range each row's text occupies, add all the rows together, and the stretches no row touches are the column boundaries.
That approach does not care whether a column is left, right, or center aligned, because it never looks at the text at all. It looks at the space around it.
Two things it still has to handle. A single long description can reach across a gap and close it, so a corridor has to survive a few intrusions rather than disappearing at the first one. And a heading wider than its column leaves gaps of its own on every row below, so a column nothing else lines up with gets folded back into its neighbor rather than becoming a column of its own.
This is what our PDF to Excel tool does. We mention it because we got the first version wrong in exactly the way described above, and fixing it is most of why this page exists.
When no tool will get it right
Some tables cannot be recovered by any converter, and it is worth knowing which so you do not waste an afternoon:
- Merged cells. A cell spanning two columns has no unambiguous home. Expect to fix these by hand whatever you use.
- Tables with no consistent gutter, where columns are separated by a hair of white space or by ruling lines with text touching them.
- Multi-line cells, where one logical row wraps onto two or three printed lines. Most converters, ours included, treat each printed line as a row.
- Tables printed across two pages with the header repeated. You will be stitching those together yourself.
If your document is one of these, the fastest route is often to convert it anyway, then fix the handful of broken rows in the spreadsheet. That is usually less work than fighting the tool.
Questions people ask
Why does my converted statement have an empty column?
Almost certainly the amount column has been split in two. The converter clustered the starting positions of right-aligned numbers, and short amounts start in a different place from long ones. Check the sum against the original before you use the file.
Does this affect CSV as well as Excel?
Yes. The problem happens when the table is reconstructed, which is before any file is written. The same wrong grid goes into whichever format you pick.
Is a scanned PDF worse for this?
The column problem is the same, because OCR also gives you positioned text and nothing else. A scan adds a separate risk on top: characters read wrongly. Check figures you rely on.
Try it
It runs in your browser, so the statement never leaves your computer.