# Test the table that continues on the next page

Multi-page tables expose mistakes that ordinary paragraph tests miss. Check the relationship between a value, its column heading and the note that qualifies it.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Build a document with a deliberate boundary

Create a small test report with a table starting near the bottom of one page and continuing on the next. Put the units in the table heading and a qualifying note below the continuation. Use invented operational figures so the fixture can be shared safely with the engineering team.

For example, the first page can state that quantities are measured in hundreds, while a row on the second page contains the value 8. The correct interpretation is 800 units. A separate note can say that the figure excludes returned items. The question should require both the unit and the exclusion.

Retain the original file and a written expected interpretation. If the source is later regenerated by a different document tool, compare the layout before assuming the fixture still tests the same boundary.

## Inspect extraction before asking the model

Run the parser and examine how it represents the two parts of the table. Check row and column relationships, repeated headings and the note. A parser may correctly read every character while assigning a value to the wrong column or treating the second page as a separate unrelated table.

Look for page headers and footers inserted into the table text. A repeated report title between rows can confuse later splitting. Also inspect reading order when the source contains two columns of prose beside the table.

If extraction is already wrong, fix or contain that problem first. A prompt that tells the model to be careful with tables is not a dependable repair for a missing relationship in the data.

## Retrieve the continuation in isolation

Ask a question that is likely to select a row from the second page. Record the exact passages supplied to the answer service. Determine whether the table title, unit, relevant column labels and qualifying note are present in a form the model can use.

Then ask a question about a row on the first page and compare the result. This exposes a design that works only because the first chunk happens to include the table header. Test a query that asks for a comparison between rows on different pages as well.

Do not judge the test only by whether the source citation points to the correct report. A report-level link can look credible while the selected passage still lacks the information needed for the answer.

## Test the correction against another table shape

A repair might repeat column headings on each emitted row or join a detected continuation before splitting. Whichever approach is chosen, test a second document with a different shape. Include a genuine new table on the next page so the repair does not join unrelated data merely because it is adjacent.

Check the amount of repeated context. Adding an entire preceding page to every row may solve the fixture but create unnecessary cost and unrelated evidence. Retain only the context the row needs, and use source relationships rather than page proximity where possible.

Keep the original failing passage and the corrected one with the regression test. They explain the reason for the rule and make future parser updates easier to review.

## Sources

- [Microsoft Learn: table and layout extraction](https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/layout?view=doc-intel-4.0.0)
- [Microsoft Learn: document chunking considerations](https://learn.microsoft.com/en-us/azure/search/vector-search-how-to-chunk-documents)