Extract data from PDFs, invoices and contracts with AI

Written by the editorial team · 12 November 2026 · Updated12 November 2026

Four approaches exist for pulling data out of PDFs, invoices and contracts: classic OCR, a language model, a cloud document service (Azure Document Intelligence, Google Document AI, Amazon Textract) and a custom agent. Fixed layouts in high volume suit a cloud service, varied documents suit a language model, and a business-specific process suits a custom agent. Whatever you pick, measure errors field by field on your own documents and keep a person in the loop for the fields that matter.

You have a folder of supplier invoices, signed contracts or scanned forms, and you want the amounts, dates and clauses in a table. There are four ways to get there, and the right one depends on how varied your documents are.

What are the four approaches?

Classic OCR turns the pixels of a scan into text. It tells you what is written, and nothing about what the text means. A line reading “12/03/2026” is text until something decides it is the due date.

A language model reads the text (or the image) and answers a question: what is the invoice number, who are the parties, when does the contract end. You describe the fields you want and the model fills them in, whatever the layout.

A cloud document service bundles OCR and extraction behind an API. Azure Document Intelligence describes itself as a machine-learning based OCR and intelligent document processing service. Its documentation lists a Read model for printed and handwritten text, a Layout model for text, tables and structure, prebuilt models for invoices, receipts and contracts among others, and custom models you train on labeled examples. Google Document AI lists Enterprise Document OCR, a Form Parser for tables and key-value pairs, pretrained processors for specialised document types and custom extractors. Amazon Textract lists text detection including handwriting, forms and tables, Queries, an AnalyzeExpense operation for invoices and receipts, and Custom Queries.

A custom agent combines a model with your rules and your tools: it reads the documents where you keep them, extracts the fields, checks them against your own data, and hands a person a result to validate.

When does each approach fit?

Classic OCR fits when all you need is searchable text, for example to make an archive of scans findable.

A cloud service fits a high volume of documents with a stable shape, such as invoices, where a prebuilt model already knows the fields. Check the model list of the service against your document types and your languages before you commit.

A language model fits documents that vary a lot: contracts written by different law firms, quotes in free format, reports where the figure you need sits in a paragraph. It handles layouts nobody planned for. In exchange, it can produce a plausible value that is not in the document, which is why validation matters more here.

A custom agent fits when extraction is one step in a longer process: reading a contract, comparing it with your standard terms, listing the deviations and drafting a note.

What schema should the output follow?

Define the output before you pick a tool. A good schema is a list of named fields, each with a type (text, number, date, amount with currency), and a rule for absence: when the document does not contain the value, the field is empty, never guessed. Add two things to every field, the page where the value was found and the quote it came from. A reviewer then checks a value in seconds instead of rereading the document.

Azure’s documentation shows the same idea at the service level: prebuilt models return typed fields (an invoice date as a date, a subtotal as a currency amount), and for custom models you assign a type to each labeled field.

How do you measure errors without trusting a vendor figure?

Published accuracy figures describe someone else’s documents. Build your own test set: take a sample of your real documents, fill in the correct values by hand once, and compare what each approach returns, field by field. Count separately the fields that are wrong, the fields that are empty when they should not be, and the fields that were invented. Track them per field, because a system can be reliable on invoice numbers and weak on payment terms.

Rerun the same set whenever you change the model, the prompt or the supplier mix.

What should a person always validate?

Add automatic checks first. Invoice lines should sum to the total, the tax should match the rate, a date should be a date, an IBAN should have a valid format, and a contract end date should come after its start date. Everything that fails a check goes to a person.

Then decide which fields are always reviewed regardless of checks: amounts above a threshold you set, termination and liability clauses, anything that triggers a payment. The rule is simple: the system proposes, a person validates, and only validated data reaches your accounting or contract tools.

What about scans and photos?

A scan has no text layer, so the first step is to read the image. Some services expose this as OCR. Google’s overview notes that Enterprise Document OCR can add image-quality analysis to check that a scan is readable, and that is a useful first filter: a blurry page should be sent back for rescanning, not extracted. Handwriting is listed among Azure’s Read model and Amazon Textract capabilities, and it is worth testing on your own samples, because handwriting varies far more than print.

Keep the original page image next to every extracted value, so a reviewer can look at the source.

And with us?

We are a forward deployed agency: three Télécom Paris engineers specialised in AI who build custom agents, and also take on machine learning and data projects. An extraction agent we would build reads your documents in SharePoint, OneDrive or Dropbox, in read-only mode, on the folders you choose, with no file kept. It cites the source of each value, drafts Word or PowerPoint outputs when asked, and a person in your company validates before anything leaves. The first call is 30 minutes, free and without commitment, and a first agent runs two weeks after it. See how the analysis of complex files works, and how your data is protected.