Purchase-to-Pay: Where the Automation Breaks

Purchase-to-pay — P2P — is the chain from the moment someone needs something to the moment the supplier is paid: requisition, approval, purchase order, receipt, invoice, matching, payment. It is the most heavily automated process in most finance departments and the one that most reliably disappoints.

The disappointment is predictable and it is almost never about the software. This is where purchase-to-pay automation actually breaks, in the order you will meet the problems.

The chain, and where the money is

Requisition — someone asks for something.
Approval — someone with authority agrees.
Purchase order — a commitment goes to the supplier.
Goods receipt — what arrived is recorded.
Invoice receipt and matching — the invoice is checked against the order and the receipt.
Payment — approved, scheduled, paid.

Most automation projects start at the invoice, because that is where the paper is and where the cost per document is easiest to calculate. That is the wrong place to start and the reason so many end up disappointing: an invoice can only be matched automatically if a purchase order and a goods receipt exist to match it against. Automating the last step of a chain whose first steps are informal produces a fast route to a queue of exceptions.

Three-way matching and why it fails in practice

Three-way matching compares the purchase order, the goods receipt and the invoice. If all three agree within tolerance, the invoice posts without a human. This is the mechanism that produces the savings, and it fails for a small number of very repeatable reasons:

No purchase order exists. Someone ordered by phone or email. There is nothing to match, so the invoice routes to a person by definition.
The goods receipt was never entered, or was entered days late, so at the moment the invoice arrives the system believes nothing was delivered.
Unit mismatch. The order is in boxes, the delivery in pieces, the invoice in kilos. Arithmetically reconcilable, not automatically.
Price and quantity tolerance. A 2% price variance may be acceptable; nobody has decided what the figure is, so everything routes for review.
Partial deliveries against a single order, where each invoice covers part of the line and the running total has to be tracked.

Notice that only the third and fourth are really about data quality. The first two are behavioural — people not raising orders and not booking receipts — which means the automation rate is largely set by process discipline outside finance.

The number that matters: straight-through rate

The metric worth tracking is the straight-through rate: the share of invoices that reach payment without a human touching them. Not "invoices processed", not "hours saved" — those move for many reasons. Straight-through rate isolates whether the automation is actually working.

And it is worth understanding the shape of the cost curve before setting a target. Getting from 0% to 60% is usually straightforward, because it means handling the clean PO-backed invoices from your largest suppliers. Getting from 60% to 85% is harder and involves fixing behaviour. Getting past 90% is often not worth doing, because the remaining exceptions are genuinely different from each other, and each rule you add to catch one makes the system harder to understand for everyone maintaining it.

The honest target for most mid-sized companies is 70–85% straight-through with a fast, well-staffed exception path — not 100% with a rule engine nobody dares change.

PO-backed spend is the real lever

If you want one number to move before buying anything, it is the share of spend covered by a purchase order. Every invoice without a PO is guaranteed manual work, forever, regardless of how good the capture software is.

This is usually a policy and enablement problem rather than a systems one: making it easy to raise a requisition on a phone, setting a threshold below which a lightweight process applies, and being willing to enforce a no-PO-no-pay rule for categories where it is reasonable. Companies that fix this before automating typically reach a higher straight-through rate than companies that buy a better OCR engine.

Document capture is no longer the hard part

Reading an invoice — supplier, number, date, amounts, VAT, line items — is a solved problem for standard layouts, and modern extraction handles unseen formats far better than the template-based tools that shaped most people's expectations. Our guide to <a href="/blog/factuurverwerking-automatiseren-ai/">automating invoice processing</a> covers that step in detail.

What has not changed is that extraction accuracy is only half the equation. A field read correctly still has to be matched, and a supplier number read perfectly is useless if that supplier exists three times in your master data under slightly different names. Which is the next problem.

Master data decides your ceiling

Duplicate suppliers, inconsistent VAT registrations, obsolete bank details and article numbers that differ between your system and the supplier's are the quiet ceiling on P2P automation. They do not announce themselves; they show up as a steady trickle of exceptions that each look like a one-off.

Deduplicate suppliers before go-live, and put a check in the creation flow so it does not immediately regrow.
Decide who is allowed to change bank details, and require the four-eyes principle on that specific field — it is the single highest-fraud-risk change in the whole chain.
Agree article or service identifiers with your top suppliers where you can. It converts a matching problem into a lookup.

Fraud controls that automation must not remove

Automating approvals makes some fraud easier, not harder, because volume and speed reduce the number of people who look at anything. Three controls are worth keeping deliberately manual or deliberately dual:

Bank detail changes — verified out of band, against a known contact, not against the details on the request itself.
New supplier creation — separated from the person who can approve invoices for that supplier.
Approval limits that cannot be circumvented by splitting an order into two below-threshold parts. Systems that check per line rather than per requisition are trivially split-able.

Approval workflows: the delegation problem

Approval routing looks like the simplest part to automate and generates more day-to-day friction than matching does. The rules themselves are easy — amount thresholds, cost centres, category owners. What breaks is everything around them.

Absence. An approver on holiday stops the chain unless delegation is built in, and delegation that has to be set up manually is delegation that will not be set up.
Reorganisations. Approval hierarchies are copies of an org chart that changes quarterly. If the hierarchy is maintained by hand in the P2P system, it is wrong within a month; if it derives from HR data, it stays right for free.
Approvers who cannot judge. Routing an invoice to someone with no context produces a rubber stamp, which is worse than no control because it creates a record of scrutiny that did not happen.

A useful design rule: route by who can meaningfully dispute the charge, not by seniority. The person who ordered the thing knows whether it arrived; a director two levels up knows only the amount.

E-invoicing changes the input, not the process

Structured e-invoicing — Peppol and the formats around it — is expanding across Europe, and public-sector suppliers in the Netherlands have been sending structured invoices for some time. The direction of travel is clear even where exact national timetables are still moving, so it is worth planning for rather than reacting to. Confirm current obligations for your sector and country before making commitments; the rules have been changing.

The practical effect is narrower than the attention suggests. A structured invoice removes the extraction step: the data arrives as data, so capture accuracy stops being a variable. It does not create purchase orders, book goods receipts, deduplicate suppliers or decide tolerances.

Which means e-invoicing raises your ceiling without moving your floor. If your straight-through rate is limited by PO coverage — as it is in most companies — structured invoices will improve it barely at all. If your rate is limited by capture errors on messy PDFs, it will help immediately. Knowing which of the two you are is, again, the audit question.

What to fix before you buy anything

Measure the current straight-through rate honestly, even if it is near zero.
Measure PO-backed spend as a percentage, by category. The categories with low coverage are your roadmap.
Count your duplicate suppliers. It is a five-minute query and it usually surprises people.
Write down the price and quantity tolerances you are willing to accept, per category. Without them, everything is an exception.
Decide who owns exceptions and how fast they must clear. An exception queue without an SLA becomes a filing cabinet.

How we approach it

Our €2,500 audit measures the straight-through rate, PO coverage and master-data quality first, and states which of the three is your binding constraint — because buying capture software when your constraint is PO coverage buys you faster exceptions. If a build follows, a €20,000 proof of concept runs on your real invoice mix for four to six weeks, reporting straight-through rate by supplier and by exception type, and production starts from €50,000.

Frequently asked questions

What is purchase-to-pay in simple terms?

The whole chain from someone needing something to the supplier being paid: requisition, approval, purchase order, goods receipt, invoice, matching and payment. It spans procurement and finance, which is why it is often nobody's process end to end.

It is sometimes written P2P, and occasionally confused with procure-to-pay, which usually means the same thing.
The finance-facing half — invoice receipt through payment — is what most "invoice automation" products cover.
The savings come from three-way matching, which needs the procurement half to be disciplined first.

What is a realistic straight-through rate for invoices?

70–85% is a healthy target for most mid-sized companies. Higher is possible but the cost curve turns sharply, because the remaining exceptions are genuinely dissimilar.

0–60% is usually easy: clean PO-backed invoices from your largest suppliers.
60–85% requires behavioural change — people raising orders and booking receipts on time.
Past 90%, each additional rule catches fewer cases and makes the rule set harder to maintain. A fast exception path is usually the better investment.

Why do so many invoices still need manual handling?

Usually because there is nothing to match against, not because the invoice was read badly. The two dominant causes are missing purchase orders and missing or late goods receipts.

An invoice with no PO cannot three-way match by definition — it will route to a person regardless of the software.
Unit mismatches (boxes ordered, pieces delivered, kilos invoiced) are reconcilable by a human and awkward for a rule.
Undefined tolerances mean every small price difference becomes an exception. Deciding the percentage is free and removes a large share of them.

Which P2P controls should stay manual?

The ones where automation increases fraud risk rather than reducing it. Speed and volume mean fewer people look at any individual transaction, so a small number of checks are worth keeping deliberately human or deliberately dual.

Bank detail changes, verified out of band against a known contact — never against the details supplied in the request.
New supplier creation, separated from whoever can approve invoices for that supplier.
Approval limits that cannot be bypassed by splitting a requisition into two smaller ones.

Purchase-to-Pay: Where the Automation Actually Breaks