Document Processing Pipelines: PDF to Structured Data on AWS
Document processing is one of the most common AI automation projects I see at clients. Invoices. Contracts. Insurance claims. Property appraisals. The pattern is always the same: PDF comes in, you need structured data out.
Most teams start with AWS Textract. It’s fast, it’s cheap, and it’s built for the job. But Textract has a ceiling. It’s great at recognizing forms and tables. It’s terrible at understanding context and extracting semantic meaning.
Then they try to glue a language model on top — Claude, GPT-4, whatever — and suddenly they have a working system.
But “working” isn’t the same as “producible.” I’m going to walk you through the architecture I’ve built for three clients. This handles hundreds of documents a month without breaking.
The Architecture
S3 Landing Zone → Lambda Processor → Claude API → DynamoDB → Validation → Notification
Here’s what each stage does:
S3 Landing Zone. Files are uploaded to s3://company-documents/inbox/. A simple bucket policy restricts who can upload. Each document gets tagged with metadata: document type (invoice, contract, claim), source system, upload timestamp.
Lambda Processor. Triggered by S3 ObjectCreated events. The function downloads the PDF, extracts text (more on this in a moment), calls Claude with structured output instructions, validates the response, and stores results in DynamoDB. If anything fails, it goes to an SQS dead letter queue.
Claude API. This is where the intelligence happens. You’re using Claude with structured output — JSON mode. You define the schema for what you want extracted, Claude returns valid JSON, and you don’t have to parse fragile regex patterns.
DynamoDB. Stores extracted data with:
- Partition key:
document_id(UUID of the PDF) - Sort key:
timestamp - Attributes:
extracted_data(the JSON),confidence_score,source_file,processing_status,errors
Validation. A second Lambda (or within the same one) validates the extracted data. Required fields present? Values in expected ranges? If validation fails, flag the document for manual review and alert someone.
Notification. Send the validated data downstream — email, webhook, Salesforce API, whatever the business process needs.
Textract vs Claude: Which One First?
This matters because it affects your cost and accuracy.
Use Textract first if:
- The document is primarily a form or table (invoices, structured reports)
- You need OCR for scanned documents
- You need coordinates of extracted text (for highlighting in UI)
- Cost is the primary constraint
Use Claude directly if:
- The document is unstructured (emails, contracts, narratives)
- You need semantic understanding (flagging unusual contract terms)
- The document is mostly text, not tables
- The PDF is already digital (not scanned)
For most of my clients, the answer is: start with Claude directly. Here’s why:
- Claude handles both born-digital and scanned PDFs.
- Structured outputs eliminate parsing errors.
- You can ask Claude semantic questions (“Is this contract unusual? Why?”) that Textract can’t answer.
- The cost difference isn’t huge if you’re smart about prompts.
If you’re processing 1,000 invoices with consistent formatting, Textract is cheaper. If you’re processing 500 diverse contracts, Claude is worth it.
The Code Pattern
Cost Breakdown: 1,000 Documents/Month
Assuming 1,000 invoices per month, average 3 pages each:
- Claude API cost: ~$0.30 per document (3 pages, ~1,500 tokens input, ~300 tokens output). Total: $300/month.
- Lambda: ~$0.0001 per invocation. 1,000 invocations = $0.10/month.
- S3: ~$0.01/month (assuming 50MB stored).
- DynamoDB: ~$5/month (on-demand pricing).
Total: ~$305/month.
Compare to Textract: $2 per page for documents over 1–5 pages. So 3,000 pages × $2 = $6,000/month. Claude is roughly 20x cheaper at this volume.
The Gotchas
Multi-page documents. Claude can handle up to 20 pages per PDF document. If your invoices are longer, you’ll need to split them or use Textract first.
Scanned PDFs. Claude handles these fine, but they take longer to process (more tokens) and cost more. Consider Textract as a first-pass for text extraction if OCR quality is critical.
Validation false negatives. Your validation logic only catches structural errors. It won’t catch semantic mistakes (e.g., wrong vendor name). Build in a manual review process for high-value documents.
Rate limiting. If you’re processing 100+ documents per minute, you’ll hit API rate limits. Use SQS with a batch processor and respect rate limits. Exponential backoff is your friend.
The Observability Setup
Log these metrics to CloudWatch:
documents_processed(count)extraction_latency_ms(histogram)validation_failure_rate(percent)claude_api_errors(count)cost_per_document(dollars)
Alert: validation failure rate > 5% or extraction latency p95 > 30 seconds.
This is a production-ready pattern. I’ve used it for invoice processing, contract extraction, and insurance claim analysis. The schema changes, but the architecture doesn’t.
Get the free AI Readiness Checklist
15 questions to diagnose your team’s AI readiness, where you’ll see ROI fastest, and what to tackle first.
No spam. Unsubscribe anytime.
Ready to build AI that actually works?
Let’s talk about how SRE discipline transforms AI from a risky experiment into a reliable business system.
Book Your Free Discovery Call