Invoices, delivery notes and contracts arrive in batches: some as PDFs, some as phone photos, some as crooked scans. A single model cannot cover this well, because there are really three jobs: read the text off an image, understand what the document says, and later find the right document among thousands. A different class of model is best at each job, so a chain of parts costs less and makes fewer mistakes than one large model doing everything.
To a computer a scan is just a grid of dots. A document recognition model turns it into text and, more importantly, keeps the layout: what is a header, what is a table, what is a signature. Drop this part and the next model has to guess from fragments, so numbers drift between table rows. On faded stamps and creased paper, recognition quality sets the ceiling for everything downstream.
Tiny models for the open Docling document converter: they turn a page into markup with tables, formulas and code. Run on an ordinary laptop.
A multilingual document parsing model: text, tables, formulas and reading order in one pass. dots.mocr also turns charts and diagrams into vector SVG.
A compact document parsing model from the popular PaddleOCR toolkit. Per the model card it supports 109 languages, including Russian; version 1.6 leads the OmniDocBench benchmark.
Text on its own is still not data. Here a language model reads the recognised document and sorts it into fields: counterparty, number, date, total, tax rate, line items. It also recognises the type of document from its content rather than from a word in the title. Without this part, staff keep typing details by hand and the gain from recognition is lost on re-keying.
A family of language models with strong Russian language support, from small versions for a laptop to a flagship on par with commercial APIs.
European models focused on speed. Mixtral was one of the first open mixture-of-experts models; there are versions for images (Pixtral, Medium 3.5), Lean proofs and moderation (Shieldstral).
Compact Google models that run well on a single computer; larger versions understand images. Includes CodeGemma for code, FunctionGemma 270M for function calling and the fast DiffusionGemma.
A dedicated table and field extraction model backs up the previous step: it stitches multi-line tables back together and pulls values against a fixed list of fields. That is a cheap way to catch a mismatch before the document reaches your accounting system. Without it, the error shows up later during reconciliation, when fixing it costs more and takes an accountant.
Small models that find tables on PDF and scanned pages and restore their structure: rows, columns, headers. The text inside is read by a separate OCR.
Models for template-based data extraction: give it a document or scan and a JSON field template, get a filled-in JSON back. NuExtract3 (4B) also converts scans to Markdown.
An embedding model turns every document into a numeric fingerprint of its meaning, so search starts matching the intent of a question instead of exact words. Someone asks about a gravel delivery last spring and gets the right paperwork even if it is worded differently inside. Without this step the archive stays a folder people scroll through by file name.
A model for meaning-based search in about a hundred languages. The core of RAG: the bot finds the right part of a document before answering.
Proven models for semantic search. The multilingual versions work well with Russian and are still a reliable base for RAG.
Strong multilingual embeddings with long context; v5-omni understands text, images and audio. Recent versions are open for non-commercial use only.
What usually breaks is the input, not the models: angled photos, copies of copies, stamps over digits. Before rolling out, collect a hundred of your worst real documents and run the chain on those rather than on clean sample PDFs. Plan for disputed cases separately: you need a mode where a document goes to a human instead of quietly landing in the database. Personal data, retention periods and what processing is allowed are described here in general terms only; a lawyer should review your specific case.
An open model can run on your own server: data stays in-house, there is no per-request fee, and the model can be fine-tuned on your documents.
