RPA vs agentic AI in procurement: what each can carry
RPA vs agentic AI is a choice between two kinds of automation. Robotic process automation (RPA) uses deterministic software robots that replay a scripted sequence of interface actions – log in, download the report, copy a field, paste it, click submit – identically on every run. Agentic AI uses goal-directed systems that read the documents in a case, retrieve the context around them, and decide a path for that specific case. The first automates procedures. The second automates investigations, and procurement generates a large supply of both.
This wiki covers source-to-pay terms for a world where AI agents carry the operational load – matching invoices, reading contracts, working exception queues – while people keep the calls that need judgment. Vendor comparisons of the two tend to stay abstract; this page frames the choice the way a procurement operator meets it: a pile of real tasks, and which machine can carry each one.
Does the task require reading something new each time?
Every RPA vs agentic AI decision reduces to that question. If every instance of a task is identical in structure – download the same settlement report every Monday, key the same twelve fields from the same form, bridge two systems that lack an API – the procedure can be recorded once and replayed indefinitely. RPA carries that work cheaply and predictably, and nothing heavier is justified: a bot keying vendor bank details from a standardized onboarding form into SAP is faster than a person and identical on every run.
If each instance turns on content – why does this invoice disagree with this purchase order, what does this contract clause permit, is the supplier's explanation consistent with the receiving records – then no two runs follow the same path, and a script has nothing to replay. The task begins with reading, and a script only matches surfaces – pixels, field positions, column letters – while the meaning of what sits in the field never enters the process.
The exception queue survived the RPA wave because it fails the test
Procurement was an early and enthusiastic RPA adopter, and the deployments that stalled generally stalled in the same place. Bots took over report pulls, vendor master updates, and invoice ingestion, then hit the queue of invoice exceptions – invoices that failed a validation check such as the three-way match, the line-by-line comparison of invoice, purchase order, and goods receipt (the record confirming what actually arrived). Every exception is a new question. This one exists because the supplier billed a price renegotiated in March; that one because the plant received 96 units against an order for 100. A script cannot work a queue where each case demands different evidence, so the queue stayed manual while the automation program declared victory around it. The queue also keeps refilling from upstream causes, which why exceptions never go to zero works through.
One price-list update shows the two failure modes
The split is easiest to see in practice, on one task walked both ways. Take a quarterly price-list update from a fastener supplier covering 340 stocked items. The RPA version: the supplier agrees to send a fixed Excel template, and the bot opens the file, reads the new price from column D row by row, and keys each one into the SAP material master, the record that holds every item's standard price. Twenty minutes, 340 updates, zero errors – until the quarter the supplier migrates its own ERP and the export arrives with merged header cells and prices shifted to column E. The bot halts or, worse, keys the wrong column, and a developer spends two days rebuilding the script against the new layout.
The agent version starts by reading whatever arrives: the old template, the new export, a PDF, a table pasted into an email. It extracts the 340 new prices, pulls the supplier's contract from the repository, and finds the escalation clause capping annual increases at 3%. It checks every line against the cap, updates the 338 prices that comply, and flags the two items that rose 9% and 12% to the category manager with the clause quoted and the arithmetic shown. The technologies fail in different directions: the bot breaks on format, the agent escalates on substance.
Brittleness is a maintenance bill, and it compounds
RPA's weakness usually gets described as fragility, which understates the economics. A script binds to surfaces – screen layouts, file formats, portal designs, field positions – and every one of those surfaces changes on someone else's schedule. An ERP patch moves a button, a supplier portal gets redesigned, a bank reformats its statement export. Each change breaks a bot, and broken bots rarely announce themselves; the queue they served simply starts growing again until a person notices.
Run the arithmetic on a mature program. A portfolio of 60 bots in which each breaks once or twice a year, at one to two developer days per repair, consumes somewhere between 60 and 240 developer days annually – a meaningful share of an engineering team spent restoring last year's automation to last year's behavior. That standing bill is why many RPA programs plateau: every new bot competes for the same developers who maintain the old ones.
Agentic AI arrives with its own bill of requirements
An honest comparison prices the agent side too. For an agent to decide a path per case it needs, first, access to the records the case turns on: the ERP, the contract repository, receiving data, the AP mailbox, supplier portals. Second, guardrails – explicit limits on what it may do without sign-off, expressed as tolerances (the variance band a company accepts before requiring review), spend thresholds, and allowed actions. Third, an escalation path, so judgment calls reach a person with the evidence attached. Fourth, an audit trail per case recording what the agent read, what it concluded, and why, reviewable months later. The harder requirement is context, including the tribal knowledge experienced analysts carry; the context problem in exception resolution treats that in depth. An agent with access and no guardrails is a liability; the reverse is an expensive chatbot.
The strongest stacks run RPA as hands and agents as the reader
In most real architectures the two divide the labor: the agent reads the case, gathers evidence, and decides what should happen, and where a legacy system exposes no API, an RPA bot executes the resulting keystrokes. Script as hands, agent as reader and decider. The pattern keeps the deterministic layer thin and boring – posting a resolved transaction, entering approved prices – while the layer that handles variation reasons its way through each case. Manual vs automated exception resolution lays out the full spectrum from human-only work through rules to autonomy; most companies will operate at several points on it at once.
The last question is where each sits across procure-to-pay
Across the P2P chain – requisition, purchase order, goods receipt, invoice, payment – the RPA vs agentic AI choice repeats at every step, and the reading test answers it each time. Stable transaction entry belongs to RPA: vendor master changes from standardized forms, scheduled report distribution, posting cleared cases into the ERP. Content-dependent work belongs to agents: exception resolution, contract compliance checks, supplier correspondence, change-order review. The broader placement of agents is mapped in AI in procurement. A team that assigns by task instead of by ideology ends up with fewer bots, better-placed agents, and a maintenance bill it can actually forecast.
Fragment builds the reading-and-deciding side of that architecture: AI agents that resolve procurement exceptions autonomously inside a company's existing SAP or Ariba environment, gathering the evidence each case requires, acting within guardrails, and escalating judgment calls with the workup attached. See the workflows the agents run or request a demo.