Intelligent Document Processing: Pipeline, Accuracy and Human Review (2026 Guide)

What intelligent document processing actually is

Intelligent document processing (IDP) is software that takes documents in whatever form they arrive, such as scanned PDFs, phone photos, email attachments and native PDFs, and turns them into validated, structured data that another system can use. The word that matters is validated. Reading text off a clean page has been a solved problem for years. The hard part is knowing which extracted values are right, sending the doubtful ones to a person, and being able to show where every number came from.

This guide describes the pipeline we build, where OCR engines still beat large language models and the reverse, how to measure accuracy so the number means something, how to design the human review step and how to keep one customer's documents away from another's. The examples come from two products we built: Edge OCR, a multi-tenant document processing SaaS, and GovDoc AI, which extracts 50+ data points from each government contract it reads.

The seven stages of an IDP pipeline

Two rules apply to every stage. Keep the original file and every intermediate output (text, coordinates, the raw model response), so you can re-run a later stage without paying for an earlier one again and can answer the question "where did this number come from?" months later. And run every stage as a queued, idempotent job, so a retry never creates a second invoice in the customer's accounting system.

How Edge OCR handles the queue

In Edge OCR, documents move through three Redis queues: a processing queue, an in-flight queue that stops two workers picking up the same job, and a dead-letter queue for jobs that have used up their retries. Bulk uploads go straight to S3 through presigned URLs, so large files never pass through the API servers, and OCR runs on AWS Lambda. Failures are captured for retry rather than dropped. That matters more than it sounds: if a customer drags in a folder of two thousand files and a handful fail, they need to see exactly which ones and press retry, not open a support ticket.

OCR engines vs LLM extraction

The main design choice in 2026 is how much to give to a multimodal LLM. Cloud OCR services return text with a bounding box and a confidence score for every word, at a predictable price per page. Models such as Claude and Gemini read the page image or its text and return fields that match a schema, cope with layouts they have never seen and understand context, such as "the amount due, not the subtotal". They fail in different ways.

What we build in practice is a hybrid. OCR, or the native PDF text when it exists, produces text with coordinates. The LLM extracts fields from that text against a JSON schema and must return, for each value, the page number and the source text it read. Code then checks that the cited text really exists on that page. A value whose citation cannot be found is flagged for review, which catches most invented values before anyone sees them. Edge OCR combines template-based and free-form extraction with AWS Bedrock for document understanding and Adobe PDF Services for complex PDFs. GovDoc AI uses PyMuPDF to extract text, Cohere embeddings and OpenSearch to find the relevant passages, and Claude on AWS Bedrock for structured extraction, with page-level references for every extracted value in its paid tier.

If your documents are long and the questions are open ("what are the termination rights?"), you are closer to retrieval than to form extraction; our pages on RAG development and AI contract analysis software cover that end.

Measuring accuracy at field level

"98 percent accurate" in a vendor demo usually means character accuracy on clean scans. It says nothing about whether your invoice totals or policy numbers are right. Measure at the field level, on your own documents:

1. Build a golden set: a few hundred real documents covering every type, sender and quality level you receive, with the correct value for each field keyed in by hand and checked by a second person.
2. Normalise before comparing: dates to ISO format, amounts to decimals, whitespace and currency symbols stripped. Otherwise you are measuring formatting, not extraction.
3. Score precision and recall per field. Precision: of the values the system returned, how many were right. Recall: of the values that exist on the page, how many it found. A missing value and a wrong value are different problems with different fixes.
4. Track the straight-through rate: the share of documents where every field passed validation and nobody touched it. This is the number the business case depends on.
5. Break every metric down by document source and scan quality. An overall average hides the one supplier whose invoices always fail.

Re-run the golden set automatically on every change to a prompt, model, template or validation rule, and block the release if a field gets worse. GovDoc AI's three-pass design is aimed at recall on long, poorly structured contracts: an initial extraction, an evaluation audit that looks for missing sections, and a gap-filling pass that extracts them. A second pass that looks specifically for what is missing is often cheaper than moving to a bigger model.

Designing the human review step

• Route by field, not by document. Show the reviewer the three doubtful fields, not all forty.
• Set the review threshold from the golden set. Pick the confidence or rule threshold at which errors stop slipping through, and accept that it sends some correct values to review.
• Show the evidence. Put the page image beside the form and highlight the box the value came from; a reviewer should confirm a value in a few seconds without scrolling.
• Design for the keyboard. Reviewers handle hundreds of documents a day: tab between fields, Enter to accept, shortcuts to jump to the next flagged item.
• Log every change: who, when, old value, new value. Feed corrections back into the golden set and the prompt or template.
• Check the checkers. Sample accepted documents for a second review and watch for reviewers who accept everything.
• Make review depth a setting per customer. Regulated customers often want every document reviewed; others want straight-through processing with a sample check.

In Edge OCR, non-technical users edit extracted values and export results without engineering help. In GovDoc AI, every value in the deep analysis carries a page reference, so a reviewer can check it at the source instead of re-reading a contract that runs to hundreds of pages.

Multi-tenant isolation for document data

Documents carry some of the most sensitive data a company holds: bank statements, contracts, medical forms, IDs. In a multi-tenant product, the isolation model is a design decision, not a detail. Both Edge OCR and GovDoc AI use a database per tenant. Edge OCR gives every organisation a dedicated MongoDB database, with dynamic model loading, per-tenant connection pooling and a circuit breaker on connections. GovDoc AI provisions a dedicated MongoDB database and S3 bucket automatically for every account. Our multi-tenant SaaS architecture guide compares this with shared-schema and row-level security designs.

Build, buy or combine

Buy when your documents are common types (invoices, receipts, IDs, bank statements) and a prebuilt model plus a no-code review screen covers the workflow. Build when the documents are specific to your domain, when extraction is the product you sell, or when the value is in the review screen, the validation rules and the integration with your own systems. Most of our projects combine the two: a cloud OCR service underneath, an LLM for extraction, and custom code for validation, review, tenancy and export.

Where to start

1. Collect a few hundred real documents and agree the field list with the person who uses the data today.
2. Run two or three engines (for example a cloud OCR prebuilt model and an LLM with a schema) over the same golden set and compare field precision, recall and cost per page.
3. Build validation rules and the review screen before polishing extraction; they decide how much the system can be trusted.
4. Pilot with one team and one document type, measure the straight-through rate for a month, then add types.

For budgets, read what AI document processing costs to build and run or open the document processing preset in the calculator. For the service itself, see AI document processing and our wider AI and data services.