DEV Community: Prasanth Pattathil

Invoice Extraction with Human Review: Route on Checks, Not on Confidence

Prasanth Pattathil — Mon, 26 Oct 2026 11:01:02 +0000

A design case study: why a confidence score can’t decide which invoices get paid, and what to route on instead.

About this case study. This is a composite scenario built on synthetic invoices. It shows a design and how to measure it. The numbers are planning figures, not benchmark results.

The problem

A mid-sized distributor gets about 6,000 supplier invoices a month. They arrive as PDFs, scans and phone photos in more than one language. Three accounts-payable clerks type each one into the ERP: vendor, invoice number, dates, line items, tax, total, and the purchase order it belongs to.

The ask from finance was simple: “Let the AI read the invoices, and have people check only the ones it is unsure about.”

That sentence hides the hard part. How does the system know when it is unsure?

Today every field is typed by hand. The goal splits invoices into clean and unsure, but who decides which is which?

The obvious answer is the model’s confidence score: auto-approve above 90%, send to a person below it. That is the design this post argues against.

Why confidence alone is the wrong gate

Extraction services return a confidence number for each field. Amazon Textract’s AnalyzeExpense, for example, gives separate scores for the label it found (“Total:”) and the value next to it (“$55.64”). Those scores are useful, but they answer a narrow question: how sure am I that I read these characters correctly?

A total read with 99.9% confidence on an invoice that should never be paid.

They do not answer the questions finance cares about:

Do the line items add up to the total?
Is this a vendor we actually do business with?
Does it match an open purchase order?
Have we already paid this invoice?
Are the bank details the same ones we have on file?

A model can read a total of $12,480.00 with 99.9% confidence on an invoice that is a duplicate, that belongs to no purchase order, or that asks us to pay a new bank account. High confidence, wrong outcome. The worst errors in accounts payable are not misread digits. They are perfectly read invoices that should never be paid.

So the rule for this system is the same one Post 1 used for permissions:

Model output is a claim. Checks against our own data are the evidence. The model extracts; deterministic checks decide.

The design in one picture

Extract, validate, route: three outcomes, a 2% audit, and every correction stored.

Five decisions shape this design.

Decision 1: The extractor is replaceable; the routing is the product

There are two reasonable extraction options on AWS today:

Textract vs. Bedrock Data Automation.

The extractor sits behind an adapter. The checks, routing and review loop stay the same.

We start with AnalyzeExpense and put it behind a small interface that returns one normalized Invoice object: fields, values, confidence and page geometry. If BDA does better on our golden set later, we swap the extractor and change nothing downstream.

That is the point of this decision. Extraction quality will keep improving and vendors will keep changing. The checks, the routing and the review loop are where our business rules live, so they should not be tied to one extractor.

Decision 2: Validate with deterministic checks

After extraction, every invoice runs the same checks. None of them uses a model.

Two checks stop an invoice outright; the rest send it to review with a reason.

Two rules are worth pointing out.

Match vendors by tax ID, not name. “ACME Ltd”, “Acme Limited” and “ACME LTD.” are the same company to a person and three companies to a string comparison. Names are for display; IDs are for joins.

Never update bank details from an invoice. Changed bank details on an invoice are the most common sign of payment fraud. If the invoice disagrees with the vendor master, the invoice goes to a separate queue that only the vendor-management team can clear, and they confirm by calling a phone number already on file. No confidence score can turn this off.

Decision 3: Thresholds per field, set by the cost of being wrong

One global threshold treats a misread invoice date the same as a misread total. Those mistakes do not cost the same.

Higher cost of error, higher bar to skip review.

These starting values are not magic. They are tuned on the golden set (Decision 5), and the target is set per field: what is the most auto-approval we can get while keeping this field’s escaped error rate under X?

Arithmetic checks also give a second signal that confidence cannot. If the total was read with 99% confidence but the line items do not add up, one of the numbers is wrong, and confidence did not catch it.

Decision 4: Build the review queue; show reviewers only what is flagged

Why not Amazon A2I

Amazon Augmented AI (A2I) used to be the default answer for “human review on AWS.” In June 2026 AWS announced that A2I, along with SageMaker Ground Truth, is moving to maintenance and stopped accepting new customers on July 30, 2026. A new system should not be built on it.

The review loop we need is small enough to own:

Step Functions with a task token. The workflow pauses at the review step with .waitForTaskToken. The review UI calls SendTaskSuccess with the corrected invoice, and the workflow continues to the ERP. No polling and no extra state machine.
DynamoDB holds the queue: invoice ID, reasons for review, assigned reviewer, SLA timestamp.
A small web UI behind Cognito shows the PDF with bounding boxes only around the flagged fields , plus the reason (“line items sum to 11,980.00; total says 12,480.00”).

Left: the workflow pauses on a task token until a reviewer finishes. Right: the reviewer sees only the flagged fields, with the reason.

Design the screen for speed, not completeness

The first review screen showed all 25 fields. Reviewers re-checked every one, so reviewing took almost as long as typing. Showing only the flagged fields, with the reason and the highlighted region, turns a review into a 20-second decision instead of a three-minute re-key.

Two rules keep this honest:

Reviewers must touch every flagged field. Each flagged field needs an explicit “confirm” or a correction, so a reviewer can’t approve the whole invoice in one click.
Hard stops never go to the normal queue. Duplicate and bank-detail cases have their own queue, their own role, and a four-eyes rule.

Decision 5: Measure what escapes, not just what gets reviewed

This is the decision most teams skip, and it is the one that matters most.

If you only look at invoices that went to review, you learn how often reviewers correct the model. You learn nothing about the invoices that were auto-approved, and those are the ones that turn into wrong payments.

The random audit is the only window into invoices nobody looked at.

So we measure four things:

Four numbers to watch. The escaped error rate is the one that matters most.

The 2% random audit is the key. A small random sample of auto-approved invoices goes to review anyway, without telling the reviewer it was auto-approved. That is the only unbiased estimate of the escaped error rate. Without it, a rising straight-through rate looks like progress even if it comes from errors slipping through.

Every correction is stored as (invoice, field, extracted value, corrected value, reason). That store becomes:

the golden set for comparing extractors (Textract vs BDA) and tuning thresholds;
a vendor watch list : vendors whose invoices are corrected often get a stricter threshold or a vendor-specific blueprint;
the release gate for any change to the extractor or thresholds (more on that in Post 4).

A sketch of the router

The routing logic is short, and it should be. It is the most important code in the system, so it needs to be easy to read and test.

from dataclasses import dataclass
from enum import Enum

class Route(Enum):
    AUTO_APPROVE = "auto_approve"
    REVIEW = "review"
    HARD_STOP = "hard_stop"

HARD_STOP_CHECKS = {"duplicate", "bank_details"}

@dataclass
class CheckResult:
    name: str
    passed: bool
    reason: str = ""
    field: str | None = None

def route(checks, amount, auto_limit, audit_sample):
    failed = [c for c in checks if not c.passed]

    # 1. Fraud and duplicates: nothing overrides these.
    if any(c.name in HARD_STOP_CHECKS for c in failed):
        return Route.HARD_STOP, failed

    # 2. Any failed check: review, with the reasons.
    if failed:
        return Route.REVIEW, failed

    # 3. Large invoices always get a person.
    if amount > auto_limit:
        why = CheckResult("amount_limit", False,
                          f"over {auto_limit}")
        return Route.REVIEW, [why]

    # 4. Random audit of clean invoices.
    if audit_sample:
        why = CheckResult("audit_sample", False,
                          "random audit")
        return Route.REVIEW, [why]

    return Route.AUTO_APPROVE, []

The router, top to bottom. Confidence never short-cuts the checks.

Notice what is missing: there is no line that says “if confidence is high, skip the checks.” Confidence is only one of the checks (per field), never a way around the others.

What we would expect, and how we would know

Each stage opens only when the data from the previous one says it is safe.

For a rollout like this, a reasonable plan is:

Weeks 1–4, shadow mode. Everything goes to review. The system’s route is recorded but not used. This builds the golden set and shows what the straight-through rate would have been.
Then, turn on auto-approve for one vendor group with clean history and low amounts. Watch the escaped error rate from the audit sample.
Widen only when the audit says so. Each new vendor group needs its escaped error rate under the agreed limit for a full month.

A realistic early target is a straight-through rate between 40% and 60%, with most of the rest needing a fast review of one or two fields instead of full re-keying. The exact number depends on the vendor mix: clean, machine-generated PDFs from large suppliers will pass far more often than phone photos from small ones.

What we would do differently

Start the corrections store on day one. Shadow-mode data is the cheapest golden set you will ever get.
Agree the escaped error limit with finance before launch, not after the first wrong payment. It is a business decision, not an engineering one.
Treat the vendor master as part of the system. Half of the “extraction errors” in a project like this turn out to be stale vendor data. The checks are only as good as the data they check against.

Key takeaways

Confidence measures reading, not correctness. Route on deterministic checks against your own data.
Thresholds belong to fields, and are set by the cost of being wrong.
Some cases never auto-approve: duplicates, bank-detail changes and large amounts.
Show reviewers only what is flagged, and make them touch each flagged field.
Audit a random sample of auto-approved invoices. It is the only honest measure of risk.
Keep the extractor replaceable. The routing and the review loop are the product.

Next in the series: Case 03, an LLM gateway that cut the bill (GCP). The design and decision records for this case, starting with “route on verified checks, not model confidence,” are in the series repository.

AWS service details reflect public documentation as of October 2026. Check current AWS docs before you build.

Designing a RAG System That Knows What You’re Allowed to See

Prasanth Pattathil — Tue, 20 Oct 2026 12:31:01 +0000

A design case study: choosing between fine-tuning, long context and RAG, and why access control belongs in retrieval, not in the prompt.

Part of the AI Architecture Casebook: real-world AI problems, redesigned one decision at a time. Start here

An employee in Bengaluru asks the company HR assistant how much parental leave she gets. The answer comes back confident, well written and wrong: it is the UK policy.

A week later, a junior engineer asks about relocation support and receives details of the executive relocation package, a document he was never meant to see.

Neither failure came from a bad model. Both came from the architecture around it. This post walks through how I approached the redesign as a design exercise: the options, the decisions, the trade-offs, and one problem that better search alone cannot solve.

I work on enterprise APIs, where one rule is non-negotiable: authorization is decided at the gateway, from a verified token, never by trusting what the caller says. When I started looking at how RAG systems handle access control, I kept seeing the opposite: permissions written into prompts and left to the model. This case study applies the gateway mindset to retrieval.

The company, people and documents in this case study are fictional. The architecture patterns are real.

The problem

Globex is a fictional company with 20,000 employees in 12 countries and about 4,000 HR policy documents. Leave, travel, benefits and expenses all differ by country, and some policies are restricted to senior grades. HR updates around 40 documents every week.

The first chatbot was built in two weeks. It found the documents that best matched a question, placed them in a long prompt, and asked the model to answer. Within a month, HR had logged three kinds of failure:

Wrong country. The UK and India parental leave policies match “parental leave” almost equally well. The bot picked the wrong one.
Leaked policy. A junior employee received text from a policy restricted to senior grades.
Stale and uncited answers. Answers had no source, and some quoted a travel policy that had been replaced two weeks earlier.

The bot was switched off. HR still answers about 6,000 policy questions a month by hand, and most of the answers are already written down somewhere.

The second failure is the serious one. A wrong answer is an inconvenience. A restricted document shown to the wrong person is a compliance incident.

What the fix had to satisfy

Before choosing any technology, I wrote down what a good answer must look like. Most design mistakes come from skipping this step.

The first line is the one that cannot bend. Every other decision is tuned around it.

Four options, and why I rejected three

All four options use a language model. The real question is where the model gets its policy knowledge: trained into the model, or looked up from the documents for each question.

Why not fine-tuning? A model is billions of numbers, called weights. Fine-tuning blends the policies into those numbers: no document remains inside the model. Think of a student who memorized the whole handbook, versus one who looks up the right page each time. The memorizer can’t tell you which page a fact came from, so answers can’t be cited. Every one of the 40 weekly policy changes means retraining. And because one model answers everyone, the executive policy can’t be hidden from a junior engineer; it’s mixed into the same numbers. Fine-tuning is good for how a model writes, not for what it knows when facts change and have access rules.

Why not long context? Every model has a context window: how much text it can read for one question. Modern windows hold hundreds of pages, so it’s tempting to skip search and paste a large pile of policies into every prompt. If fine-tuning is the student who memorized the handbook, this is handing the student the whole handbook for every single question. It fails three ways.

Cost: you pay for every word read, and 100,000 tokens per question costs far more than the 3,000 that matter.
Accuracy: models miss facts buried in long prompts, and with two near-identical parental leave policies in the pile, they pick the wrong one.
Security: if the executive policy is in the pile, the model has already read it. And once you choose which documents to send based on who is asking, you have built a retrieval system anyway.

Long context shines when the material is small, shared by everyone and rarely changes, like one contract or one product manual.

Why not pure vector search? This is the subtle one. Vector search finds text with similar meaning, and the UK and India policies mean almost exactly the same thing. What separates them are exact words: country names, policy codes, grade labels. That is what keyword search is good at.

The architecture

The Answer API is the only component that sees both who is asking and what is being searched. It reads country and grade from the verified sign-in token, builds the filter itself, and sends only the five best allowed chunks to the model. On AWS this maps to API Gateway and Lambda, Bedrock Knowledge Bases over OpenSearch Serverless, and a Bedrock model with a grounding check.

Three decisions that carry the design

I recorded each decision as an Architecture Decision Record (ADR): the context, what we chose, what we rejected, and the signal that would make us change our mind.

1. Hybrid search with a reranker

Run keyword search (BM25) and vector search together, merge the results, rerank the top candidates and keep the best five. Keyword search catches “India” and “HR-PL-IN-001”; vector search catches “time off after having a baby”.

The AWS detail that almost undid this: Bedrock Knowledge Bases support hybrid search on several vector stores, including OpenSearch (Serverless and managed clusters), Aurora PostgreSQL and MongoDB Atlas. On other stores, such as the low-cost S3 Vectors, a hybrid request quietly falls back to semantic-only search, with no error. Choosing the cheapest store would have silently brought back the original bug. That is why the store choice is part of the decision, not an implementation detail.

Trade-off: OpenSearch Serverless has a minimum cost even when idle, and reranking adds latency. I accept both: a cheaper store would bring back the wrong-country bug, and the reranker still fits within the 3-second budget.

2. Access control in retrieval, not in the prompt

Every document carries the countries and grades allowed to see it. The API reads the user’s country and grade from their verified sign-in token, builds a filter, and passes it into every search. The model only ever receives chunks the user is entitled to.

The tempting alternative is to tell the model: “Do not reveal documents the user is not allowed to see.” That is a security control in name only. The model has already received the restricted text, and a cleverly worded question can talk it out of the instruction.

Two other alternatives I rejected:

Filtering after retrieval, in code: restricted chunks still take up slots in the results, pushing out good ones, and one bug leaks data.
A model-generated filter (some platforms can build a filter from the question text): useful for relevance, but it is controlled by the user’s words, so it must never carry security.

The rule: the security filter is built from verified identity only. Never from user input, never from model output.

3. Chunk by policy section

HR policies have numbered sections, and the rules often depend on each other. “Up to 26 weeks of leave” in section 3.1 means little without “after 12 months of service” in section 3.2. A fixed 500-token split can cut a rule away from its condition, so the model answers with half the policy.

So I split on section headings, and long sections on sub-headings, keeping the parent heading as a prefix.

The part that surprised me: better search is not enough

While building the test documents, I put the UK and India parental leave policies side by side. They are the same template with different numbers. Here is section 3.1 from each:

Notice what is missing: the country. Once a policy is split into sections, the chunk that holds the answer contains no country name and no policy code. Those live in the title and the first section. So neither vector search nor keyword search can tell these two chunks apart.

That leads to two separate fixes for two separate cases:

The question names the country (“How much parental leave do employees in India get?”). Hybrid search can win here, but only if every chunk is prefixed with its document title, country and policy code. Section chunking without that prefix throws away exactly the words keyword search needs.
The question doesn’t name the country (“How much parental leave do I get?”). Here the text contains nothing to search on. No retrieval method can pick the right version from the words alone. Only the identity filter can, because it knows who is asking.

This is the real argument for access control in retrieval. It is not only a security feature. For a large share of everyday questions, the user’s identity is the only signal that separates the right answer from the wrong one.

What can still go wrong, and how I’d measure it

No design removes every risk. These are the ones I would watch:

Measure retrieval separately from answers. Most RAG failures are retrieval failures: if the right section isn’t in the top five, no prompt will fix it. So the evaluation set has 60 questions with a known correct document and section: 30 ordinary questions, 15 where the answer differs by country, 10 with no matching policy, and 5 probes asking about something the user may not see.

One rule for the leak count: if a result can’t be verified (say, it has no document id), count it as a leak. A broken system should make the security number worse, never better.

At 10x scale (200,000 employees), I would expect these to change first:

Country and grade lists become too coarse; a dedicated authorization service takes over.
Repeated questions (open-enrollment week) need caching.
Indexes split by region for data residency.
Personal questions (“how many leave days do I have left?”) need access to the HR system, which turns this into an agent.

Takeaways

Write the constraints before choosing the technology. The one that cannot bend (access control here) decides most of the design.
Fine-tuning stores style, not changing facts. For policies that change weekly and need citations, retrieval wins.
Security belongs in retrieval, not in the prompt. If the model has seen the text, a prompt instruction will not reliably keep it secret.
Small platform details can undo big decisions. A cheaper vector store would have silently turned hybrid search back into semantic search.
Identity is also a relevance signal. When a question doesn’t name the country, only knowing who asks can pick the right answer.

This is the first case study in a series where I take a realistic AI problem, compare the options, and record the decisions as ADRs. The design doc and ADRs are on GitHub: ai-architecture-casebook.

One simplification to note: real enterprises usually have far richer access rules, such as departments, projects and temporary access. Country and grade are enough to show the pattern. At larger scale, a dedicated authorization service makes the decision, but the principle stays the same: the filter comes from verified identity, never from the prompt.

How would you have handled the wrong-country problem? I’d like to hear other approaches in the comments.

Designing AI Systems with an API Mindset

Prasanth Pattathil — Tue, 20 Oct 2026 12:01:02 +0000

Introducing the AI Architecture Casebook, a series on real-world AI design decisions

The system around the model

For years, my work has been about how systems talk to each other: who is allowed to call what, where trust is decided, what happens when a dependency fails, and what every call costs. Those questions shaped how I think about any system before a single line of code is written.

When I started working with AI, I noticed how often those questions go unasked. Permissions end up written into prompts. Costs grow with no budget. Answers ship with no way to tell whether they’re right. The model gets all the attention, while the system around it, where most failures actually happen, gets very little.

I’m not the only one noticing. In everyday conversations with friends and colleagues from different companies, AI scenarios keep coming up that made the people who designed them stop and rethink. Nobody has all the answers yet. Everyone is learning, me included. And each time, I catch myself asking the same question: what would I do in this situation?

This series is my answer to that question, one problem at a time. Each post takes a real-world AI scenario and works through it the way I’d approach any design: what must never go wrong, which options exist, what each one costs, and which trade-offs I’d accept. I record the decisions as architecture decision records, including the options I rejected and when I’d revisit them.

The companies and people in these stories are made up. The problems are very real. To keep each case study readable, I simplify on purpose: one company, a few rules, a clear scope. Your real systems are probably messier, with more roles, more exceptions and more history. Where a simplification would change the design at a larger scale, I’ll say so. If you’ve faced something similar, or you’d design it differently, I’d like to hear it in the comments. Learning together is the point.