P2P vs S2P vs source-to-settle: the scopes agents work across

P2P vs S2P comes down to where each scope starts and ends. Procure-to-pay (P2P) covers the transactional cycle from purchase requisition through invoice payment. Source-to-pay (S2P) contains all of P2P and adds the upstream decisions: sourcing events, supplier negotiation, and contracting. Source-to-settle extends S2P past the payment run into settlement, dispute resolution, and spend analytics. Every company performs all of these activities regardless of which label it uses; the labels mark where a particular team's, platform's, or project's responsibility begins and stops.

This wiki defines source-to-pay vocabulary for companies where AI agents carry the operational load – matching documents, reading contracts, clearing invoice holds – and people keep the decisions that require judgment. Most comparison pages treat these three labels as vendor packaging. This one treats the boundary you pick as the decision that determines which problems you are permitted to solve.

Each wider scope adds a class of records

Procure-to-pay is the inner scope and the one that moves volume. Its records are transactional: requisitions, purchase orders, goods receipts (the warehouse's confirmation that goods physically arrived), supplier invoices, and payment runs. A mid-sized manufacturer pushes thousands of these documents through SAP or Coupa every month, and the whole point of the design is that they flow without anyone touching them.

Source-to-pay wraps the decision layer around the front of that cycle. The records it adds are commitments rather than transactions: RFx documents (the requests for quote or proposal that open a sourcing event), bid comparisons, negotiation history, and executed contracts with their pricing schedules, index clauses, rebate terms, and renewal dates. Nothing in this layer pays anyone. Everything in this layer determines what the transactional layer will consider correct.

Source-to-settle extends the back end past the moment money leaves. It adds settlement confirmations, credit and debit memos, dispute correspondence, and the spend analytics that turn a year of transactions into category intelligence. The extension exists because payment settles the invoice without settling the relationship: short payments get disputed, rebates get reconciled, and the close needs numbers it can defend.

Read the three scopes as record sets rather than software modules and the comparison gets practical, because the record set you can reach determines what you can do about a problem.

The real stake in P2P vs S2P is fix versus observe

The practical stake in P2P vs S2P is which problems a team can fix and which it can only watch recur. Most invoice exceptions surface in P2P and are caused in S2P. A price variance is usually a contract term that never reached the ERP's price master. A missing-PO invoice is usually a purchasing channel nobody built for that category. The catalogue in where three-way matching breaks reads at first pass as a list of P2P failures; trace each entry backward and most of them have an upstream address.

A team scoped to P2P owns the symptoms and none of the causes. It can clear every hold, work every queue, and hit its cycle-time targets, and the same exceptions will arrive again next month at the same rate, because the records that would end them sit on the far side of a boundary the team is not chartered to cross.

Two worked examples show how the boundary gets expensive

Take a resin buy. A category manager signs a contract amendment in January moving polypropylene from $1.84 to $1.98 per kilogram under an index-adjustment clause. The amendment is filed in the contract repository; the SAP purchasing info record that feeds new purchase orders still says $1.84. The plant buys 40,000 kg a month, so every monthly invoice arrives at $79,200 against a PO expectation of $73,600 – a 7.6% price variance against a 2% tolerance, the allowed band before an invoice requires review. AP investigates, emails the buyer, confirms the amendment, and clears the hold. Then it happens again in February. By September the team has cleared $50,400 of variance across nine identical cases, and the actual defect – one stale price master field – remains untouched, because master-data maintenance against contracts belongs to the sourcing side of the house.

Or take facilities maintenance. A company spends $60,000 a month on repairs across 14 regional service providers, with no contracts, no rate cards, and no catalog. Every one of those invoices arrives as a non-PO invoice, meaning there is no purchase order to match it against, so each one needs manual coding and an approval chase. A P2P-scoped team will route and code $720,000 a year of this spend one invoice at a time, indefinitely. The fix is a sourcing event: consolidate the category to three providers, negotiate rate cards, and stand up blanket POs (standing purchase orders that cover repeat work) so the invoices match automatically. That fix is unambiguous and permanent, and it is S2P work from the first step.

In both cases the P2P view shows a queue behaving badly, and the S2P view shows exactly why. The dollar figures accumulate on one side of the boundary while the cause sits on the other.

An agent investigating a P2P exception reads S2P records anyway

Watch an AI agent work the resin case and the P2P vs S2P boundary starts to look like a filing convention. To establish whether $1.98 is the correct price, the agent needs the PO history from the ERP, then the contract and its January amendment from the repository, then the index clause and the quarter's index value to verify the arithmetic. Two of those three stops are S2P records. The same pattern holds across exception types: sourcing events explain odd supplier choices, negotiation history explains nonstandard payment terms, contract schedules explain rebates that finance cannot reconcile. The investigation goes where the evidence is, and the evidence does not respect the org chart.

Agents change the boundary economics in a second way. Having read the amendment to clear the hold, an agent can also flag the stale info record and route a correction to the master-data owner with the contract reference attached, so the January defect stops manufacturing February's exception. The clerk who only saw the invoice could never make that connection; the agent that read both sides cannot avoid making it. Once the resolution layer reads S2P and P2P records together, the debate about which label a company runs matters mostly to its software procurement, since the work itself has already crossed the line.

Choose the scope by the records you need to read

Scoping a team, a transformation project, or an automation deployment by module name imports a vendor's packaging decisions into your operating model. The sturdier method is to list the problems you want gone and ask which records their resolution requires. Recurring price variances resolve against contracts and index data, so that scope is S2P whatever the team is called. Unreconciled rebates and disputed short payments resolve against settlement records, which puts you in source-to-settle territory. A backlog of coding errors on clean invoices is one of the few genuinely P2P-contained problems. Module names describe what a vendor sells; record access describes what your team can actually change.

Fragment's agents are built for the boundary this page describes: they resolve the exceptions that surface in P2P by reading the S2P records that explain them – contracts, amendments, sourcing history – inside a company's existing SAP or Ariba environment, with no rip and replace. See how the workflows run or request a demo.