Table Extraction From PDFs and Scanned Documents

Table extraction from PDFs is one of those problems that looks trivial from the outside and has no clean solution, because a PDF has no concept of a table. A PDF has no concept of a table. What a person sees as a grid of rows and columns is, to the file format, just text fragments sitting at XY coordinates that happen to line up. Every extraction tool, no matter how advanced, is reconstructing structure that was never actually there. That's the argument this piece makes: this is an engineering problem with a defined failure surface, not a solved problem waiting on the right library call.

The PDF format was built by a major software vendor decades ago to guarantee that a document printed the same way on any machine. It was never meant to carry data back out. So when a table renders cleanly on screen, with visible rows, aligned columns, maybe a header shaded gray, that's an illusion of structure produced entirely by placement. Strip away the rendering, and disconnected strings of text remain, each one tagged with a position on the page and nothing else. No cell boundaries. No row identity. No column type. A parser has to infer all of it from visual clues: lines, spacing, font size, whitespace gaps. Each inference method carries its own blind spot, and that mismatch between how a table looks and how a table is actually stored is the root of nearly every extraction failure covered here.

The first decision every pipeline must make: native PDF vs. scanned document

Before any table logic runs, a pipeline has to answer one question: is this a native PDF, with a real text layer sitting underneath the visual layout, or is it a scanned document, which is really just a photograph of paper wrapped in a PDF container? Native files, the kind exported from a word processor, a spreadsheet program, or an accounting system, carry machine-readable text and coordinates. Scanned files carry pixels. There is no text to read until OCR runs first and guesses at what those pixels say.

Scanned documents are everywhere in back-office work: accounts payable, logistics paperwork, HR intake forms, insurance claims, faxed anything. Two invoices can hold the identical table, but if one was exported from an ERP and the other was scanned off a fax machine, they need entirely different processing paths. Feeding both through the same extraction call causes the scanned one to either fail outright or return garbage, because there's no text layer for a coordinate-based method to grab onto.

This matters more at scale than most teams expect going in. Industry estimates put somewhere between 80 and 90% of enterprise data trapped in unstructured formats like PDFs as of 2017, and finds that by 2022, roughly 70% of organizations were burning more than 20 hours a week on manual PDF data entry, with total losses to businesses estimated around $1.5 trillion a year. Those numbers aren't about extraction accuracy. They're about the cost of getting the file-type routing wrong before extraction even starts. A pipeline that can't tell a native PDF from a scanned one at the door hasn't actually started the job yet. It's a pipeline that hasn't actually started the job yet.

How the four structural extraction approaches work and where each one breaks

Four broad approaches cover almost all table extraction methods in use today, and each one fails in a different, fairly predictable place.

Line-based detection looks for drawn borders on the page and infers cell boundaries from where horizontal and vertical lines cross. It works well on tables with visible grid lines, and it fails completely the moment those lines aren't there. A huge share of real-world tables, especially ones built in Word or dropped into a report template, have no ruled lines at all. Just whitespace doing the job of a border.

Coordinate clustering skips lines and instead groups text fragments by proximity, guessing that text sitting close together belongs to the same cell. That approach handles borderless tables reasonably well until columns are spaced unevenly or text wraps across multiple lines inside one cell. At that point the clustering logic starts merging or splitting cells that shouldn't be merged or split, and the row and column geometry falls apart.

Layout analysis leans on font size, spacing, and the order elements were drawn onto the page, which helps distinguish a table from surrounding prose. It degrades fast on multi-column layouts, where a two-column news-style page interleaves body text with an embedded table and the reading order gets scrambled.

AI and image-based approaches skip text extraction altogether and process the rendered page as an image, using a model trained to recognize table structure the way a person would. This tends to be the most reliable option across the widest range of table styles, but it adds latency, computing cost, and a dependency on an external model or service that a plain Python script doesn't need.

Borderless tables deserve their own mention because they defeat the two cheapest methods outright: line-based detection has nothing to detect, and stream-mode proximity grouping introduces its own misalignment when spacing isn't perfectly consistent. Multi-page tables cause a separate headache: most open-source parsers treat each page independently, so a table that continues across a page break gets chopped into two disconnected fragments, because the PDF format has no signal anywhere that says "this table keeps going." Merged cells and nested headers, common in financial statements and government forms, confuse coordinate-based tools into misordering columns or flattening a merged region into several duplicate cells. And embedded fonts can break things even further upstream: a parser that can't decode a document's font encoding either outputs garbled characters or drops the section silently. One documented case involved an insurance claim form that lost two entire sections purely because of font encoding it couldn't resolve.

The upshot is that no single method wins across every document type. Choosing an extraction approach means matching the method to what the document actually looks like, not picking whichever library appears first in a search result.

The open-source Python library landscape for native PDF table extraction

For native PDFs, a small set of Python libraries covers most production use.

pdfplumber is the most widely used option, with more than 9,500 stars on GitHub. It works by analyzing text positions and line geometry directly, giving developers fine control over how detection thresholds are tuned. It handles borderless tables reasonably well once configured properly, but it has no path at all for scanned PDFs, since there's no text layer for it to read.

Tabula, built on the Java library tabula-java with a Python wrapper (tabula-py), requires a Java runtime to be installed alongside it, which alone rules it out for some deployment environments. It offers two detection modes: lattice, which relies on ruled lines, and stream, which relies on whitespace. It returns results as a list of pandas DataFrames, handles multi-page documents reasonably, but struggles with merged cells and borderless layouts, and offers nothing for scanned input.

Camelot also runs lattice and stream modes and integrates cleanly with pandas, but it needs Ghostscript installed as a dependency. It fails on scanned PDFs the same way as Tabula and can stumble on PDFs with unusual internal encoding.

pypdf, now at version 6.x, deserves a mention mainly as a warning. It's the most-installed PDF library in the Python ecosystem, so it's often the first thing a developer reaches for. It has no built-in table extraction at all. Plenty of projects lose a day discovering that.

Unstract's guide identifies Camelot, Tabula, and pdfplumber as solid choices for digital PDFs, but notes that none of them has meaningfully closed the gap on borderless or scanned content in recent years. And per a G2 review aggregate cited by DigiParser, 55% of finance and HR users report failures with these open-source tools once tables run past five pages. That's a concrete number attached to a real ceiling: these libraries are free, scriptable, and stable in production, but they're built for native PDFs with clean, legible structure. Once a document goes past that, a different layer of tooling has to take over.

AI-augmented and VLM-based extraction tools for complex and scanned documents

The newer generation of tools doesn't try to reconstruct a table from coordinates and lines. It reads the page the way a person does, as an image, and infers structure from what the layout communicates rather than from pixel-precise geometry. LlamaIndex's analysis describes this shift, sometimes labeled Agentic Document Processing, as displacing the older Intelligent Document Processing model by combining multimodal models, layout awareness, and semantic reconstruction into a single step.

Vision-language models show a real advantage on noisy input. On distorted scans and receipts, VLMs post 3 to 4 times lower character error rates than traditional OCR, as the research cited in the brief for this piece shows. Several specialized open models released across 2025 and 2026 push that further. dots.ocr, at a small fraction of the parameter count of its rivals, supports more than 100 languages and outperforms models 20 times its size on the OmniDocBench benchmark. GOT-OCR 2.0, smaller still, runs on a single consumer GPU with roughly 4GB of VRAM and outputs Markdown, LaTeX, and other structured notation directly. DeepSeek-OCR, larger than GOT-OCR 2.0 but still modest in size, uses what its authors call contextual optical compression to cut the number of vision tokens needed by 7 to 20%, and can process more than 200,000 pages a day on a single A100 GPU. PaddleOCR-VL-1.6, released under Apache 2.0 at under a billion parameters and covering more than 100 languages, runs at about 45 pages a minute on an L40S GPU. Granite-Docling, smaller than the other models discussed and also Apache 2.0, runs fast on financial tables specifically. And Surya, paired with the Marker pipeline from DataLab, hit a significant version 2 milestone in May 2026: a rewritten pipeline built on Surya OCR 2, a 20-million-parameter layout model, and a dedicated TableConverter module built specifically for table extraction.

On the managed side, Google Document AI ships pre-trained parsers tuned for invoices, receipts, and bank statements, though its general-purpose processor is noticeably weaker than its specialized ones, and it requires a GCP setup to run. The research behind this piece found pricing across this tier ranges from free, for self-hosted open models, up to around $65 per 1,000 pages for some managed services. Mistral OCR costs around $4 per 1,000 pages, which undercuts Azure's custom tier by as much as 15 times.

None of this makes the older libraries obsolete. For clean, printed native PDFs, the classic Python tools remain faster and cheaper. Nothing in this landscape wins across every document type, and treating a vision-language model as a universal upgrade over pdfplumber misreads what each tool is actually good at.

Where AI-based extraction fails in production: failure modes the demos don't show

Production failure isn't rare or exotic, and it doesn't wait for edge cases. A developer integrating a parsing library into a real client workflow hit three separate failure modes across the first three documents pulled from an actual client folder, according to the research behind this piece: a scanned purchase order where field labels merged directly into their values, an insurance claim form that lost two entire sections due to embedded font issues, and a clean-looking text output riddled with mid-sentence line breaks that broke every downstream regex expecting continuous text.

VLM-based pipelines carry their own documented failure patterns. LlamaParse has traced isolated service disruptions to repetition loops and recitation errors inside VLM-powered parsing, where a model gets stuck reproducing a chunk of text rather than moving forward. Mitigations that have been proposed include watching for specific finish-reason flags, like RECITATION from Gemini or content_filter from OpenAI, and escalating those immediately rather than silently retrying; tightening retry policies so a stuck request doesn't spiral into nested retries; and adjusting sampling temperature dynamically once a recitation pattern gets flagged. A separate and more subtle issue is input quality dependency: a model that performs poorly on a raw, messy document scan can perform far better on the exact same content once it's given a cleaner, more structured representation to work from. Same model, same table, different input quality, different output quality. And VLMs can misread tables, hallucinate content that isn't on the page, or drop information without any warning, which isn't always a flaw in the model itself so much as a symptom of poor input.

The PureDocBench benchmark (2026, arxiv.org/pdf/2605.07492) documents several of these failures directly. In one case, a product's entire header metadata block went missing from the reconstructed output, leaving downstream users with no way to tell which component a datasheet was even describing. In another, tables came through intact but landed in the wrong section order, breaking the logical grouping the original document relied on. Most striking is a case where a technical symbol got silently mutated: an engineering constraint written as $L_{\sigma} \le 15 \text{ nH}$ came out as $L_{\sigma} \le 15 \text{ mH}$, a six-order-of-magnitude unit error, in a safety-critical engineering context. PureDocBench's authors point out that these failures often go unflagged by standard evaluation metrics, because those metrics don't penalize sidebar semantics or block-level completeness, and both examples above came from models ranked at the top of leaderboards at the time.

There's a pattern by document domain. STEM documents tend to fail on notation fidelity, formula formatting, symbol precision. Business documents tend to fail on structural integrity and metadata completeness. The same model can handle one domain well and fail badly on the other. Leaderboard rank on a general benchmark tells you very little about how a model will behave on the specific document type in front of you.

The engineering lesson here concerns failure cost, not failure rate, and the sentences that follow show why. A pipeline that fails loudly, throwing an error, returning obviously garbled text, is cheaper to run in production than one that fails quietly, even if the loud pipeline is technically wrong more often. Garbled output gets caught and flagged. A confidently wrong extraction, one that looks clean and reads fine, doesn't get caught until it's already caused downstream damage. That asymmetry is the real argument for independent evaluation on your own document set, rather than trusting a benchmark leaderboard to predict how a model behaves on your specific paperwork.

What the LIFT approach reveals about repairing extraction errors at the last mile

Microsoft's LIFT approach, short for Last-Mile Fine-Tuning for Table Explicitation, takes a different angle on the same problem: instead of trying to get one model to extract a table perfectly on the first pass, split the job in two. A pre-trained large language model does the first extraction from unstructured text, and a separate, fine-tuned small language model, spanning a wide range of parameter sizes, goes back over that output and repairs the structural errors it finds.

Tested against 2,596 tables pulled from three different datasets, LIFT matches or beats end-to-end fine-tuning of a small model on the TEDS metric (tree-edit-distance-based similarity, a standard way of scoring how close an extracted table's structure is to the ground truth), and it does so with as few as 1,000 training examples. At that 1,000-example mark specifically, LIFT beats end-to-end fine-tuning by up to 0.144 TEDS points, which is a meaningful gap when training data is scarce, as it usually is for any specific document type a team is trying to handle well.

The architectural point matters more than the benchmark number. LIFT works because it separates two different jobs that don't actually benefit from being handled by the same model: extracting structure from noisy, unpredictable input, and repairing structural errors in an already-extracted table. Specialization here isn't a nicety, it makes the system more robust to variation in the input. LIFT was also built around a workflow where the user selects the specific table of interest rather than uploading a full document, which sidesteps having to share or expose the entire file, a design choice with real privacy implications for sensitive paperwork.

For teams building extraction pipelines, the takeaway is straightforward: a repair or validation layer must be built in from the start, not added later if there's time. It turns a capable model into a system that can actually be trusted. LIFT gives that idea a name and a measured number attached to it, which is more than most teams have to point to when they're deciding whether to invest in one.

Measuring extraction accuracy in production: why field-level metrics are the only honest measure

Accuracy numbers get reported at the field level almost universally, and that framing hides how bad things get once a document has more than a handful of fields. With 20 fields on a document and 99% accuracy on each individual field, the odds that the entire document comes out completely correct are roughly 0.99 raised to the 20th power, which works out to about 82%. If per-field accuracy drops to a still-respectable 98%, the odds of a fully correct document fall to around 67%. Field-level accuracy and document-level accuracy diverge fast, and a vendor quoting "99% accurate" without specifying which measure they mean is quoting a number that doesn't describe the thing that actually matters to the person relying on the output.

Real production numbers land lower than demo numbers, as they usually do. Airparser.com's 2026 analysis finds that a well-configured AI parser running against a realistic, mixed batch of production documents achieves somewhere in the 93 to 97% range for field-level accuracy on average, with that range driven heavily by document quality. Clean native PDFs pull the average up, and poor-quality scans pull it right back down, sometimes in the same batch, sometimes on the same day's intake.

A 2026 audit assurance study (arxiv.org/pdf/2605.05252) puts a real number on this kind of confidence gap: across a set of processed statements, the overall average field-level confidence score came out to 0.781, with meaningful variation depending on which specific field was being extracted. That's not a failure of the technology. It's a fair description of where the technology actually sits, and it's exactly why field-level accuracy, broken out and reported honestly, is the only version of this metric worth building a pipeline's error-handling logic around. Document-level accuracy, or any single blended number, hides too much of what's actually going wrong to be useful for anyone trying to decide where a human review step still belongs.