Invoice data extraction

It binds a schema (Pydantic model, TypedDict or JSON Schema) to a chat model, using the provider's tool calling or JSON mode, so the model returns an object matching the schema instead of free text. You get typed, validated data, and a validation error when it does not fit.

Receive invoices by email or upload, convert PDFs and images to text with layout (OCR where needed) or send pages to a vision model, extract fields with with_structured_output into a Pydantic schema, validate totals, tax and supplier details with code, match against purchase orders and goods receipts, and route mismatches or low-confidence fields to an accounts payable reviewer before posting to the ERP.

Include header fields (supplier name and tax ID, invoice number, dates, currency, totals, tax amounts) and a list of line items (description, quantity, unit price, tax rate, amount), with types, formats and descriptions for each field, and optional fields marked explicitly rather than guessed.

Compare the invoice with the purchase order (prices, quantities, supplier) and the goods receipt (quantities received); within tolerance it can be approved automatically, otherwise it is flagged with the specific differences for review.

Models can misread digits or invent values that look plausible. Code checks that line items sum to the total, tax rates are valid, the vendor exists, the purchase order matches and the invoice is not a duplicate. Failing checks route the invoice to a person.

Rely on a general extraction model with a strong schema rather than per-template rules, add supplier-specific hints for difficult formats, and learn from reviewer corrections per supplier.

Combine validation results (totals add up, formats valid, supplier found), agreement between two extraction passes or models, and OCR confidence, and route fields below thresholds to review.

Check supplier plus invoice number plus amount against history, detect near-duplicates with fuzzy matching, verify bank details against the supplier master, and flag changes in bank accounts for verification by phone.

Extract GSTIN, HSN or SAC codes and tax splits (CGST, SGST, IGST), validate the GSTIN format and state codes, recompute tax amounts in code, and flag inconsistencies.

The original invoice with highlighted source regions next to extracted fields, validation errors and mismatch details, with quick edit and approve actions; corrections are saved for learning.

Process asynchronously through a queue, batch model calls, cache supplier data, use cheaper models for easy invoices and stronger ones for hard ones, and monitor throughput and error rates.

Use the ERP's API to create the payable with the vendor, GL coding and PO references, idempotently keyed by supplier and invoice number, and record the ERP document ID back on the invoice.

Recompute line amounts from quantity and unit price, sum lines plus tax, freight and discounts, and compare with the stated subtotal, tax and grand total within a small rounding tolerance. Any mismatch sends the invoice to review with the failing check highlighted.

Look up approval rules by cost centre, amount band, supplier category and whether a PO exists, assign the approver from the organisation chart, escalate if they are absent or do not act within the deadline, and record every approval with time and comments.

Label a sample of real invoices field by field, compare the extracted values per field (exact match for IDs, tolerance for amounts), and report accuracy per field and per supplier template. Track it over time as new templates appear.

Use rules from the PO and supplier defaults first, then a classifier trained on past coding for non-PO invoices, with low-confidence suggestions reviewed.

Process all pages together, detect continuation of line item tables, ignore unrelated attachments like terms and conditions, and keep page references for each field.

Use OCR or vision models designed for handwriting, ask the supplier for a digital copy when quality is too low, and always route such invoices to review.

Run it on a labelled set of invoices with field-level ground truth, compare field accuracy, straight-through processing rate and cost against the current model, then pilot on a subset.

Invoices that pass extraction, validation and matching without any human touch and are posted automatically; increasing its share is the main efficiency goal.

Encrypt documents and extracted data, restrict access to finance roles, mask bank details in logs, and keep audit trails of every change and approval.

Structured e-invoices (such as India's IRN-based e-invoicing, Peppol or UBL XML) can be parsed directly without AI extraction, so the pipeline should detect and prefer them.

Store corrected fields with the document, analyse frequent errors by supplier and field, add examples to prompts or fine-tuning sets, and re-evaluate regularly.

Extract the payment terms, such as 2/10 net 30, compute the discount deadline from the invoice date, prioritise those invoices in the approval queue, and schedule payment before the deadline when cash policy allows.

Monitor a dedicated mailbox, separate the invoice attachments from other files, handle invoices embedded in the email body, record the sender and message ID for traceability, and reject or quarantine files with suspicious types.

Match extracted supplier names, tax IDs and bank details against the vendor master, never create a new vendor automatically, and send unknown or changed details to the vendor management team for verification.

Use a held-out set of real invoices in a secure environment with access controls, plus synthetic invoices generated from templates for edge cases, and compare field-level accuracy without exporting the documents.

Route them for approval by the budget owner according to spend limits, with suggested GL coding, before posting.

Classify document type first; credit notes reduce payables and must be linked to the original invoice, with amounts validated as negative adjustments.

Field-level accuracy, straight-through processing rate, time from receipt to posting, exception rate by reason, duplicate catches and cost per invoice.

Extract the invoice currency, convert using the official rate for the posting date in code, and store both original and converted amounts.

Determine the applicable section and rate from the supplier's status and service type, calculate the deduction on the right base amount, record it separately in the ledger, and generate the certificates and filings required.

1. AThe vector store
2. BThe PDF file name
3. CA schema such as a Pydantic modelCorrect answer
4. DThe temperature setting

Why: The schema is passed to with_structured_output and enforced on the result.

1. AThree currencies
2. BInvoice vs. purchase order vs. goods receiptCorrect answer
3. CThree OCR passes
4. DThree reviewers

Why: Catches price and quantity errors.

1. AA PDF file
2. BA large font
3. CA change in the supplier's bank accountCorrect answer
4. DA new invoice number

Why: A common fraud pattern.

1. AExplicitly optional, not guessedCorrect answer
2. BFilled with likely values
3. CLeft as zero
4. DCopied from another invoice

Why: Guesses become errors.

1. AThe model
2. BValidation codeCorrect answer
3. CThe supplier
4. DNobody

Why: Deterministic arithmetic belongs in code.

1. ARecomputed in code from rates and linesCorrect answer
2. BTrusted from the model
3. CIgnored
4. DRounded up

Why: Tax needs exact arithmetic in code.

1. AIgnoring layouts
2. BA strong schema with a general modelCorrect answer
3. COne regex per supplier only
4. DManual typing

Why: Add supplier-specific hints where needed.

1. AManual checks only
2. BLonger timeouts
3. CAn idempotency key from supplier and invoice numberCorrect answer
4. DPosting twice

Why: Avoid duplicate payables.

1. APaying early
2. BSkipping validation
3. CPosting without any human touchCorrect answer
4. DScanning faster

Why: The key efficiency goal.

1. AClean digital PDFs within tolerance
2. BMatched PO invoices
3. CCredit-checked suppliers
4. DPoor-quality or handwritten scansCorrect answer

Why: Low confidence needs humans.

1. AThe supplier's website
2. BThe highlighted source regionCorrect answer
3. CThe model's weights
4. DNothing

Why: Highlights make verification fast.

1. ACounting pages
2. BRecomputing lines, tax and totals within a toleranceCorrect answer
3. CTrusting the model's total
4. DChecking the font

Why: Arithmetic checks catch extraction errors.

1. ACost centre, amount band and PO statusCorrect answer
2. BThe supplier's logo
3. CInvoice file size
4. DThe time of upload

Why: Approval rules follow finance policy.

1. AA duplicate check on vendor + invoice number + amountCorrect answer
2. BOCR
3. CLower temperature
4. DA larger model

Why: A uniqueness check catches resubmitted invoices.

1. AGSTIN and HSN/SAC codesCorrect answer
2. BSWIFT only
3. CIBAN only
4. DSSN

Why: Validate their formats.

1. AIgnored
2. BPrinted and scanned
3. CParsed directly without AI extractionCorrect answer
4. DOCRed anyway

Why: Parsing them is cheaper and exact.

1. AThe supplier's logo
2. BThe invoice date
3. CA classifier trained on past codingCorrect answer
4. DRandom choice

Why: Review low-confidence suggestions.

1. APaid out
2. BLinked to the original invoiceCorrect answer
3. CTreated as new invoices
4. DIgnored

Why: They reduce payables.

1. ABy model size
2. BBy release date
3. CField accuracy, STP rate and cost on a labelled setCorrect answer
4. DBy reading a few outputs

Why: Then pilot on a subset.

1. ALarger PDFs
2. BQueues, batching and model routingCorrect answer
3. COne synchronous request each
4. DManual review of all

Why: Cheaper models for easy cases.

1. APublished
2. BMaskedCorrect answer
3. CLogged in full
4. DEmailed

Why: Protect sensitive data.

1. AAutomatic payment
2. BRejection always
3. CNothing
4. DBudget owner approval within limitsCorrect answer

Why: Approvals keep spending under control.

1. A2% discount if paid within 10 days, else due in 30Correct answer
2. BPay 10% in 2 days
3. C30 instalments
4. DNo discount

Why: Early payment earns the discount.

1. AUsed to create a new vendor automatically
2. BIgnored
3. CPaid immediately
4. DSent to vendor management for verificationCorrect answer

Why: Automatic vendor creation invites fraud.

1. ANothing
2. BThe reviewer's name
3. CSender and message IDCorrect answer
4. DThe subject line only

Why: Traceability links the payment to its source.

1. AOn personal laptops
2. BIn a secure environment with access controlsCorrect answer
3. CIn public test repositories
4. DIn chat messages

Why: Financial documents carry confidential data.

1. AIn code with the official posting-date rateCorrect answer
2. BBy the model
3. CRandomly
4. DNever

Why: Store both original and converted amounts.

1. AFinding frequent errors and improving promptsCorrect answer
2. BNothing
3. CDeleting invoices
4. DTraining suppliers

Why: Learn per supplier and field.

1. ANumber of suppliers
2. BFont size
3. CPage count
4. DException rate by reasonCorrect answer

Why: Fix the biggest causes.

1. AJoined across pagesCorrect answer
2. BRead from page one only
3. CIgnored
4. DSplit into invoices

Why: Tables continue across pages.

1. AMP3
2. BPeppol or UBLCorrect answer
3. CHTML
4. DPNG

Why: Structured XML formats.

1. AOnly on paper
2. BNot at all
3. CSeparately in the ledgerCorrect answer
4. DInside the invoice total

Why: Separate records support certificates and filings.