Procure-to-Pay Pipeline
Procure-to-Pay Pipeline
The Procure-to-Pay (P2P) Pipeline provides a fully integrated, end-to-end procurement workflow — from the moment a purchase need is identified to the final payment to a supplier. Every stage is connected, auditable, and automated where possible.
Pipeline Overview
The pipeline follows a fixed sequence of six stages:
Purchase Requisition → Approval → Purchase Order → Receipt → Invoice Matching → Payment
Each stage must be completed before the transaction can advance, ensuring a clean audit trail and eliminating out-of-sequence processing.
Stages
1. Purchase Requisition
The pipeline begins when an employee submits a purchase requisition. A requisition captures:
- One or more line items (description, quantity, unit of measure, estimated unit price)
- Cost centre or project code
- Requested delivery date
- Supporting justification or attachments
Requisitions are saved in Draft status until submitted for approval.
2. Approval
Submitted requisitions enter the approval workflow. Approval routing is configurable and can be based on:
- Spend threshold — single-approver below a limit, multi-level above it
- Cost centre — routes to the relevant budget owner
- Category — routes to a category manager (e.g. IT, Facilities, Professional Services)
Approvers can approve, reject, or return a requisition for amendment. Rejected or returned requisitions notify the originator with comments.
3. Purchase Order Generation
Once a requisition is fully approved, the system automatically generates a Purchase Order (PO). The PO:
- Inherits all line items and metadata from the approved requisition
- Is assigned a unique PO number
- Is dispatched to the supplier (via email or integrated supplier portal)
- Remains open until goods/services are received
4. Goods / Services Receipt
When goods or services are delivered, a receiving team member records a receipt against the open PO. The receipt captures:
- Line items received (quantity and condition)
- Actual delivery date
- Partial delivery flag (if not all lines are fulfilled)
Partial receipts are supported; the PO remains open until all lines are fully received or the PO is manually closed.
5. Invoice Matching
When a supplier invoice arrives, the system attempts an automatic three-way match against:
| Source | What is checked |
|---|---|
| Purchase Order | Agreed quantities and unit prices |
| Goods/Services Receipt | Quantities actually delivered |
| Supplier Invoice | Quantities and prices billed |
Match outcomes
| Result | Description | Action |
|---|---|---|
| Clean match | All three sources agree within configured tolerances | Invoice automatically approved and queued for payment |
| Exception | One or more discrepancies detected | Invoice flagged and routed to a reviewer |
Common exception types
- Price variance — invoiced unit price differs from PO unit price
- Quantity variance — invoiced quantity exceeds quantity received
- Duplicate invoice — invoice number already processed against this PO
- PO not found — invoice references an unknown or closed PO
6. Payment
Invoices that pass (or have cleared) matching are released for payment. The payment stage integrates with the platform's spend management and payment workflows to execute the transfer and record the liability closure.
Three-Way Matching: Detail
Three-way matching is the control mechanism at the heart of the pipeline. It runs automatically when an invoice is submitted and compares values at the line-item level.
Tolerance configuration
Price and quantity tolerances can be configured per category or globally (e.g. allow up to ±2% price variance before flagging). Transactions within tolerance are treated as clean matches.
Exception resolution
Flagged exceptions appear in the Exceptions Queue for the assigned reviewer. Reviewers can:
- Approve with override — accept the variance and release the invoice for payment
- Raise a dispute — send a dispute notice to the supplier
- Request a credit note — request a corrected invoice from the supplier
- Reject the invoice — return the invoice without payment
All actions are logged against the transaction for audit purposes.
Audit Trail
Every state transition across all six stages is recorded with:
- Timestamp
- Acting user (or system, for automated steps)
- Before / after values for any changed fields
- Comments or attachments added at each step
The full audit trail is accessible from the transaction detail view and can be exported.
Related Features
- Spend Management — budget tracking and spend analytics
- Contract Lifecycle Management — link POs to master agreements
- Accounts Payable — supplier ledger and payment runs