"Every queue that moves slowly has a stack of paper at the front of it, and a person typing what is already written there into a box on a screen."
A loan, a claim, a customs release and a hospital admission all wait on the same step: someone has to read a document and copy what it says into a system. That step is where days are lost and where mistakes enter.
LEKTA reads documents — printed, handwritten, photographed or scanned — and returns them as structured fields that a system can accept without a person retyping anything.
Identity documents, receipts, contracts, delivery notes and government forms arrive on paper or as a photograph of paper, and no amount of digital transformation upstream changes what lands on the counter.
Throughput is set by how many people are typing, so a busy day becomes a backlog rather than a faster day, and the cost of handling a document barely falls no matter how many are handled.
A total is a total because of where it sits on the page. Plain text extraction throws that away, returning words in reading order and leaving a person to work out which number belonged to which row.
Reading tools are strongest on the languages and layouts they were built around. Elsewhere — mixed scripts, local forms, unusual typefaces — accuracy drops exactly where staffing is already thin.
Modern document models look at the page and produce structured text directly, instead of chaining together separate detection, recognition and assembly stages that each pass their errors down the line.
Tables, columns, stamps, signature blocks and headers are recognised as what they are, so a row stays a row and a total stays attached to the line it totals.
Once a page is text, it can be indexed and searched by meaning rather than by exact wording, which is what turns a pile of processed documents into something a person can actually ask questions of.
Models are held and served on infrastructure the customer controls, because identity papers, medical records and financial documents are frequently not allowed to leave the building at all — and where the hardware is modest, the smaller models run on it rather than demanding a data centre.
Identity cards, passports, licences, certificates and registry extracts — the documents that open an account, clear a shipment or register a person, where a single wrong character stops everything.
Merchant, date, line items, tax and total, pulled from a printed invoice or a crumpled photograph of a receipt and returned as the fields an accounting system expects.
Application forms, manifests, ledgers and statements, returned with the structure intact so that a row in the document arrives as a row in the data rather than as a paragraph.
Filled-in forms, annotated pages, faxes, faded carbon copies and photographs taken at an angle in bad light — the material that plain extraction tools quietly fail on.
Stamps, seals, signature blocks, passport photographs and pasted-in images are part of what makes a document valid. They are found and marked as regions of their own rather than skipped over on the way to the words.
The image is straightened, cropped and corrected for lighting, multi-page files are split, and pages too damaged to read are rejected at the door rather than guessed at further down.
The cleaned page goes through the document models, which return the text together with where on the page each piece of it came from.
Recognised text is matched against the shape of the document type — this is the invoice number, this is the expiry date, these rows are line items — producing named fields instead of loose text.
Fields are validated against formats, checksums and arithmetic that should balance, anything doubtful is flagged for review, and the accepted result is posted into the customer system.
Documents arrive by upload, scanner, camera or batch drop, and every one is registered with its source and arrival time before anything is done to it.
Reading models are held separately from the document types they serve, so supporting a new form is a new mapping rather than a new pipeline.
The rules that turn recognised text into named fields live in one spot per document type, which is what makes a change reviewable instead of scattered through code.
Processed documents are indexed so they can be searched and cited afterwards, because reading a document once is worth much less than being able to find it again.
Output leaves as structured records through an API, and every field keeps a link back to the page and the position it was read from, so any value can be traced to its source.
A field is never delivered as a bare value. How certain the reading was travels with it, which lets a customer route the doubtful ones to a person and accept the rest automatically.
The image and the exact spot a value was read from are kept with the record, so a disputed number is settled by looking rather than by arguing about what the system decided.
Dates that cannot exist, totals that do not add up, identifiers that fail their check digit — these are caught by arithmetic after reading, because a model can be confident and wrong at the same time.
Where a document carries legal or financial weight, the flagged cases go to a person before anything is committed, and the system is built to make that review quick rather than to design it away.
DeepSeek-OCR-2, PaddleOCR-VL-1.6, GOT-OCR2_0 and GLM-OCR — vision-language models that read a page and return structured text. These are the core of how LEKTA reads, and holding several means a difficult document type can be routed to whichever handles it best.
Florence-2 for detecting and describing regions of a page, SAM 3 for cutting out a stamp, a photograph or a table as a region of its own, and siglip-so400m-patch14-384 as the vision backbone underneath — the parts of a document that are not text at all.
bge-m3 and Qwen3-Embedding-8B for indexing processed documents by meaning, bge-reranker-v2-m3 to order the results before they are shown, and qdrant to hold the index itself.
vllm for serving the larger models, llama.cpp where the hardware on site is modest, and transformers with accelerate for loading and running the rest — the pieces that let the whole system sit inside a customer network rather than outside it.
NOCKË PAY needs receipts and identity documents read at the moment of a transaction, not hours later, and the same reading layer serves any part of ÁRKMORA where a customer arrives holding paper.
Banks and lenders opening accounts and assessing applications, government offices processing forms, logistics operators clearing shipments, and insurers handling claims that arrive as photographs.
We have not yet published accuracy figures from our own bench. Until those runs are done and recorded on documents of our own choosing, this page describes what the system is built to do, not how well it scores.
More document types mapped, more scripts and local forms covered, and field trials with the organisations whose queues actually run on paper — because the only test that counts is a real morning at a real counter.
"A document already contains the answer. The work was never in knowing it — only in reading it fast enough to matter."
LEKTA — Document Intelligence & OCR.