Invoice and document data extraction with AI: how to set it up
Extract vendor, dates, line items and totals from invoices with AI: the pipeline, the checks that catch errors, the accuracy to expect and what it costs.
By Sohail Hussain2 November 20267 min read
To extract data from invoices with AI, send each document to a model that can read PDFs and images, give it a fixed schema of the fields you want, and run every result through arithmetic and lookup checks before anything reaches your accounting system. The model does the reading. The checks decide what can be trusted. Anything that fails a check goes to a person, who sees the document and the extracted fields side by side and fixes it in seconds.
That split is what makes extraction safe to run every day. This guide covers the pipeline, the schema, the checks, the accuracy to expect and the running cost as of October 2026.
What does an AI invoice extraction pipeline look like?
It has eight steps, and only one of them uses AI. We build it this way as part of our AI workflow automation work, and invoice entry is usually the first of the 20 tasks worth automating first for a finance team.
- Collect. Invoices arrive at one dedicated address such as invoices@, or land in a shared folder. The workflow stores every original file before touching it.
- Prepare. Split PDFs that contain several invoices, reject files that are not invoices, and record a hash of each file so the same document is never processed twice.
- Extract. Send the file to the model with your schema and get structured fields back.
- Validate. Check the arithmetic, the formats, duplicates and the supplier against your records.
- Match. Compare against the purchase order and delivery note, if you use them.
- Review. Put anything that failed a check in a review queue.
- Post. Create the bill in your accounting system through its API, with the original attached.
- Log. Record what ran, what passed, what a person changed and how long it took.
Steps 1, 2 and 4 to 8 are ordinary automation: rules that cost nothing to run and behave the same way every time. Keeping AI to step 3 is what makes the workflow cheap to run and easy to debug. For the posting step with Indian accounting systems, Tally and Zoho Books integrations covers the options.
How do you get clean, structured fields out of the model?
Ask for JSON that matches a schema, and switch on the provider's structured output feature so the response cannot come back in any other shape. All three major providers offer this as of October 2026: Anthropic through structured outputs, OpenAI through Structured Outputs, and Google through a response schema in the Gemini API. With it, you stop writing code to repair half-formed JSON.
A trimmed version of the schema we start from:
{
"type": "object",
"properties": {
"supplier_name": { "type": "string" },
"supplier_tax_id": { "anyOf": [{ "type": "string" }, { "type": "null" }] },
"invoice_number": { "type": "string" },
"invoice_date": { "type": "string", "format": "date" },
"po_number": { "anyOf": [{ "type": "string" }, { "type": "null" }] },
"currency": { "type": "string" },
"line_items": {
"type": "array",
"items": {
"type": "object",
"properties": {
"description": { "type": "string" },
"quantity": { "type": "number" },
"unit_price": { "type": "number" },
"amount": { "type": "number" }
},
"required": ["description", "quantity", "unit_price", "amount"],
"additionalProperties": false
}
},
"subtotal": { "type": "number" },
"tax_total": { "type": "number" },
"total": { "type": "number" }
},
"required": ["supplier_name", "supplier_tax_id", "invoice_number", "invoice_date", "po_number", "currency", "line_items", "subtotal", "tax_total", "total"],
"additionalProperties": false
}
Three rules in the prompt matter more than the schema itself.
Extract, do not calculate. Ask for the figures printed on the document. Do the sums yourself, in code. If the model reports a total, you want the total on the paper, not its own arithmetic.
Allow "not present". Fields that can be missing, such as a PO number, should accept null. A model forced to fill every field will fill it with something.
State the date convention. 03/04/2026 is 3 April in India and the UK and 4 March in the US. The model cannot know which unless the document or your prompt says so.
If you build in n8n rather than code, its Information Extractor node does the same job with a schema defined from attribute descriptions, a JSON example or a JSON Schema. n8n for business automation covers that route.
Which checks catch the extraction errors?
The checks are where reliability comes from. Each one is a few lines of code, and together they catch nearly every error that matters.
| Check | What it catches |
|---|---|
| Line amounts add up to the subtotal | Missed, merged or duplicated lines |
| Subtotal plus tax equals the total, within rounding | Misread figures |
| Tax rate is one this supplier normally charges | Misread rates, wrong tax treatment |
| Tax ID has the right format (a GSTIN has 15 characters; a UAE TRN has 15 digits) | Misread or missing IDs |
| Supplier exists in your records, with the same bank details | New or impersonated suppliers |
| Supplier plus invoice number not already posted | Duplicates, resent invoices |
| Date not in the future and not older than your cut-off | Misread dates, stale invoices |
| Quantities and amounts within tolerance of the PO | Over-billing, partial deliveries |
Changed bank details deserve their own rule. Invoice fraud often arrives as a genuine-looking invoice with new payment details. The workflow should never update bank details from an invoice; it should stop and ask a person.
Design the review screen for speed: the document on the left, the fields on the right, failed checks highlighted, one key to approve. Where to keep a human in the loop covers how to keep that review quick enough that people actually do it.
How accurate is AI extraction, and where does it fail?
On clean, typed invoices, per-field accuracy well above 95 percent is normal as of October 2026. The errors are not spread evenly. They cluster in a few places:
- Totals on multi-page invoices, where line items continue onto a second page.
- Handwritten amounts, stamps over text and poor phone photos.
- Credit notes and proforma invoices mistaken for invoices.
- Layouts with two tax columns or prices shown both with and without tax.
Measure accuracy on your own documents before you trust any figure, including ours. Take 100 recent invoices that someone has already entered by hand, run them through the pipeline, and compare field by field. Evaluations: how to know your AI feature works explains how to turn that into a test you re-run whenever you change the prompt or model.
What does it cost to run?
Model costs are small. Assume each invoice uses about 4,000 input tokens (instructions plus the document) and 600 output tokens, and you process 2,000 a month. At list prices as of October 2026:
| Model | Input / output per 1M tokens | Per month |
|---|---|---|
| GPT-6 Luna | $0.10 / $0.50 | about $1.40 |
| Claude Haiku 5.5 | $0.10 / $0.50 | about $1.40 |
| Gemini 3.8 Flash | $0.75 / $3.75 | about $10.50 |
| Claude Sonnet 5.5 | $2 / $10 | about $28 |
| Claude Opus 5.5 | $4 / $20 | about $56 |
Your token counts will differ. Long, multi-page documents cost more, and scans cost more than text PDFs. Measure a few of your own invoices with the token counter, then put your volume into the AI API cost calculator. If invoices can wait a few hours, all three providers offer batch processing at half price.
The build is the real cost. A single extraction workflow with checks, a review screen and a connection to your accounting system costs ₹1,50,000 to ₹6,00,000 in India or $4,000 to $15,000 elsewhere from a studio, as of October 2026. Whether that pays back depends on volume. 2,000 invoices at three minutes each is 100 hours a month; the automation hours-saved calculator does the arithmetic for your own numbers.
When is AI extraction not worth building?
When volume is low. At 100 invoices a month, data entry takes about five hours. A custom pipeline will take years to pay back.
When your accounting software already does it. Many accounting packages now include bill scanning. Test the built-in feature on 50 of your own invoices before paying for anything custom. If it gets most of them right, the gap is not worth a project.
When suppliers can send structured data. E-invoices, EDI files or a supplier portal give you exact data with no reading involved. Ask your ten largest suppliers by volume what they can send; structured data beats extraction every time.
When documents are mostly handwritten. Accuracy drops far enough that the review step does most of the work.
If none of those apply, start small. Pick your three largest suppliers, run their last 100 invoices through a prototype with the checks above, and compare against what your team entered. The result tells you whether to build the full pipeline and which model it needs; choosing the right model for each task covers that second decision.
Was this guide useful?