Intelligent document processing on AWS: turn documents into structured JSON.
Intelligent document processing (IDP) turns invoices, contracts, claims, statements and forms into a clean JSON record per document. This guide covers the three AWS extraction engines and when each wins, the five-stage pipeline, tables and handwriting, confidence and human review, and cost at scale.
- Intelligent document processing on AWS turns each document into a JSON record that matches a schema you define. The pipeline is always five stages: ingest to S3, parse to layout-aware text, extract to your schema, validate against rules, and send low-confidence records to a person before they commit.
- Three engines do the extracting. Amazon Textract is cheap, fast and deterministic on known forms and tables. Amazon Bedrock Data Automation (BDA) uses blueprints that work across many layouts. A Bedrock model with structured output handles documents that need reasoning or derived fields, at a higher cost per document. Most production systems combine them.
- Accuracy comes from confidence scores, validation rules and human review (Amazon A2I), not from a perfect model. At scale, run extraction as batch: AWS prices Bedrock batch 50% lower than on-demand for select models.
IWhat intelligent document processing is
IDP turns the documents a business receives into structured data software can act on. The deliverable is a record, not text: a JSON object whose fields match a schema you defined in advance.
An accounts-payable system does not want a PDF; it wants { "invoice_number": "INV-10432", "vendor": "Acme Ltd", "total": 4820.00, "currency": "USD", "due_date": "2026-07-15", "line_items": [...] }. IDP closes that gap reliably, at volume, from documents that vary in layout and quality.
The schema is what makes it work. A generic "read this" call returns text. A schema-driven call returns named, typed fields in a fixed shape, so the record drops into a database or ledger with no re-keying.
IDP is not document Q&A or RAG (asking a corpus questions) and not plain OCR (characters on the page). OCR is one possible step inside an IDP pipeline.
The hard part is the long tail: the same invoice type in hundreds of vendor layouts, tables that span pages, forms with labels in different places, scans, photos and handwriting.
IIThe three engines: Textract vs Bedrock Data Automation vs LLM with schema
Your pipeline's architecture follows from which engine (or mix) does the extracting. Each wins a different part of the problem.
Amazon Textract: OCR, forms and tables
Amazon Textract does OCR on scanned and photographed pages, and has dedicated features for forms (key-value pairs), tables (cells with row and column positions), signatures and queries (ask "what is the total?" and get the value with a confidence score). Specialized analyzers handle invoices and receipts, IDs and lending documents.
Strengths: speed, low and predictable per-page cost, and deterministic output. Limit: weaker on highly variable or reasoning-heavy documents. Use it for high volume on known document types, and as a cheap parse step before an LLM.
Amazon Bedrock Data Automation: managed generative extraction
BDA turns unstructured content into structured output through one API. You define a blueprint naming the fields you want, each described in plain language with a type, plus optional normalization and validation. Because BDA reads with a model, one blueprint can cover many layouts of the same document type. AWS ships sample blueprints for invoices, receipts, IDs and bank statements.
Use it for production extraction of named fields when formats vary by sender and you want a managed service. It costs more per page than Textract. See the Bedrock Data Automation page.
LLM with schema: a Bedrock model plus structured output
A Bedrock foundation model (Claude, Amazon Nova, Llama, Mistral) is prompted to extract data and constrained to your schema through structured output: tool use or a JSON-schema-constrained response, so the output conforms. Feed it text already parsed by Textract or BDA.
It is the most flexible engine. It handles contracts that need interpretation, judgement calls ("credit note or invoice?"), derived fields ("total tax across line items") and rare document types. Trade-offs: higher cost per document, more latency, and a need to guard against invented fields with grounding and validation. Use it for the reasoning tail.
Textract for high-volume known types. BDA for named fields across varying layouts, managed. An LLM with schema for documents that need reasoning or derived fields. Most systems route by document type and often chain them: Textract or BDA parses, the LLM reasons.
IIIThe IDP pipeline on AWS, stage by stage
Ingest, parse, extract, validate, human review. The stages around the engine are what make a system you can trust with payments or compliance.
1. Ingest. Land originals in Amazon S3 (uploads, email via SES, upstream systems). Keep them so every field traces back to its source page. An S3 event starts the pipeline through EventBridge, Lambda or Step Functions.
2. Parse. Turn each document into clean, layout-aware text: OCR scans, keep table structure, read multi-column pages in order. Clean parsed input is the biggest quality lever for an LLM. For BDA blueprints and Textract analyzers, parse and extract are one call.
3. Extract. Map content to your schema with a Textract analyzer or query, a BDA blueprint, or an LLM with structured output. Every field should come back with a confidence score.
4. Validate. Schema validation (required fields present, correct types and formats) and business validation (line items sum to the subtotal, dates plausible, vendor exists in master data). A failing record never commits silently.
5. Human review. Route low-confidence or failed records to a person and auto-commit the rest. Amazon Augmented AI (A2I) provides review workflows with a worker UI, integrates with Textract, and lets you set the confidence threshold. Corrections become labeled data.
| Stage | What it does | AWS services | Output |
|---|---|---|---|
| 1. Ingest | Store originals, trigger the pipeline | S3, EventBridge, Lambda, Step Functions | Document in S3 plus an event |
| 2. Parse | Layout-aware text and tables | Textract, Bedrock Data Automation | Structured text, tables, key-values |
| 3. Extract | Map to your JSON schema with confidence | Textract, BDA blueprints, Bedrock LLM with structured output | Schema-shaped JSON |
| 4. Validate | Schema and business rules | Lambda or Step Functions | Pass/fail and flagged fields |
| 5. Human review | Review low-confidence or failed records | Amazon A2I | Confirmed or corrected record |
IVTables, forms and handwriting
These three inputs break naive extraction, each in a predictable way.
Tables
A table read as flat text loses its row and column links. Use Textract's table extraction or BDA, which keep structure. Serialize tables as Markdown or one record per row for an LLM. Map rows to a line_items array and check that they sum to the stated subtotal.
Forms
Textract returns key-value pairs, and Queries fetch a specific value with a confidence score. Use BDA blueprints for variable forms and an LLM for ambiguous ones. Rule: known forms → Textract; variable forms → BDA; ambiguous forms → LLM.
Handwriting
Textract reads handprint, and BDA and multimodal models can too, but accuracy is lower. Treat handwritten fields as low-confidence, isolate them in the schema, and let the threshold route them to review. Then only the handwritten fields trigger review, not the whole document.
VAccuracy and confidence
A production system knows, per field, when it might be wrong. Confidence scores, validation and human review together let you auto-commit most documents safely.
Confidence scores. Textract attaches a confidence to each value; BDA returns confidence metadata; an LLM can be asked for one or have it derived. Set a threshold per field (or per importance class) and route anything below it to review.
Validation. Confidence catches fields the model is unsure about; validation catches fields it is confidently wrong about. You need both. Cross-field checks ("do the numbers reconcile?") are among the most valuable rules you can write.
Human review with A2I. Define a worker UI, a workforce (your team, a vendor or Mechanical Turk) and triggers: a confidence threshold, failed rules and a random sample. Reviewing a sample of auto-committed records shows whether thresholds catch real errors.
Measure. Build a golden set of a few hundred hand-verified documents. Track field-level accuracy, document-level accuracy and the auto-commit rate at your error budget. That turns engine choice and threshold setting into an experiment with an answer.
VICost at scale, and why batch changes the math
A pilot costs little. At hundreds of thousands of documents a month, engine choice, auto-commit rate and batch processing dominate the bill.
Four parts: extraction (Textract per page by feature, BDA per page with a premium for blueprints, an LLM per token), parsing if separate, human review (reviewer time per flagged document), and storage and orchestration. Check current rates on the AWS pricing pages.
Batch is the big lever. Most IDP is not real-time, and AWS prices Bedrock batch inference 50% lower than on-demand for select models. Textract's asynchronous APIs are built for large multi-page jobs. Unless a document needs an answer in seconds, run it as batch. Also route each document to the cheapest engine that handles it, and raise the auto-commit rate so review cost grows slower than volume.
| Cost line | Driver | Main lever |
|---|---|---|
| Extraction | Pages or tokens × engine | Cheapest engine per document type; batch |
| Parsing | Pages processed | Parse once, reuse the text |
| Human review | Flagged documents × reviewer time | Better validation and thresholds; isolate handwritten fields |
| Storage and orchestration | Volume and pipeline runs | S3 lifecycle rules; lean retries |
VIIA step-by-step build outline
Define the contract first, prove the engine on real documents second, then add validation, review and scale.
- 1. Define the target JSON schema: Field names, types, required vs optional, formats and the line-item shape. Everything else targets this contract.
- 2. Gather a representative document set: Include the messy ones. Hand-label a golden subset of a few hundred.
- 3. Stage documents in S3 and trigger the pipeline: S3 event to EventBridge or Lambda, with Step Functions orchestrating.
- 4. Prove the engine on real documents: Run Textract, a BDA blueprint and an LLM with schema on the golden set. Compare accuracy, confidence behavior and cost per document. Pick the cheapest that clears the bar per type.
- 5. Lock structured output and confidence: Analyzer, blueprint or tool-use schema, so output cannot be malformed. Every field carries a confidence score.
- 6. Add validation rules: Schema and business rules in Lambda or Step Functions. Failures go to review.
- 7. Add human review with A2I: Per-field thresholds; capture corrections; sample auto-committed records.
- 8. Move to batch and tune: Batch wherever real-time is not needed. Tune thresholds and routing against the golden set.
VIIICommon failure modes
Most IDP projects fail in a few predictable ways.
- Testing only on clean documents: Benchmark on your messiest real intake from day one.
- No validation or review: Auto-committing everything is how a confidently wrong total reaches the ledger.
- Hoping for clean JSON: Constrain the model with structured output instead of asking for JSON in free text.
- One engine for everything: An LLM on standardized invoices overpays; Textract on reasoning-heavy contracts under-delivers.
- Skipping the parse step: Feed the LLM clean, layout-aware text, not raw OCR or flattened tables.
- Running everything synchronously: Batch whatever can wait.
- No accuracy measurement: Without a golden set you cannot set a safe threshold.
IXWho can fund an IDP pipeline build
Textract, BDA, Bedrock inference, A2I, S3 and orchestration all draw down AWS credits automatically.
Partner-filed funding: a vetted AWS partner can file POC (proof of concept) funding to prove extraction on your documents, MAP funding if you are moving document processing from another cloud or on-premises, or incremental workload (IW) funding if you already run on AWS and this is new work. For startups this is typically $50K to $150K. Depends on the workload; AWS approves.
AWS Activate: you apply yourself. Activate Founders gives self-funded startups $1,000 to start, up to $5,000. Activate Portfolio gives up to $200,000 with the Org ID from your VC, accelerator or angel group, if it is an Activate Provider. A consulting partner cannot file Activate for you.
CloudRoute matches you with one vetted AWS partner who can design the engine mix, the S3 and Step Functions pipeline, validation, A2I review and batch processing, and check which funding fits. Startups pay CloudRoute nothing. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.
| Funding | Who files it | Amount | When it fits |
|---|---|---|---|
| Migration Acceleration Program (MAP) | Your matched AWS partner | $50K to $150K for startups. Depends on the workload; AWS approves. | You are not on AWS yet and want to migrate. |
| Proof of concept (POC) funding | Your matched AWS partner | $50K to $150K for startups. Depends on the workload; AWS approves. | You want to test something, whether or not you are on AWS today. |
| Incremental workload (IW) funding | Your matched AWS partner | $50K to $150K for startups. Depends on the workload; AWS approves. | You are already on AWS and are launching new work: a new AI feature, a new customer or a new contract. |
| AWS Activate Founders | Founder applies | $1,000 to start, up to $5,000 | Self-funded startups with no investor or accelerator behind them. |
| AWS Activate Portfolio | Founder applies | up to $200,000 | Startups backed by a VC firm, accelerator or angel investor that is an AWS Activate Provider. |
| AWS Credits for AI Startups | Invite only (AWS account manager) | $200,000 or more, by invitation | AI startups ready to scale after Activate Portfolio, invited by AWS. |
Textract vs Bedrock Data Automation vs LLM with schema
Match each document type to the engine whose row fits it best. Production systems usually combine them.
| Dimension | Amazon Textract | Bedrock Data Automation | LLM with schema (Bedrock) |
|---|---|---|---|
| What it is | OCR, forms and tables service | Managed generative extractor (blueprints) | Foundation model plus structured output |
| Handles layout variety | Good on known structures | Strong: one blueprint, many layouts | Strongest: novel and free-form documents |
| Reasoning and derived fields | No | Limited | Yes |
| Output | Text, key-values, tables, query answers, confidence | Schema-shaped JSON, confidence | Your schema via tool use, derived confidence |
| Relative cost per document | Lowest | Medium | Highest |
| Determinism | High | Medium | Lower; guard with validation |
| Best for | Known forms, IDs, standardized invoices | Named fields across varying layouts | Reasoning-heavy, rare or derived-field documents |
How a match works (example)
- You tell us about the work
You fill in a short form: what you run today, what you want to move, test or build, your stage and your region.
- We pick one partner
We read your answers and pick one vetted AWS consulting partner that fits the work, the stack and the region. We reply within 24 hours; your matched partner reaches out within 5 business days.
- The partner checks POC funding
Your matched partner scopes the test with you. Then it checks whether the test qualifies for POC (proof of concept) funding. A POC can fit whether or not you run on AWS today.
- The partner files, AWS decides
If the work qualifies, the partner files the funding request with AWS. AWS reviews it and decides. The amount depends on the workload.
- You pay nothing
CloudRoute is free for startups. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.
AWS Activate credits are separate, and you apply for them yourself. Use Activate Founders if no investor backs you. Use Activate Portfolio with the Org ID or invite from your VC, accelerator, incubator or angel group if it is an Activate Provider. A consulting partner cannot apply for Activate on your behalf.
Common questions
What is intelligent document processing (IDP) on AWS?
Should I use Amazon Textract, Bedrock Data Automation or an LLM for extraction?
How do I get reliable, schema-valid JSON out of an LLM?
How do I handle tables, forms and handwriting?
How do confidence scores and validation work together?
How do I add a human review step?
What does document extraction cost at scale on AWS?
Can AWS funding cover an IDP build?
Build your document-processing pipeline with a partner who can file the funding
A vetted AWS partner can design the engine mix (Textract, Bedrock Data Automation, an LLM with schema), the S3 and Step Functions pipeline, validation, A2I review and batch processing. The same partner checks whether the work qualifies for POC, MAP or IW funding: typically $50K to $150K for startups. Depends on the workload; AWS approves. CloudRoute is free for startups.