Intelligent Document Processing
Design an agent that ingests invoices and claims, extracts structured data with LLMs, validates against business rules, and pushes to downstream ERP systems.
Last updated: September 2026
An agent that ingests incoming documents (invoices, claims), extracts structured data, validates it, and pushes it to downstream systems (ERP, CMS) - replacing a manual processing team. The key business KPI is STP rate (Straight-Through Processing): the percentage of docs processed without any human touch. Day-1 STP is typically ~70%; after 6 months of corrections and retraining it reaches 90-95%.
“Defense in depth - extraction errors caught by validation; validation failures caught by human review. No single check failure lets a corrupt record reach the ERP. Queue-based and idempotent - every step retryable safely. Immutable audit trail from day one - not added later.”
Clarifying Questions (Ask These First ~5 min)
| Question | Why it matters |
|---|---|
| Document types & formats? (PDF, scanned, Word, EDI) | Determines if OCR is needed |
| Volume - 1k/day or 500k/day? | Batch vs. streaming, compute sizing |
| What fields to extract? Fixed schema or variable? | Drives extraction approach |
| What validation rules? (PO matching, math checks, dedup) | Defines validation engine complexity |
| Where does data go? (SAP, Oracle, NetSuite) | One adapter per downstream system |
| Target STP rate? (80%? 95%?) | Sets confidence thresholds for human review |
| Compliance requirements? (SOX, HIPAA) | Audit trail requirements |
Architecture (Draw This)
Incoming Docs (email, SFTP, portal, scanner)
→ [1] Ingest + Dedup + Queue (Pub/Sub)
→ [2] Classify (what doc type is this?)
→ [3] OCR / Text Extraction (image → text + layout)
→ [4] LLM Extraction (text → structured JSON fields)
→ [5] Validation
├── PASS → [6] Downstream Adapter → ERP/DB → Audit: DELIVERED
└── FAIL → [7] Human Review Queue → Corrections → Re-validate → Downstream
↓
Corrections = labeled training data → fine-tune → higher STP
→ [8] Audit Log (immutable, every state transition)Key Components (30-second pitch each)
- 1Ingestion - Multi-channel adapters (IMAP, SFTP, REST API). SHA-256 hash for deduplication. Write to Pub/Sub queue - decouples ingestion rate from processing rate. Store raw files in immutable GCS/S3 (never delete originals - audit source of truth).
- 2Classification - Vision-language model (Gemini Pro Vision / Document AI) on first page → { doc_type, confidence }. If confidence < 0.85 → human classifies before extraction. Wrong classification = garbage extraction downstream.
- 3OCR - Digital PDF → extract directly (PyMuPDF). Scanned PDF / image → Google Document AI (returns text + bounding boxes + table structure). Layout-aware OCR is critical - column/table structure tells you which zone a value belongs to.
- 4Intelligent Data Extraction - Highest Value, Highest Risk - Use forced JSON output (Gemini response schema / Anthropic tool use) - never parse free-form LLM text for financial data. Hybrid approach: rules/regex for known vendor templates (cheap + fast), LLM only for novel layouts. Table line items → use OCR table structure directly, not LLM text parsing.
- 5Validation - Two Layers - Syntactic: required fields present, dates valid, math checks (line items = subtotal + tax = total), duplicate invoice number. Cross-system: PO matching vs. ERP, vendor master check, amount threshold (>$50k = human approval). 3-way matching = invoice vs. PO vs. goods receipt.
- 6Human Review Queue - Original doc rendered side-by-side with extracted fields. Highlight the failing field + its source bounding box on the doc image. Every correction captured as { field, model_prediction, human_correction } → training data. Re-validate after correction before downstream push.
Validation Layers
| Layer | Checks | Speed |
|---|---|---|
| Syntactic | Required fields present, date validity, math checks (line items = subtotal + tax = total), duplicate invoice number | Fast, deterministic |
| Cross-system | PO matching vs. ERP, vendor master check, amount threshold (>$50k = human approval) | Slower, API calls |
3 Biggest Risks
- 1Extraction errors that pass validation - Mitigated by 3-way matching + math checks (defense in depth) - internal consistency alone is not enough.
- 2Human review queue overload - Mitigated by queue-based autoscaling on queue depth (Kubernetes HPA) + SLA alerting when queue exceeds threshold.
- 3Model drift as vendor formats evolve - Mitigated by per-vendor accuracy monitoring + correction flywheel that continuously fine-tunes on human corrections.
Google Stack: Document AI (OCR + form parsing) → Gemini Pro (LLM extraction) → Cloud Pub/Sub (queue) → Cloud Run / GKE (workers, autoscale) → BigQuery (audit + analytics) → Looker (ops dashboard)
Azure Stack: Azure Blob Storage + Azure Service Bus (ingestion/queue) → Azure AI Document Intelligence (OCR, 300+ languages, layout + table extraction) → Azure OpenAI GPT-4o (LLM extraction, forced JSON) → Azure Logic Apps / Power Automate (downstream ERP adapters) → Azure AI Search (vendor template matching) → Azure Human-in-the-Loop (review queue) → Log Analytics Workspace (audit log)
AWS Stack: S3 + SQS (ingestion/queue) → Amazon Textract (OCR + AnalyzeDocument, native table/form extraction) → Amazon Bedrock / Claude (LLM extraction) → AWS Step Functions (workflow orchestration) → AWS Lambda (downstream adapters) → Amazon Augmented AI / A2I (human review queue) → DynamoDB + S3 Object Lock (immutable audit log)
Other Options: UiPath Document Understanding + OpenAI (enterprise RPA path) | Microsoft Power Automate AI Builder (low-code, Office 365 native) | Rossum + SAP (finance-specific, pre-built ERP connectors) | Reducto + Anthropic Claude (developer-first, high-accuracy extraction API)
Frequently asked questions
LLM extracts wrong total - how does it get caught?
Math check: line items must sum to subtotal; subtotal + tax must equal total. If internally consistent but wrong amount, 3-way PO matching catches it against the expected PO amount.
200 line items exceed LLM context window?
Use OCR table structure directly for line items (not LLM). Or chunk table by page, extract in parallel, merge results.
PO number doesn't exist in ERP?
Auto-reject with reason code PO_NOT_FOUND, notify sender. Don't route to human review - it's a sender data error, not a review task.
Reviewer rubber-stamps everything to clear queue?
Track reviewer accuracy against downstream errors. Require secondary approval on high-value items. Audit-sample fast approvals. Flag anomalously high approval rates.
10x volume spike at quarter end?
Queue absorbs the spike. Processing workers auto-scale on queue depth (Kubernetes HPA). Pre-scale proactively for known fiscal quarter spikes.
1M docs/day - LLM cost is huge?
Tiered extraction: rules/regex for known templates (85% of volume, near-zero cost), LLM only for novel layouts. Cache extraction for identical content hashes. Use a small fine-tuned extraction model (3-5x cheaper than general LLM).
How do you prove to auditors data wasn't tampered?
Content hash of original file stored at ingest. Immutable audit log records every extraction, validation, correction, and ERP push. Auditor can compare original file against final ERP entry end-to-end.