Procure to payment, more commonly written procure to pay, is the whole cycle from somebody wanting something to the supplier being paid for it. It has two clear owners and one step that in most organisations belongs to neither, and that orphan step is the goods receipt. Nearly every recurring problem in the cycle traces back to it in some form.
Purchasing owns the front half
The request, its approval, the purchase order and the supplier relationship. Their measures are usually price, supplier performance and coverage, none of which are affected by whether receipts get recorded. That misalignment is structural rather than anybody's fault, and it explains why exhortation rarely fixes the receipt problem.
Payables owns the back half
The invoice, the match, the approval and the payment. Their measures are invoices processed, exceptions cleared and not paying twice, all of which depend heavily on receipts being recorded. Payables therefore experiences the consequence of a step it does not control, which is a recipe for friction between the two functions.
The orphan in the middle
Recording what arrived belongs, practically, to whoever takes the delivery, who works for neither department and is measured on neither. Making it explicitly somebody's job, and making it take seconds on whatever device is to hand, is the single highest-value change available in most procure to payment cycles, and it costs nothing.
Questions people ask about procure to payment
Who should own the whole cycle?
Somebody senior enough to arbitrate between the two functions, because the problems concentrate at the boundary rather than inside either half.
Does one system fix the seam?
It removes the reconciliation between systems, which helps. It does not by itself assign the receipt step to anybody, which remains an organisational decision.
What is the first thing to measure?
The share of invoices that arrive with both an order and a recorded receipt behind them. That one number describes the health of the whole cycle.