The accounts payable team at most mid-market companies is doing two jobs: the job they were hired for (managing vendor relationships, cash flow, exceptions) and a job that should be automated (re-keying data from PDFs into an ERP). AI invoice document processing automation handles the second job.
This post walks through the full architecture — how documents get in, how fields get extracted reliably, how confidence scoring determines what gets auto-posted vs. reviewed, and what the integration into an ERP actually looks like.
Why Invoice Processing Is Hard to Automate Well
Invoices look simple. They're actually a mess in practice:
- 40+ vendor templates with different field layouts
- Scanned PDFs with varying image quality
- Handwritten fields on older vendor forms
- Multi-page invoices where totals appear on page 3
- Line-item structures that differ by vendor
- Currency and tax formats that vary by region
A naive OCR approach extracts text. It doesn't understand which number is the PO number vs. the invoice number vs. the account number. It doesn't know that "Net 30" in the body text means something different from "30" in the payment terms field.
AI invoice document processing automation needs extraction that understands document structure and semantic meaning.
Architecture: The Full IDP Pipeline
Stage 1: Ingestion
Documents enter through one of several paths: - Email attachment (SES → S3) - Vendor portal upload (API Gateway → S3) - SFTP drop (AWS Transfer Family → S3) - Scan-to-email (SES → S3)
All paths converge at S3, which triggers an SQS message to the processing pipeline. The trigger message includes: document S3 key, source channel, received timestamp, and any metadata captured at ingestion (submitter email, vendor ID if known).
Stage 2: Pre-Processing
Before extraction, we run:
Format normalization: Convert non-PDF formats (TIFF, JPEG, DOCX) to normalized PDF. AWS Lambda + Poppler handles most cases; Pillow handles image-based inputs.
Quality assessment: Run a quick image quality check on scanned documents. Low-quality scans trigger an email back to the vendor with a re-submission request before wasting extraction compute.
Duplicate detection: Hash the document content and check against a DynamoDB deduplication table. Duplicate invoices are a real problem — vendors resend, email clients send twice. Catch it here.
Stage 3: Extraction
Two-layer extraction:
Layer 1 — AWS Textract: Textract handles structured extraction with high accuracy and low latency. We use AnalyzeDocument with the FORMS and TABLES features for structured invoice data. Textract returns key-value pairs with confidence scores at the field level.
def extract_with_textract(s3_bucket: str, s3_key: str) -> dict:
response = textract.analyze_document(
Document={"S3Object": {"Bucket": s3_bucket, "Name": s3_key}},
FeatureTypes=["FORMS", "TABLES"]
)
extracted = parse_key_value_pairs(response["Blocks"])
line_items = parse_tables(response["Blocks"])
return {
"fields": extracted,
"line_items": line_items,
"textract_confidence": compute_avg_confidence(response["Blocks"])
}
Layer 2 — Claude on Bedrock: For fields where Textract confidence is below threshold, or for semantic fields Textract can't extract (payment terms interpretation, vendor name normalization, PO number from unstructured text), we invoke Claude via Bedrock. The prompt is structured and constrained — we ask for specific fields in a JSON schema format.
def extract_with_bedrock(document_text: str, uncertain_fields: list) -> dict:
prompt = f"""
Extract the following fields from this invoice. Return JSON only.
Fields needed: {uncertain_fields}
If a field cannot be found, return null for that field.
Invoice text:
{document_text}
"""
response = bedrock.invoke_model(
modelId="anthropic.claude-3-sonnet-20240229-v1:0",
body=json.dumps({
"anthropic_version": "bedrock-2023-05-31",
"max_tokens": 1024,
"messages": [{"role": "user", "content": prompt}]
})
)
return json.loads(extract_json_from_response(response))
Merge and validate: Combine Textract and Bedrock results. Run field-level validation: PO number format check, amount reconciliation (line item sum = total?), vendor ID lookup against master vendor file, due date logic check.
Stage 4: Confidence Scoring and Routing
After extraction, every invoice gets an overall confidence score derived from:
- Average field-level confidence from Textract
- Whether Bedrock was needed (and for how many fields)
- Validation pass/fail rates
- PO match status (did we find a matching PO?)
Routing logic:
def route_invoice(extracted: dict) -> str:
score = extracted["confidence_score"]
po_matched = extracted["po_match_status"] == "matched"
amount_reconciled = extracted["line_items_reconciled"]
if score >= 0.92 and po_matched and amount_reconciled:
return "auto_post"
elif score >= 0.75 and po_matched:
return "human_review"
else:
return "exception_queue"
auto_post → straight-through to ERP API.
human_review → review interface with pre-filled form.
exception_queue → escalation with full extraction context.
Stage 5: ERP Integration
Auto-post invokes the ERP API with the normalized invoice payload. Every integration is:
- Idempotent: We send an idempotency key (document hash) so duplicate posts fail gracefully rather than creating duplicate records.
- Retried: Lambda retry policy + SQS DLQ handles transient API failures.
- Logged: Full event written to DynamoDB before and after the API call.
For ERPs without REST APIs, we've used database-level integration (write to a staging table the ERP reads) and RPA as a last resort.
Stage 6: Audit and Reconciliation
Every invoice gets a complete lifecycle record:
{
"document_id": "uuid",
"received_at": "ISO8601",
"extracted_fields": {...},
"confidence_score": 0.94,
"routing_decision": "auto_post",
"erp_post_result": "success",
"erp_record_id": "INV-2847",
"processed_at": "ISO8601",
"processing_duration_ms": 4200
}
Finance teams get a daily reconciliation report: invoices processed, auto-posted, reviewed, and exceptions. AP managers see throughput and exception rates. Auditors get the full event log.
What We Built
One production SaaS platform we support processes vendor invoices across dozens of suppliers. Pre-automation: AP team spent a significant portion of each day on data entry. Post-automation: standard invoices from known vendors flow straight through. The team handles exceptions, new vendor onboarding, and relationship management — work that actually benefits from human attention.
Key metric: time-to-post for standard invoices dropped from same-day (best case) to minutes.
For the infrastructure backing these pipelines, see our AWS Cloud Infrastructure capability and our work on AI workflow automation for business.
Line Items: The Hard Part
Getting the invoice total right is table stakes. Getting line items right is where most IDP implementations struggle.
Line item extraction requires table understanding — not just reading the table, but understanding which column is quantity, which is unit price, which is total, even when column headers vary across vendors.
We handle this with a hybrid approach: - Textract TABLES feature for structured tables with clear headers - Custom parsing logic for common vendor-specific formats we've seen before - Bedrock for ambiguous or non-standard table structures
Every line item extraction gets validated: does quantity × unit price = line total? Do line totals sum to invoice subtotal? Discrepancies route to human review.
Frequently Asked Questions
How accurate is AI invoice processing compared to manual entry?
For well-structured documents from known vendors, AI extraction matches or exceeds manual accuracy (human error on repetitive data entry is real). The system's advantage is consistent performance at volume — it doesn't get tired or distracted. Accuracy degrades for poor-quality scans and novel vendor formats; the confidence routing layer catches these.
What happens to invoices the system can't process?
Low-confidence and exception invoices go to a human review queue with full context shown. The AP team handles these directly. Nothing gets silently dropped or auto-posted at low confidence.
How do we handle multi-currency invoices?
Currency detection is part of the extraction layer. We normalize amounts to a base currency using exchange rates from a configurable source (ECB, open exchange rates API, or your treasury system). Finance teams set the normalization rules.
Can this handle invoices for services (no PO)?
Yes, with modified routing logic. Service invoices without a matching PO route to a configurable approval flow rather than auto-post. We define cost center approval chains and spend limits in configuration.
What's the typical implementation timeline?
A focused single-vendor-type deployment can be in production in 4–6 weeks. Full multi-vendor IDP with ERP integration typically runs 8–14 weeks depending on ERP API complexity and number of vendor templates to handle.
Discuss your automation project → rutagon.com/contact | 907-841-8407 | contact@rutagon.com