From PDF invoice to ERP record without typing it in

In almost every mid-sized company there is someone who spends several hours a week looking at a PDF and typing what it says into another screen. Supplier invoices, delivery notes, orders that arrive by email, hand-signed job sheets. Document data extraction — what most people simply call "invoice OCR" — is about removing that journey from paper or PDF to ERP field. It is neither magic nor new. What is new is that it now works with documents that do not follow a fixed template, which is exactly where the solutions of ten years ago fell apart.

This article covers how to actually build it: which documents are worth it, how OCR differs from extraction, what error rate is acceptable, how to design human validation so it does not become the bottleneck, and how to connect it to the ERP without breaking the accounting process that already works.

What is document data extraction, and how is it different from OCR?

These are two distinct layers, and confusing them is behind half the projects that disappoint.

• OCR (optical character recognition) turns an image into text. It tells you the document says "TOTAL €1,234.56", with its coordinates. Nothing more. A native PDF generated by an ERP does not even need OCR — the text is already inside it.
• Extraction decides that 1,234.56 is the invoice total, that the tax ID at the top left belongs to the issuer and not to you, and that the twelve rows in the middle are line items with quantity, unit price and tax.

The leap happens in the second layer. For years it was solved with templates: you drew a zone on supplier X's document and always read from there. That works until the supplier changes the layout, adds a cover page, or until you have 400 different suppliers. Current extraction models work on layout and context — they understand that "Invoice No." and "Doc #" point to the same thing — and generalise to documents they never saw during training. So the question today is no longer "do we have a template for this supplier?" but "what do we do with the cases the model is unsure about?".

There is a third layer nobody mentions in the demo, and it is the one that creates value: business validation. That the total matches the sum of lines plus tax, that the tax ID exists in the supplier master, that the referenced delivery note has been received, that the invoice has not already been posted. A perfectly extracted figure that does not match your purchase order is still a problem for the finance team.

Which documents are worth automating first?

The criterion is not which one is most annoying, but where volume, repetition and an available automatic check intersect. This table summarises how we prioritise:

| Document type | Typical volume | Difficulty | Automatic validation available | Priority | |---|---|---|---|---| | Supplier invoices | High and recurring | Medium | Yes: match against PO and delivery note | High | | Delivery notes | High | Medium-high (signatures, stamps, skewed scans) | Yes: against the PO | High | | Customer orders by email or PDF | Medium-high | Medium | Yes: against catalogue and price list | High | | Employee receipts and expenses | High in count, low in value | High (photos, creases, thermal paper) | Partial | Medium | | Contracts and annexes | Low | Very high | No | Low (start with summarisation, not extraction) | | Handwritten job sheets | Variable | High | Yes, if there is a work order | Medium | | HR documentation | Low | Medium | No | Low |

Two readings of that table. First: start where there is a counterpart. An invoice can be matched against a purchase order and a delivery note; if all three agree, the document can go through untouched. A contract has nothing to be matched against, so the full weight falls on the model and on the person reviewing it. Second: volume rules. Automating 30 documents a month rarely pays for the maintenance; 3,000 almost always does. It is the same prioritisation logic we apply to any AI process automation project.

If the document cannot be checked against something you already hold, you are not automating a process — you are moving the risk from a person to a model.

What does the full path from inbox to ERP look like?

A system that survives in production has seven steps. Projects usually fall over at steps 5 and 6, which are precisely the ones demos skip.

1. Capture. A dedicated mailbox, a shared folder, an office scanner, a mobile upload or EDI. One important decision hides here: what happens to the original email and its attachments, because the email is usually the evidence of when the document arrived. 2. Normalisation. Split attachments, convert to image or text, break up PDFs containing several invoices in a row, rotate pages and drop blank ones. This boring step resolves a surprising share of reading errors. 3. Classification. Decide whether the document is an invoice, a delivery note, a bank statement or marketing material. Without it, the invoice model will try to extract a total from a product catalogue. 4. Extraction. Header fields (issuer, tax ID, number, dates, net, tax, total) and the line-item table. Each field comes out with a value and a confidence score, which is what makes the next decision possible. 5. Business validation. Arithmetic checks, supplier existence, matching against PO and delivery note, duplicate detection, tolerance limits by amount or percentage. 6. Selective human review. Only documents that break a rule or fall below a confidence threshold. Everything else goes straight through. 7. Posting and traceability. Create the record in the ERP with the original PDF attached and a log of what was extracted automatically, what a person corrected and when.

Step 7 is non-negotiable once the process touches accounting. When someone asks a year from now why an invoice was posted with the wrong date, the only acceptable answer is being able to open the original document and see the value read, the final value and who touched it. It is the same traceability requirement we set out in data governance.

What error rate is acceptable, and how do you measure it?

The honest answer: it depends on the field, and reporting "95% overall accuracy" means nothing.

An invoice has fields with wildly different consequences. Getting the total or the tax ID wrong produces a bad journal entry and a call from the supplier. Getting a line description wrong is cosmetic. So you measure per critical field, not in aggregate:

• Per-field accuracy: of the invoices processed, in how many were the total, tax ID, invoice number and dates exactly right.
• Straight-through rate: what percentage of documents pass end to end without anyone touching them. This is the number that determines the actual saving.
• Escaped error: of the documents that went through untouched, how many carried a wrong value. This is the one that matters and the one almost nobody measures, because it requires periodically auditing a sample of what already passed.

A well-calibrated system does not maximise accuracy — it maximises automation subject to an escaped error close to zero on critical fields. You get there by raising or lowering the confidence threshold. Set it too high and almost everything goes to review, saving nothing; set it too low and you save a lot right up until the first invoice gets paid twice.

The right way to start is with no threshold at all: for a few weeks the system extracts and a person reviews 100% of the output, comparing their correction against what was proposed. That period gives you three things: real per-field accuracy on your documents, the threshold you can afford, and a ranking of problem suppliers. There is no substitute for that measurement — the percentages in the brochure were obtained with documents that are not yours.

How do you design human validation so it isn't the bottleneck?

If the reviewer has to open the PDF, hunt for the field and mentally compare it with the screen, you have not automated anything — you have added a step. Useful review meets three conditions.

• A single view with highlighting. Document on the left, fields on the right, and clicking a field highlights where it came from on the page. Without that, reviewing takes longer than typing.
• Only the doubtful parts, not the whole document. If only one tax amount falls below the threshold, ask for confirmation of that field, not all fifteen.
• Corrections feed the system. Every corrected value must be logged, either to retrain or to generate a supplier-specific rule. If six months in you are still correcting the same thing from the same issuer, there is no learning loop.

Add a fourth, organisational condition: define what happens to cases nobody can resolve. Illegible documents, new suppliers not yet in the master, invoices with no matching order. They need their own queue, an owner and a deadline — otherwise they sit in limbo and reappear at month-end close.

On the split between deterministic and probabilistic work, be deliberate: arithmetic checks and PO matching are fixed rules and should be implemented as rules, not left to a model. It is the same practical distinction we set out in RPA vs AI: rules where there are rules, models where there is variability.

How do you integrate with the ERP without breaking the accounting flow?

Integration is where the project becomes real, and it is almost always more work than the model. Four decisions shape the outcome.

Where the data lands. The prudent move is to create the document as a draft or pre-registration and let the existing approval flow confirm it. Inserting final journal entries directly from an automated process is asking for trouble the day it fails.

What happens to master data. Extraction returns a name and a tax ID; the ERP needs a supplier code. That lookup fails with similar trading names, branch offices and badly printed IDs. Resolve it by tax ID with prior normalisation, and raise an explicit exception when there is no single match rather than creating new suppliers automatically.

How duplicates are prevented. The minimum rule is issuer plus invoice number plus fiscal year, checked before anything is created, along with a file hash to catch the same PDF resent. Duplicates are the most expensive failure mode of this automation.

What happens when the ERP says no. Closed period, blocked account, mandatory field empty. You need error handling that returns the document to a queue with the reason attached, not a log nobody reads. We go deeper into system connection patterns in integrating AI into your tools.

A compliance note: if the documents contain personal data — payslips, job sheets with names, invoices from sole traders — the processing falls under GDPR, and you should decide from the outset where it happens and how long intermediate copies are kept. We cover that in GDPR and AI.

Frequently asked questions

Does invoice OCR work with poor-quality scans?

With skewed, grey or 150 dpi scans it performs worse, and that is a capture problem, not a model problem. Raising scan resolution, avoiding photos of screens and asking the supplier for the original PDF when one exists will improve results more than switching technology.

How many documents do you need before an extraction model works?

Current document extraction models already ship trained on standard commercial paperwork and work with no prior examples on ordinary invoices and delivery notes. Your own examples are needed for sector-specific formats or fields that only exist in your documents, and there a few dozen per format usually moves the needle.

Is a specialised product better than building it in-house?

For standard invoices and delivery notes, a specialised product wins: the problem is solved and the cost sits in the integration. Custom development is justified by sector-specific documents, very high volumes, or requirements about where the data is processed.

How long does it take to get into production?

A narrow scope — one document type, one flow, one ERP — can be running in a few weeks if access to the target system is sorted. What stretches these projects is rarely the extraction itself, but permissions, dirty master data and deciding who validates the exceptions.

This is one of the easiest automations to prove out, because the before and after are measured in documents processed without intervention and in errors that stop reaching month-end close. If you want to know which part of your paperwork is automatable today and with what guarantees, in the audit we review a real sample of your documents and your current flow before proposing anything. And if you would rather talk it through in half an hour, let's talk.