Multi-Column PDF and Table Extraction Accuracy Across Leading APIs

The accuracy gap between document extraction APIs has less to do with model quality than with a structural mismatch baked into the PDF format itself. PDFs encode text as positioned glyphs on a canvas, with no rows, columns, or cell definitions anywhere in the file. Any tool that reads text before resolving geometry is therefore working with the wrong representation from the start, and the consequences show up predictably in multi-column layouts and complex tables.

The PDF format was designed for print fidelity, not data portability. A table in a PDF is nothing more than characters that happen to be visually aligned. There is no native table object, no encoded notion of row membership or column boundaries. Every extraction approach, regardless of how sophisticated its underlying model, must infer structure from coordinates, spacing, and visual cues that were never formally recorded. This is the foundational gap from which every subsequent failure mode follows.

Multi-column prose compounds the problem. In the raw glyph stream of a two-column page, text from column one and column two interleave directly: the first line of column one is followed in memory by the first line of column two, then the second line of column one, and so on. A tool that reads left-to-right has no spatial awareness, so it merges separate logical streams and paragraphs end up stitching together unrelated sentences.

Four specific failure modes follow directly from this geometry problem, and they map onto the accuracy dimensions examined throughout the rest of this article. If a cell spans multiple columns, any uniform grid assumption breaks and the output comes out misaligned downstream. The stage at which a tool resolves or ignores geometry determines which of these failure modes it inherits.

The three architectural approaches and what each one gets wrong

Rule-based, OCR-based, and layout-detection approaches each resolve or ignore the geometry problem at a different stage, and that stage predicts exactly where the tool will break when it encounters a document outside its comfort zone. Rule-based parsing, represented by tools like Tabula, Camelot, and pdfplumber, operates by reading character coordinates directly from the PDF's content stream and applying heuristics to infer structure. Feed it a merged cell and column boundaries collapse. The shared failure of this family is that none of these tools handle scanned PDFs, and all fail on merged cells or borderless layouts because geometry is inferred heuristically rather than resolved as a first step.

OCR-based extraction takes a different route and a different failure. These tools convert scanned or image-based PDFs to text first, then pass the text to a parsing layer. The problem is that OCR discards spatial relationships as part of its core operation. The geometry problem is not deferred in this architecture. It is deleted, and no amount of downstream parsing can recover what the first processing step threw away.

Layout detection, the third family, inverts the ordering. Row membership, column alignment, and cell adjacency are resolved geometrically before any text is read, which is why layout-first models recover merged cells, multi-line headers, and rotated tables that rule-based extractors miss entirely. Extend, a document processing infrastructure platform, operates on this principle, treating geometric reconstruction as a foundational step, not a post-processing one.

Why standard benchmarks have historically obscured real accuracy differences between tools

Much of the confusion in comparing extraction APIs comes from benchmarks that compress genuinely different tools into a narrow performance band. The result is that poor choices look acceptable and the failure modes that matter most in production remain concealed. Understanding metric choice becomes necessary before trusting any accuracy claim. Two tables with the same content but different HTML encoding can receive very different scores. LLM-based scores span a far wider range, making real distinctions legible where TEDS blurs them into indistinguishability. GriTS improves on TEDS by using grid-based matching, but it relies on greedy alignment rather than optimal matching and does not distinguish horizontal from vertical adjacency. Two cells can be adjacent in the wrong direction and GriTS will not catch it.

Benchmark scope creates a second layer of distortion. Even within English, aggregate scores conceal specific weaknesses: parsers achieving high TEDS scores on OmniDocBench can still fail substantially on complex real-world tables. Metric choice can flip a tool's apparent rank entirely, which is why the benchmarks in the next section matter more than older comparisons drawn from TEDS-based evaluations.

What recent benchmarks actually reveal about how leading APIs perform

When you evaluate against benchmarks that capture real structural complexity and use metrics that correlate with human judgment, the performance gap between architectural approaches becomes large enough to determine whether extracted tables are usable at all. A benchmark of 21 contemporary PDF parsers across 100 synthetic documents containing 451 tables, using LLM-based semantic evaluation, reveals the scale of the disparity. Overall scores range from 2.10 to 9.55 out of 10. The span of LLM-based scores reflects quality differences visible upon manual inspection in a way that TEDS scores do not.

PulseBench-Tab tests 9 commercial and open-source systems against 1,820 human-annotated tables spanning 9 languages and 4 scripts, drawn from 380 real-world source documents including financial filings, government reports, and regulatory disclosures. Per-language breakdowns expose performance differences across Latin, CJK, Arabic, and Cyrillic scripts that aggregate English-only benchmarks cannot surface. The T-LAG scoring captures structural errors, wrong adjacency direction and misaligned spans, that TEDS would absorb into its narrow band. The benchmark's composition is itself significant: nearly half of its tables contain merged or spanning cells, making the modal case in real regulatory and financial documents the very failure mode that rule-based parsers cannot handle.

TableParseMap has 916 real-world tables organized into five challenging scenarios and nine failure types, so it reveals where high aggregate scores hide production failures. Large tables suffer from finite input resolution and visual-token capacity that make single-pass processing difficult. The DEC framework, Decompose, Enhance, Correct, improves TEDS by 5.66 points on large tables by partitioning them along structure-aware boundaries. The failure types described in TableParseMap, omission, misalignment, duplicated output, incorrect merged cells, map directly onto production complaints from real deployments.

The same commitment to diagnostic rigor drives Extend's open-source benchmarks, RealDoc-Bench and LongArray-Extract, which address gaps that academic benchmarks leave open. LongArray-Extract specifically tests array extraction over PDFs with rows numbering in the thousands, directly measuring the large-table failure mode that TableParseMap exposes in frozen parsers. Publicly verifiable benchmarks tested on real-world document variations, rather than curated datasets, expose which APIs handle production complexity. This is the lens needed to distinguish between tools that perform well on clean test sets but fail silently on the layout drift, merged cells, and multi-page spans that appear in actual customer data.

The four accuracy dimensions that separate production-ready extraction from everything else

Across the benchmarks, four structural challenges consistently separate tools that work in production from those that fail silently: merged cell handling, column alignment under layout variation, multi-page span continuity, and borderless table detection. Each one is a direct consequence of whether the tool resolved geometry first. Merged cells and rowspan/colspan handling carry the highest stakes because the failure is semantic, not cosmetic. Layout detection models that encode rowspan and colspan as graph edges, as T-LAG does, can distinguish a spanning cell from adjacent single cells. Parsers that linearize tables into sequences cannot. The fact that nearly half of tables in PulseBench-Tab contain merged or spanning cells confirms that this is the modal case in real-world regulatory and financial documents, not an edge case.

If layout varies, column alignment breaks coordinate-based parsers in predictable ways. In multi-column prose layouts, they merge text from adjacent columns and produce strings that combine content from separate logical streams. Unevenly spaced columns break coordinate clustering because the whitespace threshold that separates one column from another is not fixed. It changes with font size, margins, and content density. Layout-first models treat column separators as bounding regions rather than whitespace thresholds, so they remain stable across layout variation where threshold-based approaches collapse.

Multi-page table continuity is where per-page parsers fail structurally. Most parsers reset structural context at each page boundary, so you get disconnected table fragments rather than a single coherent structure. VLMs preserve grid structure across page boundaries where template-based extractors reset context per page, which is why the multi-page table failure mode is largely absent from layout-first tools.

Borderless table detection tells you which tools fail loudly and which fail silently. Lattice-mode parsers that rely on visible ruling lines produce no output, not wrong output, when a table has no borders. The distinction is between a parser that requires the document to match its assumptions and one that adapts to what the document actually contains.

How architecture differences play out across the API landscape

The tools that perform best on the structural accuracy dimensions are those that resolve geometry as a first-class operation, not as a post-processing step. Open-source coordinate-based libraries remain the right choice for a narrow class of documents. Outside that class, they fail predictably. Scanned documents, merged cells, borderless tables, and multi-page spans are all outside their architecture's reach. pdfplumber offers finer control but requires separate extraction code for each document type, viable for a single known format but not for a production pipeline that ingests varied document sources.

VLM-based open-source tools have moved meaningfully in 2026. Surya and Marker from DataLab hit major milestones in May and July of 2026 respectively: a single 650M-parameter VLM replaces the old multi-model pipeline, with a dedicated TableConverter for clean table output. MinerU2.5-Pro achieves strong aggregate scores on OmniDocBench v1.6 but falls below 80 TEDS on implicit semantic scenarios in TableParseMap, confirming that aggregate scores conceal specific failure modes even in capable tools. Docling, from IBM Research, uses a deep learning layout model built on the RT-DETR architecture and trained on the DocLayNet dataset of 80,863 annotated pages among other proprietary datasets. IBM reports high table extraction accuracy on its published benchmark, confirmed in independent testing as of August 2026.

The same pattern holds among commercial APIs. Tools that score well on LLM-based semantic evaluation do so because they operate layout-first. Mathpix scored 8.53 out of 10 across 451 tables, the top individual API result in that study, while the tools at the bottom of the same ranking, including GROBID at 2.10, rely on older rule-based or sequence-based approaches that linearize table content and discard spatial structure. The ranking is not a contest of model brands. It is a map of architectural choices.

Extend's API takes a system-level approach that reflects a broader architectural insight: the surrounding harness, confidence scoring, schema enforcement, and multi-page context management, determines production accuracy as much as the underlying model does. The platform uses a combination of trained-in-house and frontier models to balance accuracy, latency, and cost for each use case rather than routing all documents through a single general-purpose model. Its open-source benchmarks, RealDoc-Bench and LongArray-Extract, run on real-world documents, not synthetic or pre-cropped ones, validating performance on the logistics, financial services, healthcare, and real estate document types that reach production. LongArray-Extract specifically penalizes silent row dropping, addressing the failure mode most table benchmarks ignore: a parser that extracts 950 of 1,000 rows correctly but silently drops 50 receives an inflated score on cell-level metrics.

Why confidence scoring is an architectural requirement, not a feature add-on

An extraction pipeline is not production-ready for high-stakes document workflows if it achieves high average accuracy but cannot identify which specific fields or cells are unreliable. Silent errors in financial reconciliation or compliance verification are more dangerous than visible failures because they compound before anyone notices them. The failure mode is well-documented. Token-level log-probabilities, verbalized confidence, and multi-sample self-consistency all collapse toward all-positive behavior at practical thresholds: a model that is wrong says it is confident, and there is no signal to trigger review. The result is that teams cannot distinguish between extractions they should trust and extractions they should not, which defeats the purpose of measuring accuracy in the first place.

Field-level confidence scores are what make escalation-based workflows practical. With escalation models, AI handles the majority of work autonomously and humans review only flagged exceptions, so productivity gains are substantially higher than with approval models where humans review every output. Without per-field confidence, the escalation threshold cannot be set reliably. The confidence score is the mechanism that makes the threshold possible.

General-purpose frontier LLMs lack per-field confidence scores, source citations, schema versioning, and evaluation frameworks. Extend's platform treats confidence scoring and built-in evaluations as core infrastructure. Any API evaluation should include a confidence scoring test alongside accuracy on benchmark datasets, because accuracy without discrimination is not reliability.

What to look for when evaluating a table extraction API against your actual documents

Because extraction accuracy is determined by architecture rather than by which model is advertised on a feature page, evaluating APIs on your own documents against the four structural failure modes is the only reliable way to predict production performance. Start with document class, not tool reputation. Most benchmarks have measured primarily English documents, so multilingual performance requires specific evidence, such as PulseBench-Tab's per-language breakdowns across 9 languages and 4 scripts.

Test on your own documents, not on the vendor's benchmark documents. Aggregate benchmark scores conceal substantial weaknesses on specific failure types: a tool that scores well on a curated benchmark may fail on the large tables, borderless layouts, or implicit semantic structures common in your document corpus. Measure silent failure, rows dropped, cells silently merged, multi-page tables split into disconnected fragments, not just accuracy on the cells that were extracted. Require confidence scoring as a first-class evaluation criterion. If the distribution of confidence scores is narrow and high regardless of output quality, the scoring is not calibrated.

Evaluate the system, not just the model. Deployment options, cloud API, self-hosted, and BYOC, and compliance certifications such as SOC 2, HIPAA, and GDPR are part of the production architecture evaluation for regulated industries, not separate considerations. Any API that meets those criteria on your actual documents is a candidate. Any that cannot is not.