How to Automate PDF Data Extraction Using Local AI Models Without a Cloud API

The most reliable local PDF extraction workflow is usually a pipeline, not a single AI prompt: first recover trustworthy text and layout from the PDF, then ask a local model to map that content into a strict schema, and finally validate the fields before saving them. Sending every PDF page directly to a vision model can work, but it is often slower, more hardware-intensive, and harder to audit than using native PDF text or OCR when those are sufficient.

This distinction matters if your goal is “no cloud API.” You can still use a local API on your own machine—for example, Ollama’s HTTP endpoint on localhost—without sending document contents to a hosted service. Ollama states that prompts and responses are not sent back to Ollama when models run locally, and it provides a local-only mode that disables cloud features. Docling likewise keeps remote services disabled by default, although model files may still need to be downloaded during setup unless you prefetch them for offline use.

The right stack depends on the PDF. Born-digital invoices with selectable text need a different approach from scanned receipts, complicated financial tables, or image-heavy forms. This guide compares those options and gives a four-stage automation pattern you can adapt to invoices, contracts, purchase orders, application forms, reports, and other recurring documents.

Quick recommendation: choose the pipeline by document type

There is no universal winner. If your documents are predictable and contain embedded text, a parser plus a small local language model may outperform a much larger vision workflow on cost, speed, and reproducibility. If the position of text is part of the meaning—for example, a table with merged cells or a form where labels and values are spatially paired—layout-aware processing becomes more valuable.

Step 1: Classify the PDF before choosing OCR or AI

Start by determining whether the document already contains usable text. Born-digital means the PDF was generated from software and usually contains text objects that can be selected and copied. A scanned PDF may contain only page images, so a normal text parser returns little or nothing.

PyMuPDF’s official documentation shows direct text extraction with page.get_text(). A minimal local test looks like this:

import pymupdf

def extract_native_text(pdf_path: str) -> str:
    pages = []
    with pymupdf.open(pdf_path) as doc:
        for page in doc:
            pages.append(page.get_text())
    return "\f".join(pages)

text = extract_native_text("invoice.pdf")
print(text[:1000])

See the official PyMuPDF basics. PyMuPDF also warns that plain PDF text may not appear in natural reading order and may contain unexpected line breaks. That is a parser limitation, not necessarily an AI problem.

Best fit: invoices, statements, reports, and forms where text copy/paste already works and the fields are easy to identify from nearby labels.

Watch out for: a page can contain a tiny text layer plus a large scanned image. Simply checking whether “some text exists” is therefore not a perfect scan detector. For production automation, inspect representative documents rather than relying on one universal character-count threshold.

Action: take 20–50 representative PDFs and classify them into born-digital, scanned, mixed, and layout-heavy groups. Your pipeline should route by document behavior, not only by file extension.

Step 2: Extract text locally—or OCR only when you need it

Option A: PyMuPDF for clean digital PDFs

If the text layer is reliable, direct extraction is normally the simplest route. It avoids OCR latency and avoids introducing OCR character errors into text that was already encoded correctly. For long documents, you can preserve page separators and process page groups or logical sections rather than passing the entire document to the model at once.

Tradeoff: plain text is cheap and fast, but tables, multi-column pages, headers, footers, and reading order may need extra handling. If those relationships matter to the target fields, move to a layout-aware representation rather than piling prompt instructions onto poor source text.

Option B: OCRmyPDF plus Tesseract for scanned pages

Tesseract is an open-source OCR engine. Its current user manual documents the 5.x series and support for many languages through separate trained-data files. OCRmyPDF wraps OCR around PDF-specific processing so scanned pages can gain a searchable text layer.

For a mixed document where some pages already contain text, current OCRmyPDF versions support a skip mode:

ocrmypdf --mode skip input.pdf searchable.pdf

The official OCRmyPDF advanced documentation explains that --mode skip leaves pages with existing text alone and OCRs the pages that need it. The same documentation describes redo for replacing detected prior OCR and force for rasterizing and OCRing all content. Use force cautiously because rasterization can discard vector advantages and flatten interactive content.

For Tesseract installation, languages, and command-line behavior, use the official Tesseract user manual. OCR language matters: if your invoices contain English and German, for example, install and configure the appropriate language data rather than assuming the default English model will handle both equally well.

Option C: Docling when structure matters

Docling is designed for document conversion with layout, table, OCR, and local vision-language processing options. Its project documentation lists advanced PDF understanding, table structure, OCR, and lossless JSON/Markdown-style outputs, with local execution intended for sensitive and air-gapped workflows.

A basic Python conversion can be as small as:

from docling.document_converter import DocumentConverter

converter = DocumentConverter()
doc = converter.convert("input.pdf").document

markdown = doc.export_to_markdown()
structured = doc.export_to_dict()

See the official Docling quickstart. Docling also supports local VLM pipelines and several OCR backends. Its advanced options explain that remote-service calls require explicit opt-in, while model artifacts can be prefetched for offline use.

Best fit: complex tables, headings, multi-column reports, mixed scans, or cases where you want a reusable document representation instead of a plain text dump.

Tradeoff: the pipeline is heavier than a simple PDF parser. Use it because the extra structure improves your extraction accuracy—not merely because it has more components.

Action: choose the lightest extraction method that preserves the information your target schema needs. Do not OCR clean embedded text, and do not throw away layout when layout determines meaning.

Step 3: Map the recovered content into a strict schema with a local model

Once you have trustworthy source content, use the local model for what it is good at: semantic mapping. Instead of asking, “Extract everything from this invoice,” define the fields you actually need.

For example:

from pydantic import BaseModel
from typing import Optional

class LineItem(BaseModel):
    description: str
    quantity: Optional[float]
    unit_price: Optional[float]
    amount: Optional[float]

class Invoice(BaseModel):
    invoice_number: Optional[str]
    invoice_date: Optional[str]
    vendor_name: Optional[str]
    currency: Optional[str]
    subtotal: Optional[float]
    tax: Optional[float]
    total: Optional[float]
    items: list[LineItem]

Ollama’s current structured-output documentation supports passing a JSON Schema through the format field and validating the response with Pydantic. A local call can look like this:

from ollama import chat

schema = Invoice.model_json_schema()

prompt = f"""
Extract the invoice into the supplied schema.

Rules:
- Use only information present in the source.
- Use null when a field is not found.
- Do not infer missing invoice numbers, dates, tax, or totals.
- Preserve line items individually.

SOURCE:
{text}
"""

response = chat(
    model="gpt-oss",
    messages=[{"role": "user", "content": prompt}],
    format=schema,
    options={"temperature": 0},
)

invoice = Invoice.model_validate_json(response.message.content)

This follows the pattern in Ollama’s official Structured Outputs documentation, which recommends reusable schemas and a low temperature such as zero for more deterministic structured completions.

The model name above is an example from Ollama’s own structured-output documentation, not a claim that it is the best model for every extraction job. A smaller model may be adequate for repetitive invoices with clear labels; a stronger model may help with ambiguous contracts or inconsistent layouts but will generally require more memory and processing time.

Text model or vision model?

Use a text model when the parser/OCR output already preserves the field relationships you need. Use a vision-capable local model when visual position is essential or the text conversion is consistently losing structure. Ollama’s official Vision documentation supports image inputs to local vision models, and its structured-output feature can be combined with vision-capable models.

However, rendering every page to an image changes the tradeoff:

• more pixels must be processed;
• high-resolution pages consume more compute and memory;
• page batching becomes important for long PDFs;
• visual models can still invent a field or misread a number;
• you need a way to trace extracted values back to a page or source region.

Action: start with parser/OCR text plus a schema-constrained local LLM. Escalate only the difficult page types to a local VLM instead of paying the vision cost for every page.

Step 4: Validate before writing JSON, CSV, Excel, or a database

Schema-valid JSON is not automatically factually correct. A model can produce valid fields with the wrong values. The last stage should therefore use deterministic checks wherever possible.

For an invoice, useful checks include:

• Required identity fields: invoice number or vendor name must be present if your workflow needs them.
• Date parsing: parse dates with a fixed policy rather than trusting ambiguous strings such as 03/04/26.
• Arithmetic: compare the sum of line-item amounts with the document subtotal within a defined tolerance.
• Totals: verify whether subtotal plus tax and other charges is consistent with total.
• Currency: do not assume USD because the document is in English.
• Provenance: store the source filename, page number, extraction timestamp, and optionally a hash of the original PDF.
• Review queue: route missing, conflicting, or low-confidence cases for human review instead of silently filling values.

A basic batch structure can separate extraction from validation:

from pathlib import Path
import json

for pdf_path in Path("inbox").glob("*.pdf"):
    source_text = extract_native_text(str(pdf_path))

    # If text is unusable, run your OCR or Docling branch here.
    record = extract_with_local_model(source_text)

    errors = validate_record(record)

    if errors:
        save_for_review(pdf_path, record, errors)
    else:
        output = Path("processed") / f"{pdf_path.stem}.json"
        output.write_text(
            json.dumps(record, ensure_ascii=False, indent=2),
            encoding="utf-8"
        )

The helper functions are intentionally left application-specific because validation rules differ dramatically between invoices, contracts, tax forms, lab reports, and purchase orders. A universal validator would create false confidence.

If you need CSV or Excel, flatten only the fields that actually belong in rows and columns. For documents with repeated line items, it is often cleaner to create one document-level table and a second line-item table linked by a document ID rather than forcing every field into one wide spreadsheet row.

Action: define validation rules before processing thousands of files. Test against a labeled sample set and record field-level accuracy, not just “documents processed successfully.”

A practical fully local architecture

For many small and medium automation jobs, this division of responsibilities is easier to maintain than an all-in-one model:

PDF inbox
   |
   +-- born-digital --> PyMuPDF -------------------+
   |                                               |
   +-- scanned/mixed --> OCRmyPDF/Tesseract -------+--> normalized text/layout
   |                                               |
   +-- layout-heavy --> Docling -------------------+
                                                   |
                                                   v
                                         local LLM / VLM
                                                   |
                                            JSON Schema
                                                   |
                                                   v
                                   deterministic validation
                                                   |
                            +----------------------+----------------+
                            |                      |                |
                           JSON                   CSV             database

This design lets you swap components independently. If OCR quality is weak, improve the OCR layer without retraining the LLM. If the local model is too slow, use a smaller one without changing the PDF parser. If one vendor’s invoices need special table handling, route only those files through Docling or a vision branch.

Ollama vs. llama.cpp vs. Docling VLM: which local runtime should you choose?

The official llama.cpp repository documents a local llama-server and grammar-constrained generation; current server code also accepts JSON schema constraints. Docling’s Vision Models documentation lists local VLM options for document conversion.

Do not select a runtime based only on a model leaderboard. For PDF extraction, the practical measures are field accuracy, throughput per document, memory usage on your machine, failure rate on your layouts, startup complexity, and how easily you can inspect wrong results.

How to keep the pipeline genuinely local

“No cloud API” should be a deployment property you can verify, not just a marketing label.

Ollama

Ollama’s official FAQ says local prompts and answers are not sent back to Ollama. It also documents a cloud-disable setting:

OLLAMA_NO_CLOUD=1

or the equivalent disable_ollama_cloud server setting. Ollama’s local API runs at http://localhost:11434 and does not require authentication for local access, according to its authentication documentation.

Remember that a service bound to localhost is different from one exposed to your LAN. If you change its bind address or place it behind another server, you are responsible for access control.

Docling

Docling keeps remote-service use disabled by default. Its documentation also distinguishes processing privacy from model acquisition: models may be fetched on first use unless you pre-download them. For an air-gapped system, use docling-tools models download on a connected staging machine or otherwise pre-stage approved model artifacts, then point the offline environment to that local artifacts directory.

Action: before processing sensitive documents, block outbound network access at the operating-system or network layer and run a test while monitoring connections. Application settings are useful, but network controls give you an independent verification layer.

What local AI does not solve

Running locally improves data-control options, but it does not automatically make the extraction correct, compliant, or secure. Local files can still leak through debug logs, temporary directories, backups, shared folders, overly permissive services, or copied exports. A local model can also hallucinate values exactly as a hosted model can.

Do not use the model as the only verifier for high-impact fields such as bank account numbers, payment instructions, contract dates, medical values, or regulatory identifiers. For those, compare against source text, apply deterministic validation, and require human review when confidence is insufficient.

How to test before automating a whole folder

Build a small labeled evaluation set containing the cases you actually receive:

• clean digital PDF;
• low-resolution scan;
• rotated or skewed page;
• multi-page invoice;
• table spanning pages;
• missing optional fields;
• different date and number formats;
• at least one deliberately difficult document.

For each target field, compare extracted value with ground truth. Measure exact match for identifiers, numeric tolerance for amounts, and row-level accuracy for line items. Also record processing time and the percentage of documents sent to manual review.

If a simpler PyMuPDF-plus-LLM path reaches your required accuracy, keep it. If scans are the main failure, improve OCR. If table relationships are the problem, test Docling. If visually positioned fields remain hard, route that subset through a local vision model. This staged escalation usually gives you better control over speed and hardware use than applying the heaviest model to every page.

Bottom line

A good local PDF extraction system separates document reading from semantic extraction. Use PyMuPDF when the PDF already contains good text; OCRmyPDF/Tesseract when the page is scanned; Docling when structure and tables matter; and a local Ollama or llama.cpp model when you need flexible mapping into a business schema. Use local vision only where visual layout adds information that the text pipeline cannot preserve reliably.

The final requirement is validation. JSON Schema can constrain the shape of a model response, but it cannot prove that the amount, date, name, or account number matches the source. If you design the pipeline so uncertain documents are visible and reviewable, you can automate a large fraction of PDF data extraction without handing the documents to a cloud API—and without pretending that local AI removes the need for quality control.