The number you need sits in a table, at the intersection of a row and a column. Flatten the PDF to text and that intersection is gone: the label lands in one place, the value in another, and the model is left guessing. Tables are where naive parsing quietly loses the answer.

This article is a bonus in Enterprise Document Intelligence, a series building an enterprise RAG system from four bricks. It consolidates fragments into one coherent treatment of why tables break the pipeline and what to do instead. New to the series? Every article sits on the Towards Data Science author pages of Angela Shi and Kezhan Shi.

The standard RAG pipeline reads a PDF, chunks it into text, embeds the chunks, and retrieves the closest match. The moment the answer lives inside a table cell, the standard pipeline starts hallucinating numbers, and often nobody notices until an auditor opens the source document. A table in a PDF is not a table in the data sense; it is a set of rectangles drawn on a page, with text positioned in cells, often without explicit row or column markers.

The parser has to reconstruct the grid from spatial geometry. When it does not succeed, three things go wrong at once: row and column structure is lost, the header is often only on the first page of a multi-page table, and line-level citation discipline breaks down. The right move is not to handle tables better as text, but to restore them to their native structured form as early as possible and treat them as data.

The same table can live in the pipeline at four different levels of structure, picking the right level being the first design decision before any operation runs.