What is source-to-pay (S2P), when AI agents work the process?
Source-to-pay (S2P) is the complete cycle a company runs to buy goods and services: identifying a sourcing need, selecting and qualifying suppliers, negotiating contracts, requisitioning, creating purchase orders, receiving, matching and approving invoices, and paying. It spans procurement, accounts payable, and finance, from the first request for quotation to the cleared payment. Procure-to-pay (P2P) is the back half of the same cycle, requisition through payment; S2P adds everything that happens before a requisition exists, and the P2P vs S2P vs source-to-settle comparison draws those boundaries precisely.
The definitions across this wiki assume a specific division of labor: AI agents carry the operational load of S2P – converting requisitions, matching invoices, clearing exception queues – while people keep the decisions that need judgment. A software vendor's glossary presents source-to-pay as a numbered sequence of stages; this page presents it as territory, split between the work agents can own and the calls that should stay with people.
Source-to-pay is two layers moving at different speeds
Strip away the stage diagrams and S2P separates into two layers. The decision layer holds the sourcing events, negotiations, contract awards, and supplier approvals: low volume, high stakes, human-led. A category manager might run fifteen sourcing events in a year, and each one fixes prices, payment terms, rebate clauses, and service levels for thousands of transactions to come. Its records live in sourcing suites like Ariba, in contract repositories, and in the email threads where the actual negotiating happened.
The transaction layer executes those decisions at volume: requisitions, purchase orders, goods receipts (the warehouse's record that goods physically arrived), invoices, payments. A mid-sized manufacturer pushes tens of thousands of these documents through SAP every month, each one individually small and together the entire spend of the company. This is the layer where automation investment already concentrates, and it maps roughly to P2P.
The two layers connect through a seam. Every decision has to be translated into the transaction layer's master data before it changes anything: a negotiated price becomes real when someone updates the purchasing info record in SAP, a rebate clause becomes real when finance builds the accrual, an approved supplier becomes real when the catalog lists them. Until that translation happens, the decision exists only as a document.
Most of what goes wrong in source-to-pay is the seam failing
Procurement leaders tend to hunt for losses inside one layer or the other – a badly negotiated contract, a mis-keyed invoice. The larger and quieter losses sit between the layers, where a decision was made correctly and then never executed.
Take a machined bracket a sourcing team renegotiates from $412 to $388 a unit, on annual volume of 1,400 units. The award is recorded in Ariba, the amended contract is filed in the repository, and the SAP info record keeps its old price because updating it belongs to nobody's job description. Buyers keep cutting POs at $412. The supplier, invoicing against the PO, bills $412. Every three-way match – the line-by-line comparison of invoice, purchase order, and goods receipt – passes cleanly, because both documents carry the same stale number. Twelve months later the company has paid $33,600 above its own contract, and the $33,600 of savings the sourcing team reported to the CFO never reached the P&L. When the supplier bills the contract price instead, the miss at least becomes visible: invoices fail matching and pile up as price variance exceptions, the loud version of the same seam failure.
Rebates fail the same way with fewer witnesses. Suppose a distributor contract carries a 2% rebate on annual spend above $3 million. Legal files the signed contract; nobody in finance builds the accrual or diaries the claim deadline. Spend lands at $4.6 million, the rebate is worth $92,000, and the claim window closes at year-end with no claim filed. No exception fires anywhere, because every individual transaction was correct; the loss lives entirely in the gap between a clause and a process.
Seam failures also seed the exception queues downstream. A stale price master generates match failures for months. An approved supplier missing from the catalog pushes requesters into off-PO purchases, the compliance pattern the PO-first culture problem page examines. The map of exceptions across source-to-pay traces how much queue volume starts life as one of these translation misses.
The seam persists because no system owns it
Each layer's software considers its own job finished at the boundary. The sourcing suite closes the event at contract signature and reports the savings as achieved. The ERP executes whatever master data it holds, with no way of knowing that a repository two systems away contradicts it. Between them sits a handoff that is manual, checklist-driven, and staffed by people who also have a month-end to close – and a single category renegotiation can touch hundreds of info records, so the checklist loses to the calendar more often than anyone audits.
Procurement automation has historically attacked the layers themselves – e-sourcing tools for the decisions, invoice automation for the transactions – and left the translation between them untouched. Where source-to-pay automation breaks down catalogs the resulting gaps stage by stage; nearly all of them cluster at the seam.
Agents work the seam, people keep the decision layer
Reading the decision layer's records and keeping the transaction layer consistent with them is exactly the shape of work AI agents handle well. An agent can read a contract amendment the day it posts, compute the new unit price, and update or flag the SAP info record before the next PO cuts. It can extract a rebate clause at signature, build the accrual schedule, and track spend against the $3 million threshold each quarter so the claim gets filed. It can reconcile the approved supplier list against the live catalog and surface every gap. And when a mismatch still reaches the queue, it can resolve the exception with the contract evidence attached instead of routing a bare hold code to an analyst. What is autonomous procurement covers this category of system in full.
The context this work needs is split the same way the process is. Half of it is structured: info records, PO history, receipt postings. The other half lives in documents and heads – amendment PDFs with handwritten effective dates, the knowledge that one supplier's "unit" means a box of twelve, the plant that books freight differently from every other plant. An agent working the seam has to read both, the way a strong analyst does, which is why simple integrations and RPA scripts have never closed it.
What stays human is the decision layer itself. Choosing to consolidate two suppliers, deciding how hard to push on payment terms, judging whether a strategic supplier's price increase is worth a fight – these calls depend on relationships and risk appetite, and no company should want them delegated. The division of labor worth building toward: agents make sure every decision people make actually lands in the systems that spend the money.
Fragment builds AI agents that work this seam inside a company's existing SAP and Ariba environment – keeping price masters true to signed contracts, operationalizing rebate clauses, resolving the match failures stale data creates – with no rip and replace, and with people approving the calls that matter. See the S2P workflows Fragment covers or book a demo walked through on your own systems.