Design an agent that automates invoice processing end to end: receive, extract, match to purchase orders, and schedule payment. Finance signs off on it. What does the design look like?

Question

Accepted Answer

First decision: this is a workflow with LLM steps, not a free-form agent. The process is known, so orchestration is deterministic code with the model working inside steps, which is what makes it auditable and signable. Extraction: vision-capable model on the document, schema-constrained, every field typed and nullable so absence is never fabricated, followed by deterministic validation: dates parse, formats check, line items sum to subtotal, subtotal plus tax equals total, and that arithmetic alone catches most misreads. Matching: retrieve candidate POs by supplier and reference, score on amount, lines and terms, three-way match against goods receipts where they exist, outputting a match confidence plus named discrepancies. The autonomy tiers are the part finance signs, so they are policy, not model judgment: clean extraction, exact PO match, approved supplier, amount under say 5,000 auto-processes, often 60 to 70 percent of volume; soft exceptions queue for one-click human approval with the case prepared and the discrepancy highlighted; hard exceptions, no PO, new supplier, large variance, above-cap amounts, always go to a human. Money-grade engineering underneath: idempotency keys on every payment-adjacent action so a crashed and resumed run cannot schedule twice; checkpointed state per invoice, the pipeline resumes, never replays; duplicate detection on supplier, number, amount and near-duplicates, the classic invoice fraud and error mode; an immutable audit log of every extraction, match score, decision and actor, human or system, which is what the auditors actually ask for; and hard limits in code, no single payment above X, daily aggregate caps, new-supplier holds, that no model output can override. Measured like a finance system: straight-through rate, per-field accuracy, exception aging, and a monthly sampled audit of auto-processed invoices feeding the eval set. Rollout: 4 weeks of shadow mode, then auto-processing for the lowest tier only, expanding as the audit stays clean.

Answer

Why is the escalation boundary policy rather than model confidence?

Model self-assessment is uncalibrated and gameable by a weird invoice. Finance can audit "under 5,000, exact match, approved supplier"; nobody can audit "the model felt sure". Confidence can inform the tiers, never define them.

Answer

An invoice was paid twice anyway. Walk me through what failed and what you check.

The audit log first: was it two documents evading duplicate detection, an idempotency key gap on retry, or a human override. Each has a different fix, near-duplicate matching, key coverage on every side-effect path, or override friction. The log answers it in minutes, which is why it exists.

Design an agent that automates invoice processing end to end: receive, extract, match to purchase orders, and schedule payment. Finance signs off on it. What does the design look like?

Design an agent that automates invoice processing end to end: receive, extract, match to purchase orders, and schedule payment. Finance signs off on it. What does the design look like?

The follow-ups they ask next

What the interviewer is listening for

What sinks the answer

If you genuinely do not know

Keep going with system design

Knowing the answer is not the same as recalling it under pressure