You select a table in a PDF, copy it, paste into a spreadsheet, and get every value stacked in column A in an order that does not match what you saw.
Nothing went wrong. You asked a format that has no concept of tables to give you one.
What a table in a PDF actually is
A PDF content stream says where to draw each glyph. A table is text placed so that a human reads it as a grid, plus possibly some lines drawn separately. There is no row object, no cell, no column, and no relationship between the number in one place and the header above it.
So extracting a table means inferring the structure: grouping glyphs into text runs, clustering their x-coordinates into likely column boundaries, clustering y-coordinates into rows, and hoping the layout was regular enough for that to work.
This is the same inference problem as converting a PDF back to Word, applied to a grid instead of paragraphs, and it fails in the same situations.
Why it goes wrong
Reading order is drawing order. Glyphs are stored in whatever sequence the producer emitted them, which is often column by column rather than row by row. Copying then yields a column when you wanted a row.
Merged cells break the grid. A heading spanning three columns gives the clustering algorithm a text run whose x-range covers three boundaries at once.
Wrapped text creates phantom rows. A description that runs onto a second line looks like another row to anything counting y-positions.
Right-aligned numbers shift boundaries. A column of figures aligned right has its left edge determined by digit count, so a column boundary computed from x-coordinates moves when one value is longer.
Borderless tables have no hint at all. Where there are no ruling lines, whitespace is the only signal.
The approach that works
1. Find out what you are dealing with. Try to select a sentence. If nothing highlights, it is a scan and there is no text to extract. Run OCR first, at 300 DPI or better, and accept that the accuracy caveats apply to every digit.
2. Extract the text and look at what comes out before doing anything else. The shape of the failure tells you what to fix. Values in reading order with inconsistent separators is recoverable. Values in the wrong order is a reading-order problem and usually needs a different approach.
3. Work one page at a time if the table spans pages. Repeated headers mid-document are a common source of rows that are not data.
4. Normalise the separators. Extracted output is usually space-aligned rather than delimited. Converting runs of whitespace into a single delimiter turns it into something a CSV cleaner or editor can work with.
5. Fix it in a grid, not in text. Once it is roughly tabular, a CSV editor is far faster for the remaining corrections than editing delimiters by hand.
Checking, which is the part that matters
Extraction failures do not announce themselves. A column shifted by one produces a table full of numbers that are individually plausible and collectively wrong, and nothing highlights in red.
Two more things worth checking, both covered in why CSVs break in Excel: identifiers that begin with a zero, and long numbers that a spreadsheet will silently convert to scientific notation and truncate. A table of account numbers extracted correctly can still be destroyed by the program you paste it into.
When to stop
If the document is a bank statement, an invoice or any published report, ask whether the data exists somewhere better. Most institutions offer a CSV export of the same information, and five minutes looking for it beats an hour of extraction and reconciliation.
Extraction is the right tool when the PDF is the only copy, which is common for older archives and for documents you received rather than generated.
Try PDF to Excel first for a digital PDF, fall back to text extraction when the columns come out merged, and use OCR only for scans; then check totals in the CSV editor against the original before trusting a single figure.