Oracle Fusion procure-to-pay (P2P) process flow
Editable Oracle Fusion Cloud procure-to-pay process flow: Self Service Procurement requisition, approval, purchase order from an agreement, receiving, Payables invoice validation and holds, and the payment process request.
What the oracle fusion procure-to-pay (P2P) process flow process is
Oracle Fusion splits procure-to-pay across Self Service Procurement, Purchasing, Receiving and Payables, and each has its own work area and its own approval rules. Oracle's own documentation describes each one well; what implementation teams usually lack is one picture that joins them, so that a buyer, a receiver and an AP specialist can see how their step depends on the one before it.
The decisions that shape the process are the agreement check, which decides whether a buyer touches the requisition at all, the match level (two-, three- or four-way), and invoice holds. Holds are where cycle time goes: an invoice that fails validation sits on hold until someone resolves the price or quantity difference and validates it again.
Use the template for design workshops on a Fusion implementation, for a migration from E-Business Suite, or to train new users. Rename the lanes to your business units, set the match level you use, and add the approval levels your rules enforce.
What this flowchart covers
In this template
- Requisition creation in Self Service Procurement and the approval workflow configured in Manage Requisition Approvals
- Automatic PO creation from a blanket purchase agreement, or buyer processing in Process Requisitions
- Receiving against the PO, with an inspection step when four-way matching applies
- Payables invoice entry, validation against the PO and receipt, and resolving holds
- Invoice approval and the payment process request that produces the payment file
When to use this template
- You are designing future-state procurement processes for an Oracle Fusion Cloud ERP implementation
- You are moving from Oracle E-Business Suite R12 to Fusion and want to compare the two flows step by step
- Invoice holds are piling up and you need to show which upstream step causes them
- New buyers, receivers and AP staff need training material that shows the whole cycle
How it works
Map lanes to your business units
Rename the lanes to your requesters, approvers, buyers, receiving locations and Payables team; use one chart per procurement business unit if the flows differ.
Set the match level
Keep the inspection branch for four-way matching, or delete it and leave three-way (receipt) or two-way (PO only) matching.
Write your approval rules
Put the real approval conditions (amount thresholds, category, cost center hierarchy) on the approval steps or in their notes.
List the hold types you see most
Add notes to the hold step for your common holds, such as price, quantity received and quantity ordered, and who resolves each one.
Approve and publish
Send the flow to the procurement and AP process owners; the approved version and later changes are kept in the version history.
Frequently asked questions
What are the steps in the Oracle Fusion P2P cycle?
Create a requisition in Self Service Procurement, get it approved, turn it into a purchase order (automatically from an agreement, or by a buyer in Process Requisitions), receive the goods, create and validate the Payables invoice, resolve any holds, approve the invoice, and pay it through a payment process request.
What is the difference between two-, three- and four-way matching in Oracle?
Two-way matching compares the invoice with the purchase order. Three-way adds the receipt quantity. Four-way also requires the goods to be inspected and accepted. The match level is set on the purchase order schedule, and a mismatch outside tolerance places a hold on the invoice during validation.
Is the Oracle Fusion P2P flow the same as in E-Business Suite?
The business flow is similar, but the tools differ: Fusion uses Self Service Procurement instead of iProcurement, BPM-based approval rules instead of AME, and payment process requests in a redesigned Payments module. Mapping both flows side by side is a useful step in an EBS to Fusion migration.