AI Invoice Processing Automation: eInvoices, OCR, and Review

A PDF lands in the shared inbox and someone says to send it to the model. For a messy scan, a model may be part of the path. For a structured eInvoice, the first move is to parse and validate the data. For a text PDF, use layout-aware extraction. For a scan, use OCR. Call AI where the format or the coding choice varies. Use ordinary rules for facts you can calculate. Leave exceptions, and any approval that moves money, with a person.

The thing you want at the end is a received document turned into a posting proposal you can trace. The model should not have a free hand in the ERP. For the line between a conversational interface and process automation, see AI agent vs chatbot vs automation.

Structured eInvoice and PDF or scan paths merge into deterministic checks, human exception review, and a controlled ERP draft with approval

First distinguish eInvoices from invoice files

The European Commission defines an eInvoice as an invoice issued, transmitted, and received in a structured data format that allows automatic processing. It separates that from PDFs, images, unstructured HTML, and scans. A PDF sent by email is not, by that alone, a structured eInvoice.

That split decides the path. OCR earns its place on pixels. Run it across valid structured XML and you discard structure you could have trusted, then add recognition errors. An XML parser, meanwhile, cannot read a scanned page.

Incoming item	What it contains	Best first method	Appropriate AI role	Required control
Structured eInvoice	Machine-readable fields in an accepted syntax and semantic model	Parse the structure; validate schema, business rules, and code lists	Classify an exception or suggest an account only when rules and reference data cannot decide	Preserve the original payload and validation result; reject or quarantine invalid structure
Text PDF	Human-readable layout with an embedded text layer; not an eInvoice by itself	Extract text and coordinates, then apply templates or layout-aware extraction	Map variable labels and layouts into a typed candidate record	Show source evidence for each important field and run deterministic checks
Scan or photo	Pixels, often with skew, blur, handwriting, stamps, or compression	Image-quality checks followed by OCR or vision extraction	Resolve layout variation and propose normalized fields	Route unreadable or low-evidence fields to review; never infer missing financial facts
Email and attachment bundle	Message metadata, prose, links, and one or more files	Authenticate intake, identify attachments, deduplicate, and route by file type	Classify the message or document type within a constrained schema	Treat message and attachment content as untrusted data, not instructions

The Commission’s EN 16931 registry publishes code lists, validation artefacts, and technical resources. They change. In production, validate against a version you control, rather than assumptions someone copied into a prompt.

A seven-step invoice automation flow

1. Capture the invoice and its provenance

Take invoices in through channels you have named. Record the channel, the sender or network identifier, the arrival time, the message ID, the attachment hash, and the original file. Scan or quarantine files under your security policy. Use hashes and business keys to catch duplicates.

2. Detect the format and route it

Recognize a supported structured eInvoice before you fall back to a PDF or an image. Check the content. The extension is only a hint. Send unsupported, protected, corrupt, or unexpectedly large files to exceptions. Format detection is routing you can test without a model.

3. Produce a typed candidate record

Parse structured fields directly. On a text PDF, use the embedded text, the coordinates, and a stable template where you have one. On a scan, run image checks and then OCR. AI can map variable wording and layouts onto supplier, invoice number, dates, currency, totals, purchase-order reference, tax details, and line items.

Return a strict schema: the source page or region, the extraction method, the version, and whatever confidence the tool reports. Confidence is a signal for triage. It does not prove the field.

4. Run deterministic validations

Code should test the conditions that have a reproducible answer. A language model should not be the component that redoes the arithmetic. Typical checks include:

accepted syntax and schema for structured eInvoices;
required fields, data types, date formats, currency codes, and tax codes;
arithmetic relationships among quantity, unit price, net amount, tax, discounts, and gross total, with the rounding rules written down;
supplier identity against approved master data, including the tax identifier and the remit-to details you allow;
duplicates, using the attachment hash and a business key such as supplier, invoice number, date, currency, and amount;
purchase-order, contract, cost-centre, and legal-entity references against current records;
a bank-account change checked in a separate verification process, never merely against text on the invoice;
workflow permissions, approval state, accounting-period state, and idempotency before any write.

Do not invent one tolerance for everything. Rounding, quantity, price, and tax differences carry different risk. Store tolerances as configuration someone owns, with a scope, an effective date, and an audit history.

5. Match against business records

Matching compares the candidate invoice with records you trust. Two-way matching typically compares invoice details with a purchase order. Three-way matching also uses evidence that the goods or services were received. Invoice-total matching can compare totals on the invoice with the totals you expected. Microsoft’s accounts-payable documentation is one example of these patterns, and it treats tolerances as configuration rather than a universal constant.

AI can suggest a contract, a receipt, or a cost category that looks relevant. It must not invent evidence, and it must not override a mismatch. Put the values you compared on the exception, so the reviewer sees them.

6. Send exceptions to focused human review

The review screen should say why the invoice stopped, show the source next to the extracted fields, highlight the differences, and limit what each role can do. Creating a supplier, changing bank details, unusual tax treatment, a kind of exception you have not seen, final posting, and releasing a payment need controls that match the organisation’s risk model.

Keep those review decisions as evaluation data. Do not quietly retrain on them. Preserve who changed what, when, and why.

7. Cross a controlled ERP write boundary

Extraction should hand a proposal to an integration service you trust. That service checks schema, authorization, references, version, approval, and idempotency again before it creates a draft or posts. Posting and payment stay as separate permissions.

If an ERP call times out, find out whether it succeeded before you retry. Use least-privilege identities, an allowlist of operations, audit events, and a link back to the source document. The wider pattern is in how to connect AI agents to internal systems.

Put rules, OCR, AI, and people on the right side of the boundary

Capability	Use it for	Do not rely on it for
Deterministic rules	Schema validation, arithmetic, duplicates, permissions, reference lookups, tolerances, and routing	Interpreting genuinely variable language or unreadable images
OCR and document extraction	Turning visible text and layout into candidate fields with evidence	Deciding whether a transaction is legitimate or approved
AI model	Classifying variable documents, normalizing descriptions, and suggesting coding or matches	Final financial truth, access control, tolerance enforcement, or unconstrained ERP actions
Human reviewer or approver	Resolving exceptions, verifying sensitive changes, applying judgement, and accepting accountability	Re-keying every clean invoice simply because automation lacks a controlled exception path

For each step, use the method with the least variation that still does the job. Exact calculations and lookups belong in ordinary code.

Treat every invoice as untrusted model input

An invoice can contain “ignore previous instructions,” text hidden in an image, or some other attempt to steer the model. OWASP treats an external file as a possible source of indirect prompt injection. The damage grows with the agency the model has and with the privileges behind it.

A system prompt will not hold this by itself. Keep the document content apart from the instructions. Constrain the output to a schema and validate that output in code. Allowlist the actions, restrict the credentials, and require approval for a privileged operation. The model that reads the document should not hold credentials that write to the ERP. Test adversarial PDFs, images, instructions in other languages, links, and content split across pages. Keep security logs in proportion to the risk.

An invoice gives you data to check. It does not give the workflow new authority, and it does not give the model new instructions.

Design privacy and retention into the flow

An invoice can carry names, contacts, signatures, bank details, and other confidential data. GDPR principles include purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, and accountability. The regulation also requires data protection by design, and security that matches the risk.

Before a pilot, write down the purpose and the lawful basis with the person who owns privacy. Name the roles. Cut the fields to what the process needs. Define who can see the data and when it is deleted. Read the vendor terms, the subprocessors, and where processing is transferred. Protect the documents, the logs, the backups, and the exports. Whether a formal review is required depends on the processing you actually do and on the risk. This is not legal advice.

Run a 30-day shadow pilot before enabling writes

A shadow pilot compares what the automation proposes on one bounded invoice lane. The process you already run stays the one that counts.

Days 1–5: map the lane and baseline

Pick one legal entity, one intake channel, and one family of invoices. Map the handoffs, the exceptions, the roles, the systems, and the writes. Collect examples that cover your suppliers, languages, formats, credit notes, line items, and the edge cases you actually see. From your own numbers, record cycle time, review time, corrections, exceptions, and cost.

Days 6–10: define the contract and controls

Write down the fields, formats, rules, reference sources, matching, exception owners, roles, retention, and tests. Define what “correct” means for each field, and the conditions that stop the invoice. Confidence thresholds and the size of the sample have to reflect the risk of the field, how varied the documents are, and the decision that sits downstream.

Days 11–18: build the read-only path

Build the routing, the parsing or OCR, the typed extraction, the evidence, the validation, the matching, and an explanation for each exception. Use read-only access to ERP reference data where you can. Leave writes off.

Days 19–24: shadow real work

Run the invoices alongside the current workflow. Compare each proposal with the outcome that was approved, and record failures by format, supplier, field, and version. Test duplicates, malformed files, access failures, master data that changed, prompt injection, and ERP responses you cannot interpret.

Days 25–30: decide with evidence

Look at the metrics, the security findings, how many exceptions landed, and who owns the result. Then stop, revise, keep shadowing, or allow a narrow next step such as creating an approved draft in the ERP. A date on the calendar is not a reason to go live.

If you want a number on the opportunity without invented savings, use the baseline you measured and the method in the AI agent cost and ROI calculator. When you pick a tool to run it, compare governance, integration, observability, and what it costs to operate. The automation platform comparison is for that comparison. It does not name a universal winner.

Metrics that reveal the real failure modes

Report the metrics by field. Slice them by input format, by supplier or layout, by language, and by document type. Google’s Document AI evaluation guide defines precision, recall, and F1, and it explains why one generic “accuracy” number is a poor fit for optional labels and for fields that repeat, such as line items.

Field precision = correctly extracted field values / all extracted field values.
Field recall = correctly extracted ground-truth instances / all ground-truth instances for the evaluated field, equivalent to TP / (TP + FN).
F1 = 2 × precision × recall / (precision + recall), when the denominator is non-zero.
Validation-ready rate = invoices whose required fields pass deterministic validation without correction / invoices attempted.
Human correction rate = invoices with at least one human field correction / invoices reviewed.
Exception rate = invoices routed to an exception / invoices attempted.
Straight-through eligibility rate = invoices that satisfy every defined rule and approval prerequisite / invoices attempted. In a shadow pilot, this is eligibility—not actual posting.
Duplicate interception rate = confirmed duplicates stopped / confirmed duplicates in the evaluated set.
Median and 90th-percentile cycle time measure both the common path and the slow tail; report human review minutes separately.
Cost per accepted invoice = model, platform, infrastructure, review, and operational costs / invoices accepted by the reference process.

Also count write attempts that were not allowed, failures in the security tests, reconciliation incidents, and errors found after a person had accepted the invoice. Look at each one. An average will hide the case that matters. Set the bar from the risk and from your own evidence. A vendor benchmark, or a universal “99% accuracy,” is not that bar.

Frequently asked questions

Is a PDF invoice an eInvoice?

Not by itself. The Commission defines an eInvoice as structured data that allows automatic processing. A PDF, an image, an unstructured HTML document, or a scan does not become an eInvoice because someone sent it electronically. If the package is a hybrid, validate the structured part on purpose.

Do we need AI for every invoice?

No. Use deterministic parsing for structured eInvoices, a template for PDFs that stay predictable, OCR for scans, and AI where the variation justifies a model. Fewer steps that depend on a model are easier to test, and easier to reason about when they fail.

Can AI post invoices directly to the ERP?

It can. That is a poor first design. Let the model propose a record. Let a service you trust enforce validation, authorization, idempotency, approval, and the audit trail. Start read-only. A narrowly scoped draft is the earliest write worth discussing after that.

What extraction accuracy is good enough?

There is no single answer. A wrong bank account, tax identifier, total, or supplier is a different failure from a misspelled description. Measure by field. Set the bar from the decision downstream and from the controls around it.

What is the difference between OCR and AI invoice extraction?

OCR turns visible characters into text and positions. AI can map variable text and layout into a schema, or suggest a classification. Validation, matching, approval, and a pointer back to the source still have to happen. Neither OCR nor the model replaces those.

How many invoices should a pilot include?

Use labelled examples that cover the formats, suppliers, languages, line-item patterns, and the exceptions that have a consequence. A set in which every invoice looks the same can miss the failures that matter. Choose what the set has to cover, and the rule for stopping. A round number will not do that job for you.

Where should we start?

Start from the process. A vendor shortlist can wait. Define the lane, the evidence, the rules, the owners, the systems, and what a failure costs. Soror’s AI process automation assessment can help you find a first workflow that fits and turn it into a pilot plan with controls.

Official sources

Reviewed on August 31, 2026. This operational guide is not legal, tax, accounting, or audit advice. eInvoicing requirements, schemas, code lists, product capabilities, and official documentation change; recheck the linked official sources and obtain qualified advice for your organisation’s obligations and controls.