Reading the text was
never the hard part.

Document processing is turning incoming documents (invoices, forms, contracts, statements, scans) into data a business can use: sorting them, reading the fields, checking them and filing the result in the right system. Intelligent document processing adds AI so it can cope with layouts it has not seen before, and with documents that mix text, tables and handwriting. What matters in practice is not the reading but the checking: confidence scores, validation against your rules and a person reviewing anything uncertain.

Outsourced data entry sends documents to a vendor whose staff key the values by hand. Here the reading is done by software inside your own systems, every field is checked against your rules, and only uncertain items go to a person. It is usually faster and keeps your documents in your environment, but a team of people can still be the better answer for rare or highly irregular documents, and we will say so.

No, and the distinction is the entire point of this page. OCR turns pixels into characters, which is the part that has largely been solved. What has not been solved is turning a document into data you can rely on: working out what the document is, whether it is a duplicate or a superseded draft, whether the table on page four continues from page three, whether the totals actually reconcile, which fields are uncertain enough to need a person, and how to keep provenance so a number can be defended a year later. In our experience the extraction step is rarely where a document pipeline fails. It fails at classification, validation or structure — all of which sit either side of OCR.

Most production pipelines in 2026 run both, and that is what we build. Multimodal models — Gemini, GPT-4o, Claude and similar — measurably outperform classical OCR on degraded scans, complex tables and handwriting, by roughly ten to fifteen accuracy points on difficult inputs. Classical engines such as AWS Textract, Google Document AI and Tesseract remain better on clean, consistent, high-volume documents where speed, cost and deterministic output matter more than handling the awkward cases. Routing each document to the right engine, and reconciling when they disagree, is a large part of the engineering. Anyone telling you it is one or the other is selling the one they have.

Not a number, and you should be wary of anyone who offers one before seeing your files. Published benchmarks predict remarkably little about real documents, because the characteristics that break extraction in practice — layout complexity, handwriting, references across pages, varying scan quality and domain-specific conventions — are precisely what standard evaluation sets avoid. What we will commit to is measured on your documents: we run a sample, report per-field accuracy on your actual files, and agree thresholds from that. A pipeline that is 99% accurate on the fields that do not matter and 90% on the one that does is a bad pipeline with a good headline.

That is normal and it is worth correcting a common piece of shorthand: mainstream OCR engines have supported a hundred-plus languages for years, so language alone is rarely the blocker. What actually causes trouble is the combination — a regional script in an unusual layout, at poor scan quality, with domain conventions no general model has seen, and often mixed languages within one document. We handle those together rather than treating language as a checkbox, and where a document is translated we keep the original alongside so a reviewer can always see what the source really said.

It means the documents can be retrieved from and cited, not just stored. In practice: classified and organised into a schema that reflects your business, chunked in a way that respects the document's own structure rather than cutting tables in half, indexed so a query returns the right passage, and carrying enough provenance that an answer can point to a specific page of a specific version. Most "we put our documents into AI" projects fail at exactly this layer — the files were uploaded, but nothing was structured, so the AI answers confidently from the wrong version of a contract.

At the start, more than people expect — and that is deliberate, because early review is how thresholds get calibrated on your real documents rather than on an assumption. It then falls as validation rules tighten and corrections feed back. It does not go to zero, and we would be suspicious of a system that claimed it had: some documents genuinely are ambiguous, and the right behaviour is to surface them. The number we care about is how much of the queue is genuine ambiguity rather than the same avoidable failure arriving every month.

It starts with your documents, not a workshop. Send a representative sample — deliberately including the worst ones, because those decide the architecture — and we will tell you where a pipeline would break, what per-field accuracy looks like on your actual files, and which parts are worth automating. That produces a scope, a definition of what counts as working, and a fixed price before any build starts.