Procure to Pay Process: Design and Controls

2026-09-18 · Tommaso Maria Ricci

Most companies do not have a broken procure to pay process. They have four of them, running in parallel, and nobody owns the seams between them. Purchasing negotiates a contract. A department orders without a purchase order. Finance receives an invoice for something it cannot match. Treasury pays it anyway, because the supplier is calling and the month is closing.

That is not a technology gap. That is a design gap, and it is expensive in a way that never shows up as a line item.

Here is the number that makes the point. In the 2025 Global Chief Procurement Officer Survey, Deloitte surveyed more than 250 procurement leaders across 40 countries and found that the top performers, the ones the study calls Digital Masters, met or exceeded their cost savings plan 96% of the time, against 80% for the followers. On cost avoidance the gap was wider: 94% against 75%. Same economy, same suppliers, same inflation. Different process discipline.

This guide is about that discipline. It is not a software comparison and it does not rank vendors. It is how I would design, audit and fix a procure to pay process if I were walking into your company on Monday.

What the procure to pay process actually covers

Procure to pay, often shortened to P2P or written as purchase to pay, is the end to end chain that starts when somebody in the business decides they need something and ends when the supplier has been paid and the transaction is closed in the books.

The chain has a boundary problem, and the boundary problem is where most of the money leaks. Two definitions matter before anything else.

Source to pay is the wider chain. It starts earlier, with category strategy, market analysis, sourcing events and negotiation, and it includes procure to pay as its execution half. If your problem is that you are paying too much per unit, your problem is upstream and this article covers only half of it.

Procure to pay starts when the need is recognised inside an approved commercial framework. If your problem is that you cannot tell what you bought, from whom, under which contract, and whether the price paid matches the price agreed, your problem is here.

That distinction is not academic. Companies routinely buy a procurement suite to fix a payment problem, or an accounts payable automation tool to fix a compliance problem. Both fail, and the postmortem blames the software.

Procure to pay process steps and owners

A working procure to pay process has nine steps. What matters more than the list is the owner column, because a step with two owners has none.

|---|---|---|---|

Three observations about this table, each of which I have watched cost real money.

Step 6 is the one nobody owns. Goods receipt is a warehouse task when the thing is physical and an orphan when it is a service. Consulting hours, software subscriptions, marketing retainers and maintenance contracts arrive with no receiving dock. Without a service receipt step, the three way match collapses into a two way match and the only control left is whether somebody remembers what was agreed.

Step 8 has a hidden owner. Exception resolution sits in accounts payable on the org chart, but the information needed to resolve it lives with the requester or the buyer. That is why exception backlogs grow: the team that owns the queue does not own the answer.

Step 3 is where compliance is decided. If supplier selection happens after the need is urgent, the buyer has no leverage and the requester has already promised the vendor. Everything downstream is then administration.

The five sub-processes people keep confusing

Inside those nine steps sit five distinct sub-processes with different failure modes. Treating them as one is the most common design error I see.

Requisition to order. The internal approval chain. Fails through slowness, which trains people to bypass it.

Order to receipt. The physical or contractual fulfilment. Fails through missing or late receipts, which turns into invoice exceptions weeks later.

Invoice to match. The reconciliation. Fails through bad master data more often than through bad invoices. A supplier recorded twice under two spellings will generate mismatches forever, which is why this work belongs inside the discipline I described in building a master data management strategy.

Match to pay. The release. Fails through approval bottlenecks and through duplicate payments.

Pay to close. Reconciliation and accrual. Fails quietly, and you find out at audit.

Each of these needs its own metric and its own owner. A single dashboard showing "invoices processed" tells you nothing about which of the five is failing.

Where the process breaks: seven failure points

1. No purchase order coverage

The single most diagnostic number in procure to pay is PO coverage: the share of addressable spend that flows through a purchase order before the commitment is made. Low coverage means the commercial decision has already been taken by the time finance sees anything, and every control downstream is theatre.

If you measure one thing after reading this article, measure this, split by category and by business unit. The split matters more than the total, because the average hides the two departments that generate most of your exceptions.

2. Off contract buying

Buying outside negotiated agreements, commonly called maverick spend, is the mechanism by which negotiated savings evaporate between the signature and the invoice. It is rarely malice. It is usually a buyer who cannot find the contract, a catalogue that is out of date, or a requisition path that takes nine days when the need is tomorrow.

The fix is almost never enforcement first. It is making the compliant path the fastest path, then enforcing. Enforcement without speed produces workarounds, and workarounds produce the shadow process you were trying to eliminate. The contract side of this problem is its own discipline, and I have gone through it stage by stage in the contract lifecycle management process.

3. Service receipts that never happen

Covered above and worth repeating, because it is the leak nobody budgets for. Services are typically the largest indirect category and the one with the weakest receipt discipline. Without an explicit acceptance step, you are paying against an invoice and a memory.

4. Supplier master data drift

Duplicate suppliers, stale bank details, inactive vendors left open, entities merged without cleanup. Each one produces three effects: false mismatches, blocked spend visibility, and fraud exposure.

On that last point, the ACFE Report to the Nations is the reference. The 2026 edition analysed 2,402 real cases of occupational fraud across 143 countries and 22 industry categories. Among the behavioural red flags, an unusually close association between an employee and a vendor or customer correlates with a median loss of 300,000 dollars. That is not a small control failure. That is one relationship, unmonitored, inside a process with weak master data.

5. Approval chains built on seniority instead of risk

If a 200 dollar order and a 200,000 dollar order follow the same number of approvals, both are wrong. The small one is over controlled and slow, which drives bypass. The large one is under controlled relative to its risk, because six people signing quickly is not six reviews.

Build the chain on amount, category risk and supplier status, not on the org chart. This is the same principle that governs a workable expense framework, and the reasoning transfers directly from how to write an expense policy.

6. Exception queues with no ageing discipline

Exceptions are normal. Exceptions that are three weeks old are a process failure. What matters is not the exception rate, it is the ageing profile and the clearance rate. A team clearing 95% of exceptions within five days with a 20% exception rate is healthier than a team with a 9% exception rate and a backlog nobody touches.

7. Payment runs disconnected from terms

Paying early destroys working capital. Paying late destroys supplier relationships and, in many jurisdictions, triggers statutory interest. Both happen in companies that run payments on a calendar rather than on terms, and both are invisible until somebody measures days payable outstanding against contracted terms, supplier by supplier.

Three way match, and when to relax it

The three way match compares the purchase order, the goods receipt and the supplier invoice. When price, quantity and item agree across all three, the invoice is cleared automatically. When they do not, a human intervenes.

This is the core control of the whole process, and it is also the one most often applied badly in both directions.

Applied too loosely, it becomes a two way match between order and invoice, which verifies that you were billed what you ordered but not that you received it.

Applied too rigidly, it blocks everything. A supplier who ships 99 units against an order of 100 generates an exception that costs more to resolve than the unit is worth.

The answer is tolerance, set deliberately and reviewed twice a year. A workable starting design:

| Scenario | Tolerance | Rationale |

|---|---|---|

| Price variance | Lower of 2% or a small absolute cap | Catches repricing, ignores rounding and currency noise |

| Quantity variance under | Zero, block | Underdelivery is a supplier issue, not an AP issue |

| Quantity variance over | Zero, block | Overdelivery accepted silently becomes free inventory risk |

| Freight and small charges | Fixed absolute cap per invoice | Not worth a human touch below the cap |

| Services without receipt | Approval by budget owner replaces receipt | Only where a service acceptance step genuinely cannot exist |

Two rules I would not compromise on. First, tolerances are set by finance and procurement together, never by whoever is clearing the queue. Second, every tolerance auto approval is logged and sampled, because a tolerance nobody reviews is a permanent hole sized exactly to your tolerance.

Controls that pay for themselves

Six controls, in the order I would implement them in a company that currently has none.

1. Separation between supplier creation and payment. The person who can create a supplier must not be able to release a payment to it. This is the single cheapest fraud control that exists and it costs nothing but a permissions review.

2. Bank detail change verification through an independent channel. A supplier emailing new bank details is the most common invoice fraud vector in existence. Verification means calling a number you already hold on file, not the one in the email signature. Make it a written rule with no exceptions for urgency, because urgency is the pretext the fraud uses.

3. Duplicate payment detection before release, not after. Same supplier, similar amount, similar date, similar reference. Running it before the payment file is generated turns a recovery project into a non event.

4. Dormant supplier suspension. Any supplier with no activity for a defined period goes inactive automatically and requires reactivation. This shrinks the attack surface by a large multiple in most companies.

5. Surprise sampling of tolerance approvals. Pull twenty auto approved invoices a quarter and check them properly. The point is not the twenty, it is that everybody knows the sample exists.

6. Segregated approval for new supplier first payment. The first payment to any new supplier gets a second pair of eyes regardless of amount. Fraud lives disproportionately in first payments.

Notice that five of these six cost almost nothing to implement and none of them requires new software. That is the general shape of control work in procure to pay: the expensive part is deciding, not building.

The cost model: three line items nobody budgets

When companies build the business case for a procure to pay redesign, the model contains licences, implementation, integration and training. Then it contains a savings figure, usually expressed as a percentage of addressable spend, and the two are compared.

The model is wrong in a predictable way, because three real costs are missing.

Supplier onboarding and enablement. Every supplier you want on a catalogue, a portal or an electronic invoicing channel has to be contacted, convinced and configured. A few will refuse. Budget for a per supplier effort and a realistic adoption curve, and accept that you will run two channels for a long time. Companies that skip this end up with a beautiful system used by 30% of their supply base.

Master data remediation before go live. Deduplication, entity mapping, tax identifiers, bank details, payment terms normalisation. This is unglamorous and it is the prerequisite for every downstream benefit. Do it before, or discover it during, at three times the cost and with the project's credibility already spent.

Approver time outside finance. Every approval step you design consumes minutes from people whose time is not in the procurement budget. A chain with four approvals on ten thousand transactions a year is a real headcount cost sitting in other departments. This is why approval chains should be designed as a cost, not as a safety blanket.

Where the return actually comes from

| Source | Typical time to appear | How you measure it |

|---|---|---|

| Price compliance on contracted items | Month 3 onwards | Invoiced price against contracted price, by item |

| Reduction in off contract spend | Month 4 onwards | PO coverage by category |

| Early payment discounts captured | Month 2 onwards | Discounts available against discounts taken |

| Reduced duplicate and erroneous payments | Immediate | Recovery audit findings trend |

| Working capital from terms alignment | Month 6 onwards | DPO against contracted terms |

| AP processing cost per invoice | Month 6 onwards | Fully loaded AP cost divided by invoice volume |

The third row is the one finance teams forget. Early payment discounts that expire because an invoice sat in an exception queue are pure loss, fully attributable, and easy to quantify retroactively. It is often the fastest credible win in the whole programme.

If you want the deep version of the last two rows, the mechanics of invoice handling deserve their own treatment, and I have written it out in how to automate the accounts payable process.

PO coverage: the metric that drives all the others

If a board asks me for one number to govern procure to pay, I give them PO coverage, and I give them the reason.

PO coverage is the percentage of addressable spend that was committed through a purchase order issued before the goods or services were delivered. Note the three qualifiers, because each one is where the number gets fudged.

Addressable. Exclude what genuinely cannot be ordered in advance: payroll, taxes, utilities under regulated tariffs, intercompany. Exclude nothing else. Categories that are hard are not the same as categories that are impossible, and most "we cannot PO this" claims are about difficulty.

Committed through a purchase order. A PO raised after the invoice arrives, purely to make the system happy, is not coverage. It is a reconciliation artefact. Measure the share of POs created after the invoice date and report it separately. In companies measuring this for the first time, that figure is frequently above 30%.

Before delivery. The date test is what makes the metric honest.

Why this one metric governs the rest: with high genuine coverage, spend is visible before it is spent, contracts can be enforced at the point of commitment, the three way match becomes possible, accruals become accurate, and budget owners see commitments rather than surprises. With low coverage, every one of those breaks, and no amount of automation downstream repairs it.

A realistic target progression for a company starting from a low base: 40% in six months, 65% in twelve, 80% in twenty four, with the residual being genuinely hard categories that you document rather than chase.

Four operating models, and how to choose

There is no universally correct structure. There are four, and the choice depends on spend concentration and on how many legal entities you run.

Fully decentralised. Each business unit buys for itself. Fast, locally responsive, and structurally unable to leverage volume. Defensible only in genuinely unrelated businesses.

Centre led with local execution. Category strategy and contracts are central, transactional buying is local. This is the model that works for the largest number of mid sized companies, because it separates the negotiation, which benefits from scale, from the execution, which benefits from proximity.

Fully centralised. All buying through a central function. Maximum leverage and compliance, higher risk of becoming a bottleneck that the business routes around.

Shared services plus centre of excellence. Transactional processing consolidated into a shared service, strategic work in a small central team. Efficient at volume, and it requires the process to be standardised first. Consolidating a broken process produces a faster broken process.

A practical test for which one you are ready for: if your top twenty suppliers account for less than half your addressable spend, you have a fragmentation problem and centralising the strategy will pay quickly. If they account for most of it, your problem is supplier performance rather than structure, and the work belongs in the territory I covered in building a vendor management program.

Seven metrics worth reporting

| Metric | Definition | What it tells you |

|---|---|---|

| PO coverage | Addressable spend committed via PO before delivery | Whether control exists at all |

| Retroactive PO rate | POs created after invoice date, as share of POs | Whether coverage is real |

| First time match rate | Invoices clearing without human touch | Health of data and of order discipline |

| Exception ageing | Share of exceptions older than five days | Whether the queue is managed |

| Contract price compliance | Invoiced price against contracted price | Whether negotiated savings survive |

| DPO against contracted terms | Actual payment days minus agreed terms | Working capital and supplier risk |

| Cost per invoice, fully loaded | Total AP cost divided by invoices processed | Efficiency, once the others are healthy |

Report them in that order, because they are causal in that order. A company optimising cost per invoice while PO coverage sits at 35% is polishing the last step of a process that failed at the third.

One warning about the last metric. Benchmark research on accounts payable performance, including the work published by The Hackett Group and by APQC, consistently shows an order of magnitude gap between top and bottom performers on cost per invoice. That gap is real, but it is an output. Chasing it directly, without fixing coverage and match rate first, produces a cheaper version of the same errors.

Eighteen questions for your own process

Not for a vendor. For your team, in a room, with the answers written down. If more than five produce a debate rather than an answer, you have found your project.

What percentage of our addressable spend went through a PO last quarter?
How many of those POs were created after the invoice date?
Who is allowed to commit the company to a supplier without procurement involvement?
How do we record acceptance of a service that has no physical delivery?
How many active suppliers do we have, and how many did we pay in the last twelve months?
Who can create a supplier record, and can that person also release a payment?
What is our procedure when a supplier emails changed bank details?
What are our match tolerances, who set them, and when were they last reviewed?
How many invoices are currently in exception, and what is the oldest?
Who resolves an exception caused by a missing receipt, the buyer or AP?
How much did we lose last year in expired early payment discounts?
What is our average approval cycle time from requisition to PO?
At what point does a requester decide to bypass the process, and why?
Do budget owners see commitments or only actuals?
How do we detect a duplicate payment, and does that check run before or after release?
What happens to a supplier we have not transacted with for two years?
Which three categories generate most of our exceptions?
If our AP lead left tomorrow, what would stop working within a week?

Question 18 is the one I would ask first. The answer tells you exactly how much of your process lives in a system and how much lives in a person.

What this looks like in practice

A few patterns from work I have done, stripped of anything identifying.

At a sports distribution company, the visible project was marketing and the 30% sales increase came from there. The part nobody talks about is that it was only possible because the commercial side finally had reliable supplier and stock data to plan against. Bad purchasing data does not just cost purchasing money, it caps what every downstream function can attempt.

At a hotel group that moved from nine to ten million in revenue, a meaningful slice of the improvement was cost side rather than revenue side: the same buying, run through a proper commitment process, stopped leaking through last minute purchases at list price. Nobody negotiates well at seven in the evening when the delivery is needed at eight.

At a medical centre that increased delivered capacity by 20% without hiring, the enabling change was scheduling. But the reason the plan held was that consumables and maintenance were finally ordered against forecast demand rather than against whoever noticed the shelf was empty.

The pattern in all three: procure to pay is not a back office function that occasionally saves money. It is the mechanism that determines whether the rest of the business can plan.

If your PO coverage number is unknown, or known and embarrassing, that is the place to start and it takes a week to measure. Send me a description of your setup and I will tell you which of the seven failure points above is most likely costing you the most, based on what the pattern usually looks like at your size.

A 90 day plan

Days 1 to 30: measure and decide

Week 1. Pull twelve months of spend and classify it: addressable against non addressable, PO backed against not, contracted against not. This is the fact base and nothing else should start before it exists.

Week 2. Calculate PO coverage and retroactive PO rate by category and business unit. Calculate exception ageing. Pull the last twelve months of expired discounts.

Week 3. Run a supplier master audit: duplicates, dormant records, missing tax data, shared bank accounts across different suppliers. The last check often produces the most interesting conversation of the whole exercise.

Week 4. Pick the three categories that generate most exceptions and design the target flow for those only. Resist the urge to redesign everything.

Days 31 to 60: fix the cheap things

Implement the six controls listed above. None of them requires procurement software and all of them can be done with permissions, a written procedure and a scheduled report.

Set match tolerances explicitly and document who owns them. Publish the exception resolution rule: who resolves what, and the five day ageing target.

Launch the compliant path for the three chosen categories, and make it demonstrably faster than the workaround. Measure the cycle time from requisition to PO before and after. If it is not faster, the rollout stops until it is.

Days 61 to 90: extend and lock in

Extend to the next set of categories by spend, not by ease. Move dormant suppliers to inactive. Start the monthly reporting pack with the seven metrics, in causal order.

At day 90, compare against the week 2 baseline. If PO coverage has not moved, the problem is not the design, it is that the compliant path is still slower than the shortcut. That is a fixable problem, but only if you name it correctly.

The mistake that undoes all of this

The most common failure I see is sequencing. A company buys a procure to pay platform, implements it against the process it already has, and automates its own dysfunction at speed. Twelve months later the metrics look identical, the vendor is blamed, and the next project starts from a worse position because the organisation has learned that these programmes do not work.

The order that works is unglamorous: measure, design, control, then automate. Automation is the multiplier at the end, not the intervention at the start. A company that fixes PO coverage, service receipts and supplier master data with nothing but rules and discipline will outperform a company that buys the best platform on the market and points it at a broken chain.

If you are at the beginning of this and want a second opinion on where to spend the first 30 days, describe your situation and I will tell you what I would look at first and what I would deliberately ignore.

FAQ

What are the procure to pay process steps and owners?

Nine steps, each with a single accountable owner. Need identification and requisition sit with the requester and the cost centre owner. Supplier selection and purchase order issue sit with procurement. Order acknowledgement is shared between the supplier and the buyer. Goods or service receipt sits with the receiver or, for services, with the budget owner who accepts the work. Invoice capture and matching sit with accounts payable. Exception resolution sits with AP for the queue but with the originating buyer or requester for the answer. Payment and reconciliation sit with treasury and accounting. The step that most often has no owner at all is service receipt, and that is where the three way match quietly collapses.

What is the difference between procure to pay and source to pay?

Source to pay is the wider chain and includes everything procure to pay does, plus the upstream strategic work: category strategy, market analysis, sourcing events, negotiation and contract award. Procure to pay begins once a commercial framework exists and covers execution, from requisition through purchase order, receipt, invoice matching and payment. The distinction is practical rather than theoretical: if you are paying too much per unit, the problem is upstream in sourcing. If you cannot tell what you bought, under which contract, and whether the invoiced price matches the agreed price, the problem is in procure to pay.

What is a three way match and when should tolerances apply?

A three way match compares the purchase order, the goods receipt and the supplier invoice on price, quantity and item. When all three agree, the invoice clears without human intervention. Tolerances exist so that trivial differences do not consume a person's time. A workable design blocks all quantity variance in either direction, allows a small percentage or absolute cap on price variance to absorb rounding and currency noise, and sets a fixed cap for freight and small charges. Two rules matter: tolerances are set jointly by finance and procurement rather than by whoever clears the queue, and a sample of tolerance approvals is reviewed every quarter.

How do you measure whether a procure to pay process is working?

Seven metrics, reported in causal order. PO coverage, meaning addressable spend committed through a purchase order before delivery. Retroactive PO rate, which tells you whether that coverage is genuine or manufactured after the fact. First time match rate. Exception ageing, specifically the share older than five days. Contract price compliance, comparing invoiced price to contracted price. Days payable outstanding against contracted terms. Cost per invoice, fully loaded, last. Reporting cost per invoice while PO coverage sits below half is optimising the final step of a chain that already failed at the third.

How long does it take to fix a broken procure to pay process?

Measurable movement in 90 days, structural change in 12 to 24 months. The first 30 days are measurement: spend classification, PO coverage by category, exception ageing, supplier master audit. The next 30 are the controls that cost nothing, including separation of supplier creation from payment release, bank detail verification through an independent channel, duplicate detection before payment release, and explicit match tolerances. The final 30 extend the compliant path to more categories. Full PO coverage maturity, meaning 80% or better on addressable spend, typically takes two years and is limited by supplier enablement rather than by internal capability.

Do we need procurement software to fix this?

Not to start, and starting with software is the most common way these programmes fail. Five of the six highest value controls require only permissions changes, a written procedure and a scheduled report. The expensive part of control design is deciding, not building. Software becomes the right investment once the process is defined and stable, because automation multiplies whatever it is pointed at. A company that automates a chain with 35% PO coverage and no service receipt step gets the same errors, faster, and loses the organisational credibility needed for the next attempt.

What is maverick spend and how do you actually reduce it?

Maverick spend is buying that happens outside negotiated agreements, which is how contracted savings disappear between signature and invoice. It is almost never deliberate. It is the result of a requisition path that is too slow, a catalogue that is out of date, or a contract nobody can find at the moment of need. Enforcement alone produces workarounds. The sequence that works is to make the compliant path faster than the shortcut first, measured as cycle time from requisition to purchase order, and only then enforce. If your compliant path takes nine days and the need is tomorrow, the bypass is not a discipline problem, it is a design outcome.

Who should own the procure to pay process end to end?

One person, and in most mid sized companies that person sits in finance with a dotted line to procurement, or the reverse. What does not work is splitting ownership at the invoice, with procurement owning everything before it and finance everything after, because every expensive failure in this process happens exactly at that seam. The practical test: name the single person who is accountable for PO coverage and for exception ageing at the same time. If two different names come up, the seam is unowned and that is the first thing to fix, ahead of any tool or structural change.