Document processing that reads, extracts and checks before anything is posted
Turn forms, scans, PDFs and emailed attachments into validated records in your systems, with every low-confidence field routed to a person and every value traceable to its source page.
Keying documents by hand is slow, and the errors travel
Application forms, delivery notes, claims, identity documents, lab reports, purchase orders: most organisations still have people reading them and typing the contents into a system. Volume peaks create backlogs, and the mistakes made at the keyboard surface weeks later as wrong payments, failed deliveries or compliance findings.
Template-based OCR tools helped with a few fixed layouts and broke on everything else. Vision-capable language models read any layout, but on their own they are confident when they are wrong. The engineering is in the validation and review around the model, not the model itself.
How it works
From inbox or scanner to a validated record
Each extracted field carries a confidence score and a pointer to the source page. Validation rules catch the errors a model cannot see, such as totals that do not add up; the reviewer only sees what failed.
1. Classify and prepare
Incoming files are split into documents, each page classified by type, rotated and cleaned. Unknown types go to a holding queue rather than being guessed.
2. Read and extract
A vision-capable model reads the page as a human would, including tables, stamps and handwriting, and fills the schema you defined. Each value is returned with its location and a confidence.
3. Validate and route
Deterministic rules check formats, arithmetic and reference data. Documents that pass post directly. Fields that fail or score low wait for a reviewer, whose correction improves the next run.
What you get
A pipeline your operations team can run
Intake connectors
Shared mailboxes, SFTP drops, scanner folders, web uploads and portal downloads, each producing the same normalised document object.
Schema-driven extraction
One schema per document family, versioned in code, with field types, allowed values and the validation rules that apply. Adding a field is a configuration change, not a project.
Review workstation
A side-by-side screen showing the source page and the extracted fields, with flagged values highlighted. Keyboard-driven, built for people who process hundreds of documents a day.
Labelled eval set and dashboard
A few hundred of your real documents, labelled during discovery, scored per field on every release. The dashboard shows straight-through rate, review load, accuracy and cost per document.
Downstream integration
Validated records written to your ERP, database or case system through its API, built with our AI data engineering practice, with the source document linked for audit.
Guardrails we build in
Accuracy thresholds: a target per field, agreed before the build and measured on your labelled set; a field below its confidence threshold never posts unreviewed. Human-in-the-loop: reviewers see only flagged fields, and a sample of straight-through documents is spot-checked each week. Audit trail: every record links to the source page, the model version, the confidence and any reviewer correction. PII handling: identity documents and personal data are masked in logs, processed in your chosen region and deleted on your schedule, as set out in AI data privacy. The full control set is described under AI security and governance.
Typical rollout
Shadow the manual process, then replace it
Sample and label (2 weeks)
Collect a representative batch per document family, define the schema with the people who key the data today, and label the eval set.
Extract and validate (3–4 weeks)
Build classification, extraction and validation rules. Iterate on prompts and rules until each field meets its target on the eval set.
Shadow run (2–3 weeks)
The pipeline processes live documents in parallel with the manual team. Differences are reviewed daily and thresholds adjusted.
Switch over (1–2 weeks)
Straight-through posting enabled for passing documents, review queue goes live, operations team trained and runbooks handed over.
Illustrative example
What a first release usually looks like
Illustrative scenario, not a client case
A logistics operator receives proof-of-delivery notes, customs forms and damage reports from hundreds of drivers and partners as photos and scanned PDFs. A back-office team keys the reference numbers, quantities and signatures into the transport system, and billing waits on them. The first release covers proof-of-delivery notes only. During the shadow run, clean printed notes pass validation and post automatically; photographed notes with handwritten quantities are flagged more often and go to the review screen. The team keeps the reviewers, who now handle exceptions instead of everything, and billing runs daily instead of weekly. Customs forms become the second document family once the first is stable.
It depends on the document type, scan quality and how strict your validation rules are. We do not quote a blanket figure. We agree a target per field before the build, measure it on a labelled sample of your real documents, and route any field below its confidence threshold to a reviewer. Accuracy on clean, consistent forms is usually high; on mixed handwritten scans it is lower and the review queue is busier.
Do we need to train a custom model?
Rarely at the start. Current vision-capable language models read layouts, tables and handwriting well enough for most business documents with a schema and good prompts. We only add fine-tuning or a dedicated model when the eval set shows a specific document family falling short, as covered in fine-tuning and evals.
Can it handle documents in several languages?
Yes. The models we use read the major European and Asian languages, and the schema is language-independent. Validation rules such as date formats and currency symbols are set per locale.
What happens to the original documents?
They are stored in your document store with a link from every extracted record, so an auditor can open the source page for any field. Retention and deletion follow your policy, and personal data in scans is handled as described in AI data privacy.
How long does an IDP project take?
Six to ten weeks for a first document family in production: two for discovery and labelling, three to four for build and evaluation, and two to four for a shadow run against the existing manual process before switching over.
Ready to make AI work in production?
Tell us about your systems, your data and your constraints. We reply within one business day with a straight answer and a suggested next step.