Multi-Page Table Extraction: JSON, HTML, and Validation

The short answer

Extracting a multi-page table means recovering one logical dataset from several page layouts. Recognizing the cells is only part of the job: the result must retain the right headers, distinguish detail rows from subtotals, and avoid joining unrelated tables.

Use layout-aware parsing to recover the table, decide whether adjacent sections belong together, and validate the result before exporting or aggregating it. A successful request or valid JSON response does not establish that every row is present or correctly associated.

This guide focuses on those implementation decisions. For vendor selection, see Best Table Extraction Software for Complex PDFs.

Choose the output your application needs

Reducto Parse returns structured document content, including tables and positioned blocks. That is different from an application-specific record with named business fields.

Reducto’s table output options include HTML with merged-cell spans, Markdown, JSON row arrays, and CSV. Its JSON table format contains string values; it is not a typed business schema. Markdown and the simple JSON table format flatten merged cells.

Keep a structural representation while resolving multi-level headers. Export a rectangular dataset only after deciding which header, unit, and period apply to each column. Otherwise, a clean-looking CSV can conceal a wrong association.

If you need named fields or repeating records, use Extract with a schema. Define whether you want detail rows, summary rows, or both. The schema-based extraction guide covers that design.

Decide whether the next table is a continuation

Do not merge simply because two tables are adjacent. Check their headings, entity, reporting period, units, and column meanings.

The decision is especially important in statements and reports that reuse one layout for different accounts or sections. Equal column counts do not mean equal semantics.

Reducto documents merge_tables for consecutive tables with identical column counts. It uses semantic analysis to identify continuations and removes repeated headers. The documentation warns that unrelated structures can be merged incorrectly. Treat it as a processing option, not an acceptance check. See the table configuration documentation.

Merging table blocks also should not be assumed to repair every record split across pages. Inspect the final row associations, especially where a description wraps or numeric cells appear on a different page from their labels.

Validate the dataset before using it

Check coverage and row identity

Account for all relevant table pages. If the document states a record count, compare it with the extracted detail rows after excluding headers and summaries. If no count exists, do not invent one; reconcile the page-level source against the resulting dataset.

Look closely at the first and last records around each boundary. Check for missing rows, duplicated continuation fragments, and rows placed under the wrong header.

Use identifiers when they exist, but do not delete rows merely because their values match. Repeated transactions or positions can be legitimate. Duplicate handling needs document context and an explicit rule.

Separate detail rows from summaries

Mark subtotals, carried-forward balances, and grand totals separately from detail records. Otherwise, an aggregation can count the same amount twice.

Reconcile arithmetic in application code using the document’s stated scope. Account for currencies, units, tax, discounts, sign conventions, and rounding where relevant. A mismatch should produce a reviewable exception, not a silently adjusted extracted value.

A matching total is helpful but insufficient: missing and duplicated values can offset one another.

Preserve ambiguity instead of guessing

A blank, a dash, an unreadable value, and zero are not automatically equivalent. Define their treatment for the document type and preserve the source representation when normalizing them.

Keep reported values separate from calculated values. Do not fill a missing amount solely to make a reconciliation pass. Similarly, preserve an identifier’s leading zeros when they are meaningful rather than treating every numeric-looking cell as a number.

Preserve evidence through normalization

Keep a connection between each normalized record and the source material used to create it. Store document identity, available page references, and the original representation alongside any transformations your application applies.

Reducto’s optional Extract citations provide source text and locations for extracted values. A citation array can be empty, so review logic must handle missing evidence. Confidence helps prioritize inspection; it does not prove that a value belongs to the intended row or period.

Page markers identify boundaries, not exact cell evidence. For cell coordinates, Reducto documents jsonbbox for legacy Parse; it is not currently supported by r-1 and disables legacy agentic table enhancement. Check compatibility before choosing it. These details are covered in the table output documentation.

When your application joins fragments or changes column names, retain that transformation history. A reviewer should be able to understand both what the source said and how it became the stored record.

Debug missing rows at the right stage

First compare the source with Parse output. If a table or value is missing there, investigate parsing before adjusting the extraction schema. If the parsed content is present but the extracted records are incomplete, inspect field descriptions, array requirements, and the treatment of summaries.

Deep Extract iteratively checks and refines extraction, and its documented use cases include long multi-page tables. It is an option to evaluate for difficult extractions, not a replacement for independent row and arithmetic checks.

Keep processing success separate from validation status. A completed job can still need review before its records are used downstream.

Frequently asked questions

Is JSON better than HTML for multi-page tables?

They serve different needs. Choose a representation that preserves the relationships you still need to interpret, then normalize to the application’s schema. Choosing JSON alone does not solve continuation, row completeness, or validation.

Should I always enable table merging?

No. Use it when adjacent tables are likely continuations, and check the result. Keep tables separate when their entity, period, units, or column meanings differ, even if their layouts look alike.

Can I export straight to CSV?

For simple rectangular tables, that may be appropriate. For multi-level headers or page-spanning records, resolve the structure and run validation first. Retain source evidence outside the CSV if the export cannot carry everything needed for review.