Why PDF Tables Convert Incorrectly to Excel

PDFs store layout, not semantic rows

A PDF page is a set of drawing instructions: place this glyph here, draw this line there. A visual table can be four independent text runs. Nothing in the file has to say “row 12, column Price”. Converters infer structure from coordinates. When inference fails, you get shuffled columns, split descriptions or prices attached to the wrong product.

Wrapped text

Long descriptions wrap. The second line may have no code and no price. A naive extractor creates a new product with an empty SKU. Linework can merge a description-only continuation into the row above on the same page, but only after you recognise it. Multi-line packs (“6 x” on one line, “1 L” on the next) cause the same class of error.

Merged visual cells

Designers merge a category title across columns or sit a note under three products. Humans read that as one label. Software sees empty coordinates or a wide text box. Those “cells” do not become Excel merges, and they should not become fake products. Delete them in review.

OCR errors

A scanned table has no text until recognition invents it. Digits and codes are the first casualties. Confidence scores are not accuracy. The OCR converter flags weak words; you still compare with the page.

Multiple columns and repeated headers

A catalogue page with two product grids side by side can interleave left and right items if reading order is visual but extraction is positional. Repeated headers on each page are useful anchors—and also duplicate rows if they are treated as products. Linework can follow matching repeated headers when columns shift, but a second table with different fields on the same page remains hard.

Hidden text order

Some PDFs contain text in a different order from the printed table: accessibility tags missing, columns encoded top-to-bottom then left-to-right, or invisible duplicates. Copy-paste from the PDF viewer already looks wrong in those files. Extraction will too. The page preview is the source of truth.

Product-code formatting

Excel likes to turn 00124 into 124 and E1234 into a number or a scientific value. That is a destination-format problem as much as an extraction problem. Linework writes the product-code column as text. Opening the file in another tool can still coerce types if you copy cells into a general-format column.

Thousands and decimal separators

1.249,00 and 1,249.00 are different numbers depending on locale. If the converter assumes the wrong separator, a wholesale price becomes a fraction, or a pack price becomes a thousand. Set decimal comma or decimal point explicitly, then recheck. Details are in extracting product codes and prices.

Linework does not claim complete extraction. It gives you candidate rows, a preview, and a review gate. For a cleaner starting point see PDF table to Excel and converting a price list.