Symptoms
What leaders usually see
- Manual invoice rescue work
- Exception queues growing faster than decisions
- Finance, procurement and business owners interpreting rules differently
Executive search path
P2P Operating Model Review before automation amplifies the wrong system.
P2P pain is often treated as tooling or compliance noise when the real issue is ownership, handoff design and decision speed.
Diagnosis
What I diagnose
- Handoff breaks
- Control vs speed conflicts
- Where governance produces delay instead of clarity
Output
What you leave with
A review of the operating model behind P2P performance and one next move to reduce recurring friction.
Definition
Procure-to-Pay is a control system wearing a process costume
P2P is drawn as a flow: requisition, approval, order, receipt, invoice, match, payment. Read that way, it looks like administration. It is not. Every step in that flow exists to answer one question: is this commitment legitimate, and does the organisation still agree to it.
That is why P2P pain is rarely fixed by making the flow faster. A faster route to an unclear commitment produces the same exceptions, sooner. What changes the outcome is where the commitment is confirmed, by whom, and how early.
The standing conflict
Control, speed and cost cannot all be maximised
Every P2P design is a position on three axes. Most organisations never state the position, which means each function optimises its own axis and the model drifts.
Finance and audit push for approvals, thresholds and evidence. Each one is defensible. Together they create the queue.
The business needs the thing this week. Every hour the compliant route costs is an hour of pressure on the workaround.
The axis nobody owns. Manual rescue work is real money, spread thinly enough across teams that it never appears as a line item.
A P2P model is healthy when the position on all three is deliberate and written down. It is unhealthy when the position exists only as the accumulated residue of past incidents.
Schaubild
Six control points, and what each one is actually for
Each control exists for a reason. Most P2P estates run all six without anyone able to say which risk each one still covers.
01Requisition approvalConfirms the budget exists and someone accountable wants it. Cheapest place to say no.
02Channel routingDecides catalogue, framework or free text. The single largest lever on downstream exception volume.
03Purchase orderTurns an intention into a commitment the supplier can rely on. Without it, nothing later can match.
04Goods or service receiptConfirms the thing arrived. The control most often skipped and most expensive to skip.
05Invoice matchCompares three records that only agree if the first four controls held.
06Payment releaseThe last gate. By this point every real decision has already been made or skipped.
Read left to right and the economics are visible: the cost of a correction rises at every step. A no at requisition costs minutes. The same no at invoice match costs a rescue.
Made concrete
Four exception types, four different fixes
Exception queues get reported as one number, which is why they get one answer: more people, or a tolerance change. Split by type and each one points somewhere different.
An invoice arrives with no purchase order behind it.
- What it means
- A commitment was made outside the system. The control did not fail, it was bypassed.
- Usual response
- Raise a retrospective order so the invoice can be paid.
- What that costs
- The order now confirms a decision instead of governing it. The control becomes theatre.
- Real fix
- Control point 02. Give the request a fast compliant channel, or accept that the bypass is the design.
Order and invoice exist. Nobody confirmed delivery.
- What it means
- The receipt is someone extra work with no visible benefit to them.
- Usual response
- Chase the requester, or auto-receipt on invoice arrival.
- What that costs
- Auto-receipt removes the only independent confirmation that anything was delivered.
- Real fix
- Control point 04. Make receipting take seconds for services, not only for goods.
The invoice price and the order price disagree.
- What it means
- Either the contract never reached the order, or the supplier is billing something else.
- Usual response
- Widen the tolerance until the noise stops.
- What that costs
- A wider tolerance hides both the errors and the leakage it was built to catch.
- Real fix
- Trace ten mismatches to the contract. The distribution says whether it is data or behaviour.
Documents are correct. Nothing moves.
- What it means
- The approver has no deadline, no delegate, and no consequence for waiting.
- Usual response
- Reminders, then escalation, then a chase list owned by finance.
- What that costs
- Chasing becomes a permanent role. The queue is now staffed rather than removed.
- Real fix
- Every approval step needs a named delegate and a default action when the clock runs out.
Every one of these has a fast answer that works and a real answer that lasts. The fast answer is usually chosen because nobody costed the slow bleed it creates.
Before automating
Automation amplifies whatever the model already does
P2P is the most automated part of procurement, which makes it the place where an unclear model does the most damage. Touchless invoice processing on a clean estate removes work. On an estate with bypassed orders and skipped receipts, it removes the person who was catching the problem.
The order matters. Fix control point 02 and 04 first, because they determine how much there is to automate at all. An estate where most invoices carry an order and a receipt automates almost by itself. An estate where they do not will spend the automation budget on exception handling and call it a platform issue.
What a review answers
Four questions, and the estate looks different afterwards
A P2P operating model review is not a process mapping exercise. It answers four questions that most estates cannot currently answer with evidence.
Which control points still cover a risk that exists today. Where the compliant path is slower than the workaround, measured rather than assumed. Which exception types dominate, split by root cause rather than by supplier. And which decisions have an owner with both the authority and the deadline to make them. Those four answers change what the next tooling decision should be, and quite often remove the need for it.
Questions leaders ask first
Before the next P2P initiative
Is high exception volume a finance problem?
It is measured in finance and caused upstream. Exceptions are the accumulated cost of every unclear decision at requisition, channel routing, ordering and receipting. Staffing the queue treats the symptom and makes the cause permanent.
Should we widen matching tolerances to reduce noise?
Only once you know what the noise is made of. A wider tolerance hides errors and leakage together. Split the mismatches by root cause first. If most trace to contract terms that never reached the order, the tolerance was never the problem.
Our compliance rate is low. Is that a policy issue?
Almost never. People take the fastest route to a working outcome. If the compliant path is slower, policy adds awareness without changing behaviour. Time both paths end to end before designing an intervention.
Can touchless processing fix this?
It can remove a great deal of work on an estate where orders and receipts are already reliable. On an estate where they are not, it removes the human who was compensating and turns a visible queue into an invisible one.
Where does this start?
With one senior read of which control points still earn their cost, and where the compliant path loses on time. That is usually enough to change the next twelve months of investment.
Proof
Proof before methodology.
Use the proof stack to reduce buying risk, then start with one senior diagnosis before adding another program, tool, workshop or consulting layer.
Open Proof