Somewhere in your company, someone is retyping documents. A clerk at a building materials distributor copies the supplier, VAT number, amounts and order numbers from 600 invoices a month, in 40 different layouts. An office manager reads lease contracts to find the notice period. A clinic receptionist types referral forms into the patient system.
Older OCR tools (optical character recognition, software that turns a scanned page into text) could read the words, but they needed a template for every layout and broke whenever a supplier changed theirs. Current AI models can read a document they’ve never seen and fill in a fixed set of fields. They still make mistakes, so the design around the model matters more than the model itself.
This guide shows how such a pipeline works, where it fits for invoices, contracts and forms, how accurate you can expect it to be and how to test it on your own documents before you rely on it.
What changed, and what didn’t
Three ways to get data out of documents
| Template OCR | AI extraction | Structured e-invoice | |
|---|---|---|---|
| Reads layouts it hasn’t seen | No | Yes | Nothing to read |
| Same input, same output | Yes | Partly | Yes |
| Reads contracts and free text | No | Yes | No |
| Errors from misreading | Some | Some, different ones | None |
| Running cost per page | Low | Low to medium | Very low |
Look at the last column first. A structured e-invoice carries its data in a machine-readable file (XML), so nothing needs to be read at all. Slovakia is introducing mandatory e-invoicing between domestic VAT payers from 1 January 2027, and EU rules for cross-border invoices are planned from 2030. Dates like these can move, so check the current status. If most of your invoices will soon arrive structured, build for that first and use AI for the rest: foreign suppliers, receipts, delivery notes, and every document that isn’t an invoice.
How an AI document pipeline works
The parts of a document pipeline
- Intake One inbox, a portal upload, the office scanner
- Reading Text layer, OCR or a vision model turns the page into text
- Extraction A language model fills your fields in a fixed format
- Validation Your rules: totals, VAT IDs, orders, duplicates
- Review A person fixes only what was flagged
- Your systems ERP, accounting, document storage, audit log
Intake. Documents arrive in one place: a dedicated inbox, an upload in a client or supplier portal, the scanner. The system stores the original file and ignores exact duplicates.
Reading. PDFs created by software already contain text. Scans and phone photos need OCR, or a vision model that reads the image directly. Tables with many line items are where most reading errors happen.
Extraction. You define a schema: the list of fields, their type (date, amount, VAT ID) and which ones are required. The model must return exactly that structure. It must also be allowed to say “not found”. An empty field is far better than an invented one.
Validation. This is the step people skip, and it needs no AI at all. Net plus VAT equals the total. Line items add up to the net amount. The VAT ID has the right format and exists in the EU’s VIES register. The IBAN checksum is valid. The supplier is already in your system, the order number exists and the amount matches within a tolerance. The same supplier hasn’t sent the same invoice number before. Each failed rule flags the document. We go deeper into why models make things up, and how checks like these catch it, in designing around AI mistakes.
Review. A person sees the document on one side and the extracted fields on the other, with flagged fields highlighted. They fix and confirm. Every correction is logged and becomes a test case for later.
Your systems. Clean data goes to the ERP or accounting system, usually as a draft, with a link back to the original file. Who sees and approves what stays the same as before.
Invoices and purchase orders
A supplier invoice, end to end
- Invoice arrives Email, portal or scanner
- AI reads the fields Supplier, dates, amounts, VAT, line items
- Rules check it Totals, VAT ID, duplicates, order match
- Draft in accounting With a link to the original file
- A person handles exceptions Flagged fields only, document alongside
- Approved and paid Your approval rules, as before
The approval logic you already have (who approves what amount) stays a plain workflow. Our post on workflows, AI workflows and agents uses invoice processing as its main example of an AI step inside a fixed process.
For a distributor, the real time saver is often the match, not the reading. Once the AI has pulled the order number and line items from the invoice, rules compare them with the purchase order and the goods receipt (the three-way match). Invoices that match within tolerance need nobody’s attention. Invoices that don’t go to the person who knows why the delivery was short.
Contracts: finding things, not deciding them
With contracts, the AI’s job is to find and point, not to judge. It does a good job of pulling out the parties, start and end dates, notice periods, renewal terms, payment terms, liability caps and governing law. It can compare each clause with your standard terms and flag the ones that differ. It can summarise a long contract in plain language.
Reviewing a supplier contract
Today
- Someone reads all 30 pages
- Notice period noted by hand, if at all
- Comparison with your standard terms from memory
- A missed renewal found after the deadline
With AI extraction
- Key dates and clauses pulled out with page references
- Deviations from your standard terms flagged
- Renewal dates in a calendar with reminders
- A lawyer reviews only the flagged clauses
Every extracted item should come with a page or clause reference, so a person can check it in seconds. What the AI shouldn’t do is decide whether a deviation is acceptable, give legal advice or negotiate.
A good first project is often a one-off. A property manager with 120 lease contracts, written on different templates over 15 years, has the AI pull rent indexation clauses, notice periods and end dates into one table. A person checks the table once. From then on, new leases go through the same extraction when they’re signed. The value is high and the risk is low, because every row gets checked.
Reading is only half the story. For the contracts you issue yourself, generating them from templates beats reading them later. For Transfer International, a Slovak staffing agency, we built a flow where contracts and addenda are generated from DOCX templates using data already in the system, converted to PDF and sent for e-signature. Nothing has to be extracted afterwards, because the system already knows what each document says.
Forms and everything else
Application forms, insurance claims, delivery notes, customs documents, medical referrals. The same pipeline works, with two cautions.
Handwriting, ticked boxes and phone photos taken at an angle are harder to read than clean PDFs. Test them separately. If you control the form, an online form is better than any AI reading a scanned one.
Forms often carry personal and health data. Check where the documents are processed and whether the provider keeps them. When the data can’t leave your infrastructure, models that run on your own servers are an option; we compare the two approaches in self-hosted models or API models.
How accurate is it?
There’s no honest single number. It depends on the quality of the document, the field and the layout. In general, header fields on clean, software-generated PDFs (supplier, invoice number, dates, totals) are read reliably. Errors cluster in long tables of line items, poor scans, handwriting and stamps across the text.
Two things matter more than the average:
- Which fields are wrong. A wrong delivery note number is an annoyance. A wrong IBAN or total is money.
- Whether errors are caught. A slightly less accurate pipeline with good validation rules is safer than a more accurate one without them, because its mistakes get flagged before they reach your books.
Don’t rely on the model telling you how sure it is. Use signals you can trust: a validation rule failed, a required field is missing, two independent readings disagree, or this is the first invoice from a new supplier.
A test plan before go-live
- Collect 200–300 real documents Including the ugly ones: scans, photos, foreign languages, many pages
- Type the correct answers once A person fills in the fields by hand. This is your answer key
- Measure per field, not per document Totals and the IBAN matter more than a reference number
- Count what the rules catch An error caught by a rule costs a minute. One that slips through costs money
- Decide what always gets a human check For example new suppliers and amounts above a limit
- Keep the test set Run it again whenever the model or the instructions change
What to keep human
- Approving payments, and anything above your approval limits
- Changes to supplier details, especially bank accounts
- Decisions about contract deviations, and negotiations
- Documents the pipeline flags or can’t classify
- Rare document types. If you get five a year, a person is cheaper than an automation.
How to design the review step so it’s fast, and when the line can move, is covered in human in the loop.
Buy or build?
Many accounting systems now read invoices on their own, and for standard invoices that go into that one system, they’re often good enough. Try them first.
A custom pipeline makes sense when documents feed several systems, when you have your own validation rules (order matching, approval limits, cost centres), or when the documents aren’t invoices at all: contracts, forms, delivery notes, certificates.
How to measure it
- Share of documents that go through without anyone touching them
- Field error rate after go-live, from a small weekly sample
- Time per document, including review
- Time from receipt to approval or posting
- Business effects: early-payment discounts taken, late fees avoided, renewal deadlines missed (the target is zero)
Where to start
- Pick one document type with volume. Usually that’s supplier invoices or delivery notes.
- Count them per month and time how long one takes today.
- Build the test set and the answer key before you choose a tool.
- Write your validation rules down. Many of them already live in your accountant’s head.
- Start with a review screen where a person confirms every document. Let clean ones through on their own once the numbers support it.
We build pipelines like this as part of our work on document management and automation. Send us a few anonymised sample documents and we’ll tell you what can be read reliably and what should stay with a person.
