Use case assessment
Is AI invoice matching worth building?
The matching isn't the hard part. Reading the document is, and that's a narrower problem than the proposal usually claims.
Matching an invoice to a purchase order and a receipt is deterministic arithmetic. Reading a scanned invoice from a supplier who changes their layout is not.
What it usually means
Two different jobs get proposed under one name. Extraction — getting structured fields out of a document that arrived as a PDF or a scan. And matching — comparing those fields to a purchase order and a goods receipt and deciding whether they agree.
Separating them is most of the assessment.
Is it genuinely AI?
The matching is not. Three-way matching is a set of tolerance rules: does the quantity agree within a threshold, does the price agree, does the total. Those rules are auditable, and in a finance context that auditability is not a nice to have.
The extraction often is. A supplier who sends the same template every month is a template-parsing problem. Four hundred suppliers with different layouts, some of them scanned at an angle, is genuinely a model problem — and a well-solved one, with mature vendors.
What the simpler version looks like
Template parsing for your top suppliers by volume, which is usually a surprisingly small number covering a surprisingly large share of invoices. Rules for the matching. A human queue for exceptions.
Run that and measure the exception queue. If it is dominated by a long tail of low-volume suppliers with inconsistent formats, you have found the case for extraction models. If it is dominated by genuine discrepancies, you have found a procurement problem that no model addresses.
What it costs to run
Extraction accuracy degrades quietly when suppliers change their layouts, which they do without telling you. That means ongoing evaluation against a labelled set, and someone reviewing low-confidence extractions.
The number worth calculating: cost per invoice processed, all in. Compare it to the loaded hourly cost of the person currently doing it, multiplied by the time per invoice. That comparison is often less flattering than the vendor's, and it is the one that decides.
Where it sits under the EU AI Act
Accounts payable automation is not an Annex III high-risk use. If you buy an extraction system and run it as delivered, you are a deployer.
Worth knowing that fine-tuning it on your own invoices, or putting your name on it internally, can be the sort of change that moves you toward provider obligations under Article 25 — a decision usually made by an engineer rather than by legal.
When it is worth building
When the supplier tail is genuinely long and genuinely varied. When invoice volume makes a few minutes per document a material number. When the exception queue is an extraction problem rather than a discrepancy problem.
Not when the goal is to remove the human review step entirely. In finance, the review is usually the control, and removing it is a different conversation than the one about efficiency.
Common questions
Does invoice matching need AI?
The matching does not. Three-way matching against a purchase order and a goods receipt is a set of tolerance rules, and rules are auditable in a way a model is not. The extraction step, reading fields out of varied supplier documents, often does.
What is the simplest version worth trying first?
Template parsing for your highest-volume suppliers, rules for the matching, and a human exception queue. What accumulates in that queue tells you whether you have an extraction problem or a procurement problem.
Is AI invoice processing high-risk under the EU AI Act?
No, accounts payable automation is not an Annex III high-risk use. But fine-tuning a purchased extraction system on your own data can constitute substantial modification under Article 25, which affects which obligations you carry.
Scoring 40 AI use cases in a regulated enterprise — the assessment framework this page applies, run across forty real proposals.