Procure to Pay Business Process: Ownership Model

Most procure to pay problems are not process design problems. The flow chart is usually fine. What breaks is ownership: who decides, who is accountable when the join between procurement and finance fails, and who holds the mandate to change anything. This guide takes the organisational view of procure to pay. It covers who should own the process, how global process owners and shared service centres fit, what service levels to commit to, and how to report the capability to an executive audience that cares about outcomes.

Why ownership is the hard part

The mechanics of procure to pay are well understood. A need is raised, approved, turned into an order, delivered, invoiced, matched and paid. Our complete procure to pay guide walks that chain step by step, and the companion process mapping and automation guide deals with how to document and streamline it. Neither of those, on its own, tells you why two organisations running the same design on the same software get very different results.

The difference is almost always the operating model. Procure to pay is unusual among business processes because it crosses a functional boundary at exactly the point where the risk sits. Procurement raises the commitment; finance settles it. In between lies receipting, matching and exception handling, work that neither function naturally volunteers for and both quietly blame for delays. When something goes wrong at that seam, the escalation path often runs all the way to a chief financial officer before anyone with authority over both sides can decide.

That is the practical definition of an ownership gap. It shows up as invoices sitting in a queue nobody is measured on, and as improvement projects that stall because they would require the other function to change something. Fixing the flow chart does not touch any of this. Fixing the accountabilities does.

Procurement, finance, or both?

The ownership debate usually starts as a turf question and is best answered as a design question. Both functions have a legitimate claim. Procurement owns supplier selection, commercial terms and the quality of what is bought. Accounts payable sits inside finance and owns the control, the liability and the cash. Neither can deliver the outcome alone.

The workable answer is to separate ownership of the end-to-end process from ownership of its component activities. One named owner holds the whole; the functions hold their parts within an agreed design. Set out plainly, the split is less contentious than it sounds:

Read down the final column and you can see what the process owner role really is. It is not a second manager for the same people. It is accountability for the measures that no single function can move alone, plus the authority to settle disagreements without escalation. Where that column is empty, the seam is unowned and problems will collect there. The tensions between the two functions, and the shared measures that resolve them, are covered further in our procurement and finance guide.

The global process owner role

In larger and multi-country organisations, the end-to-end owner is usually formalised as a global process owner. The title varies but the mandate is consistent: one person accountable for how procure to pay works everywhere the organisation operates. The role is often misunderstood as a senior operations job. It is closer to a design and governance job.

A global process owner does four things that nobody else is positioned to do. They hold the standard design and decide where local variation is genuinely required, which is usually a legal or tax matter rather than a preference. They own the end-to-end measures, so the numbers reported are not each function's favourable slice. They arbitrate between procurement and finance when priorities collide, which removes the escalation that otherwise consumes executive time. And they hold the improvement roadmap, so change is sequenced rather than opportunistic.

Two design choices decide whether the role works. The first is reporting line: a process owner buried inside either procurement or finance will be read as partisan, so report to a transformation lead or jointly to both functions. The second is resourcing. A process owner with no analyst, no budget and no change capacity becomes a coordinator of other people's plans.

Shared service centres and outsourcing

Once ownership is settled, the next question is where the work physically sits. Most organisations of scale end up with some combination of local teams, a shared service centre and possibly an outsourced provider. That choice follows from the nature of each step.

• High volume, rule based. Invoice capture, matching, supplier master data and payment runs concentrate well. Volume creates specialism, and standard rules travel across geographies without much loss.
• Judgement heavy. Category strategy, negotiation, supplier development and complex exception resolution depend on context and relationships. Centralising them tends to produce technically correct decisions that the business will not follow.
• Locally constrained. Tax treatment, statutory invoice formats and language-bound supplier contact often force a local footprint regardless of preference. Design for it rather than fighting it.
• Control critical. Payment authorisation and bank detail changes should sit where segregation of duties is strongest and monitoring is tightest, which is usually a controlled central team.
• Improvement work. Analysis, reporting and change delivery belong with the process owner, not distributed across sites where each solves the same problem differently.

Outsourcing takes the same logic one step further by handing transactional work to a third party. It can lower unit cost and give access to capacity quickly, but it hardens the boundary you drew. Anything you did not specify in the contract will not happen, and exception handling, the part of procure to pay that most needs judgement, is the hardest thing to specify. Organisations that outsource successfully tend to retain the process ownership, the data and the exception policy in house, and buy execution capacity rather than accountability.

Internal service levels and operating rhythm

A procure to pay function that publishes no service levels will be judged entirely on its failures. Nobody notices the invoices that pay on time. Committing to internal service levels changes that dynamic by making the normal performance visible and giving requesters something to plan against.

The measures that matter are the ones felt by the people outside the process: requisition to approval, approval to order issued, invoice received to payment scheduled, time to resolve a blocked invoice and time to answer a supplier query. Each should be measured from the moment the request arrived, not from the moment your team picked it up, because queue time is exactly what the requester experiences.

Service levels only hold if there is an operating rhythm behind them. A short daily review of aged exceptions keeps the backlog from compounding. A weekly meeting between procurement and accounts payable clears contested items and spots patterns. A monthly review with the process owner looks at trend rather than incident. Without that cadence, published targets quietly become aspirations.

Policy, controls and compliance ownership

Policy is where operating models most often drift. The document is written once, approved, filed, and then contradicted daily by what people actually do. The gap is rarely defiance. It is usually that the compliant route is slower than the deadline the requester is working to.

Good procure to pay policy is short, states its thresholds plainly, and is enforced by the system rather than by memory. If purchases above a value require three quotes, the requisition form should ask for them. The ownership question here is specific: procurement should own buying policy, finance should own approval and payment controls, and the process owner should own the interaction between them, because that is where contradictions hide.

Compliance reporting should distinguish three things it usually blurs together. Policy breaches are people going around the process. Control failures are the process failing to catch something. Design gaps are cases the policy never anticipated. They need coaching, remediation and a policy amendment respectively, so reporting them as one non-compliance percentage guarantees the wrong fix.

Training, adoption and the human side

Every procure to pay operating model depends on occasional users doing something correctly a few times a year: the budget holder approving a requisition, the site manager confirming a delivery. These people will not remember training delivered at go-live, and designing as if they will is the most reliable way to build a process that only the core team can operate.

Adoption is also a measurement question. Track the share of spend arriving with a compliant purchase order, the proportion of requisitions raised through the standard route, and the number of invoices with no order behind them. Those numbers describe adoption more honestly than course completion rates ever will.

Continuous improvement governance

An operating model that cannot change itself will decay. Suppliers change, entities are acquired and volumes grow. Organisations that keep procure to pay healthy treat improvement as a standing capability with its own governance rather than as a project that finished at go-live.

That governance needs three components. A backlog of improvement ideas, sourced from exception analysis, user feedback and supplier complaints, prioritised openly rather than by whoever asked loudest. A regular forum where the process owner, procurement, finance and the systems team review that backlog and commit to a small number of items. And a benefits check some months later, asking whether the change actually moved the measure it promised to move. The third component is the one most often skipped, and its absence is why improvement roadmaps grow indefinitely without the numbers improving.

Keep the scope of each change small: a tolerance adjustment, a routing rule, one supplier moved to electronic invoicing. Small changes can be reversed if they misfire, and a steady sequence of them compounds faster than an annual redesign that consumes a year of goodwill.

Reporting performance to the executive

Executives do not want the operational detail, and giving it to them is how procure to pay loses attention. What a board or executive committee needs is a short answer to four questions: is spending under control, is cash being managed, is the process efficient, and is risk contained. Five or six measures cover it. Spend under management answers the first. Days payable outstanding and on-time payment answer the second. Touchless invoice rate and requisition-to-order cycle time answer the third. Supplier risk coverage and audit findings answer the fourth.

Present them as trend against a stated target, with a named owner for anything off track. Resist adding measures each time a question is asked; the value of the pack is that the same numbers appear every period. Everything else belongs in the monthly operating review, where the process owner and both functions work at the level of exception queues and root causes.

The reporting is also the clearest signal of whether the operating model is real. If the numbers come from one connected record covering requisition through to payment, they will reconcile and the conversation will be about performance. If they are assembled from a procurement spreadsheet and a finance extract, the meeting will be spent arguing about which figure is right. A platform such as ProcureWave matters here less for the automation than for the fact that one process, one record and one set of measures make the ownership model enforceable rather than aspirational.

If your procure to pay process is well designed but nobody quite owns it end to end, start with the accountabilities rather than the technology. Name the owner, agree the split, publish the service levels, then let the tooling make the model visible. See how ProcureWave holds the whole chain on one record, or talk to our team about where the seams in your own operating model are costing you time and control.

Frequently asked questions

Who should own the procure to pay business process?

Most organisations that run procure to pay well give end-to-end ownership to a single named process owner, then agree that procurement owns the buying decisions and finance owns the payment and control side within that frame. Ownership of the whole is what matters. Splitting the process at the invoice, with nobody accountable for the join, is the single most common reason procure to pay underperforms even when both halves look healthy on their own dashboards.

What does a global process owner actually do?

A global process owner sets the standard design of the process, decides where local variation is allowed, owns the end-to-end measures, arbitrates between procurement and finance when their priorities conflict, and holds the improvement roadmap. They rarely manage the people who do the work day to day. Their authority comes from owning the design, the data and the change agenda rather than from a large reporting line.

Should procure to pay be run from a shared service centre?

Transactional steps such as invoice processing, supplier data maintenance and payment runs suit a shared service centre well, because they are high volume, rule based and benefit from concentration. Judgement-heavy steps such as category strategy, negotiation and supplier relationship management usually do not. The practical test is whether a step needs local market knowledge or a relationship. If it does not, it can be centralised.

What internal service levels should a procure to pay function commit to?

Useful internal service levels cover requisition approval time, purchase order turnaround, invoice processing time, exception resolution time and supplier query response time. Each should be measured from the requester or supplier point of view, not from the moment a queue was picked up. Publishing them turns procure to pay from an opaque back office into a service with visible promises people can plan around.

How should procure to pay performance be reported to the executive?

Report a short set of outcome measures rather than a long list of activity counts. Spend under management, touchless invoice rate, cycle time from requisition to order, on-time payment and realised savings tell an executive whether the capability is working. Anything more granular belongs in the operating review, not the board pack. Our procurement and finance guide covers how the two functions agree those numbers.