Docling vs Marker vs LlamaParse for Invoice Extraction

Document parsers sit above OCR. OCR recognizes characters; a parser reconstructs reading order, layout, and tables; an extraction layer maps that representation into invoice fields; validation decides whether those fields are safe to post. No tool wins all four layers.

For Docling vs Marker vs LlamaParse, choose by the failure you cannot accept. Start with line-item fidelity, totals and tax consistency, source provenance, deployment constraints, and the engineering work your team will own after the first successful demo. Test those criteria on your invoices, because a clean Markdown rendering is not evidence that quantities, unit prices, and line totals stayed in the right rows.

Tool	Processing model	Base output and extraction path	Signals useful for review	Best initial fit
Docling	Local Python execution, including air-gapped use; self-hostable service	Rich DoclingDocument output with layout and tables; schema extraction through dictionary or Pydantic templates and the companion Docling Graph project	Page, bounding-box, element provenance, plus parser-stage confidence scores	Teams that want a permissively licensed local document-understanding component and are prepared to build invoice validation
Marker	Local on GPU, CPU, or Apple MPS; hosted and licensed on-prem options also exist	Markdown, HTML, chunks, or a generic JSON block tree; invoice-field mapping remains a separate concern	Page and polygon metadata, but no documented invoice-field confidence or review queue	Teams that want a controllable local conversion layer and can accept the model-weight license
LlamaParse	Proprietary managed service in LlamaIndex's secure cloud or a customer VPC	Parsing for complex documents; schema extraction is part of the wider LlamaCloud offering rather than proof that parsed fields are finance-ready	Page and block bounding boxes, optional confidence, and table parse concerns	Teams that accept a managed service and want to reduce parser infrastructure
Unstructured	Local open-source library, with separate commercial deployment options	Typed document elements for broad ingestion and partitioning; invoice-schema extraction is downstream or part of commercial workflows	Page coordinates, parent relationships, and layout-detection probabilities, not invoice-field confidence	Teams building a broad document-ingestion layer across many file types
Mistral OCR	Document AI API; enterprise self-managed deployment is available	Layout-aware OCR plus schema-based document annotations	Bounding boxes and page- or word-level confidence for source checking	Teams that want managed multimodal OCR and structured annotations without treating them as an accounts-payable control system

The best document parser for invoices is therefore the one that clears your deployment gate and produces the lowest business-risk error rate on your supplier mix. That answer cannot be read from a general PDF or RAG leaderboard.

OCR, parsing, schema extraction, and validation are separate layers

An invoice pipeline has four distinct jobs:

1. Character recognition turns pixels into text. A digital PDF may already contain usable text; a scan needs an OCR engine.
2. Document parsing restores reading order, page structure, and table relationships. Its output may be Markdown, HTML, positioned elements, or a document object.
3. Schema extraction maps that representation to fields such as vendor, invoice number, invoice date, currency, net, tax, total, and line items.
4. Validation and review check types, field relationships, arithmetic, and uncertain results before anything reaches an ERP or accounting system.

That separation matters because a document parser versus OCR comparison for invoices answers only part of the design question. Docling can call OCR engines for scanned pages, for example, but selecting Docling does not make the OCR layer irrelevant. If recognition turns 8 into 3, good table reconstruction may preserve the wrong value perfectly. The existing comparison of Python OCR engines for invoices covers that lower layer.

Likewise, not every PDF needs a learned parser. Python PDF table extraction libraries such as deterministic table tools can remain the better choice when invoices are digitally generated, layouts are stable, and table boundaries are predictable. Their narrower behavior is sometimes an advantage: fewer model updates, lower compute requirements, and easier regression analysis.

Parser output also varies in meaning. A Docling document object preserves hierarchy, tables, element types, bounding boxes, and provenance. Marker JSON is a tree of content blocks, not a ready-made invoice record. The open-source Unstructured library emits typed elements with coordinates and parent relationships. These representations help a downstream extractor find evidence, but none guarantees that an amount beside “VAT” has become the correct tax_amount for the correct invoice.

Schema-driven invoice extraction is another model or processing step. Docling's information-extraction examples accept dictionary and Pydantic templates, while Docling Graph can produce validated objects with source provenance. Mistral Document AI applies a supplied JSON schema through document annotations. LlamaParse handles document parsing; field extraction sits within the wider LlamaCloud service. Unstructured's open-source library focuses on partitioning, with custom-schema extraction supplied downstream or through its commercial workflows.

A structurally valid object can still be financially wrong. Pydantic can reject a string where a decimal is required, but it will not know that a quantity belongs to the next row, that a missing tax amount was silently replaced with zero, or that the line totals fail to reconcile with the invoice total unless those rules are explicitly encoded. Treat parser JSON as evidence-bearing input to an invoice schema, not as posting-ready data.

Deployment and licensing can eliminate a parser before testing

Decide where invoice bytes are allowed to travel before comparing extraction quality. A requirement for local or air-gapped processing immediately changes the shortlist; so does a policy that permits a managed service only in a customer-controlled cloud environment.

Docling and the open-source Unstructured library are permissively licensed local building blocks, but they solve different center-of-gravity problems. Docling's MIT-licensed toolkit emphasizes document understanding, a rich internal representation, and source provenance. Unstructured's Apache 2.0 library emphasizes partitioning many file types into typed elements for later processing. In an Unstructured versus Docling decision for invoices, choose Docling when the document model and finance-specific extraction path matter most; choose Unstructured when invoice files are one input among a much broader ingestion estate.

Marker also runs locally, but “open source” is not a complete procurement answer. Its code is Apache 2.0, while its model weights use a modified OpenRAIL license. The published terms permit research and personal use and cover startups below the stated $5 million funding or revenue threshold; larger commercial deployments need separate terms. Legal review should cover the code, weights, optional LLM service, and the way the resulting system will be distributed or exposed.

LlamaParse is a proprietary managed service, not a locally installed open-source parser. LlamaIndex offers secure-cloud processing and a customer-VPC option. A VPC option may satisfy some isolation requirements, but it does not remove the need to confirm region, retention, subprocessors, access controls, incident terms, and the DPA. Those checks precede a benchmark whenever invoices contain employee, supplier, bank, or tax identifiers.

Local execution is not free execution. A self-hosted invoice parser moves cost and accountability into your environment:

• CPU or GPU capacity and scaling
• model and package distribution
• patching and vulnerability response
• telemetry, logs, and alerting
• parser, OCR, and model upgrades
• failed-job handling and human review

The software license governs what the team may do with the component. The deployment model governs where data is processed. The operating model determines who responds when an upgrade changes table reconstruction on a high-volume supplier. Treat all three as gates rather than columns in an accuracy leaderboard.

---

Plausible tables are more dangerous than obvious parser failures

A parser that crashes creates a visible exception. A parser that returns a clean table with one value copied into seven rows creates a finance risk.

In a same-document comparison of Docling, Marker, and LlamaParse, CodeCut processed a six-page academic PDF containing multi-level headers, merged cells, and dense numerical tables. This was not an invoice benchmark, and its timings and outcomes should not be treated as universal tool scores. Its observed failure shapes are still useful test cases:

• Docling hallucinated headers, repeated an identical value down consecutive rows, lost merged cells, and split some names.
• Marker merged columns, packed multiple values into a cell, and corrupted row alignment in borderless tables.
• LlamaParse handled the dense tables best in that document but still produced an occasional hallucinated or duplicated column.

Applied to an invoice, those are not cosmetic Markdown defects. A repeated value may become seven posted line amounts. A merged cell may attach a quantity to the wrong SKU. A shifted row may pair one description with another item's unit price. A hallucinated header may send a number into the wrong field while leaving the final JSON syntactically valid.

Field-level measurement exposes risks that a single accuracy percentage hides. A 2025 invoice extraction evaluation used a curated set of 102 digital and scanned invoices. For that study's particular Docling-based method and dataset, line-item entity accuracy was 58%, while invoice-name and invoice-number accuracy reached 90%. The paper also reported an 80% pass rate on its consistency checks; failures included numerical mismatches, line-item and summary misalignment, and tax-calculation errors.

Those figures are not a score for every Docling release, OCR engine, schema, or invoice population. They show why “invoice number was correct” says little about whether a pipeline is safe for line-level posting. Header extraction, tax breakdowns, totals, and line items need separate measures because their difficulty and financial impact differ.

Provenance helps investigate an error but does not make the extraction correct. A page number and bounding box can take a reviewer back to the source value quickly. They cannot prove that the value was assigned to the right row, interpreted in the right currency, or reconciled with the rest of the invoice.

Benchmark an annotated invoice set field by field

An invoice parser accuracy test should reproduce the documents and decisions the production system will face. A public PDF benchmark can help identify candidates; it cannot set an auto-posting threshold for your suppliers.

1. Build a representative set. Sample across suppliers, digital PDFs, scans, mobile photos, image quality, languages, currencies, page counts, credit notes, multi-tax invoices, borderless tables, and multi-page line items. Keep invoices from unseen suppliers in a holdout set so the test measures generalization rather than familiarity.

2. Create field-level ground truth. Annotate invoice number, vendor, invoice and due dates, currency, net, tax, adjustments, total, and each line-item attribute. Store the source page and region where practical. Have a second person resolve ambiguous labels instead of encoding one annotator's guess as truth.

3. Score errors by type and impact. Separate missing values, wrong values, invented values, duplicate rows, and values assigned to the wrong row. Exact matching may suit invoice numbers; normalized comparison may suit dates and currencies; decimals need explicit tolerances and locale handling. Give posting-critical amounts stricter thresholds than optional description text.

4. Evaluate line items as relationships. Cell accuracy alone misses row drift. Measure expected versus extracted row count, completeness per row, and whether description, quantity, unit price, tax, and line total stayed together. Test continuation pages and repeated headers explicitly.

5. Run business-rule checks. Net plus tax plus adjustments should reconcile with total within the permitted rounding tolerance. The sum of line totals should agree with the relevant subtotal. Dates should be plausible and currencies consistent. Duplicate invoice detection should use more than the invoice number when suppliers reuse or omit references.

6. Measure the operating burden. Record end-to-end latency, page cost, hardware utilization, retries, technical failures, and reviewer minutes. A parser with slightly better field accuracy may still be the worse system choice if it creates an unmanageable review queue or requires scarce GPU capacity.

The practical guide on how to test an invoice extraction pipeline covers the broader harness and regression approach. Every production failure should become a named test case. Rerun the fixed suite before changing the parser, OCR engine, model, extraction prompt, schema, or numerical rules; otherwise an upgrade that fixes one table pattern can silently break another.

Typed output is necessary, not sufficient. You can validate extracted invoice JSON with Pydantic to enforce required fields, decimals, dates, enums, and nested line-item shapes. Add domain validators for arithmetic and relationships, because a value can have the correct type while belonging to the wrong invoice row.

Match the tool to the part of the stack you want to own

Choose Docling when local document understanding and provenance are the priority. It parses many formats into a rich document object, supports multiple OCR paths, and can report parsing, layout, table, and OCR confidence by page. Those scores describe parser stages, not the probability that an extracted tax amount is correct. A Docling invoice extraction system still needs a field schema, arithmetic checks, calibrated review rules, and regression tests.

Choose Marker when you want a local conversion component you can tune. It runs on GPU, CPU, or Apple MPS and emits Markdown, HTML, chunks, or JSON blocks. That makes it useful when an engineering team wants control over OCR, layout processing, and optional model assistance. Its generic JSON is not invoice JSON, and its lack of a documented field-confidence or human-review signal means the surrounding pipeline must supply those controls. Review the model-weight license separately from the Apache 2.0 code.

Choose LlamaParse when a managed parsing service fits the security model. It is designed to handle complex layouts, handwriting, tables, and charts without the team packaging parser models. Page and block bounding boxes, optional confidence, and parse concerns provide useful diagnostics. They do not replace finance-specific validation. Treat schema extraction in the wider LlamaCloud offering as a separate capability from proving that LlamaParse reconstructed a table correctly.

Choose Unstructured when the main problem is broad document partitioning. Its local library turns PDFs, images, Office files, email, and other formats into typed elements. For PDFs, strategy matters: fast processing extracts available text but does not provide the same layout and table path as high-resolution processing, while scanned documents bring local OCR dependencies into the stack. This breadth is valuable when invoices are one document class among many; it also means the invoice extraction layer remains yours to design.

Choose Mistral OCR when you want Document AI behind an API, or qualify for enterprise self-managed deployment. Current Mistral OCR can return structured text, bounding boxes, typed blocks, and page- or word-level confidence across a broad multilingual set. Document annotations apply a supplied schema to produce structured JSON. For Mistral OCR invoice extraction, retain the distinction between OCR confidence, schema-conformant output, and a field that has passed accounting rules.

Non-negotiable	Shortlist first	What remains yours
Local, permissively licensed Python base	Docling or Unstructured	Schema mapping, validators, review, monitoring
Local conversion with tunable model pipeline	Marker	License review, invoice mapping, field-level controls
Managed parsing with secure-cloud or customer-VPC options	LlamaParse	Invoice validation, service governance, review thresholds
Managed OCR plus schema annotations	Mistral OCR	Business rules, exception routing, posting controls
One ingestion framework across many document classes	Unstructured	Document-specific extraction and quality measurement

Versioned feature tables age quickly in this category. The durable shortlist comes from execution location, base output, evidence retained for review, schema path, and the operational controls the team must add.

---

Build the parser stack only if you want to own its failures

A proof of concept proves that a component can process sample invoices. Production requires the team to keep that behavior dependable as suppliers change templates, scans degrade, model packages move, and extraction schemas evolve.

Building is rational when local processing is non-negotiable, the documents or fields are unusually specialized, the team already has document-AI expertise, and the volume or product requirement justifies dedicated infrastructure. That team owns more than the parser:

• OCR selection and language packs
• compute, queues, retries, and failed jobs
• mapping parser output into the invoice schema
• numerical and relationship validators
• provenance and exception-routing interfaces
• monitoring for supplier and model drift
• regression testing before every component upgrade
• staffing the human-review path

Managing those layers gives engineers control over models, deployment, and failure handling. It also means the person on call must diagnose whether a broken total came from OCR, table reconstruction, schema extraction, a validator, or an upstream document change.

A managed service is the more direct choice when the requirement is consistent structured invoice data rather than ownership of document-parsing infrastructure. The Invoice Data Extraction invoice extraction API accepts natural-language prompts or structured field definitions and can return one row per invoice or per line item in XLSX, CSV, or JSON. API results include source-file and page references. When a result needs manual verification, Review Needed warnings identify what to check and the affected output fields or rows; they are review signals, not a promise that downstream accounting controls are unnecessary.

That managed route does not provide local or self-hosted processing, and it should not be described as open source. It removes the need to assemble and maintain the parser, OCR, schema-output, upload, polling, and result-delivery layers. The consuming system still decides which warnings require review, what arithmetic must reconcile, and what conditions permit posting.

Use three facts to make the decision: the deployment model your policy permits, the field-level results on a representative holdout set, and the engineering responsibility your team is willing to retain. If a parser clears the first two but the team cannot own its regressions, it is not the right production architecture.