The P2P Process: Roles, Controls and Best Practices

Procure to pay looks like a workflow, but it is really a control framework with a workflow wrapped around it. Every stage exists because someone has to be accountable for a decision and someone else has to be able to check it. This guide sets out who does what across the process, maps the roles into a responsibility matrix, and then walks through the controls that hold it together: segregation of duties, approval thresholds, match tolerances, override handling, audit evidence, and the fraud each of them is designed to stop.

P2P is a control framework, not just a workflow

It is tempting to describe procure to pay as a sequence of steps: someone needs something, someone approves it, an order goes out, goods arrive, an invoice is paid. That description is accurate and almost useless, because it says nothing about why the steps are separated in the first place. The sequence exists to make sure that the person who wants to spend money is not the same person who authorises it, receives the goods, or releases the cash.

Seen that way, each handover is a control point. The requisition captures intent and cost centre before any commitment exists. The approval attaches a named individual to the spend decision. The purchase order creates the legal commitment and the accounting accrual. The goods receipt evidences that something actually arrived. The invoice match proves the supplier is billing for what was ordered and delivered. Remove any one of them and the chain of evidence breaks.

This is why P2P projects fail when they are treated purely as automation. Speeding up an approval nobody was really performing simply produces uncontrolled spend faster. For the mechanics of each stage rather than the accountability, our procure-to-pay guide covers the full cycle in sequence.

The seven roles in the P2P process

Job titles vary between organisations, but the functional roles do not. These seven responsibilities have to be discharged by someone, and the further apart they sit, the stronger the process.

• Requester. Identifies the business need, raises the requisition, specifies quantity and required date, and codes it to the right cost centre. Accountable for accuracy of the need, not for the commercial terms.
• Budget holder. Approves or rejects the spend against an available budget. Owns the decision that money should leave the organisation at all, and is the first person auditors ask when a cost looks unjustified.
• Buyer or procurement officer. Selects or confirms the supplier, applies negotiated pricing and contract terms, converts the approved requisition into a purchase order, and manages supplier queries. Owns commercial value.
• Receiver. Confirms what physically arrived or what service was performed, records quantity and condition, and raises discrepancies. Often a warehouse team, sometimes the requester, which is a compromise worth being deliberate about.
• Accounts payable clerk. Registers the invoice, runs the match, resolves blocks, and prepares the payment run. Owns the accuracy and timing of settlement rather than the decision to spend.
• Financial controller. Sets the thresholds and tolerances, owns the supplier master data policy, approves the payment run, and signs off period-end accruals. Owns the design of the control framework.
• Internal audit. Independently tests whether the controls operate as designed, samples transactions, investigates overrides, and reports to the audit committee. Owns assurance, never execution.

Two boundaries matter more than the rest. The buyer should not approve budget, because commercial enthusiasm and budgetary restraint are meant to pull in different directions. And internal audit should never process transactions, because nobody can independently test their own work.

Who does what: a P2P responsibility matrix

A RACI matrix makes accountability explicit by naming, for each stage, who is responsible for the work, who is accountable for the outcome, who is consulted, and who is informed. The version below is a sensible default for a mid-sized organisation and a starting point for your own.

Read the matrix vertically as well as horizontally. If one name appears in the responsible column on both the approval row and the payment row, you have a segregation problem whatever the policy says. The value of writing it down is that these collisions become visible.

Segregation of duties in practice

Segregation of duties splits a transaction so that completing it alone is impossible. In P2P the classic split is four ways: request, approve, receive, pay. A single person who could create a supplier, raise a requisition for it, approve that requisition, confirm receipt and release payment could move money out of the business without a second pair of eyes anywhere in the chain.

The subtle failures are more common than the obvious ones. Supplier master data is the usual weak point, because the ability to add or amend a supplier bank account is functionally the ability to redirect payments. That permission should sit outside both procurement and accounts payable, with changes subject to independent verification against a known contact rather than details supplied in the request itself.

Access rights are where segregation is either enforced or quietly undone. Roles in the system should mirror roles in the matrix, temporary elevated access should expire automatically, and leavers should be removed the day they go. Reviewing user permissions quarterly is unglamorous work that catches more real exposure than most policy refreshes.

Approval thresholds and delegation of authority

A delegation of authority matrix states who may commit the organisation to what. Typically it steps up by value: a team leader to a modest limit, a department head above that, a finance director higher still, and the board beyond a defined ceiling. Good matrices add a second dimension for category, so that professional services, capital expenditure and anything touching regulated activity route differently from routine stationery.

Three details separate a matrix that works from one that gets bypassed. First, delegation during absence must be explicit and time-bound, or urgent requests will simply be approved by whoever is available. Second, thresholds must be tested against actual spend distribution; a limit that sends ninety per cent of requisitions to a director will be circumvented within a month. Third, cumulative value must be assessed, not just individual transactions, otherwise the matrix invites splitting.

Where a framework agreement is already in place, approval can often be lighter because the commercial terms were settled at contract stage. That is one of the practical benefits of good procurement contracts: they let routine draw-down orders flow quickly while reserving heavyweight approval for genuinely new commitments.

Three-way match and tolerance settings

The three-way match compares the purchase order, the goods receipt and the supplier invoice. If quantity and price agree across all three, the invoice is cleared for payment. If they do not, it is blocked. The control is simple, which is exactly why it is effective: it prevents payment for goods never ordered, goods never received, and prices never agreed.

Tolerances make the control usable. Without them, a two-pence rounding difference blocks an invoice and consumes an hour of somebody's day. Set as a percentage, an absolute value, or the lower of the two, they define the range within which differences pass automatically. Common practice is a tight tolerance on unit price, a slightly looser one on quantity for goods prone to natural variation, and a hard block on any invoice with no matching order at all.

Tolerances need review, not set-and-forget treatment. Track how many invoices pass automatically and what proportion of blocks turn out to be genuine errors. If nearly every block resolves as a timing difference, the tolerance is not the problem; the receipting discipline is.

Exceptions, overrides and audit evidence

Every control framework needs a route for the case it did not anticipate. Emergency purchases and retrospective orders are facts of business life, and the risk is not that overrides exist but that they become routine and invisible. An override should require a reason from a defined list, a named approver above the normal threshold, and an entry in a log that someone reviews.

Audit evidence is the by-product of doing this well. When an auditor selects a transaction, they should be able to see the requisition and who raised it, the timestamped approval, the order sent to the supplier, the receipt with the receiver's identity, the invoice, the match result, and the payment. That trail is the difference between asserting that a control operates and demonstrating it, and systems that store approvals as immutable records rather than email threads make it straightforward.

Trend data on exceptions is management information in its own right. A supplier who consistently invoices above order price, or a department with an unusual concentration of overrides, points to something worth investigating well before it appears in an audit finding. Our P2P business process guide looks at how these measures feed process improvement.

The fraud P2P controls are designed to stop

Purchasing fraud rarely involves sophistication. It involves finding the point where nobody is looking and doing something ordinary there repeatedly.

Duplicate invoices are the most common loss and often are not fraud at all, merely the same invoice submitted twice and paid twice. Automated detection on supplier, amount, invoice number and date catches almost all of it, including the deliberate variants where a digit is altered to defeat an exact match. Fictitious or related-party suppliers depend on weak master data control; the counter is independent supplier setup, verification of bank details through a channel the requester did not supply, and periodic screening for addresses or account numbers shared with employees.

Split purchase orders break one commitment into several smaller ones to stay under an approval limit. Cumulative spend monitoring by supplier and requester over a rolling window exposes the pattern quickly. Over-receipting confirms delivery of goods that never arrived, which is why receipting should sit with someone other than the requester wherever headcount allows. And diverted payments, where a convincing email changes a supplier's bank account days before a large invoice falls due, are stopped by treating any bank detail change as a controlled event rather than an administrative update. These risks are common across every organisation that engages in procurement at scale, whatever the sector.

Making the framework work day to day

Controls that depend on memory and goodwill decay. The ones that endure are built into the system people already use, so following the process is easier than avoiding it. That means routing driven by the delegation matrix rather than by choosing an approver from a list, matching that runs automatically, and permissions that make segregation structural rather than aspirational.

Start with the responsibility matrix, because almost every weakness shows up there first. Fill in the real names, look for anyone appearing twice in the same transaction, and fix those collisions first. Then set thresholds and tolerances against your actual spend data, agree a short list of valid override reasons, and decide who reviews the exception log and how often.

Software carries the load once the design is right. ProcureWave connects requisitions, approvals, orders, receipts and invoices in one auditable flow, applies your thresholds and tolerances automatically, and keeps a timestamped record of every decision, so segregation of duties is enforced by the system rather than by reminders. If you would like to see how your own responsibility matrix would look in practice, talk to our team.

The P2P process is best understood as a series of accountable handovers, each one a control that exists because a specific thing can go wrong. Define the seven roles clearly, write the responsibility matrix down, keep requesting, approving, receiving and paying in separate hands, set thresholds and tolerances that reflect reality, and treat every override as an event worth logging. Do that, and the trail you build for auditors turns out to be the same trail that keeps the process honest the rest of the year.

Frequently asked questions

Who is responsible for the P2P process?

No single person owns it end to end. The requester raises the need, the budget holder approves the spend, the buyer converts it into an order, the receiver confirms delivery, and accounts payable matches and pays the invoice. A financial controller owns the control framework overall, and internal audit tests whether it actually works.

What is segregation of duties in procure-to-pay?

Segregation of duties means no one person can complete a purchase alone. Requesting, approving, receiving and paying are split across different people, so creating a fictitious supplier, ordering from it and releasing the payment would require collusion rather than a single set of credentials. It is the backbone of the wider procure-to-pay process.

What is a delegation of authority matrix?

It is the document that states who can approve what value of spend, in which category, and who covers them when they are away. Thresholds usually rise through line managers, department heads, finance directors and the board. Encoded in software, the matrix routes each requisition automatically instead of relying on people to remember the rules.

What are three-way match tolerances?

Tolerances are the small permitted differences between the purchase order, the goods receipt and the invoice, set in percentage or absolute terms. Within tolerance the invoice posts automatically; outside it, the invoice is blocked for review. Sensible tolerances stop trivial rounding differences from consuming the whole accounts payable team.

Which frauds do P2P controls prevent?

Chiefly duplicate invoices, fictitious or related-party suppliers, split purchase orders used to dodge approval limits, inflated quantities on receipt, and diverted bank details. Each has a specific control that counters it, from supplier master data checks to duplicate detection and cumulative spend monitoring.