.svg)
The purchase to payment process covers everything from the moment a purchase request is raised to the moment the supplier is paid. It sounds straightforward. In practice, it is one of the most complex and time-consuming workflows in a finance function, and most of the complexity is not in the steps themselves. It is in the handoffs between them.
This article breaks down each stage of the P2P process, explains where time is genuinely lost in a manual environment, and shows what changes when the process is automated end to end.
The purchase to payment process (also called procure to pay, or P2P) is the end-to-end workflow that governs how a business acquires goods or services from an external supplier and pays for them.
It starts with procurement and ends with payment reconciliation. Everything in between, purchase requests, purchase orders, goods receipts, invoice processing, matching, approval, and payment, is part of the P2P cycle.
The terms "purchase to payment" and "procure to pay" refer to the same process. P2P is the shorthand used across most finance and procurement teams.
The P2P process is not just a procurement concern. It sits at the heart of how a business manages its financial commitments, its supplier relationships, and its cash position.
An inefficient P2P process creates delays at every stage: requisitions waiting for approval, POs raised too late, invoices sitting in queues, payments made after due dates. Each delay is a cost, whether in late payment charges, missed early payment discounts, strained supplier relationships, or simply the time the finance team spends chasing things through a system that was not designed to move quickly.
A well-run P2P process gives finance leaders accurate visibility into committed spend before it becomes a liability. It makes cash flow forecasting more reliable. And it ensures suppliers are paid on time, which is the foundation of a supplier relationship that works in both directions.
The P2P process runs across six connected stages. Each one has to complete before the next can begin, which is why delays at any point compound as they move through the system.
The process starts when someone in the business identifies a need. A purchase requisition is an internal request to buy goods or services. It captures what is needed, the estimated cost, the cost centre it should be charged to, and the business justification.
In a manual environment, requisitions are typically submitted via email or a shared form. The approval process is often informal: a manager replies approving the spend, or the request sits in an inbox waiting for someone to notice it. There is no central record of what has been requested, what has been approved, or what is still outstanding.
Lack of visibility at this first stage is what creates most of the downstream problems in the P2P process. Spend that has not been properly authorised creates matching exceptions when the invoice arrives. Cost centres that are not captured correctly at requisition stage create coding errors that need to be fixed manually later.
Once a requisition is approved, a purchase order is raised. The PO is the formal document that commits the business to the purchase. It specifies the supplier, the goods or services, the agreed price, the quantity, the delivery date, and the cost centre.
The PO is what automated matching relies on later in the process. An invoice that arrives without a corresponding PO in the system, or with a PO that does not match the invoiced amount, becomes an exception. The quality of matching downstream depends entirely on the quality of POs upstream.
The most common source of matching exceptions is not invoice fraud or supplier error. It is POs that were raised without complete information, or not raised at all.
In businesses where PO creation is manual and inconsistent, teams often find themselves processing invoices with no PO to match against. The invoice is valid. The supplier is legitimate. But the process cannot confirm it automatically, so someone has to review it manually every time.
When the goods or services are delivered, the receiving party confirms receipt. In a goods-based context, this is the goods receipt note (GRN) or delivery note. In a services context, it may be a sign-off from the business unit that commissioned the work.
Goods receipt confirmation is the third leg of the three-way match. Without it, the AP team cannot confirm that what was ordered was actually received, which means they cannot approve payment against the invoice. When goods receipts are not recorded promptly in the system, invoices sit in a holding queue waiting for a confirmation that has already happened in the real world but has not yet been captured in the system.
This stage is often underestimated as a source of P2P delay. Finance teams frequently focus on invoice processing speed, but the bottleneck is often the goods receipt confirmation sitting outstanding for days after delivery.
The invoice arrives from the supplier. In a manual P2P process, it is received by email or post, read by a team member, and entered into the AP system by hand. Invoice data is extracted manually: supplier name, invoice number, date, line items, amounts, tax, total, payment terms.
This is the stage that varies most in speed and accuracy between manual and automated environments. Manual entry of invoice data is slow and error-prone. Error rates on manual data entry typically sit between 1% and 5%, depending on volume and team capacity. At scale, that error rate translates directly into exceptions, disputes, and reconciliation problems.
Automated invoice processing replaces manual entry with AI-based extraction. The system reads the invoice and extracts all relevant fields without human intervention. First-pass accuracy on established AI platforms is above 95%, and it improves over time as the system processes more invoices from your specific supplier base.
Once invoice data is captured, it is matched against the purchase order and the goods receipt note. This is the three-way match: confirming that the supplier, quantity, and price on the invoice agree with what was ordered and what was received.
When all three agree within configured tolerances, the invoice is approved for payment without requiring any human review. This is the straight-through processing (STP) rate: the proportion of invoices that move from receipt to approval without any manual step.
Well-implemented automated platforms achieve STP rates above 80%. In a manual environment, the STP rate is effectively zero, because every invoice requires at least some manual step.
When matching fails, the invoice becomes an exception. In an automated system, exceptions are routed immediately to the right person with the specific discrepancy identified and the relevant documents attached. In a manual system, exceptions sit in a queue until someone picks them up, often with no indication of what went wrong or who needs to resolve it.
Invoices that pass matching enter the approval workflow. Approval rules determine routing based on invoice amount, supplier category, department, or entity. Approvers receive a notification and act on it, with escalation if they do not respond within the configured window.
Once approved, the invoice is included in the next payment run. Payment data syncs to the ERP and back to the AP platform in real time. The invoice is closed. The liability is removed from the AP ledger. The supplier record is updated.
Reconciliation confirms that the AP sub-ledger, the GL control account, and the bank statement all agree. In a manual environment, this happens at month-end and takes days. In an environment with real-time ERP integration, it is continuous.
Most P2P problems are not caused by a single broken step. They are caused by the accumulation of small delays and data quality issues across multiple steps that were never designed to work together smoothly.
Businesses that have not enforced PO discipline find that a significant proportion of invoices arrive with no matching PO. These invoices cannot be automatically matched, regardless of how good the matching system is. They all become manual exceptions.
The fix is upstream, not in the AP function. Consistent PO creation, even for lower-value purchases, is the single most effective way to reduce the AP team's exception workload.
When procurement runs in one system, ERP in another, and AP in a third, the P2P process involves manual handoffs at every boundary. Data that exists in procurement has to be re-entered in the ERP. Data that exists in the ERP has to be checked manually in the AP system. Each handoff introduces delay and the possibility of error.
The most significant efficiency gains from P2P automation come from eliminating these handoffs, not from automating individual steps in isolation.
Approval delays are the single most consistent cause of late payments in manual P2P processes. When approval relies on an email chain with no automated escalation, an approver who is travelling or on leave stops the entire process for that invoice.
Automated approval workflows with configured escalation paths remove this dependency. The process continues regardless of whether a specific individual is available.
A fully automated procure to pay process does not just speed up the existing steps. It changes the structure of the workflow.
Invoices that match clean pass through without any human involvement. The team's time is spent on exceptions that genuinely require judgement, not on routine processing. The system learns from how exceptions are resolved, so the exception rate decreases over time.
Visibility is continuous, not periodic. Finance leaders see committed spend, outstanding invoices, pending approvals, and cash outflow forecasts in real time, not as a snapshot from yesterday's batch.
ERP data is always current. Month-end close is a review of an already-reconciled period, not a reconciliation project.
According to Ardent Partners' AP Metrics That Matter report, best-in-class AP teams process invoices at an average cost of under £2 and achieve STP rates above 80%. The gap between best-in-class and average performance is almost entirely explained by the degree of automation in the P2P process.
Dost handles the AP stages of the purchase to payment process as a single connected workflow. Invoice capture, validation, three-way matching, approval routing, payment initiation, and ERP reconciliation work together in one environment.
Native, real-time, bidirectional integration with SAP, Microsoft Business Central, Sage (200, Intacct, X3), and Oracle means that PO data and goods receipts are available to the matching system the moment they are recorded, not at the next sync. Payment data flows back to Dost as soon as it is posted in the ERP. There is no reconciliation lag.
The AI is trained on your data. Your supplier base, your PO formats, your exception patterns, your approval logic: the system learns from all of it. The STP rate on month six is meaningfully higher than on month one, without any configuration change from the team.
See what end-to-end P2P automation could save your finance team. Use Dost's ROI calculator to calculate your potential savings based on your current invoice volume and processing costs.
The terms refer to the same process. Procure to pay (P2P) is the more common term in procurement and finance technology. Purchase to payment is used interchangeably in many organisations. Both describe the end-to-end workflow from purchase requisition through to supplier payment. The scope, stages, and challenges are identical regardless of which term a business uses.
Three-way matching is the validation step in Stage 5 of the P2P process. It compares the invoice against the purchase order and the goods receipt note to confirm that the supplier, quantity, and price all agree. When they do, the invoice passes to approval without human review. When they do not, it becomes an exception. The quality of three-way matching determines the straight-through processing rate, which is the primary driver of AP team efficiency in an automated P2P environment.
Best-in-class automated P2P processes achieve straight-through processing rates above 80%, meaning more than four in five invoices move from receipt to approval without any manual step. The rate on a newly implemented platform is typically lower at the start, as the system learns your supplier base and exception patterns, and improves over the first three to six months. The starting STP rate depends heavily on PO coverage: businesses with high PO discipline from the start achieve higher initial STP rates.
The purchase to payment process is one of the most visible indicators of how a finance function is actually running. A P2P process that moves quickly, with high STP rates, accurate data, and real-time ERP visibility, reflects a function with strong controls and reliable data. A P2P process that relies on manual steps, email approvals, and periodic batch updates reflects one that is consuming significant team capacity on work that should be automated.
The case for improving the P2P process is not made in theory. It is made in the time the AP team spends on exceptions that should not exist, in the supplier disputes that result from inconsistent PO data, in the early payment discounts that a manual process cannot capture fast enough to take advantage of.
Automation addresses all of these at the root cause level, not by working harder on the same process, but by removing the manual steps that create the problems in the first place.
Calculate what an automated P2P process could save your finance team with Dost's ROI calculator.
