The procure-to-pay (P2P) cycle in Oracle Apps is the end-to-end flow that runs from raising a request for goods or services through to paying the supplier, all inside the Oracle Purchasing and Payables modules. It ties together requisitions, purchase orders, receipts, invoices, and payments on one set of tables, so every document links back to the one before it.
This guide walks through each step of the P2P cycle in Oracle E-Business Suite (R12), the base tables behind every step, the accounting entries Oracle posts along the way, how invoice matching and common holds work, and how the flow differs in Oracle Fusion Cloud.
Our other articles on the P2P Cycle are
What is the P2P cycle in Oracle Apps?
The P2P cycle in Oracle Apps is the procurement-to-payment process managed across the Oracle Purchasing and Payables modules. It begins when a user raises a requisition for something the business needs and ends when Payables issues payment to the supplier, with every document in between linked by shared keys so the audit trail stays intact from request to cash.
In Oracle E-Business Suite the buying steps are done from a Purchasing responsibility and the invoicing and payment steps from a Payables responsibility. The sourcing steps (RFQ, quotation, and quote analysis) are optional: a simple flow goes straight from an approved requisition to a purchase order.
Steps in the P2P cycle in Oracle Apps
The full cycle has nine steps. Steps 2 to 4 belong to Oracle Sourcing and are optional, so many organizations run the shorter path of requisition, purchase order, receipt, invoice, and payment.
| # | Step | Oracle module |
|---|---|---|
| 1 | Create a requisition | Purchasing / iProcurement |
| 2 | Request for quotation (RFQ) | Purchasing / Sourcing (optional) |
| 3 | Receive quotations | Purchasing / Sourcing (optional) |
| 4 | Quote analysis | Purchasing / Sourcing (optional) |
| 5 | Create a purchase order | Purchasing |
| 6 | Receive the goods or services | Purchasing (Receiving) |
| 7 | Enter the supplier invoice | Payables |
| 8 | Validate and create accounting | Payables / Subledger Accounting |
| 9 | Pay the supplier | Payables / Payments |
1. Create a requisition
The cycle starts with a requisition, an internal request for goods or services raised in Purchasing or in iProcurement. The requester enters the item, quantity, need-by date, and the charge account, and the requisition routes through approval before it can become a purchase order. Internal requisitions move stock between inventory organizations, while purchase requisitions become orders to outside suppliers.
2. Request for quotation (RFQ)
When buyers want competitive pricing, they turn the requisition into a request for quotation and send it to one or more suppliers. The RFQ lists the items, quantities, and terms the buyer needs a price on. This step is optional and is part of Oracle Sourcing.
3. Receive quotations
Suppliers respond with quotations against the RFQ. Each quotation records the supplier’s price and terms and is stored so the buyer can compare like for like. In Oracle, RFQs and quotations live in the same purchasing tables as orders, distinguished only by their document type.
4. Quote analysis
The buyer compares the returned quotations on price, lead time, and terms and picks a supplier. This quote analysis is the decision point that feeds the purchase order. In a straight-through flow without sourcing, steps 2 to 4 are skipped and the approved requisition goes directly to a purchase order.
5. Create a purchase order
The buyer converts the requisition (or the winning quotation) into a purchase order, the binding commitment to the supplier. The PO carries the supplier, items, prices, ship-to and bill-to details, and delivery schedule. Oracle supports several PO types, including standard, blanket, planned, and contract purchase agreements, and the order goes through its own approval hierarchy before it is issued.
6. Receive the goods or services
When the supplier delivers, the receiving team records a receipt against the purchase order, entering the quantity accepted. Oracle supports different receipt routings, including direct delivery, standard receipt, and inspection required, and it is at this point that inventory items post their first accounting entry. Accurate receiving is what makes three-way matching possible later.
7. Enter the supplier invoice
The supplier’s invoice is entered in Payables, usually matched to the purchase order so the amounts flow through automatically. Matching is where Oracle enforces control:
- Two-way match: invoice against purchase order (quantity and price).
- Three-way match: invoice against purchase order and receipt.
- Four-way match: invoice against purchase order, receipt, and inspection.
If a quantity or price is outside tolerance, Oracle places the invoice on hold and blocks payment until the hold is reviewed and released.
8. Validate and create accounting
Validation runs the matching and tolerance checks and, if the invoice is clean, makes it available to account and pay. Creating accounting then generates the subledger journal entry through R12 Subledger Accounting (SLA): for a matched invoice, Oracle debits the AP accrual or charge account and credits the accounts payable liability, posting any invoice price variance separately. The exact accounts depend on whether the item is an inventory or expense item, covered in the accounting-entries section below.
9. Pay the supplier
Finally, Payables pays the validated invoice, either as a single payment or through a Payment Process Request that selects all invoices due. Oracle builds the payment, records it in the payments tables, and posts the settlement accounting: it debits the accounts payable liability and credits cash clearing (and then cash when the payment clears the bank). At this point the invoice is closed and the full requisition-to-payment trail is complete.
P2P cycle base tables in Oracle Apps (R12)
Each step writes to a specific set of Oracle E-Business Suite base tables. These are the tables developers query to trace a document from requisition to payment (the _ALL suffix means the table is partitioned by operating unit).
| Step | Oracle EBS base tables | What they store |
|---|---|---|
| Requisition | PO_REQUISITION_HEADERS_ALL, PO_REQUISITION_LINES_ALL, PO_REQ_DISTRIBUTIONS_ALL | Requisition header and status, the requested lines, and the accounting distributions |
| RFQ and quotation | PO_HEADERS_ALL, PO_LINES_ALL (TYPE_LOOKUP_CODE = RFQ or QUOTATION) | RFQs sent out and quotations received, held in the PO tables with a different document type |
| Purchase order | PO_HEADERS_ALL, PO_LINES_ALL, PO_LINE_LOCATIONS_ALL, PO_DISTRIBUTIONS_ALL | PO header, lines, shipment schedules, and charge-account distributions |
| Receipt | RCV_SHIPMENT_HEADERS, RCV_SHIPMENT_LINES, RCV_TRANSACTIONS | The receipt, its received lines, and every receiving transaction (receive, deliver, return) |
| Invoice | AP_INVOICES_ALL, AP_INVOICE_LINES_ALL, AP_INVOICE_DISTRIBUTIONS_ALL | Supplier invoice header, lines, and the distributions created at validation |
| Payment | AP_CHECKS_ALL, AP_INVOICE_PAYMENTS_ALL, AP_PAYMENT_SCHEDULES_ALL | The payment document, the payment-to-invoice link, and each invoice’s due schedule |
| Accounting (SLA) | XLA_AE_HEADERS, XLA_AE_LINES | The subledger journal entries R12 posts to General Ledger for receipts, invoices, and payments |
Accounting entries in the P2P cycle
The journal entries depend on whether the item is an inventory item (perpetual accrual, posted at receipt) or an expense item (usually period-end accrual). The common inventory-item flow looks like this:
| Stage | Debit | Credit |
|---|---|---|
| Receive into receiving | Receiving Inspection | Inventory AP Accrual |
| Deliver to inventory | Inventory Valuation | Receiving Inspection |
| Invoice validated (matched) | Inventory AP Accrual (or charge account) | Accounts Payable Liability |
| Invoice price variance, if any | Invoice Price Variance | Accounts Payable Liability |
| Payment | Accounts Payable Liability | Cash Clearing |
For an expense item there is no inventory valuation entry: the invoice debits the expense (charge) account and credits the accounts payable liability, and the payment debits the liability and credits cash clearing. The key correction worth remembering is that the accounts-payable liability is credited when the invoice is accounted and debited when the payment is made, so the debit-liability, credit-cash entry belongs to the payment step, not the invoice step.
P2P cycle in Oracle EBS vs Oracle Fusion Cloud
The business flow is the same in Oracle Fusion Cloud, but the environment differs. Fusion replaces EBS responsibilities and forms with role-based work areas such as Purchase Requisitions, Purchase Orders, and Manage Invoices, and it uses the Supplier Portal for supplier collaboration instead of iSupplier. The underlying data model is also different, so the EBS base table names above do not carry over directly to Fusion, where reporting is done through Oracle Transactional Business Intelligence (OTBI) and BI Publisher rather than direct table queries. If you are on Fusion, treat the steps and accounting logic here as accurate and the specific table names as EBS-only.
Common errors and holds in the Oracle P2P cycle
Most P2P problems in Oracle show up as invoice holds or accounting failures. The frequent ones are:
- Matching holds: the invoice quantity or price is outside tolerance against the PO or receipt, so Oracle blocks payment until the hold is released.
- Quantity received is short: a three-way match invoice cannot be paid in full because the receipt has not been entered.
- GL date in a closed period: validation or create-accounting fails because the accounting date falls in a Payables or General Ledger period that is already closed.
- Missing or wrong distribution account: an invalid or inactive code combination stops the invoice from accounting.
- Supplier or supplier-site setup gaps: a missing pay site, bank account, or payment method holds up payment even after the invoice is validated.
Best practices for the Oracle P2P cycle
- Match invoices to POs and receipts rather than entering them unmatched, so tolerances and holds do the checking automatically.
- Set sensible matching tolerances for quantity and price so genuine exceptions get held without flooding the team with false holds.
- Keep supplier and site data clean (pay sites, bank accounts, payment terms), since most stuck payments trace back to supplier setup, not the invoice.
- Run validation and create-accounting on a schedule and reconcile the AP accrual account regularly so received-not-invoiced balances do not drift.
- Watch open periods: close Payables before General Ledger and confirm accounting is transferred, so nothing is stranded in the subledger.
Frequently asked questions
What are the steps in the P2P cycle in Oracle Apps?
The full cycle is: create a requisition, raise an RFQ, receive quotations, analyze quotes, create a purchase order, receive the goods, enter the supplier invoice, validate and create accounting, and pay the supplier. The RFQ, quotation, and quote-analysis steps are optional, so a common shorter flow is requisition, purchase order, receipt, invoice, and payment.
What are the base tables in the Oracle P2P cycle?
The main EBS R12 tables are PO_REQUISITION_HEADERS_ALL and PO_REQUISITION_LINES_ALL for requisitions; PO_HEADERS_ALL, PO_LINES_ALL, PO_LINE_LOCATIONS_ALL, and PO_DISTRIBUTIONS_ALL for purchase orders; RCV_SHIPMENT_HEADERS, RCV_SHIPMENT_LINES, and RCV_TRANSACTIONS for receipts; AP_INVOICES_ALL and AP_INVOICE_DISTRIBUTIONS_ALL for invoices; and AP_CHECKS_ALL and AP_INVOICE_PAYMENTS_ALL for payments.
What are the accounting entries in the Oracle P2P cycle?
For an inventory item, the receipt debits Receiving Inspection and credits Inventory AP Accrual; the validated invoice debits the AP accrual and credits the accounts payable liability; and the payment debits the liability and credits cash clearing. For an expense item, the invoice debits the expense account and credits the liability, and the payment debits the liability and credits cash clearing.
What is the difference between two-way, three-way, and four-way matching?
Two-way match compares the invoice to the purchase order (quantity and price). Three-way match adds the receipt, so you only pay for what was actually received. Four-way match adds inspection, paying only for received quantities that also passed inspection.
Is the P2P cycle the same in Oracle Fusion?
The steps and accounting logic are the same, but Oracle Fusion Cloud uses role-based work areas and the Supplier Portal instead of EBS responsibilities and forms, and its data model differs, so the EBS base table names do not apply directly in Fusion.
Conclusion
The P2P cycle in Oracle Apps connects purchasing and payables into one controlled flow, from requisition to payment, with every step writing to its own base tables and posting its own accounting through Subledger Accounting. Get the matching, tolerances, and accounts right and the cycle largely runs itself; most problems come down to invoice holds, closed periods, or supplier setup rather than the process itself.