Procure to Pay: Document and Review Your Process

Procure to Pay: Find and Review Process Exceptions

A procure to pay process covers the steps from a purchase request through approval, supplier selection, purchase order, and invoice handling. Document the agreed flow, review it with stakeholders, and compare it with event data to see where actual buying differs. This can help you investigate off-contract spend, split orders, and purchases with missing approvals. ProcessMind makes these patterns visible; it does not enforce procurement policy.

Why document your procurement process?

Procurement knowledge often lives across documents, spreadsheets, email threads, and the experience of a few people. As work changes, these sources can drift. Your teams may disagree about which process is current or who owns a decision.

A shared model gives process owners, approvers, and teams a common reference for the standard flow, decision points, roles, and exceptions. Sign-off and version history help you review changes and identify the approved version. Shareable links make current documentation easier to find.

For guidance on assigning responsibilities, see this RACI matrix for processes. The process owner is accountable for the process; approvers make the relevant control decisions.

Which procurement exceptions can you investigate?

Compare the agreed model with purchase-to-pay event data to see where actual cases vary. You can investigate patterns such as:

• Off-contract spend: purchases that appear to bypass the expected contract or supplier path.
• Split orders: multiple purchases that may warrant review against your purchasing rules.
• Missing approvals: cases where the expected approval activity does not appear in the event data.
• Different approval paths: variations by team, region, supplier, or purchase type.
• Rework and delays: repeated activities, handoffs, or long waits.

These patterns are signals to review, not proof of a policy violation. Your team decides what each exception means and what action to take.

How do you compare the model with actual buying?

Start with a documented process and a suitable event log. Process Mining uses event data to show the paths cases followed, including cycle times, handoffs, rework, approval paths, and deviations from the model.

Review the differences with the process owner and approvers. Confirm whether a variation is an approved exception, a documentation gap, or a process issue that needs further investigation. Learn more about comparing process data with a model.

Learn how Process Mining works.

How do you keep the approved process current?

Create a BPMN model that captures the standard flow, roles, decisions, systems, and known exceptions. Involve the process owner and relevant approvers in review and sign-off before publishing a change.

Use shareable links to point teams to the agreed documentation, and version history to track changes over time. This gives you a practical basis for reviewing the model as policies, suppliers, or working practices change.

Read about process documentation.

Where the RFP process, the RFQ process and the quotation process fit

Document the RFP process, the RFQ process and the quotation process within the wider purchasing flow, or as linked processes if that better reflects how your organization works. Record the decision points, responsibilities, and handoffs that matter. Then compare the documented route with event data where those activities are captured.

The three names answer different questions and are often used interchangeably. A request for information asks what a supplier can offer; a request for proposal asks for a solution and a price for work that is not yet fully specified; a request for quotation asks for a price against a specification you have already fixed. Standard goods may need only an RFQ, while services can pass through an RFI and an RFP first. Model the sequence your organization actually uses, and mark the points where the process waits for a supplier response.

You can also document the contract management process alongside purchasing, so teams can see how contract-related steps connect to requests, approvals, and orders.

What can procure to pay automation analysis tell you?

Process Mining can show where work follows a repeatable path, where manual handoffs occur, and where exceptions need attention. This evidence can help you assess potential automation opportunities, but ProcessMind does not execute or automate procurement work. Validate the process and controls before deciding whether automation is appropriate.

For a broader view of how teams use process evidence to identify improvement opportunities, read how to find automation opportunities with Process Mining.

How should you get started?

Choose one purchasing flow with a clear process owner and a specific question, such as whether purchase orders follow the expected approval path. Gather an available PO extract and the current process documentation, even if it is incomplete.

Agree on the model with the process owner and approvers, then compare it with the data. Review exceptions together and record approved changes in the model’s version history. Keep responsibilities clear: the process owner is accountable for the process, while approvers make the relevant control decisions. Align those roles with your organization’s RACI guidance.

How can this support audit reviews?

A maintained model and visible process deviations can help you prepare for a review by showing the expected flow and where actual cases differ. Your audit team can investigate the evidence and assess the controls. The analysis does not determine whether a purchase is compliant.

See the auditor use case

What should you do next?

Start with one PO extract and one agreed model. Compare purchasing data with the documented flow, then review exceptions with the people responsible for the process.

Model your purchasing flow and compare it to the data