Insight — June 12, 2026 · 6 min

How we cut invoice processing time by 90% with Claude and AWS Textract

OCR alone can read an invoice, but it can't understand one. The two-stage pipeline we built for Smart IDP pairs Textract's document parsing with Claude's field mapping — and dropped per-document time from 4.2 minutes to 25 seconds.

AIClaudeAWS TextractDocument Intelligence

The problem OCR can't solve on its own

The finance team we built Smart IDP for was processing 800–1,200 invoices a month across 12 supplier formats. Every one of them was keyed into spreadsheets by hand — 3 to 4 hours a day of copy-typing, with a ~2.3% error rate that quietly poisoned month-end reconciliation.

The obvious answer, OCR, had already failed them. Tools like raw Textract output can tell you every string on the page, but they don't know that '4500023' is a PO number and not an invoice number, or how to parse a multi-line itemised bill where quantity and unit price share a column. Extraction without understanding just moves the manual work one step downstream.

Two stages: parse, then understand

The architecture that worked is a strict two-stage pipeline. Stage one is AWS Textract doing what it's genuinely good at: low-level document parsing — bounding boxes, table detection, per-token confidence scores. We never ask Textract to interpret anything.

Stage two is Claude Sonnet sitting on top as an intelligent field-mapping layer. Each supplier format is captured once as a JSON template — field names, positional hints, validation rules. Claude receives the raw Textract output plus the template and maps everything to one canonical invoice schema, regardless of layout variation. Structured-output prompting keeps the response machine-parseable; business-rule validation runs before anything is persisted.

The feedback loop is the part most teams skip: users review AI confidence scores field-by-field, override wrong values, and trigger re-extraction with corrected hints that feed back into the template. Templates get better with use instead of rotting.

What it moved

Per-document processing time fell from 4.2 minutes to under 25 seconds end-to-end — a 90%+ reduction that freed roughly 60 staff-hours a month. Keying errors on structured fields dropped to effectively zero, and the extraction trail baked into every record carried the team through their first ISO compliance review without a single finding.

The lesson we keep reusing: don't ask one model to do everything. Let the OCR engine parse, let the LLM understand, and put a template between them so domain knowledge accumulates somewhere durable.