Get a PDF table into Excel without losing the numbers

Financial data has a habit of arriving as a PDF. Bank statements, supplier invoices, exported reports, regulatory filings — all of them present tidy tables that refuse to become a spreadsheet without a fight. Understanding why makes the fight much shorter.

A PDF has no idea it contains a table

In a spreadsheet, a cell is a real object with an address, a value, and a type. In a PDF there is no such thing. The page is a list of drawing instructions: place this glyph at this coordinate, using this font, at this size. Repeat a few thousand times.

What you perceive as a table is a visual pattern produced by alignment. The numbers line up because the generator placed them at the same x-coordinate, not because anything in the file declares a column. There may also be line-drawing operations that produce rules and borders — helpful clues, but not structure.

Extraction therefore means reconstruction. A converter groups glyphs into words, words into lines, and lines into rows; it clusters x-coordinates into candidate column boundaries; it uses ruling lines where they exist to confirm those boundaries; and it decides which rows are headers, which are data, and which are subtotals. Every one of those steps is a heuristic.

The PDF to Excel tool shows you the grid it detected before it exports anything, which turns the risky part of the process — silent misalignment — into something you can see and correct.

First check: is it text, or a picture of text?

This determines everything that follows, and it takes five seconds. Open the PDF and try to select a number in the table with your cursor.

• The selection highlights individual characters. The table is native text. Extraction can work directly from the glyph coordinates, which is the accurate path.
• The selection highlights a whole rectangle, or nothing. The page is an image. There are no glyphs to extract, and any converter that appears to produce numbers has recognised them from pixels.

For the second case, run optical character recognition first to add a text layer, then extract from that. Be correspondingly more careful with the result: recognition introduces digit confusions that arithmetic checks are very good at catching, and eyeballing is very bad at catching. The OCR guide covers the scan quality work that makes the difference here.

Where extraction usually goes wrong

Certain table designs defeat coordinate clustering. Recognise them and you will know where to look during review:

• Merged and spanning cells. A header spanning three columns has one x-position where the algorithm expects three, so alignment can shift for the whole block underneath.
• Wrapped text in a cell. A long description that wraps onto two visual lines looks like two data rows unless the row grouping is smart about it.
• Borderless layouts. Without ruling lines, only whitespace separates columns, and a wide value can appear to bridge two of them.
• Right-aligned numbers with mixed widths. A column of figures where some entries have thousands separators and some do not can cluster into two columns.
• Repeated headers across page breaks. Useful on paper, duplicate junk rows in a spreadsheet.
• Footnote markers attached to figures. A superscript dagger next to a total turns a number into text and breaks every formula referencing it.

Validate with arithmetic, not with a glance

Reading the exported sheet and thinking "looks right" is the failure mode. The numbers are aligned in a grid either way. Use checks that fail loudly instead:

1. Re-add every column total in the spreadsheet and compare it against the total printed in the PDF. This single check catches missing rows, duplicated rows, and misplaced decimals at once.
2. Count the rows. If the PDF shows 87 transactions and the sheet has 84, you have lost three, most likely at a page boundary.
3. Check the type of every numeric column. Values that arrive as text will sum to zero and sort alphabetically, which is a very quiet way to be wrong.
4. Spot-check the extremes. The largest and smallest values in each column are where formatting oddities concentrate.
5. Inspect negatives. Parentheses-style negatives, (1,234.00), frequently survive as text rather than becoming -1234.

For a second opinion on a suspicious block, run the text extraction tool over the same pages and read the raw text. Seeing the sequence of values without the grid makes it obvious when a value has landed in the wrong column.

When to stop converting and change the source

If you are extracting the same report every month, the conversion is a symptom. Nearly every system that produces a PDF report can also produce CSV, XLSX, or an API response, and the person who owns that system is usually happy to switch a setting. Ten minutes of asking replaces an indefinite stream of extraction and verification work.

Conversion is the right tool when the PDF is genuinely the only artefact that exists: a scanned historical record, a document from a counterparty, a regulatory filing. In those cases, do it locally, review the detected grid before export, and let arithmetic — not appearance — tell you whether it worked.