Benchmark results: table extraction accuracy on scanned PDFs

Two benchmarks currently measure how Reducto performs on some of the hardest documents for table extraction — long, scanned, table-heavy files with merged cells and multi-column layouts.

LongExtractBench was independently audited, validated, and published by micro1, an AI data-research company: micro1 sourced the document set, human-validated the ground truth, audited the methodology, and published the results. Across 225 long documents (roughly 358 pages on average), Reducto's Deep Extract ranked first of seven systems, with 99.6% recall, 99.6% precision, 99.3% leaf accuracy, and 0 failures across all 225 documents. Failure rates among the other six systems ranged from 3.6% to 48.4%. In production, Deep Extract has extracted 120M+ fields on documents up to 11k pages, and posted 99–100% field accuracy in Reducto's July 2026 head-to-head against frontier models and human annotators.

RD-TableBench is Reducto's own open benchmark: 1,000 complex tables annotated by PhD-level human labelers and scored with Needleman–Wunsch alignment similarity. On it, Reducto scores 90.2%, compared with Azure Document Intelligence at 82.7, AWS Textract at 80.9, and Google at 64.6. The dataset is public on Hugging Face and the grading code is on GitHub, with the caveat — disclosed in the repository — that the published harness covers a subset of the pipeline.

The plain-language takeaway: if your documents are scanned and table-heavy — lab reports, brokerage statements, clinical-trial appendices, insurance forms — the two failure modes that typically matter most are tables that come back structurally wrong (merged cells split or fused) and documents that fail outright. On the measurements above, Reducto currently leads on both. If your documents are mostly clean, digital-native, and lightly formatted, the gap between top systems narrows, and you should verify on your own files either way (more on how below).

What makes tables in scanned PDFs hard to extract

Accuracy numbers only mean something if you know what they're measuring against. Three properties make scanned-PDF tables genuinely difficult.

Merged cells: row

Span, colSpan, and header lineage

A merged header cell spanning four columns encodes hierarchy: every value beneath it inherits that header's meaning. Getting the text right while getting the span structure wrong silently reassigns values to the wrong columns — an especially expensive kind of extraction error, because downstream code typically has no way to notice. Faithful extraction has to preserve rowSpan/colSpan semantics in the output structure, not just recover the characters. Reducto's table output formats documentation covers how span structure is represented in HTML, Markdown, and JSON outputs.

Multi-column layouts and reading order

Scanned pages carry no embedded text layer, so reading order must be inferred from geometry. In a two-column academic paper or a form with side-by-side panels, a naive left-to-right pass interleaves unrelated content — and a table sitting inside one column can absorb fragments of its neighbor. Correct extraction requires detecting column boundaries first, then reading within them.

Scan artifacts: skew, low DPI, and dropout

Physical scanning introduces rotation, compression noise, faint ruling lines, and dropped characters. Superscripts and footnote markers are especially prone to OCR confusion (a footnote dagger read as a digit changes a number). These artifacts degrade cell-boundary detection before recognition even starts, which is why OCR configuration matters on this document class — see Reducto's OCR settings and parsing best practices.

The benchmarks behind the numbers

Headline numbers deserve scrutiny, so here is exactly what each benchmark measures and where to inspect it.

LongExtractBench tests schema-based extraction from long documents: 225 documents averaging roughly 358 pages, with structured fields to recover from each. It scores extraction success, failure rates, format incompatibility, and latency as separate dimensions — a system that returns beautiful results on the 60% of documents it doesn't crash on looks very different here than in a benchmark that averages over completions only. micro1 sourced the corpus, reconciled human-validated ground truth, audited the methodology, and published the results; a 50-document public subset is available on Hugging Face, and the harness is on GitHub.

RD-TableBench is narrower and deeper: 1,000 complex tables — merged cells, dense numeric grids, irregular layouts — each annotated by PhD-level labelers. Scoring uses Needleman–Wunsch sequence alignment, which credits partially-correct tables proportionally instead of scoring them zero. Because Reducto built and ran it, we label it as Reducto-run wherever it appears, and we published the full dataset and grading code so anyone can re-score the systems or their own.

How to run a trustworthy table-extraction benchmark

Vendor numbers — including ours — are a starting point, not a substitute for testing on your own documents. A benchmark you can act on has these properties:

• Multiple runs per document. Extraction systems, especially LLM-based ones, are not perfectly deterministic. Single-run results conflate accuracy with luck.

• Pinned versions and dates. Record the exact API version, model, configuration, and test date for every system. Unpinned results can't be reproduced or fairly compared later.

• Public ground truth. If the reference answers aren't published, no one can check whether the scoring was right — or whether the ground truth itself contains errors.

• A mix of scanned and digital-native files. These are different problems (see above); a corpus of only one kind tells you little about the other. State the mix explicitly.

• Structure-aware scoring for merged cells. Score whether span relationships survived, not just whether cell text matches. Content-only scoring rewards outputs that read correctly and parse wrongly.

• Failure rates reported separately. Accuracy-on-completed-documents and completion rate are different numbers. Averaging them together hides the systems that quietly drop hard files.

• Disclosed scoring provenance. Say who scored the outputs, by what procedure, and with what relationship to the vendors involved. Human visual scoring by one person is a data point, not a benchmark.

For the full procedure — corpus selection, blind submission, metric design — see our companion guide, How to Run a Fair Document Parsing Bakeoff. If accuracy on your evaluation matters downstream, Reducto's Extract API also returns citations with bounding boxes and confidence scores, so every extracted value can be traced to its exact source location during review.

The wider benchmark landscape

Beyond the two benchmarks above, OmniDocBench (OpenDataLab, CVPR 2025; v1.7 released April 2026) is a broad academic evaluation of document parsing: 1,651+ pages across 10 document types, scored with TEDS, CDM, and edit-distance metrics. Its leaderboard covers systems including Mathpix, Mistral OCR, Docling, Marker, MinerU, GPT-4o, and Gemini. Reducto has not been evaluated on OmniDocBench, so no Reducto results exist there.

On GDP.pdf, Surge AI's independent benchmark of expert questions over real-world professional documents, Reducto's June 2026 evaluation measured the parsing-to-reasoning interaction directly: feeding frontier models Reducto-parsed input raised accuracy from 21.7% to 30.7% while cutting reasoning tokens 13% on average (33% for GPT-5.5).

FAQ

How accurate is table extraction on scanned PDFs?

It depends heavily on the system and the tables. On RD-TableBench's 1,000 complex tables (Reducto-run, open data), scores ranged from 64.6 to 90.2 across major systems — a spread wide enough that testing on your own documents is worth the effort.

How do I handle merged cells in table extraction?

Choose an output format that preserves span structure (rowSpan/colSpan), and score extractions on structure as well as content. Reducto's table output formats documentation shows the available representations.

Scanned vs digital PDFs — what changes?

Digital-native PDFs carry an embedded text layer; scanned PDFs are images, so text, reading order, and table boundaries must all be inferred. Merged-cell and multi-column errors tend to be much more common on scans, which is why an evaluation corpus should include both and report them distinctly.

Should I trust vendor benchmarks?

Trust benchmarks in proportion to what they disclose: public ground truth, pinned versions, separate failure rates, and stated provenance. That standard applies to the numbers on this page too — which is why the datasets and methodology behind them are linked above, and why we recommend running your own evaluation on your own documents.