Why merged cells break retrieval, and what to do about it

The failure looks like this.

A supplier quality report has a table. The header row has one cell reading FY2025 spanning four columns, and beneath it four cells reading Q1, Q2, Q3, Q4. Then a second header block for FY2026, same shape. Down the left, a merged cell reading Tier 1 suppliers spanning six rows, then Tier 2 suppliers spanning nine.

Somebody asks what the Tier 1 defect rate was in Q3 2025. The system answers 4.2 percent, cites the page, and it is wrong. The real figure is 2.8. The 4.2 belongs to Tier 2, or to Q3 of the following year, depending on which way the flattening went.

Nothing errored. The document was found, the table was found, a number was returned with a citation. It is simply the wrong number, and the only person who could catch it is someone who already knew the answer.

Why flattening destroys meaning

Most document pipelines convert a page to text early, because almost everything downstream is easier on a string. For prose that is fine. For a table it discards the thing that makes a table a table.

A cell’s meaning is entirely positional. 2.8 means nothing. 2.8 at the intersection of the row labelled Tier 1 suppliers and the column labelled Q3 under the span labelled FY2025 means a specific thing. Flatten it and you get a sequence of numbers whose row and column context has to be reconstructed by inference — and inference works most of the time, which is precisely what makes it dangerous.

Merged cells are where it breaks first, because a merged cell is a claim about a range. FY2025 does not label the column it sits in. It labels four columns. Serialise the header row naively and you get FY2025, , , , FY2026, , , , and the association is gone. A model reading that will guess, and it will guess confidently.

Three more shapes fail the same way:

Stacked headers. Two or three header rows that must be read as a composite. Region / Channel / Net is one column identity spread over three rows. Flattened, it becomes three unrelated tokens.

Row-span labels. A category label that governs the next nine rows. Once flattened, rows two through nine have no category at all, and the nearest preceding text is whatever happened to be on the line above.

Tables split across a page break. The header is on page 7 and half the rows are on page 8. If those become separate chunks, the page 8 rows are a grid of numbers with no column meaning whatsoever.

Silent failure is the actual problem

It is worth being precise about why this class of bug matters more than its frequency suggests.

A retrieval miss is loud. The system says it cannot find anything, the person goes and looks, and the cost is a few minutes of annoyance. A parsing failure is quiet. The system produces a plausible number with a real citation attached, and the citation even points at the right page — it is only the cell that is wrong. Every quality signal a reader uses to decide whether to trust an answer is intact.

This is the mechanism behind the pattern we hear about constantly: an analyst who has been told the AI is reliable checks it by hand three times, finds a discrepancy once, and stops using it. They were right to stop. One silent wrong number costs more trust than fifty correct ones build.

What preserving structure requires

The fix is not a better model. It is refusing to throw the structure away in the first place.

Reconstruct the grid, with spans. A table should be stored as a grid where each cell knows its row range and column range. A header cell spanning four columns is stored as spanning four columns, not as one cell followed by three empty ones. Every data cell can then resolve its full header path — Tier 1 suppliers → FY2025 → Q3 — without any inference.

Keep the three chunk types distinct. Text, table and figure are different objects with different retrieval behaviour. A table should never be retrieved as a paragraph that happens to contain digits.

Record where every piece came from. Each cell carries the region of the page it was read from. This is what turns a citation from a claim into something checkable: an answer that cites page 12 can outline the exact block, and a person can confirm it in two seconds rather than reading the page.

Stitch tables across page breaks at parse time, using the repeated header or the column geometry, so the rows on page 8 keep the meaning they had on page 7.

Handle the scan case honestly. A mixed-layout scan — half spreadsheet, half photocopied form, at an angle — is where naive pipelines fail hardest. The right behaviour when structure genuinely cannot be recovered is to say so and mark the region low-confidence, not to emit a best guess with the same confidence as a clean parse.

How to test whether your pipeline does this

You do not need a benchmark. Take four documents from your own estate — the worst ones, the ones people complain about — and check three things:

1. Ask a question whose answer sits under a merged header two levels deep. Verify the cell, not the page.
2. Ask a question about a row in the second half of a table that spans a page break.
3. Ask something whose answer is genuinely not in the documents, and see whether the system says so or manufactures something.

The third is the one that predicts everything else. A pipeline that will not admit an absence is a pipeline that is guessing when it does not have to, and it is guessing on the merged cells too.

Getting this right is unglamorous work — it is closer to computational geometry than to machine learning, and it never demos as well as a chart appearing out of a sentence. It is also the floor. Everything built on top of retrieval inherits whatever the parser got wrong, and no amount of reasoning above it can recover a number that was attached to the wrong quarter three steps earlier.