In this article
  1. Before you start
  2. Why interviewers ask this
  3. Invoice extraction pipeline from first principles
  4. Worked example
  5. Trade-offs and edge cases
  6. How to answer it in an interview
  7. Common mistakes
  8. Follow-up questions
  9. Sources

Before you start

This page is one step of the GenAI system design interview guide learning path.

Why interviewers ask this

An invoice pipeline is a compact test of whether a candidate treats a model as one unreliable part inside a system. The input is messy: scanned Portable Document Format (PDF) files, photos and tables. The output feeds an enterprise resource planning (ERP) system, where a wrong total becomes a wrong payment.

A weak answer says "send the PDF to the model and ask for JSON." A strong answer names the stages, forces a schema, and says what the schema does not check. A Staff-level answer adds validation that does not trust the model, a per-field gate for human review, and a labelled sample to measure the whole thing. The neighbouring LLM document-processing pipeline design covers the general case; this page narrows to invoices.

Invoice extraction pipeline from first principles

strict schema
A strict schema is a JSON Schema, supplied with the request, that the model's output is forced to follow, with every property required and no extra properties allowed, so the output has the right keys and types but not necessarily the right values.
Field-level confidence
Field-level confidence is a score between zero and one attached to one extracted value, such as the invoice total, that estimates how likely that value was read correctly, so a pipeline can send only the weak fields to a person instead of judging the whole document.
Review queue
A review queue is a list of extracted records, or single fields, that a person must confirm or correct before the data is exported to the accounting system, filled by the validation and confidence checks that sit before it in the pipeline.

In plain words

Picture a mailroom clerk who types invoices into the ledger. A second person adds up the columns. Anything the clerk could not read goes to a supervisor.

That is the pipeline. The five stages are read the file, extract into a schema, validate, route to review and export. The analogy breaks in one place: a model does not hesitate when it guesses. It sounds as sure when wrong as when right, so the checks must come from outside the model.

In one precise sentence, the pipeline maps a file to a schema-shaped record, rejects records whose numbers contradict each other, and lets a person settle the rest.

Step 1: Classify the file and read the page

The input is one file; the output is text or page images. First classify it. A native electronic invoice is an Extensible Markup Language (XML) file and needs a parser, not a model. European Norm (EN) 16931 is the standard for the semantic data model of an electronic invoice, and Universal Business Language (UBL) and Cross Industry Invoice (CII) are XML syntaxes for it (e-invoice.be, read 2026-10-26).

The standard also names the terms a schema needs: seller, buyer, value-added tax (VAT) breakdown, totals and line items. Some PDFs are hybrid e-invoices (Factur-X, ZUGFeRD) with the XML embedded inside the file, and the validator page lists both as users of the CII syntax (e-invoice.be); extract and parse that XML before treating the file as a PDF.

Only PDFs and scans without embedded invoice XML need a model. A PDF with a text layer can be read as text; a scan needs OCR or page images. The Claude documentation says each page typically uses 1,500–3,000 text tokens depending on content density, that image costs apply because each page is converted to an image, and that standard pricing applies with no additional PDF fee.

Step 2: Extract into a strict schema, which fixes the shape but not the values

JSON mode is a setting that makes a model return valid JSON, but not necessarily the keys you asked for. OpenAI's guide says that while both ensure valid JSON is produced, only Structured Outputs ensure schema adherence. You switch it on with strict: true and a json_schema, list every property under required and set additionalProperties to false. Where an invoice can omit a field, a common pattern is to allow null for it; check your provider's schema rules first. The schema sits in response_format for Chat Completions (Microsoft Learn) and in text.format for the Responses application programming interface (API), and a safety refusal can be detected in code; both are documented in OpenAI's guide.

Here is the catch. A strict schema checks that total exists and is a number. It does not check that the number is the one printed on the page, so a misread digit passes. Step 3 catches it.

Step 3: Validate the arithmetic and the business rules

Validation is code that tests the extracted record against rules the model cannot bend. Quantity times unit price must sum to the subtotal. The total check follows the standard's document totals (EN 16931 mapper): the line net sum, minus document-level allowances, plus charges, plus VAT for each rate, then minus any prepaid amount to get the amount due. A rounding tolerance such as an illustrative 0.01 absorbs cents. The worked example below is the simple case of one rate and no allowances. The currency must be one you accept, the date must be plausible, the vendor must exist in your master list, and the invoice number must not already be booked.

Arithmetic checks catch totals that do not add up. They cannot catch values that are wrong but consistent with each other, such as a vendor read from the wrong block.

Layering is standard practice in e-invoicing. A Peppol validator describes three layers of checks: XML syntax, EN 16931 business rules and Peppol schematron rules (schematron is a rule language that tests an XML file against business rules) (e-invoice.be), and Peppol Business Interoperability Specifications (BIS) Billing 3.0 adds hundreds of business rules on top of EN 16931 (eConnect).

Step 4: Route weak fields to a person

Routing sends a record to a review queue when a field fails a check or scores low. Field-level confidence beats a document-level score. Microsoft's accuracy and confidence documentation advises targeting a score of 80% or higher, and close to 100% for financial or medical records; a dev.to guide quotes the same advice. That guide's advice is to gate on the fields that carry financial or legal consequence, individually.

Do not assume every service returns a score: Microsoft's own Q&A says not all fields return a confidence score (Microsoft Q&A). A language model's reply does not come with a calibrated one (a score that matches how often the value is really right). Build signals instead: validation outcomes, agreement between two extraction runs, or token probabilities where the interface exposes them.

Step 5: Export and measure

Export writes the approved record to the ERP system. Attach the source page reference, the schema version and the model version to every record, so a disputed payment can be traced. Make the export safe to repeat, keyed on vendor plus invoice number, so a retry cannot book twice.

Then measure. Hand-label a sample of invoices and compare field by field with exact match, reporting the review rate and the errors that escape review as well. Reviewer corrections become new labelled data, so the sample grows with use and the thresholds of Step 4 can be tuned against real mistakes instead of guesses. You now have the whole system: classify, extract, validate, route and export.

Each pipeline stage checks the record before the exportFlow of five stages: read the file, extract into a strict schema, validate sums and rules, route weak fields to a person, and export to the ledger.Read the filetext, OCR or imagesExtractstrict schemaValidatesums and rulesRoutefield confidence gateExportledger and logDiagram: Interview Clozo, CC BY 4.0 ·interview.clozo.ai/blog/invoice-extraction-llm-pipeline.html

Each stage hands a narrower, better-checked record to the next, so errors are caught before the export.CC BY 4.0 — source: How does an invoice extraction LLM pipeline work?
Step-by-step description
  1. Parse the XML, or read text and page images.
  2. The model fills a strict schema.
  3. Code checks sums and rules.
  4. Weak fields go to a person.
  5. The approved record reaches the ledger.
  • The five stages are read the file, extract into a schema, validate, route to review and export.
  • Validation catches totals that do not add up.

Knowing it is half the job. Saying it is the other half.

Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.

Start Free Trial →

Worked example

Take one illustrative invoice with three lines: 12 units at 18.50, 3 at 145.00 and 1 at 64.25. The line amounts are 222.00, 435.00 and 64.25, so the subtotal is 721.25. At an illustrative tax rate of 20%, tax is 144.25 and the correct total is 865.50.1 Suppose the model returns 856.50, two digits swapped. The strict schema accepts it: the key is there and the type is a number. The validation step adds subtotal and tax, gets 865.50, and finds a difference of 9.00, far above the 0.01 tolerance, so the invoice goes to review.1

The misread total of 856.50 passes the schema but fails validation, because it is 9.00 away from the 865.50 that the lines and tax add up to.1
QuantityValue (illustrative)
Line amounts222.00, 435.00, 64.25
Subtotal721.25
Tax at 20%144.25
Correct total865.50
Total the model returned856.50
Difference found by validation9.00
Input tokens per two-page invoice, before the prompt and schema6,000 to 9,000
Input tokens for 10,000 invoices a month60,000,000 to 90,000,000

The token rows use the Claude range of 1,500–3,000 text tokens per page (Claude documentation) for two pages, plus an illustrative 1,500 image tokens per page, before the prompt and schema.1 To price it, multiply by your vendor's current price per million tokens; those prices change, so none is quoted here. Sending extracted text alone drops the image tokens but can lose layout cues such as table columns.

Now the gate. Take four illustrative field scores, modelled on a dev.to guide in which a high document-level score hid a weak total: invoice number 0.981, vendor name 0.944, invoice date 0.972 and invoice total 0.612, with a document-level score of 0.93. The total field scores 0.612 while the other three fields score 0.94 or higher. A document-level gate at 0.80 would pass this invoice. The review gate is 0.80 for the other three fields and 0.95 for the total, a financial field, so the total fails its gate and the invoice goes to review.1

One weak field hides inside a high document scoreBar chart of illustrative field confidence for one invoice next to each field's review gate: invoice number 0.981, vendor name 0.944, invoice date 0.972 and invoice total 0.612 against a total gate of 0.95.Field confidence00.51Invoice numberVendor nameInvoice dateInvoice totalInvoice fieldField confidenceReview gate0.9810.9440.9720.6120.80.80.80.95Below its gateDiagram: Interview Clozo, CC BY 4.0 ·interview.clozo.ai/blog/invoice-extraction-llm-pipeline.html
A high document score can hide one weak field, so the gate looks at each field on its own.CC BY 4.0 — source: How does an invoice extraction LLM pipeline work?
Text description of the diagram
  • The total field scores 0.612 while the other three fields score 0.94 or higher.
  • The review gate is 0.80 for the other three fields and 0.95 for the total.

Finally, measure. On an illustrative labelled sample of 200 invoices, 188 totals match exactly, which is 94.0%. Of the 12 wrong totals, validation catches 9, so 3 wrong totals reach the export, and, assuming reviewers correct every flagged invoice, the exact-match rate after review is 98.5%. Validation also flags 6 correct invoices, so 15 invoices, or 7.5%, go to a person.1

Trade-offs and edge cases

Each check layer catches a different kind of error, and the combination is the design.

Each check layer catches a different kind of invoice errorTable of four layers: JSON mode, strict schema, arithmetic checks and confidence routing, each with the kind of error it catches and the kind it misses.LayerCatchesMissesJSON modeBroken JSONsyntaxMissing keys,wrong typesSchema (strict mode)Missing keys,bad optionsWrong numbersArithmetic checksTotals that donot add upConsistent butwrong valuesConfidence routingWeak readsConfident errorsDiagram: Interview Clozo, CC BY 4.0 ·interview.clozo.ai/blog/invoice-extraction-llm-pipeline.html
No single layer catches every error, so a pipeline stacks them.CC BY 4.0 — source: How does an invoice extraction LLM pipeline work?
Text description of the diagram
  • A strict schema catches missing keys but not wrong numbers.
  • Arithmetic checks catch totals that do not add up.

A strict schema catches missing keys but not wrong numbers. Arithmetic checks catch totals that do not add up, and confidence routing catches weak reads but not confident errors.

Edge cases worth naming:

  • Images or text. Page images keep layout, which helps with tables; extracted text is cheaper but can lose columns. The OCR text of the Scanned Receipts OCR and Information Extraction (SROIE) dataset, a receipt benchmark, is reported to contain numerous little errors (arXiv 2309.05429), so an OCR stage adds its own error source. For tables that span pages or mix columns, see designing retrieval-augmented generation (RAG) over real documents with tables and charts.
  • Benchmarks. The SROIE competition set has 1000 whole scanned receipt images and three tasks (Huang et al.), and most test layouts also occur in the training set (arXiv 2309.05429). It covers receipts, not multi-page vendor invoices, so its scores say little about your invoices; label your own sample.
  • Number and date formats. Normalise decimal separators and date order per vendor or country before validation; a swapped separator can turn 1.234,56 into 1.23456 (illustrative), and 03/04 can be March or April. The result is well typed but wrong, and an arithmetic check may or may not catch it.
  • Untrusted text. Text inside an invoice is input, not instruction. Keep the model's output limited to the schema and give it no tools.
  • Platform. Retries, keys and logging belong behind a gateway; see the LLM gateway interview questions. Invoices rarely need retrieval, so whether you need retrieval-augmented generation (RAG) at all is a fair opening question.

How to answer it in an interview

Interviewer asks

Design a pipeline that extracts data from vendor invoices with an LLM.

A strong answer

I would build five stages. First I classify the file: e-invoices that carry XML, native or embedded in a PDF, are parsed directly, and only PDFs and scans without it go to a model. Then I extract into a strict schema, with every field required and nullable where an invoice can omit it. A strict schema fixes the shape, not the values, so the third stage checks that lines add up to the subtotal and the subtotal plus tax equals the total. Fourth, I gate each field on its own confidence, not the document's, and send weak ones to a review queue. Finally I export with the source page attached and measure field-level accuracy on a labelled sample.

The spoken structure: classify, extract with a schema, say what the schema does not check, validate, route by field, then measure.

Common mistakes

  • "JSON mode gives me my schema." (wrong) JSON mode ensures valid JSON, not adherence to your schema. (right) "I use structured outputs with a strict schema, and I still validate the values."
  • "Structured outputs mean the total is correct." (wrong) They fix format, not truth. (right) "I recompute the total from the lines and tax and compare."
  • "The document confidence is high, so every field is safe." (wrong) One weak field can hide inside a high document score. (right) "I gate on each financial field individually."
  • "I send every invoice, including UBL files, to the model." (wrong) Structured XML can be parsed with no model at all, including XML embedded in hybrid PDFs such as Factur-X. (right) "I parse native and embedded e-invoice XML and use the model only for PDFs and scans without it."
  • "The benchmark score tells me my accuracy." (wrong) Receipt benchmarks do not transfer to your vendors. (right) "I label a sample of my own invoices."

Follow-up questions

Is JSON mode enough for invoice extraction?

No. JSON mode ensures valid JSON, while only Structured Outputs ensure schema adherence (OpenAI), and neither checks that the values are correct. Add arithmetic and business-rule validation after the model.

Do you need OCR if the model can read the page image?

Not always. A vision-capable model can read page images directly, at the image token cost the vendor documents. A separate OCR stage gives exact strings to check against, but adds its own errors, so compare both on a labelled sample.

How do you set a confidence threshold for invoice fields?

Start from the published guidance of 80% or higher, and nearer 100% for financial fields (dev.to guide). Then tune each field's threshold on a labelled sample, trading review rate against errors that escape.

Do you need an LLM for e-invoices such as UBL or Peppol?

No. Structured XML invoices, including XML embedded in hybrid PDFs, can be parsed and checked against the three validation layers of syntax, EN 16931 rules and Peppol rules (e-invoice.be). The model is for PDFs and scans without embedded XML.

How do you evaluate an invoice extraction pipeline?

Label a sample, then report field-level exact match, the review rate and the errors that escape review. In the worked example the total field goes from 94.0% exact match to 98.5% after validation and review, assuming reviewers fix every flagged invoice.1 The stage-by-stage evaluation of a RAG system uses the same habit of measuring each stage.

How much does it cost to extract one invoice?

Count tokens, then multiply by the vendor's current price per million tokens. A two-page invoice is about 6,000 to 9,000 input tokens in the example above, before the prompt and schema.1 Cheaper routes are sending extracted text instead of page images and reusing the repeated prompt and schema through the vendor's prompt caching.

Key takeaways
  • An invoice extraction pipeline classifies, extracts, validates, routes and exports.
  • Invoices with XML, native or embedded in a PDF, are parsed; only PDFs and scans without it need a model.
  • A strict schema fixes the shape of the output, not the values in it.
  • Recompute totals from the lines and tax, and gate each field on its own confidence.
  • Measure on your own labelled invoices, not on a receipt benchmark.

Sources

  1. Structured model outputs (OpenAI API docs) — OpenAI, 26 Oct 2026
  2. PDF support (Claude Platform Docs) — Anthropic, 26 Oct 2026
  3. Structured outputs with Azure OpenAI in Microsoft Foundry — Microsoft Learn, 26 Oct 2026
  4. ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction (arXiv 2103.10213) — arXiv (Huang et al.), 18 Mar 2021
  5. SROIE dataset analysis (arXiv 2309.05429) — arXiv, 1 Sep 2023
  6. EN 16931 mapper — e-invoice.be (secondary explainer), 26 Oct 2026
  7. Peppol validator — e-invoice.be (secondary explainer), 26 Oct 2026
  8. Peppol BIS Billing V3 — eConnect (secondary explainer), 26 Oct 2026
  9. Building an invoice extraction pipeline with Azure AI Document Intelligence and Power Automate — dev.to (secondary, quotes Microsoft guidance), 15 Sep 2026
  10. Document Intelligence not providing a confidence score (Microsoft Q&A) — Microsoft Learn Q&A, 17 Nov 2023
  11. Accuracy and confidence scores (Azure AI Document Intelligence) — Microsoft Learn, 26 Oct 2026