Wiki/Procure-to-pay/
P2P vs S2P vs source-to-settle

P2P vs S2P vs source-to-settle

Procure-to-pay
·
2 min read
·
Updated July 2026
Joshua Kurian
Joshua Kurian
On this page

The three labels nest. Procure-to-pay runs from requisition to payment. Source-to-pay wraps sourcing, supplier selection, and contracting around the front of it. Source-to-settle stretches past payment into settlement, analysis, and the close. Vendors use the labels to size their footprint; buyers should use them to find the seams.

The seams are where documents change hands between processes, and they are where exceptions are born.

The labels nest, and the boundaries are seams

Every boundary between the processes is a handoff: a contract becomes a purchase order, an order becomes a receipt, an invoice becomes a ledger entry. Each handoff copies data from one record into another, and every copy is a chance for the two to drift apart. Naming the process is easy. Owning the seams is the work.

P2P is the operational core

P2P is where volume lives: thousands of orders, receipts, and invoices a month, each one expected to flow without help. It is also where the failure shows up, as invoice exceptions and stalled payments. Whatever happens upstream, P2P is where the business feels it.

S2P adds the decisions upstream of the order

Source-to-pay pulls sourcing events, negotiations, and contracts into scope. That matters operationally because the contract is where prices are agreed, and a contract that never syncs to the purchase order manufactures price variances downstream. Companies that treat sourcing and P2P as separate worlds pay for the gap one exception at a time.

Source-to-settle is S2P with the books closed

Source-to-settle extends through settlement, reconciliation, and spend analysis. The extension is honest about something the shorter labels hide: the process has to produce trustworthy numbers at the end, and untrustworthy coding or unresolved exceptions surface at the close, when they are most expensive to fix.

Pick by the seams you need to own

The label a company adopts matters less than which seams it decides to own. Contract-to-order staleness, receiving-to-invoice timing, and invoice-to-ledger coding each generate their own exception family, catalogued in where three-way matching breaks. Own the seams that leak, and expect what still slips through to resolve autonomously rather than by queue.

Fragment works across those seams, reading the contract, order, receipt, and ledger context in place. See how it works or request a demo.

From Fragment
See exception resolution on your own data
Fragment resolves invoice exceptions autonomously across your existing ERP and documents.
Request demo