Local PDF processing helps businesses receiving orders, forms, delivery documents, contracts or technical files that are difficult to search. The aim is to turn them into verifiable fields and records. A sound project separates document reading, AI interpretation and data validation before information enters business applications.

Identify document types before choosing a model

A PDF containing selectable text, a scan and a photograph of a page have different characteristics. Check for native text, page orientation, tables and columns. One file may combine text pages with scanned images. The import workflow must recognise these situations and retain the original document.

Choose frequently used document families for the pilot and define their required outputs. An order may require customer, product codes, quantities and currency. A form may require field names and selected values. Separating families helps define rules and build trials covering the files' actual structure.

Three reading paths

  1. Text PDF

    Native extraction and structure checks.

  2. Scan

    OCR and recognised-text verification.

  3. Mixed document

    Select the appropriate path for each page.

Retain the original for field verification.

Build a local extraction workflow

For text documents, extract structure and check reading order. Add OCR for scans. Docling provides document-processing components and options for local model use, including preparing artefacts before disconnecting from the internet. Select models and OCR engines according to their own licences and requirements.

A workstation with 32–64 GB RAM and an SSD provides a business pilot assessment profile for processing stages. If a local vision model is added, size its memory and context separately. Scheduling stages sequentially can avoid loading every model on the same GPU simultaneously. Measure processing capacity using the selected batch and formats.

Professional checking paperwork and using a calculator
Mikhail Nilov

Preserve the page and information location

Link extracted text to the original document, page and, where available, position on the page. For tables, retain the relationship between header, row and column. A quantity moved onto the neighbouring product row can pass a superficial format check yet create the wrong order. Assessment must follow that correspondence.

Test rotated pages, stamps, small text, repeated headings and attachments separately. A footnote can change a field's interpretation. Route incorrectly processed documents to review and retain the reason. Operators must be able to compare a proposed value with the relevant area of the original.

Define a data schema before interpretation

The schema defines fields, types, permitted values and treatment of missing information. A demonstration order might contain identifier DEMO-01, quantity 2, unit price 125.00, total 250.00 and currency EUR. These values illustrate an arithmetic check rather than customer data.

A local model can receive relevant text or images and the output schema. Ollama documents structured outputs through the request's format field. The application then validates the returned response. Handle missing required fields, disallowed currencies or unknown identifiers through application rules before sending data onwards.

An illustrative validation example

  1. Input

    Two units at EUR 125.00 each.

  2. Calculation in code

    2 × 125.00 = EUR 250.00.

  3. Comparison

    Check the extracted total against the calculation and original.

Illustrative example: extracted fields are validated by calculation and compared with the original.

Separate reading a value from validating it

The engine can recognise a character sequence, while the model proposes its meaning. Validation establishes whether the value matches the document and business rules. Keep quantity and unit of measure separate: two boxes do not automatically become two individual items. Conversions require a catalogue rule and a verifiable reference.

Perform calculations in code using representations appropriate to monetary values and required precision. Compare line totals with the document total and explicitly define rounding tolerance. Retain the original field text alongside the normalised value. For calendar dates, document input format separately from storage format.

Integrate results with duplicate control

Before import, check whether the document has already been processed. A file hash and business identifiers can help detect duplicates, with rules for corrected editions. Assign every processing job an identifier and status. Retrying a task must be able to resume the case without creating an additional CRM order.

For initial batches, an operator confirms fields before saving. Following evaluation, the business can define which cases pass automatically and which exceptions require review. Enforce and log those criteria technically. Changing a model, template or normalisation rule triggers a trial against reference documents.

From proposal to saved record

  1. Extract

    Text, fields and page references.

  2. Validate

    Types, catalogue, calculations and duplicates.

  3. Review

    An operator checks defined exceptions.

  4. Save

    One identifiable operation in the application.

Saving and recovery rules belong to the application.

Acceptance covers fields and complete documents

Check fields individually and also check documents containing no critical errors. Good performance on frequent fields can conceal a problem with product codes or quantities. Include different layouts, image quality levels, duplicate documents and files that must be rejected. Record processing time and operator review time.

An import-trial record

Prepare a reference batch containing originals and operator-completed expected fields. For every output, retain the file identifier, processing version and source for each field. The operator sees proposed values alongside the relevant page and can correct them without losing the initial extraction. Review records identify changes and who approved import.

Repeat the trial with the same file, a renamed copy and a corrected document edition. The system must apply its defined duplicate or version rule to each case. Next test an incomplete file and a document exceeding the accepted page limit. Rejection must be identifiable, and the document recoverable through the defined procedure without a hidden partial record in the target application. Keep all these cases in the acceptance set so later extraction changes are checked against the same expectations.

WebHat uses a customised local AI system and provides consultancy on document processing and integrating data into business work. A business automation project with AI can connect import to CRM or inventory management. Permissions, file retention and access to extracted results are designed alongside application data protection.

Questions about PDFs and extracted data

Does every PDF require OCR?

PDFs with native text can be processed directly. Scans require text recognition, and mixed documents may need both paths on different pages.

Does a vision model replace checking totals?

Calculations and acceptance rules run in code. Model output is a structured proposal checked against the document and business rules.

How do we avoid repeatedly importing the same order?

Identify both the file and business document, retain processing status and use a save rule recognising a resumed operation.

Which documents belong in the first pilot?

Frequent, representative families with human-verified reference results. Add difficult cases to define the review path clearly.