# Choosing models for data extraction from tables and CSV

[Skip to content](#lm-inhoud)Network/[NL](/en/modellen-kiezen-voor-data-extractie-uit-tabellen-en-csv)EN[Hubhub.llmnet.nlCompare models on task, language, cost and license.](https://hub.llmnet.nl/en/)[Communitycommunity.llmnet.nlPrompt techniques, patterns and system prompts.](https://community.llmnet.nl/en/)[APIapi.llmnet.nlLLMs in production: rate limits, routing, structured output.](https://api.llmnet.nl/en/)[Consultancyconsultancy.llmnet.nlRolling out AI in an organization, pilot to production.](https://consultancy.llmnet.nl/en/)[Newsnieuws.llmnet.nlAI developments, explained for the Netherlands.](https://nieuws.llmnet.nl/en/)[Benchmarkbenchmark.llmnet.nlMeasure AI quality yourself, on your own tasks.](https://benchmark.llmnet.nl/en/)[Careersvacatures.llmnet.nlAI roles, salaries and career paths in the Netherlands.](https://vacatures.llmnet.nl/en/)[Learnleren.llmnet.nlAI concepts in plain language, beginner to builder.](https://leren.llmnet.nl/en/)[Guidegids.llmnet.nlRun AI privately on your own Mac, PC, NAS or home server.](https://gids.llmnet.nl/en/)[Directorydirectory.llmnet.nlMapping the AI ecosystem: tools, models, companies.](https://directory.llmnet.nl/en/)[Radarradar.llmnet.nlSignals from X, research and communities for indie developers.](https://radar.llmnet.nl/en/)[Appsapps.llmnet.nlReviews of AI apps and open-source repos, with tips for builders.](https://apps.llmnet.nl/en/)[llmnet.nl — main site](https://llmnet.nl/en/)[](https://x.com/intent/post?url=https%3A%2F%2Fhub.llmnet.nl%2Fen%2Fmodellen-kiezen-voor-data-extractie-uit-tabellen-en-csv&text=Choosing%20models%20for%20data%20extraction%20from%20tables%20and%20CSV)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fhub.llmnet.nl%2Fen%2Fmodellen-kiezen-voor-data-extractie-uit-tabellen-en-csv)[](https://www.reddit.com/submit?url=https%3A%2F%2Fhub.llmnet.nl%2Fen%2Fmodellen-kiezen-voor-data-extractie-uit-tabellen-en-csv&title=Choosing%20models%20for%20data%20extraction%20from%20tables%20and%20CSV)[](#)[](https://x.com/intent/post?url=https%3A%2F%2Fhub.llmnet.nl%2Fen%2Fmodellen-kiezen-voor-data-extractie-uit-tabellen-en-csv&text=Choosing%20models%20for%20data%20extraction%20from%20tables%20and%20CSV)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fhub.llmnet.nl%2Fen%2Fmodellen-kiezen-voor-data-extractie-uit-tabellen-en-csv)[](https://www.reddit.com/submit?url=https%3A%2F%2Fhub.llmnet.nl%2Fen%2Fmodellen-kiezen-voor-data-extractie-uit-tabellen-en-csv&title=Choosing%20models%20for%20data%20extraction%20from%20tables%20and%20CSV)[](#)

 
# Choosing models for data extraction from tables and CSV

 By Ivo Donker — compiled with AI assistance (Claude & Gemini)

 Automated extraction and structuring of data from tables, CSV files, and spreadsheets remains a persistent bottleneck in data processing. Where traditional, deterministic parsers such as regular expressions or fixed scripts immediately get stuck on missing delimiters, merged cells, or varying column orders, modern language and vision models offer flexibility. At the same time, deploying generative AI introduces new risks: subtle hallucinations in numeric cells, skipped rows in large tables, and unpredictable token costs.

 Within the broader task breakdown of language models, table extraction falls under specialized document transformation. Those who want to explore how this task relates to broader use cases can consult [the overview of AI models by task](https://hub.llmnet.nl/en/model-per-taak) for a systematic comparison. In this article, we analyze how different model classes handle spatial and textual table structures, which specific failure modes occur across different file formats, and how the trade-off between precision, compute time, and operational cost should be made.

 
## Task Definition: From Unstructured Cells to Reliable Schemas

 Data extraction from tables sits at the intersection of semantic text understanding and two-dimensional structural reconstruction. Unlike regular text processing, where meaning flows sequentially from left to right, an individual cell derives its meaning from the intersection of a horizontal row entity and a vertical column definition. As soon as column headers span multiple lines or cells are merged, the linear relationship disappears entirely.

 In practice, production pipelines process three fundamentally different input sources:

 1. Plain textual tables: CSV, TSV, or Markdown tables in which rows and columns are delimited with punctuation. The complexity here lies not in visual aspects, but in inconsistent escaping, nested commas within quotation marks, varying date formats, and unexpected line breaks within a cell.

 2. Semi-structured spreadsheets: Worksheets in which human users have added formatting as a carrier of meaning. Think of color coding, merged header rows, hidden columns, empty separator rows, and formulas that calculate interim subtotals.

 3. Visual and rendered tables: Tables within PDF documents, scans, or screenshots. Here, underlying structural markup is missing, and the spatial arrangement must be visually inferred before extraction can take place.

 The goal of the extraction task is almost always to transform this heterogeneous input into a validated format, such as a strict JSON schema or normalized database records. Those specifically looking for techniques to make models answer strictly within a JSON schema can consult the article about [choosing models for structured output](https://hub.llmnet.nl/en/modellen-selecteren-voor-gestructureerde-output) for in-depth schema validation methods.

 
## Technical Requirements: Where Table Processing Breaks Down

 When evaluating AI models for tabular extraction, specific criteria apply that differ significantly from standard text generation. A model that excels at writing or summarizing prose can be completely unsuitable for accurately parsing a financial balance sheet.

 
### 1. Tokenization and spatial blindness

 Language models break text down into tokens using algorithms such as Byte-Pair Encoding (BPE). Numbers, whitespace, and punctuation are not treated uniformly in this process. A series of spaces that aligns columns in a plain text table can be merged into a single token or, conversely, split across multiple subtokens. As a result, a purely textual model loses track of which cell belongs under which column header. Models with a strong code background generally perform better here, because formal syntax and whitespace indentation are a fixed part of their training data.

 
### 2. Context window versus attention dispersion

 A CSV file with a few thousand rows quickly exceeds tens of thousands of tokens. Although modern models support large context windows, attention drift regularly occurs with long tables. Rows in the middle of the file get skipped, or column definitions from the first line get incorrectly linked halfway through the document. To understand how context length affects attention distribution and compute power, the article about [how a context window works](https://hub.llmnet.nl/en/context-window-uitleg) explains the underlying transformer mechanisms.

 
### 3. Numerical reliability and rounding

 In tables, numbers represent hard facts: monetary amounts, percentages, serial numbers, IBAN numbers, or dates. Where a small synonym substitution in running text may be acceptable, a changed decimal point or an omitted minus sign renders a data record worthless. Models must have an extremely low hallucination rate when copying numeric data and must not round numbers unless explicitly instructed to do so.

 
## Candidate Models: Architecture Classes and Suitability

 For table and CSV extraction, we distinguish three primary model categories, each with specific strengths, limitations, and operational costs.

 
 
 
 
 Model class | 
 Typical characteristics | 
 Strengths | 
 Weaknesses | 
 

 
 
 
 Large multimodal frontier models | 
 Cloud-based general models with advanced vision encoders | 
 Superior understanding of complex layouts, multimodal input (PDF/scans), high precision with compound headers | 
 High token costs for bulk processing, dependency on external API availability | 
 

 
 Compact open-weight instruction models | 
 Locally hostable language models (roughly 7B to 14B parameters) | 
 Full control over data and privacy, low latency, cost-effective for millions of rows | 
 More sensitive to syntax errors with long CSVs, require strict decoding restrictions | 
 

 
 Specialized vision-language document models | 
 End-to-end trained on document structures and layouts | 
 Directly trained on document structures and OCR-free table extraction | 
 Limited general reasoning capability outside the visual domain, require custom integration | 
 

 
 
 

 The choice depends heavily on the representation of the input data. When tables are embedded in visual documents, a multimodal approach is often more robust than first forcing plain text through optical character recognition (OCR). Those who want to determine when a vision model is more effective than traditional pipelines will find in [the comparison between vision models and traditional OCR](https://hub.llmnet.nl/en/vision-modellen-vs-traditionele-ocr) an analysis of recognition errors and layout preservation.

 
## Edge Cases and Failure Modes in Tabular Data

 Table extraction rarely fails on simple, uniform tables; it's the edge cases where models go off the rails. A reliable architecture must explicitly account for the following patterns:

 
### 1. Merged cells and hierarchical headers

 In financial overviews, a parent category often spans multiple underlying quarterly columns. A purely textual model reads the lines sequentially and links the category name only to the first column beneath it, causing the remaining columns to be mislabeled. Multimodal models or specific markdown transformations in which cells are explicitly duplicated (so-called spanning unrolling) prevent this error.

 
### 2. Interim totals and aggregation rows

 Spreadsheets regularly contain subtotals, section titles, or footnotes in the middle of the data block. When a model is instructed to "convert all rows to JSON records," these subtotals are often extracted as regular transactions. This leads to double counting in downstream analyses. The prompt and the extraction schema must explicitly distinguish between detail lines and aggregated rows.

 
### 3. Inconsistent date and currency conventions

 In international datasets, notations get mixed up: date formats with varying day and month order cause confusion, as do number formats where periods and commas swap roles for decimals and thousands separators. An extraction model must be instructed to normalize values to ISO 8601 and numeric floats without separators, or to strictly preserve the source data unchanged.

 
## Evaluation Methodology: How Do You Measure Table Quality?

 Validating table extraction requires a measurable benchmark set. Manually spot-checking a few records gives a false sense of certainty. A methodical evaluation rests on four pillars:

 
### 1. Cell-level precision, recall, and F1 score

 Compare each extracted field exactly against a manually annotated ground truth. Make a distinction here between string fields (where a normalized Levenshtein distance or exact match applies) and numeric fields (where any deviation greater than 0 counts immediately as an error).

 
### 2. TEDS: Tree-Edit-Distance-based Similarity

 For complex tables with varying layouts, TEDS is the industry standard. This metric represents tables as an HTML-like tree structure of rows, columns, and cells. TEDS calculates the number of operations (insert, delete, rename) needed to transform the predicted tree structure into the true tree structure. As a result, both structural errors (such as a shifted column) and content parsing errors are weighted proportionally.

 
### 3. Schema conformity and JSON validation ratio

 Measure the percentage of generated responses that validate without errors against the predefined JSON schema. In production environments, this score must be above 99.5% to prevent automated data flows from getting stuck.

 
### 4. Row Completeness Ratio

 Check whether the number of extracted rows exactly matches the source. With long tables, models tend to merge repeating rows or truncate them with summary remarks. An automated check on row counts detects these truncation errors immediately.

 
## Cost and Efficiency Trade-off: Bulk Processing versus Precision

 When processing thousands of spreadsheets, the costs of commercial APIs escalate exponentially. A CSV with thousands of rows quickly consumes tens of thousands of tokens of context. If this file is sent to a frontier model in its entirety to filter out just a few records, you pay for tens of thousands of unnecessary tokens.

 To calculate the financial impact of large documents precisely, [the calculation bridge for the real cost of long context windows](https://hub.llmnet.nl/en/wat-kost-een-lang-contextvenster-echt-de-rekenbrug) shows how input costs per call add up when documents are submitted unprocessed. In addition, the benchmark overview of [comparing cost per task between models](https://benchmark.llmnet.nl/en/kosten-per-taak) offers an objective measurement method to weigh token consumption against extraction accuracy.

 In production, a layered processing strategy proves the most cost-effective:

 1. Deterministic preprocessing: Use regular code (such as Python with Polars or Pandas) to remove empty columns, enforce uniform whitespace, and strip irrelevant metadata before the text goes to the LLM.

 2. Chunking with header preservation: Cut long tables into logical blocks of 50 to 100 rows, adding the original column headers and contextual metadata to each block. This prevents the model from losing track and keeps the response time per call low.

 3. Dynamic routing: Simple, plain tables are handled by a compact local model. Only tables that fail schema validation or visually complex files are automatically forwarded to a heavier frontier model.

 
## Implementation Example: CSV to Strict JSON with Schema Enforcement

 The Python example below shows how a semi-structured CSV input is converted into a strictly typed JSON structure via Pydantic. The schema enforces that optional fields are represented as null and that numeric values are preserved exactly.

from pydantic import BaseModel, Field
from typing import List, Optional

class FactuurPost(BaseModel):
 artikelcode: str = Field(description="Exacte artikelcode of SKU")
 omschrijving: str = Field(description="Omschrijving van het product of de dienst")
 aantal: float = Field(description="Aantal geleverde eenheden")
 eenheidsprijs: float = Field(description="Prijs per eenheid exclusief BTW")
 btw_tarief: float = Field(description="Toegepast BTW-percentage als decimaal, bijv 0.21")
 regel_totaal: float = Field(description="Totaalbedrag van deze regel exclusief BTW")
 korting_percentage: Optional[float] = Field(default=None, description="Korting indien vermeld")

class FactuurExtractie(BaseModel):
 factuurnummer: str
 factuurdatum: str = Field(description="Datum in ISO formaat YYYY-MM-DD")
 leverancier_kvk: Optional[str] = Field(default=None)
 posten: List[FactuurPost]
 totaal_excl_btw: float
 totaal_incl_btw: float

system_prompt = (
 "Je bent een gespecialiseerd data-extractiesysteem. Converteer de aangeleverde "
 "tabelgegevens strikt conform het JSON-schema. Neem getallen exact over zonder "
 "afronding. Indien een veld ontbreekt in de bron, vul dan null in."
)

 By defining the schema explicitly, the API provider can use constrained decoding to restrict the model's logit generation to tokens that produce grammatically correct JSON. This eliminates syntax errors in the output.

 
## When Should You Not Use AI Models for Table Extraction?

 Although language and vision models are flexible with messy data, deploying AI for predictable, structured data processing is a structural design flaw. An LLM always introduces a chance of non-deterministic behavior, significant response time, and ongoing operational costs.

 Use no AI models in the following situations:

 1. Standard CSV and TSV exports: When files are generated by databases, CRM systems, or APIs with consistent delimiters. Traditional parsers such as Python's built-in csvmodule or polars.read_csv() process hundreds of thousands of rows per second, cost zero euros in API tokens, and produce zero hallucinations.

 2. Programmable spreadsheets: Excel documents with an intact structure can be read directly using libraries such as openpyxl or DuckDB. Formulas, cell properties, and data types can be queried deterministically without AI.

 3. Strict latency requirements under 50 milliseconds: In real-time transaction processing, the response time of an LLM (typically hundreds of milliseconds to several seconds) is unacceptable.

 Only deploy AI when the structure of the input varies unpredictably, human errors in the layout need to be corrected, or visual elements from scans need to be converted into meaningful data fields.

 
## Step-by-Step Plan for the Right Model Choice

 When setting up a production system for table extraction, following a structured selection process leads to the most stable and cost-efficient architecture. Those looking for a broadly applicable evaluation framework for business AI applications can consult [the reusable method for model selection within a field of expertise](https://hub.llmnet.nl/en/modelkeuze-voor-een-vakgebied-een-herbruikbare-methode) to formalize selection criteria.

 The concrete steps for tabular workflows are as follows:

 1. Characterize the input layer: Assess whether the data is purely textual (CSV/TSV), a semi-structured spreadsheet, or a visual document (PDF/scan). For visual files, choose a multimodal model directly to avoid errors from intermediate OCR.

 2. Define the validation schema in advance: Build a strict Pydantic or JSON schema and enforce constrained decoding on the model API.

 3. Build a benchmark set with edge cases: Evaluate candidate models on datasets with merged headers, missing values, and deviating number formats using TEDS and cell precision measurements.

 4. Implement chunking and fallback mechanisms: Cut large tables into pieces while preserving headers, and set up a routing layer that handles simple tasks locally and escalates complex edge cases to heavier models.