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.

  1. 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.
  2. 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.
  3. Extract. Send the file to the model with your schema and get structured fields back.
  4. Validate. Check the arithmetic, the formats, duplicates and the supplier against your records.
  5. Match. Compare against the purchase order and delivery note, if you use them.
  6. Review. Put anything that failed a check in a review queue.
  7. Post. Create the bill in your accounting system through its API, with the original attached.
  8. 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:

json
{
  "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.

CheckWhat it catches
Line amounts add up to the subtotalMissed, merged or duplicated lines
Subtotal plus tax equals the total, within roundingMisread figures
Tax rate is one this supplier normally chargesMisread 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 detailsNew or impersonated suppliers
Supplier plus invoice number not already postedDuplicates, resent invoices
Date not in the future and not older than your cut-offMisread dates, stale invoices
Quantities and amounts within tolerance of the POOver-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:

ModelInput / output per 1M tokensPer month
GPT-6 Luna$0.10 / $0.50about $1.40
Claude Haiku 5.5$0.10 / $0.50about $1.40
Gemini 3.8 Flash$0.75 / $3.75about $10.50
Claude Sonnet 5.5$2 / $10about $28
Claude Opus 5.5$4 / $20about $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?

Questions

Frequently asked.

Do we still need separate OCR software?

Usually not. Current models read PDFs and images directly, including scans, and return structured fields in one step. A separate OCR pass still helps with very poor scans or when you must store searchable text for compliance, but for typed invoices from suppliers it adds cost and another place for errors without improving accuracy much.

Which model should we use for invoice extraction?

Start with a small model such as GPT-6 Luna or Claude Haiku 5.5 and measure it on 100 of your own invoices. Move to a mid-tier model only for the document types where the small one fails the checks too often. Many teams end up with a small model for most suppliers and a larger one for a handful of awkward layouts.

Can it handle invoices in Arabic or Hindi?

The major models read Arabic, Hindi and mixed-language invoices, but accuracy is lower than for English and varies more by layout. Test with your own documents, keep the review step on for those suppliers longer, and ask for amounts as numbers so the script on the page does not matter for the checks.

Sohail Hussain

Founder, MSH Technologies

Sohail has designed and built websites, web apps and AI products for over 12 years, for clients from Singapore-based industrial groups to early-stage SaaS startups. He writes about what actually worked.

Keep reading

Related guides.

All posts

Your next move

Like what you see? Tell us about it.

A process that takes too long, a website that undersells you, or an idea ready to take shape. Tell us where you are and we will suggest a useful next step.

India · Working with clients worldwide

We reply within a working day. No spam, ever.