Table extraction

Table extraction is the process of detecting tabular structures in a document and converting them into structured data (rows, columns, and cell values) that a downstream system can query or process. It goes beyond reading text: the system must first recognize that a table exists, then work out which words belong to which row and column, including cases where cells span multiple rows or columns. Good table extraction preserves the logical structure of the data, not just the visible text.

How it works

A table extraction pipeline typically runs in stages. First, a detection step locates table regions on the page, often using layout models trained to spot grid-like structures, borders, or repeated column alignments. Second, a structure-recognition step maps out the grid: it has to infer row and column boundaries even when lines are missing, faint, or inconsistent across pages.

This is where most of the real difficulty sits. Merged cells break the simple grid assumption: a header spanning three columns, or a subtotal row spanning two, forces the model to reason about span rather than just position. Multi-page tables add another layer: a table that starts on page 3 and continues on page 4 needs its rows stitched back together, with headers either repeated or implied. And line items (the individual rows in an invoice or claim, each with a description, quantity, unit price, and total) need to be extracted with enough consistency that quantities and prices actually line up correctly, row by row, even when a description wraps onto two lines.

Once structure is resolved, each cell's text is read (via OCR or a vision-language model) and typed: numbers as numbers, dates as dates. The output is usually a structured object (JSON or a table format) rather than a flat text dump, so it can be validated, summed, or fed into another system.

Why it matters for document processing

Most of the financial and operational content in business documents lives in tables, not in free text. Invoice totals, claim schedules, contract pricing grids, financial statements: these are all tables, and getting them wrong has direct consequences. A misread line item can flip a quantity or a price, and a badly stitched multi-page table can silently drop rows, which is far worse than an obvious extraction failure because nobody notices until reconciliation fails.

Generic OCR reads characters in the right visual order but has no concept of rows or columns, which is why table extraction is treated as its own capability in IDP systems rather than a side effect of text recognition. For finance and operations teams, the practical test isn't whether a tool can extract text from a table. It's whether it correctly handles merged headers, multi-page continuation, and row-level line items on the specific document types they actually process, invoices, claims forms, contracts, without manual cleanup afterward.

Related terms

• Data extraction
• Key-value extraction
• OCR vs VLM
• Intelligent Document Processing (IDP)
• E-invoicing France

FAQ

How do systems handle tables that span multiple pages?

They detect that a table's column structure continues on the next page, usually by comparing column positions and header text across the page break, then merge the rows into a single logical table. Repeated headers on each page help, but many real documents omit them, so the system has to infer continuity from layout alone.

Why are merged cells hard to extract correctly?

Merged cells break the assumption that every cell occupies exactly one row and one column. A model has to detect the visual span (a wider box, a missing internal line) and decide which rows or columns the value actually applies to. Get this wrong, and values get duplicated, dropped, or attached to the wrong row entirely.