Document Processing Workflows with LLMs

Key facts, with sources

• McKinsey's State of AI 2025 found nearly nine in ten organizations now use AI in at least one business function, yet only about 6 percent attribute 5 percent or more of EBIT to their AI use. (McKinsey)
• McKinsey found AI high performers are 2.8x more likely than others to have fundamentally redesigned workflows (55 percent versus 20 percent), and workflow redesign has the biggest effect on realizing EBIT impact from gen AI. (McKinsey)
• Zapier's survey of 525 enterprise executives found human-in-the-loop is the most common agent management approach at 38 percent, while 20 percent say their AI systems now operate autonomously with minimal oversight. (Zapier)
• 84 percent of enterprise leaders say they will likely or certainly increase AI agent investment over the next 12 months, with customer support (49 percent) and operations (47 percent) leading deployment. (Yahoo Finance)
• Menlo Ventures found coding and developer tools were the largest enterprise AI workflow category at $7.3 billion in 2025 spend, with half of developers now using AI tools daily. (Menlo Ventures)

The pipeline shape, and why each stage exists

Ingest normalizes whatever arrives — PDFs, scans, emails with attachments — into text or images the model can consume, and records provenance. Classify determines the document type before any extraction happens. Extract runs a type-specific prompt with a type-specific schema. Validate applies rules the schema cannot express. Review routes exceptions to humans, and their corrections feed back as test cases.

Teams that skip straight to a single mega-prompt covering all document types pay for it in accuracy and debuggability: one prompt handling invoices, receipts, and contracts simultaneously does all three worse than dedicated prompts do individually, and when quality drops you cannot tell which document population regressed. Separate the stages and each becomes independently testable and independently improvable.

Classify first, extract second

Classification is a cheap call that pays for itself immediately. It selects the right extraction schema and prompt, it filters out garbage before you spend tokens extracting from it — blank pages, wrong-language documents, files that are not the expected type at all — and it gives you a routing key for volume analytics.

I constrain classification to an enum via structured outputs and include an explicit escape hatch value like unknown. The single most common design mistake I find in audits is a classifier forced to choose among valid types with no way to say none of these — that silently pushes junk into extraction, and the junk emerges downstream as plausible-looking fabricated fields.

Schema-constrained extraction

Extraction calls use structured outputs with an explicit JSON schema, which eliminates the parse-failure class entirely and constrains field names and types. Dates come back as strings in a declared format, amounts as numbers, and anything the schema marks required is present.

What the schema cannot guarantee is that the values are correct — that is the next stage's job. This is the extraction call I start from:

import json
from anthropic import Anthropic

MODEL = "claude-opus-4-8"  # always swap in the latest Claude model id
client = Anthropic()

INVOICE_SCHEMA = {
    "type": "object",
    "properties": {
        "vendor_name": {"type": "string"},
        "invoice_number": {"type": "string"},
        "issue_date": {"type": "string", "format": "date"},
        "currency": {"type": "string"},
        "total": {"type": "number"},
        "line_items": {
            "type": "array",
            "items": {
                "type": "object",
                "properties": {
                    "description": {"type": "string"},
                    "amount": {"type": "number"},
                },
                "required": ["description", "amount"],
                "additionalProperties": False,
            },
        },
    },
    "required": ["vendor_name", "invoice_number", "issue_date", "currency", "total", "line_items"],
    "additionalProperties": False,
}

def extract_invoice(document_text: str) -> dict:
    response = client.messages.create(
        model=MODEL,
        max_tokens=2048,
        output_config={"format": {"type": "json_schema", "schema": INVOICE_SCHEMA}},
        messages=[{
            "role": "user",
            "content": f"Extract the invoice fields from this document:\n\n{document_text}",
        }],
    )
    return json.loads(response.content[0].text)

Validation beyond the schema

A schema-valid extraction can still be wrong, and the dangerous failures are the plausible ones. So validation is its own stage with three layers. Deterministic checks: line items sum to the total within tolerance, dates are not in the future, currency codes are real, invoice numbers match the vendor's known format. Cross-reference checks: the vendor exists in your master data, the purchase order it cites is open. Grounding checks: key values like the total must literally appear in the source text — if the model reports a number the document does not contain, that is a fabrication, and it goes straight to review.

Each failed check attaches a machine-readable reason to the document. Those reasons drive routing and, aggregated over weeks, tell you exactly where the pipeline needs prompt or schema work.

Human review as a designed component

Some fraction of documents will always need eyes — degraded scans, novel layouts, genuinely ambiguous content. The design decision is whether review is a planned lane with tooling or an inbox of failures someone dreads. I route to review on failed validation, a classifier verdict of unknown, or any grounding failure, and the reviewer sees the document alongside pre-filled extracted fields so correcting takes seconds rather than re-keying everything.

Every correction is stored as a labeled example. That corpus becomes your regression suite: before any prompt or model change ships, it must match or beat current accuracy on the accumulated set. This loop — exceptions become tests — is what makes the pipeline improve with volume instead of decaying. On costs: classify with a cheaper model, extract with a stronger one, and run non-urgent volume through batch processing, which typically halves the bill.

When to hire senior help

Bring in senior help when workflows cross system boundaries such as CRM, billing, or anything touching customer PII, or when a no-code prototype hits reliability and cost limits. The redesign work itself, mapping the process, defining checkpoints, and instrumenting metrics, benefits most from someone who has shipped production AI workflows before. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships AI — AI Workflows projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Bolting AI onto an existing process instead of redesigning it, when McKinsey data shows redesign, not adoption, separates the roughly 6 percent of companies seeing real EBIT impact
• ✕Automating a workflow nobody measured first, leaving no baseline to prove time or cost savings when budget review comes
• ✕Using an expensive frontier model for every step instead of routing simple steps to cheap models and reserving reasoning models for the hard ones
• ✕Jumping to full autonomy on day one and skipping the human-in-the-loop stage most enterprises use to build trust and surface failure modes

Frequently asked questions

Sources

• McKinsey
• McKinsey
• Zapier
• Yahoo Finance
• Menlo Ventures