IntermediateFinancials · Procurement + Payables

Procure-to-Pay in Oracle Fusion

The end-to-end flow from requisition to reconciled payment, across Procurement and Payables.

End-to-End Process Flow

Click a stage for detail

Requisition

A requester creates a requisition — either from a catalog or as a non-catalog request — specifying item or service, quantity, and need-by date. This is the entry point into Procurement and can be raised by an employee via Self Service Procurement or created on behalf of someone via Purchasing.

Tables Involved

PO_REQUISITION_HEADERS_ALL

Requisition header — preparer, requisitioning BU, status.

PO_REQUISITION_LINES_ALL

Requisition line — item, quantity, need-by date, destination.

Overview

Procure-to-Pay (P2P) covers everything from a business need being raised as a requisition through to the supplier being paid and that payment being reconciled against the bank statement. In Oracle Fusion it spans two pillars — Procurement (requisitions, approvals, purchase orders, receiving) and Financials (AP invoicing, validation, accounting, payment) — connected by matching.

A PO-matched invoice inherits price and quantity controls from the purchase order and receipt, which is what makes P2P a control framework as much as a transaction flow: every dollar paid to a supplier can be traced back to an approved requisition and a confirmed receipt.

Modules Involved

Self Service Procurement

Requester-facing catalog and non-catalog requisitioning.

Purchasing

Requisitions, purchase orders, suppliers, buyer workbench.

Receiving

Receipt confirmation against POs, inspection where required.

Payables

Invoicing, matching, validation, holds, payment.

Cash Management

Bank statement reconciliation for issued payments.

Subledger Accounting

Turns AP invoice and payment events into GL journal entries.

Accounting Impact

Receiving an inventory-destination PO line can generate a receiving accrual — debiting inventory or expense and crediting a receiving inspection account. Invoice validation and Create Accounting then debit that accrual (or expense directly, for non-inventory lines) and credit the AP trade liability.

Payment debits the liability and credits cash. The exact account derivation is driven by Subledger Accounting (SLA) rules, which can be customized per ledger — so two Oracle instances can post P2P transactions to different accounts even with identical business processes.

Common Statuses

Requisition: Incomplete → In Process → Approved / Rejected / Withdrawn

Tracked on PO_REQUISITION_HEADERS_ALL.AUTHORIZATION_STATUS.

PO: Incomplete → Pending Approval → Approved → Closed / Cancelled

Tracked on PO_HEADERS_ALL.AUTHORIZATION_STATUS.

Invoice: Incomplete → Validated → Needs Revalidation → Cancelled

Validated is the prerequisite for accounting and payment.

Payment: Issued → Negotiable → Cleared → Void

Cleared reflects bank reconciliation in Cash Management.

Common Issues

Invoices stuck on matching holds when PO price or quantity doesn't align with the invoice within tolerance — check AP_HOLDS_ALL for the HOLD_LOOKUP_CODE.
Tax calculation holds when tax setup is incomplete for a supplier, item, or ship-to location combination.
Accounting failures when a code combination is invalid, disabled, or a GL period is closed for the invoice's accounting date.
Duplicate invoice holds when the same supplier invoice number is entered twice for the same supplier.
Requisitions stuck in approval when an approver is inactive or an approval rule references a role nobody currently holds.
PO not auto-created from an approved requisition when requisition-to-PO automation setup doesn't match the line's category/supplier.

EBS vs Fusion

The functional flow is the same in EBS and Fusion, but the underlying schema overlaps more than people expect: EBS Purchasing's PO_HEADERS_ALL/PO_LINES_ALL and Payables' AP_INVOICES_ALL carried over into Fusion largely intact, so SQL written against EBS Purchasing/Payables often needs only minor changes.

Requisitioning changed more visibly: EBS iProcurement maps to Self Service Procurement in Fusion, with a modernized UI and catalog experience.

Approval routing changed under the hood: Fusion uses BPM-based approval rules configured in Functional Setup Manager, replacing EBS's AME (Approvals Management Engine) — the concepts are similar, but the setup UI and rule engine are different.

Useful SQL

Open (unpaid) AP invoices for a business unit

SELECT
  invoice_id,
  invoice_num,
  invoice_amount,
  invoice_currency_code,
  invoice_date
FROM ap_invoices_all
WHERE org_id = :business_unit_id
  AND payment_status_flag != 'Y'
ORDER BY invoice_date;

Purchase order lines for a requisition

SELECT
  pol.po_header_id,
  pol.line_num,
  pol.item_description,
  pol.quantity
FROM po_lines_all pol
JOIN po_distributions_all pd
  ON pd.po_line_id = pol.po_line_id
WHERE pd.req_line_id = :requisition_line_id;

Active holds on an invoice

SELECT
  hold_lookup_code,
  hold_date,
  release_lookup_code,
  release_date
FROM ap_holds_all
WHERE invoice_id = :invoice_id
ORDER BY hold_date DESC;

Interview Questions

Walk through the P2P cycle end to end — what happens at each stage?
What causes an AP invoice to go on a matching hold, and how do you resolve it?
Where does the accounting for a receipt accrual get generated, and what's the journal entry?
What's the difference between a 2-way, 3-way and 4-way match?
How would you trace a payment back to the originating requisition?
What Oracle module handles approval routing, and how does it differ from EBS's AME?
Why might a requisition fail to auto-create a purchase order even after full approval?

Next Steps

After Reconciliation: Period Close

How the reconciled cash and posted accounting flow into closing the GL period.

Compare with Order-to-Cash

The mirror-image cycle on the sell side — sales order through cash application.