Best Python OCR Library for Invoices: 6 Engines Compared (2026)

Choosing the best Python OCR library for invoices comes down to three trade-offs: extraction accuracy on financial documents, processing speed, and deployment complexity. Here is how the six leading engines compare on the metrics that matter for invoice pipelines.

Tesseract 5.x (via pytesseract) delivers the strongest accuracy-to-speed balance for clean scanned invoices, processing a typical page in under one second with a roughly 10 MB install footprint. PaddleOCR with PP-StructureV3 is the better choice when your pipeline handles tabular line items and multilingual invoices, thanks to its built-in layout analysis. EasyOCR handles handwritten annotations and mixed-script documents well, but at roughly 3x slower inference and a ~500 MB model footprint, it suits batch processing more than real-time extraction. Surya, RapidOCR, and DocTR round out the field with distinct strengths covered in detail below.

A peer-reviewed 2024 benchmark tested Tesseract, EasyOCR, PaddleOCR, MMOCR, and Keras OCR across several languages and found Tesseract achieved 92% accuracy on English text. But the same study showed performance varied dramatically across document types, with no single engine excelling in every scenario. That tracks with invoice work in practice: an engine that scores well on prose can fail on a three-column line-item table with currency symbols, tax codes, and mixed font sizes. The right Python OCR library for your invoice pipeline depends on the specific documents you process, not aggregate text accuracy scores.

If you are evaluating approaches beyond OCR engine selection (template matching, AI-based extraction, or hybrid pipelines), our broader guide to extracting invoice data with Python covers the full landscape. For production invoice pipelines processing varied document types at scale, a managed extraction API can eliminate the library selection trade-offs entirely: you describe the fields you need in plain language and get structured rows back, with no engine, layout, or parsing stack to maintain.

---

Two Generations of Python OCR in 2026

That 2024 benchmark tested one generation of tooling. By 2026 there are two, and knowing which one you are shopping in prevents most of the wasted evaluation time.

Traditional detect-and-recognize engines — the six compared in this article — locate text regions on a page and transcribe them, returning character strings with bounding boxes. Most run acceptably on CPU, cost nothing per page, and produce the same output for the same input every time. For the large majority of invoice pipelines they remain the right answer, and the next three sections are about choosing between them.

Vision-language document models — Surya 2, PaddleOCR-VL, olmOCR, dots.mocr, Mistral OCR and the Qwen vision line — read the whole page as a single model and emit structured output directly: markdown, HTML or JSON with the line-item table already reconstructed. They skip the table-reconstruction work that dominates traditional pipelines, and they introduce failure modes that traditional engines simply do not have, including fabricated values on exactly the numeric fields an invoice pipeline cares about.

If you already know you want the newer generation, skip ahead to VLM-based OCR. Otherwise, start here.

---

Six Python OCR Engines: Installation, Speed, and Architecture

Each engine makes a different trade-off between deployment footprint, layout awareness, multilingual coverage, and speed.

Tesseract 5.x (via pytesseract)

Tesseract is the oldest and most widely deployed open-source OCR engine, now on version 5 with an LSTM-based recognition model. The current release is 5.5.3 (July 2026), driven from Python by pytesseract 0.3.13. The Python wrapper is a thin interface that calls the system-installed Tesseract binary, which means installation is a two-step process: you install the Tesseract binary for your OS, then pip install pytesseract. Note that the binary version you actually get depends on your OS package manager or base image, not on pip — distribution packages routinely lag the upstream release by months, so pin and check it explicitly if a specific fix matters to you.

The total footprint is roughly 10 MB, making it the second lightest option here. Processing speed sits around 0.8 to 1 second per page on CPU, with no GPU support or requirement. That simplicity is both its strength and its constraint. Tesseract treats each page as a flat image and runs recognition line by line. It has no built-in understanding of tables, columns, or document layout analysis, so extracting structured invoice data requires significant post-processing on your end.

EasyOCR

EasyOCR is a PyTorch-based engine that pairs CRAFT text detection with a deep learning recognition network. Installation pulls in PyTorch and torchvision, ballooning the footprint to roughly 500 MB. Processing speed is approximately 2.5 to 3 seconds per page. GPU is optional but strongly recommended; without it, that per-page time climbs fast.

EasyOCR's advantage over Tesseract shows up on degraded inputs. It handles handwritten annotations, skewed scans, and distorted text better than Tesseract. For invoices with handwritten PO numbers or stamps, that matters. The trade-off is the heavy dependency chain and slower throughput, which can be a blocker if you are processing thousands of documents daily.

One thing worth weighing before you commit: the current release is 1.7.2, published in September 2024. That is nearly two years without a new version, while PaddleOCR, RapidOCR, and Surya have all shipped releases within the last few months. The library still works and its recognition models are unchanged by the passage of time, but a stalled release cadence means no new language models, no dependency updates as PyTorch moves, and slower resolution of issues you hit in production. Treat it as a maturity signal rather than a disqualifier.

PaddleOCR (with PP-StructureV3)

PaddleOCR, built on Baidu's PaddlePaddle framework, is the most invoice-relevant engine out of the box. The PP-StructureV3 module adds native table structure recognition and document layout analysis directly into the pipeline. It can identify table cells, row/column relationships, and reading order without custom code. The current release is 3.7.0 (June 2026), and the project is among the most actively maintained in this comparison.

Install size is 150 to 200 MB. Speed is competitive at roughly 1 to 1.5 seconds per page, and GPU is optional. PaddleOCR also offers the broadest multilingual and script coverage of the six engines, which is relevant if your pipeline handles invoices across regions. The main friction point is the PaddlePaddle framework itself, which is less familiar to most Python developers than PyTorch or TensorFlow. When comparing all three engines, PaddleOCR's structured extraction capability gives it a distinct architectural advantage for invoice line items.

Surya OCR

Surya is a newer, transformer-based OCR engine with built-in line detection, layout ordering, and reading order analysis. It was designed from the start to handle complex multi-column layouts, which makes it relevant for invoices that mix header blocks, line item tables, and footer details across non-trivial page structures.

Install size is roughly 200 MB, with processing speed of 1.5 to 2 seconds per page. GPU is recommended for production workloads. The transformer architecture gives Surya strong contextual awareness of how text regions relate to each other on a page. The downside: it is a younger project with less community documentation and fewer Stack Overflow answers when you hit edge cases.

Two things changed in 2026 that older comparisons miss. First, the architecture: release 0.20.0 (May 2026) rebranded the project "Surya 2" and replaced the previous stack of separate task-specific models with a single ~650M-parameter vision-language model that handles layout, text recognition, table recognition, and reading order in one pass, served through vLLM on GPU or llama.cpp on CPU and Apple Silicon. The current release is 0.22.1 (July 2026). The footprint and speed figures above describe the pre-2.0 line; Surya 2 has a genuinely different runtime profile, and it belongs to the newer generation discussed later in this article as much as to this one.

Second, and more important for commercial work: Surya's code is Apache 2.0, but its model weights are not. They ship under a modified AI Pubs Open RAIL-M license that is free for research, personal use, and companies below a $5M funding-and-revenue threshold, with a separate paid commercial license required above it. Every other engine in this comparison is straightforwardly Apache 2.0. If you are building an invoice pipeline inside a funded company, check that threshold before Surya reaches your production branch — this is the single most common way teams get surprised by it.

RapidOCR

RapidOCR takes PaddleOCR's trained recognition models and converts them to run on ONNX Runtime, eliminating the PaddlePaddle framework dependency entirely. The result is the lightest deployment footprint of the six at roughly 50 to 80 MB and the fastest raw speed at 0.5 to 1 second per page, fully CPU-optimized.

This makes RapidOCR ideal for containerized deployments or serverless functions where image size and cold start time matter. The trade-off is direct: RapidOCR does not include PP-StructureV3's table structure recognition. You get fast, accurate text extraction, but table parsing and document layout analysis become your responsibility.

Install the right package. The project consolidated its previously separate backend packages — rapidocr_onnxruntime, rapidocr_openvino, and rapidocr_paddle — into a single rapidocr distribution that also adds PyTorch inference, and the older packages are no longer actively maintained. The current release is rapidocr 3.9.2 (July 2026), installed as pip install rapidocr onnxruntime with the inference engine as a separate dependency; the legacy rapidocr-onnxruntime has sat at 1.4.4 since January 2025. Tutorials written before the consolidation still point at the old package name, which is the most common reason a RapidOCR install ends up on stale models.

DocTR (python-doctr)

DocTR is a two-stage document text recognition library: a detection model locates text regions, then a separate recognition model transcribes each one. What distinguishes it from the other five is that both stages are swappable from a model zoo. Detection offers DBNet (db_resnet50, db_mobilenet_v3_large), LinkNet, and FAST variants; recognition offers CRNN backbones, parseq, vitstr, sar_resnet31, and master. You pick the pair that matches your accuracy and latency budget rather than accepting a single vendor default, which is genuinely useful when you are tuning against one known invoice population.

Two current facts are worth knowing, because most comparison articles still get them wrong. First, DocTR is PyTorch-only as of version 1.0.0; TensorFlow was removed as a supported backend, along with the torch and tf install extras, so installation is now simply pip install python-doctr. Articles describing DocTR as a dual-backend library are out of date. The current release is 1.0.1 (February 2026), it is Apache 2.0, and it requires Python 3.10 or later.

Second, and decisive if you arrived here comparing DocTR against PaddleOCR for line items: the released version does not do table structure recognition. Layout, reading-order, and table-structure modules exist in the project's development branch and appear in the latest documentation, but they are not in 1.0.1, and documentation built from the development branch is the likely reason you may have read otherwise. What 1.0.1 does ship is a kie_predictor for key information extraction, which is the closer analogue for pulling header fields such as invoice number and date. For the line-item grid itself, PaddleOCR with PP-StructureV3 remains the stronger choice today.

Comparison Table

The ranges below are practical deployment estimates, not universal benchmarks. Actual speed and footprint depend on page resolution, preprocessing, CPU or GPU type, batch size, and model configuration. Versions are the current releases as of July 2026; for Tesseract, the version you actually run depends on your OS package, not on pip.

Library	Version (Jul 2026)	Install Size	Speed (per page)	GPU Required	Primary Strength for Invoices
Tesseract 5.x	5.5.3	~10 MB	0.8–1 s	No (CPU-only)	Minimal footprint, widest ecosystem
EasyOCR	1.7.2	~500 MB	2.5–3 s	Optional (recommended)	Handwritten and distorted text
PaddleOCR	3.7.0	~150–200 MB	1–1.5 s	Optional	Native table structure via PP-StructureV3
Surya OCR	0.22.1	~200 MB	1.5–2 s	Recommended	Multi-column layout and reading order
RapidOCR	3.9.2	~50–80 MB	0.5–1 s	No (CPU-optimized)	Fastest speed, lightest deployment
DocTR	1.0.1	PyTorch-scale	Varies by backbone	Optional (recommended)	Swappable detection/recognition models

DocTR carries no single speed figure here because that is a property of the backbone pair you choose, not of the library: a MobileNet detection and recognition combination is dramatically faster and less accurate than a ResNet-50 and PARSeq pairing on the same page. That configurability is the point of the library, and quoting one number for it would misrepresent how it is used.

For open-source invoice OCR in Python, no single engine dominates across every axis. Tesseract and RapidOCR win on deployment simplicity. PaddleOCR wins on structured extraction. EasyOCR and Surya win on handling messy, real-world document quality. DocTR wins when you want to tune the accuracy-latency trade-off yourself. Your deployment constraints and the condition of your source documents should drive the shortlist.

---

Invoice Extraction Accuracy: Tables, Currency, and Layout Challenges

Generic OCR benchmarks measure character error rates on clean paragraphs of text. Invoices are nothing like clean paragraphs of text. They combine structured tables, mixed font sizes, currency symbols, multi-column headers, and footer legalese into a single page. This is where the six libraries diverge in ways that matter for your pipeline.

Line Item Table Extraction

The line item table is the highest-value region on any invoice, and it is the hardest to extract correctly. Each row contains a description, quantity, unit price, and line total, all in aligned columns that OCR engines handle very differently.

PaddleOCR with PP-StructureV3 is the clear leader here. Its native table structure recognition identifies row-column relationships directly, outputting cell-level coordinates that map to a structured grid. You get a table, not a bag of text fragments.

Tesseract outputs flat, linearized text with zero table awareness. It reads left to right across the entire page width, which means a description field can merge with the quantity column in the same text line. Reconstructing the table requires custom post-processing: you need to calculate bounding box positions, cluster text regions into columns by x-coordinate, and sort rows by y-coordinate. This works, but it is fragile and breaks when column widths vary between invoices.

EasyOCR detects individual text regions with bounding boxes, which gives you spatial data to work with. However, it does not preserve the relationship between cells in the same row. Two values that sit side by side in a table row are returned as independent detections with no grouping. You still need heuristic logic to associate them.

Surya's layout analysis preserves column structure more reliably than Tesseract, identifying text blocks within their visual columns rather than reading straight across. You will still need post-processing to map detected text into a proper table schema, but the input quality is significantly better.

RapidOCR inherits PaddleOCR's strong text detection and recognition models, but it does not include PP-StructureV3's table structure features. For table extraction specifically, it performs closer to EasyOCR than to PaddleOCR's full pipeline.

DocTR returns detected text blocks organized into a page-word-line hierarchy with bounding boxes, which is more structure than a flat text dump but is still not a table. Because the released version ships no table structure module, reconstructing the line-item grid is your work here, exactly as it is with Tesseract and EasyOCR. Where DocTR helps is upstream of that: choosing a stronger detection backbone reduces the number of missed or merged text regions your reconstruction logic has to survive in the first place.

Currency Symbols and Decimal Alignment

Financial documents live and die on numeric precision. A misread decimal separator turns a $1,250.00 invoice into $125,000, and your downstream validation has to catch it.

EasyOCR has a well-documented weakness with currency symbols on lower-quality scans: "$" frequently becomes "S" and "€" becomes "E". On clean, high-resolution PDFs the problem is minimal, but on scanned paper invoices at 200 DPI or below, expect to build symbol correction logic.

Tesseract handles standard currency symbols reliably on clean input. Its failure mode is subtler and more dangerous: confusion between period and comma decimal separators on international invoices. A European-format total of 1.250,00 can be read as 1,250.00 or produce garbled output depending on the Tesseract language pack and font. If your pipeline processes invoices from multiple countries, this requires explicit locale-aware validation.

PaddleOCR's multilingual training corpus gives it a measurable advantage on non-Latin currency symbols (¥, ₹, ₩) and mixed numeral formats. It handles European decimal notation more consistently than Tesseract or EasyOCR without needing language-specific configuration.

Layout and Scan Quality Failure Modes

Invoice layouts fail OCR in a few predictable ways. Two-column headers can cause Tesseract to interleave vendor details with invoice metadata unless page segmentation is tuned; Surya and PaddleOCR handle reading order and column transitions more reliably. Footer details such as payment terms, bank account numbers, and tax IDs often appear in 8pt or 9pt type, where Tesseract degrades faster than EasyOCR or Surya on scanned images. Skewed pages add another failure mode: Tesseract and PaddleOCR can correct moderate rotation when configured, while Surya is the strongest option for severe orientation issues.

Low-Quality Phone Photos

Field invoicing is increasingly common: delivery drivers photograph receipts, employees snap expense reports, technicians capture work orders on-site. These images have uneven lighting, perspective distortion, motion blur, and compression artifacts.

EasyOCR's deep learning backbone gives it a clear edge in this scenario. Its recognition model was trained on diverse real-world image conditions, not just clean scans. On phone photos with moderate noise and distortion, EasyOCR maintains usable accuracy where Tesseract's output degrades substantially — though applying targeted OCR preprocessing steps like deskewing, binarization, and noise removal before recognition can narrow that gap significantly regardless of engine. If your pipeline ingests user-submitted photos rather than flatbed scans or digital PDFs, weight this factor heavily.

PaddleOCR also handles degraded image quality well, though its advantage over EasyOCR on phone photos is less pronounced than its advantage on structured documents.

For production pipelines processing invoices at scale, raw OCR output is only the starting point. Tracking extraction accuracy across document types, identifying systematic failure patterns, and iterating on pre-processing are what separate a prototype from a reliable system. Our guide on measuring and improving invoice OCR accuracy covers the metrics and feedback loops that matter most.

---

Which OCR Engine Fits Your Invoice Pipeline

Most developers start with Tesseract. It has the deepest documentation, the simplest mental model, and decades of community answers on Stack Overflow. That works until it doesn't. The typical progression: Tesseract handles clean PDFs fine, then a batch of photographed invoices arrives with skewed tables, and suddenly line items merge into unreadable strings. You switch engines, rewrite your parsing logic, and lose a week.

The decision matrix below shortcuts that trial-and-error cycle. Find your scenario, get a recommendation.

Clean scanned invoices from a consistent vendor format — use Tesseract 5.x. When input quality is high and layouts are predictable, nothing beats its speed-to-accuracy ratio. It carries the smallest integration overhead, runs on CPU without heavy dependencies, and produces reliable output on single-column invoices with standard header/line-item/total structures. If your pipeline ingests invoices from a known set of suppliers with consistent templates, Tesseract is the pragmatic default.

Invoices with structured line item tables requiring row-column extraction — use PaddleOCR with PP-StructureV3. Table extraction is where most OCR engines break down on invoices. PP-StructureV3's native table structure recognition preserves the relationship between line item descriptions, quantities, unit prices, and totals. Rather than post-processing raw text coordinates into table rows yourself, you get cell-level structure out of the model. For invoices where the line item table is the payload, this advantage compounds across every document.

Multilingual invoices from EU cross-border or international trade — use PaddleOCR. It covers the broadest set of languages and scripts, handling non-Latin currencies, mixed-script documents, and character sets that Tesseract's language packs struggle with. If your pipeline processes invoices in German, Arabic, Chinese, and Thai from the same vendor pool, PaddleOCR eliminates the need to maintain separate language-specific configurations. Arabic invoices in particular layer right-to-left reading order on top of table-grid reconstruction, and our deeper look at Python OCR options for Arabic invoice tables covers the RTL and numeral-handling pitfalls worth knowing before you commit.

Invoices with handwritten annotations or heavily distorted scans — use EasyOCR. The speed penalty and larger model size are real costs. But when you're dealing with warehouse receipt stamps, handwritten PO numbers scrawled in margins, or invoices photographed at angles on a loading dock, EasyOCR's deep learning recognition recovers text that rule-based segmentation engines misread or skip entirely.

Multi-column invoice layouts with non-standard reading order — use Surya. Some invoices stack billing and shipping addresses side by side, split line items across columns, or interleave header blocks in ways that violate top-to-bottom, left-to-right assumptions. Surya's transformer-based layout detection resolves these complex reading orders where Tesseract's page segmentation modes (PSM) produce scrambled output. If you find yourself cycling through PSM values to get Tesseract to read columns correctly, that is the signal to evaluate Surya OCR for invoice processing in Python instead.

Lightweight deployment, embedded systems, or strict CPU-only environments — use RapidOCR. Smallest footprint of the six engines. No framework dependency, no system binary requirement, fastest CPU inference. When you need to run OCR on an edge device, inside a minimal container, or in an environment where installing the PaddlePaddle framework or Tesseract system binaries isn't feasible, RapidOCR delivers PaddleOCR-level accuracy through ONNX Runtime without the deployment overhead.

A known invoice population you can tune against — use DocTR. When you process invoices from a stable supplier set and have a labeled sample to measure against, DocTR's swappable detection and recognition backbones let you trade accuracy for latency deliberately instead of accepting one vendor's default. Start with a ResNet-based detector and PARSeq recognition to establish your accuracy ceiling, then step down to MobileNet variants and measure what you actually lose. This only pays off if you have the evaluation set to make the comparison meaningful; without one, the configurability is just more decisions.

One practical distinction worth highlighting: Tesseract requires OS-level binary installation and version management across environments. RapidOCR is a pure Python package with no external binaries. If you need the best OCR library for invoices in Python without C++ dependencies in your Docker image, RapidOCR is the direct substitute. Once you have settled on an engine, wrapping it in a FastAPI extraction endpoint is one of the fastest paths from library evaluation to a deployable invoice processing service.

Looking for an Alternative to a Specific Engine

Developers often arrive at this comparison already using one engine and looking for a way out of it. The replacement depends on which constraint pushed you off it.

A PaddleOCR alternative is usually wanted for one of two reasons. If the PaddlePaddle framework dependency is the problem — install friction, container size, or a platform where it does not build cleanly — RapidOCR is the direct answer, because it runs Paddle's own trained models through ONNX Runtime with no framework dependency and no accuracy penalty on text recognition. If instead you need PaddleOCR's table capability from a different project, there is no clean like-for-like substitute among traditional engines; PP-StructureV3 is genuinely the strongest open-source table structure module in Python today, and the honest alternatives are either reconstructing tables yourself from another engine's bounding boxes or moving up to a vision-language model that emits table structure directly.

An EasyOCR alternative is typically sought over throughput or the stalled release cadence. For the same deep-learning robustness on degraded scans with active maintenance, PaddleOCR is the closest match and is meaningfully faster. For the same PyTorch foundation with more control, DocTR covers similar ground with configurable backbones.

A Python OCR library without Tesseract — meaning no system binary, no apt-get, no C++ dependency in your image — leaves you RapidOCR, EasyOCR, PaddleOCR, DocTR, and Surya, all of which install from pip alone. RapidOCR is the lightest of them by a wide margin and the natural first stop if avoiding the binary was the whole motivation.

No single engine wins across all invoice types. The right choice depends on your dominant document characteristics, not on benchmark scores averaged across generic datasets. Pick the engine that matches your hardest 20% of invoices — the clean ones will work with anything.

---

VLM-Based OCR: When the New Generation Earns Its Cost

The six engines above detect text and transcribe it. A vision-language document model does something different: it reads the entire page and writes out a structured representation directly — markdown, HTML, or JSON with the line-item table already assembled. The table-reconstruction work that consumes most of the engineering time in a traditional invoice pipeline is, in principle, done for you.

That is a real advantage, and it comes with a set of trade-offs that are specific enough to invoice work that they deserve stating plainly.

The current open-weight and API options

If your shortlist includes higher-level parsing stacks rather than only OCR models, this comparison of document parsers for invoice extraction evaluates their hosting, validation, and build-versus-buy trade-offs.

Surya 2 is the newest architecture from the same project covered above: a single ~650M-parameter model doing layout, OCR, tables, and reading order together, outputting HTML with bounding-box attributes. Smallest of the open options, and subject to the RAIL-M weights license discussed earlier.

PaddleOCR-VL pairs a dynamic-resolution visual encoder with a 0.3B ERNIE language model for a ~0.9B total, and it is Apache 2.0 — genuinely open weights, unlike Surya's. It outputs JSON and markdown with HTML tables and LaTeX formulas, covers over 100 languages, and version 1.6 arrived in May 2026. If you already run PaddleOCR, this is the shortest path into the new generation.

dots.mocr (~3B, MIT-licensed, formerly named dots.ocr) has the most directly usable output shape for invoice work: one JSON object per page, each element carrying a bounding box, a category from a fixed vocabulary such as Table, Text, Section-header, or Page-footer, and its text, with tables as HTML and elements pre-sorted into reading order. Categorized, localized elements are far easier to validate field by field than a wall of markdown.

olmOCR from the Allen Institute for AI is Apache 2.0, built on Qwen2.5-VL-7B, and is the only option in this group that publishes a concrete hardware floor: an NVIDIA GPU with at least 12 GB of VRAM, plus 30 GB of disk. Surya, PaddleOCR-VL, and dots.mocr publish no minimum VRAM figure at all, which means budgeting for them requires measuring on your own hardware.

Mistral OCR 4 is the API route — no open weights — at $4 per 1,000 pages, halved for batch submissions. It returns bounding boxes, typed block classification, and, uniquely in this group, per-word confidence scores, which give you a native hook for flagging uncertain fields instead of inferring uncertainty yourself. Worth noting that Mistral's own model card lists high-stakes financial decisions as out-of-scope use.

Qwen deserves a version warning. Many tutorials still name Qwen2.5-VL, which is now two generations old; Qwen3-VL followed it and the current Qwen3.5 line is natively multimodal with no separate -VL branch. Qwen2.5-VL still matters as olmOCR's base model. If you do use it directly, check the license per size: the 7B and 32B are Apache 2.0, but the 3B is research-only and the 72B carries a separate community license.

Read the benchmark numbers carefully

Published scores for these models are inconsistent enough across sources that comparing them casually will mislead you. Three reasons, all worth knowing before you cite a number in a design document:

The scales differ. olmOCR-Bench is a pass/fail unit-test suite — 1,403 PDFs, roughly 7,000 assertions — scored as a percentage from 0 to 100, higher better. OmniDocBench reports an overall score from 0 to 100 where higher is better, but its component metrics are normalized edit distances from 0 to 1 where lower is better. Mixing the two produces the wildly contradictory figures you find in roundups.

The versions are not comparable. OmniDocBench changed both its dataset and its matching algorithm at v1.5 and again at v1.6, so a v1.5 score and a v1.6 score are different measurements. Any number quoted without its benchmark version is unusable.

Most headline figures are vendor self-reported, with disclosed harness modifications. Several projects state outright that they adjusted the evaluation to fit their output format or removed certain element types before scoring. That is honest disclosure rather than misconduct, but it means cross-vendor comparison of self-reported numbers is not sound. The scores worth most are the ones where a third party evaluated someone else's model.

One caveat matters more than any individual score: olmOCR-Bench contains no invoice, receipt, or business-form category, and nearly half its assertions test mathematical formula accuracy. A model that tops it has demonstrated something real about academic-document parsing and close to nothing about whether it will read your supplier's line-item table correctly. Benchmark on your own invoices; there is no published leaderboard that substitutes for it.

The failure modes that matter on financial documents

Fabricated and altered values. This is the serious one. A 2026 academic benchmark built on 10,000 human-annotated real-world receipts evaluated leading multimodal models on structured field extraction and documented failure patterns that should shape how any invoice pipeline uses these models. When a unique identifier is not visually present on the document, models were found to fabricate a plausible-looking string for the invoice number rather than return an empty value — the schema demands a field, so the model supplies one. The researchers also observed digit confusion between visually similar characters in identifier fields, and, most consequentially, a behavior they term value tampering: models altering a line-item price so that the detail rows sum correctly to the stated total.

Sit with that last one. The standard validation check on an extracted invoice is whether the line items add up to the total. Against a model that has quietly adjusted a line item to make the arithmetic work, that check passes on corrupted data. The safety net most pipelines rely on is precisely the one this failure mode defeats. Cross-field validation against the source image, not internal arithmetic consistency, is what catches it.

Non-determinism. Traditional engines return identical output for identical input. These models do not, and not only for the obvious reason. olmOCR's shipping pipeline samples with a temperature ladder that escalates from 0.1 up to 1.0 across as many as eight retries, meaning the pages that fail first — your hardest, most degraded invoices — get transcribed with the most randomness. Separately, even at temperature zero, models served through batched inference can return different outputs for the same input because results depend on the composition of the batch they happen to land in, which varies with server load. For a pipeline where the same invoice reprocessed must yield the same numbers, this needs explicit handling.

Cost and hardware. The traditional engines run on a CPU you already pay for. The new generation needs a GPU you must provision, or an API you pay per page for. At $4 per 1,000 pages, a pipeline processing 50,000 pages a month is $200 in OCR alone before anything downstream.

So when does the new generation earn it?

Reach for a vision-language model when your invoices are structurally varied enough that table reconstruction has become the dominant engineering cost — many suppliers, unstable templates, layouts that defeat the coordinate-clustering logic you have already written. That is the problem these models genuinely solve, and it is a problem worth real money when you have it.

Stay with the traditional engines when your invoices are structurally consistent, when per-page cost or CPU-only deployment is a hard constraint, or when reproducibility is a requirement rather than a preference. For a large share of invoice pipelines — a stable supplier set and predictable layouts — PaddleOCR with PP-StructureV3 on a CPU still resolves the problem at zero marginal cost and with output you can reason about deterministically. Newer is a different set of trade-offs, not a strict upgrade.

---

When Open-Source OCR Reaches Its Limits

Choosing the right OCR engine matters, but it solves exactly one layer of the problem. Tesseract, EasyOCR, PaddleOCR, Surya, RapidOCR, and DocTR output raw character strings or bounding boxes; they do not return a validated invoice number, due date, vendor name, or line-item table. That transformation still requires parsing, layout-specific configuration, validation, and monitoring.

The newer vision-language models change one part of that sentence and not the rest. They do return a line-item table, in markdown or HTML or JSON, without you writing coordinate-clustering code — that layer really is solved. What none of them return is a validated invoice. No model in either generation checks that the tax rate is plausible for the vendor's country, that the invoice number is not a duplicate of one you paid last month, that the currency matches the supplier record, or that a total is consistent with the purchase order. And as the receipt benchmark above documents, arithmetic self-consistency is not proof of correctness: a model that adjusts a line item to make the sum work produces an invoice that passes your validation and is wrong. Structured output moved the boundary. It did not remove it.

At scale, those remaining layers become the expensive part. A proof-of-concept that handles five templates is very different from a production system that ingests documents from 200 vendors. Each new layout can require different page segmentation, preprocessing, language packs, regex patterns, and review rules — and on the model-based path, GPU capacity or per-page API spend, plus a strategy for what happens when the same document returns different numbers on a retry. Deciding between assembling this yourself and buying it is the open-source versus managed invoice OCR trade-off in its practical form, and the answer turns on how much of your team's time the parsing, validation, and review layers deserve.

Whichever generation you build on, the piece that has to exist somewhere is a review path: a way for values the system is not confident about to reach a human before they reach your ledger, rather than being silently guessed. For tightly scoped use cases with known invoice formats, a well-tuned Tesseract or PaddleOCR pipeline plus your own checks can work. When the goal is structured invoice data from varied sources at volume, it is worth evaluating whether you can extract invoice data automatically without managing OCR libraries — describing the fields you need in plain language, getting Excel, CSV, or JSON back with uncertain values flagged for verification, and leaving the engine selection, parsing, and deployment layers to someone else.