When an invoice arrives for 100 items, and you've only got 80 in the warehouse, accounts payable notice the invoice, purchasing has the purchase order, and the receiving team has the receipt of goods. Before the company actually pays the invoice, these records need to tell the same story. The procure-to-pay process links these activities so the company can monitor what was requested, ordered, received, and paid for.
Without that link, teams are forced to email for approvals and review multiple spreadsheets. A good P2P process is easy to follow, especially when there is a short delivery, a disputed invoice, or when a team member is away.
What Is the Procure-to-Pay Process?
Procure-to-pay, abbreviated P2P, is the business process that links a purchase request to ordering, receipt of goods/services, validation of supplier invoice, and payment. Procurement (the requesting party), receiving, and finance all hold responsibility for the process.
The terms are often thrown around casually. Source to pay is a broader term that also covers the areas of sourcing, contracting, and supplier negotiation. Accounts payable covers the invoice-to-payment component of P2P. Neither phrase encompasses quite the same length of the overall purchase-to-pay process.
Procure-to-Pay Process Steps
A company might merge some of these stages or have various approval routes for inventory, equipment, recurring costs, and services. .
1. Raise a Purchase Request
It begins when a department needs something. A purchase requisition is created that states the item needed, the quantity, the date it is required, the department requesting it, and the business reason for the requirement. Specifications or reference to an existing supplier arrangement can be included.
For example, a request for replacement machine parts should specify the exact part and date. Otherwise, purchasing might order what appears to be the correct part but cannot be used on receipt.
2. Review and Approve the Request
The responsible approver can authorize the purchase if it is justified and within the specified budget and policy. Authorization can be based on value, department, product category, project, or legal entity.
Explain the consequences of an approver being absent. Delegate and escalate rules should keep work moving while maintaining the level of authority required. After approval, if additional or larger scope is desired, does this workflow ask, “Another review?”
3. Issue the Purchase Order
The purchase order, or PO, records the agreed supplier, items or services, quantities, prices, delivery arrangements, and payment terms. Purchasing sends it to the supplier and records any confirmation or agreed changes.
Keep approved revisions traceable. If a buyer changes the unit price after an invoice arrives, finance needs to know whether that change was authorized or simply entered to remove a mismatch.
4. Record What Was Received
The receiving team checks the delivery against the PO and records actual quantities, shortages, damage, and any inspection status. A supplier's dispatch notice is not proof that the business received and accepted the goods.
For services, the equivalent evidence might be an approved timesheet, completed milestone, or service acceptance record. The person confirming completion needs enough information to verify the work rather than approving it because an invoice has arrived.
5. Capture and Validate the Supplier Invoice
Accounts payable checks the invoice's supplier identity, reference, dates, amounts, and relevant purchasing records. Duplicate checks help identify invoices already entered through another channel.
Where three-way matching applies, the business compares the purchase order, receipt, and invoice. An invoice outside the approved matching tolerances should enter a defined review process. Non-PO purchases need their own authorization and evidence requirements.
6. Approve and Execute Payment
Once the required checks are complete, finance schedules payment under the agreed terms and approval rules. Payment release should use verified supplier details, with separate review for sensitive changes such as a new bank account.
An invoice marked as approved has not necessarily been paid. The workflow needs to distinguish approval, payment submission, confirmation, and failure so employees do not release a second payment while the first is still being processed.
7. Reconcile and Close Outstanding Items
Finance applies the confirmed payment to the appropriate invoices and reconciles the relevant bank and accounting records. Credits, remaining balances, failed payments, and open purchase quantities still need attention.
A paid invoice does not always mean the PO is complete. If part of the delivery is outstanding, purchasing must keep that balance open or obtain approval to cancel it.
Procure-to-Pay Example: A Partial Delivery
Consider an illustrative purchase of 100 replacement parts at $20 each. The PO totals $2,000 before tax and freight. The warehouse receives 80 usable parts, while the supplier invoices all 100.
| Record | Quantity | Amount |
|---|---|---|
| Purchase order | 100 | $2,000 |
| Recorded receipt | 80 | $1,600 at the PO unit price |
| Supplier invoice | 100 | $2,000 |
| Unreceived quantity | 20 | $400 at the PO unit price |
Under this example's policy, payment requires receipt evidence for the billed quantity, with no tolerance for unreceived items and no advance-payment arrangement. The invoice therefore needs review before release.
Purchasing checks whether the remaining parts are still coming. Accounts payable follows the agreed resolution, which could involve waiting for delivery or obtaining a corrected invoice or credit. Any partial payment must follow the supplier agreement, company policy, and system capabilities.
The receiver should not increase the receipt to 100 just to clear the invoice. That would hide the shortage and overstate inventory. The difference needs an owner and a recorded resolution.
Controls That Keep the P2P Process Reliable
Three-way matching compares the purchase order, receipt and invoice within the controls you configure. Two-way matching compares the purchase order and invoice. Four-way matching includes inspection acceptance as well. Which control you use depends on the purchase and your needs..
Explicit approval of tolerances. A cost difference may be OK on one order type, and a quantity difference on a controlled item could trigger an inquiry. Note the authorizers for changing the rules and releasing an exception.
Other controls should address the points where people can change purchasing or payment outcomes:
- Separate sensitive responsibilities: Avoid giving one person unrestricted control over supplier creation, purchase approval, and payment release.
- Verify supplier changes: Review bank-detail changes through a trusted verification procedure before using them for payment.
- Retain supporting records: Keep approvals, PO revisions, receipts, invoice holds, and authorized overrides traceable.
- Assign exception owners: A blocked invoice needs a reason, a responsible person, and a route to resolution.
Supplier identifiers, payment terms, item codes, and units of measure also need consistent ownership. A receipt entered in cases cannot be compared safely with an invoice entered in individual units unless the conversion is understood. These underlying responsibilities belong in your ERP master data management process.
What Procure-to-Pay Automation Should Handle
Procure-to-pay automation can route requests, create POs from approved requisitions, capture invoice information, compare records, and notify the person responsible for a discrepancy. Its value depends on whether employees can trust the records and understand the exceptions.
Invoice capture, for example, can reduce typing, but extracted quantities, supplier details, and totals still need validation. A readable invoice is not evidence that the delivery happened or that the purchase was authorized.
When purchasing, receiving, and accounting use separate applications, decide which system owns each record and how updates reach the others. A receipt may be recorded in a warehouse application while invoice approval happens in the ERP. If that update fails, finance needs a visible exception rather than a misleading zero receipt. Our guide to ERP integration challenges explains the broader synchronization and recovery issues.
Before approving automation, ask the team to demonstrate a partial receipt, duplicate invoice, rejected approval, changed PO, and failed payment. Those cases reveal more about the design than an uncomplicated purchase.
Building P2P Workflows With Moqui and Apache OFBiz
Moqui and Apache OFBiz provide different foundations to build your enterprise application. The choice of implementation should be determined by the required workflow and the existing functionality that is available in the desired environment.
Moqui and Mantle
Moqui provides the application framework. Mantle adds reusable business data and services, including documented procure-to-pay capabilities for suppliers, purchase orders, receiving, and accounts payable.
A project still needs to establish how those capabilities fit its approval rules, user interfaces, financial systems, and exception handling. NOI's Moqui development services can support that assessment and the required application extensions or integrations.
Apache OFBiz
Apache OFBiz provides business applications for accounting, orders, inventory, and other functions with a common architecture that can be extended by developers. Before adding new components, evaluate the current purchasing and financial workflows.
Where the business needs specialized receiving screens, approval behavior, reports, or external connections, Apache OFBiz development and customization can address the agreed gaps. The installed version and configuration must be checked before promising a particular matching or payment control.
How to Measure Procure-to-Pay Performance
Start with a few measures that show where work waits: requisition-to-PO time, invoice receipt-to-approval time, the percentage of invoices requiring manual resolution, and the value of overdue unresolved exceptions.
Specify the beginning event, ending event, and exceptions for every measure. Separate time working on fixing errors internally from time waiting for the response from the supplier. Otherwise, the average cycle time will hide the problem, which your team needs to resolve.
Improving Your Purchasing-to-Payment Workflow
Pick one recent purchase with manual follow-up, and see the record from request to payment. Spot where data was lacking, which decision took place outside the system, and who had to fix it. Now you have a real data point to tell your team where to focus.
NOI Technologies helps businesses assess and develop connected ERP workflows using Moqui and Apache OFBiz. Bring a representative purchase, its exceptions, and the systems involved so the discussion can focus on the changes your operation needs.