Which procurement processes to automate first, now that agents exist

Which procurement processes to automate first comes down to three factors: volume, meaning how many instances a month the process generates; cost per touch, meaning what one instance costs in loaded labor; and context availability, meaning whether the records needed to complete the work sit in systems software can reach. Now that AI agents can carry work that requires reading and reasoning, scoring the candidates on those three factors produces a ranking close to the reverse of the classic playbook: invoice exception resolution first, GL coding second, approval assembly and change-order reconciliation third, document-heavy supplier onboarding fourth.

This wiki treats source-to-pay as a world where AI agents do the operational work – investigating holds, coding invoice lines, chasing documents – while people keep the judgment calls. Most prioritization guides still assume the automation is a script, and their advice follows from that assumption. This page rebuilds the ranking for teams choosing where an agent should start.

Three factors decide which procurement processes to automate first

Volume matters because automation compounds on repetition. A process that runs 5,000 times a month repays an investment that a process running twelve times a year never will, whatever the stakes of each run.

Cost per touch is the loaded labor cost of one instance: the minutes a person spends on it multiplied by a fully loaded hourly rate. Touches vary enormously across the procure-to-pay chain. Releasing a clean purchase order takes two or three minutes. Investigating a three-way-match failure – an invoice that disagrees with the purchase order or the goods receipt, the record confirming what actually arrived – routinely takes half an hour and can stretch across days of waiting on a buyer or supplier to answer email.

Context availability is the factor older playbooks never scored, because scripts could not use context anyway. It asks whether the evidence required to finish an instance exists in reachable systems: the ERP, the contract repository, receiving records, resolution history, email threads. When the evidence is reachable, an agent can complete the work and attach proof that it did. When the evidence lives in someone's head, or at a site whose records are spreadsheets on a shared drive nobody connected, capability in the model makes no difference.

The usual candidates sort into uneven tiers

Requisition intake, PO creation, and invoice capture score high on volume and low on cost per touch, and most of that prize has already been claimed. Catalog buying and workflow tools absorbed intake and PO creation years ago; OCR and e-invoicing absorbed capture. What remains in those processes is the residue the tools could not handle, which is smaller and stranger than it looks on a process map.

The picture changes at invoice exceptions, the invoices that fail a validation check and drop into a hold queue. Take a manufacturer pushing 30,000 invoices a month through SAP. Suppose 4,500 fail a check and go on hold. At 35 minutes of analyst time per case and a $54 loaded hourly rate, each touch costs about $31.50 and the queue costs roughly $141,750 a month. The same company's 9,000 monthly requisitions, at three minutes each, cost about $24,300 – a sixth of the money for twice the instances. The full cost anatomy is documented at the cost of invoice exceptions.

GL coding – assigning each invoice line to the correct general ledger account and cost center – scores high on volume, moderate on cost per touch, and badly on the cost of being wrong, because miscoded lines surface at month-end close as reconciliation work. Supplier onboarding runs at lower volume with expensive, document-heavy touches. Contract renewals sit at the bottom of the volume scale with the most judgment-dense touches in the function.

Agents invert the old automation playbook

Deciding which procurement processes to automate first used to follow one rule: start with simple, repetitive work you can fully specify, and defer anything that needs judgment. The rule matched the tools. RPA bots and workflow engines execute rules, so the work had to be reducible to rules before it could be handed over – the RPA vs agentic AI page traces that boundary in detail. The same rule explains why exception resolution and coding stayed manual for twenty years: both require reading a contract clause, weighing precedent, and deciding, none of which reduces to a rule set anyone could maintain.

Score those deferred processes on the three factors and the old ranking flips. Exception resolution runs at high volume. Its touches are the most expensive routine touches in the chain. And the context it needs – purchase orders, goods receipts, contract pricing schedules, years of resolution history – has been sitting in the ERP and the systems around it the whole time, in formats a script could never parse and an agent reads directly. The work the old playbook deferred longest is now the highest-return starting point.

Sequence the rollout by verifiability, then by compounding

1. Exception resolution first. The queue is contained, the baseline is measurable in cases and minutes, and success is countable through zero-touch resolutions – cases that close with no human involvement. Autonomous exception resolution covers how agents work these cases end to end.
2. GL coding second. Every line an agent codes correctly becomes precedent for the next thousand lines from the same supplier and category, so accuracy compounds month over month. Automated GL coding walks through the mechanics.
3. Approval assembly and change-order reconciliation third. Assembling the evidence an approver needs, and reconciling change orders – post-issue amendments to a PO's price, quantity, or delivery terms – against what suppliers actually invoiced. Both are research tasks with checkable end states, but their baselines are messier than an exception queue's.
4. Document-heavy supplier onboarding fourth. Collecting tax forms, banking details, and certificates is agent-suited work, but part of the context comes from outside the company, so cycle time depends on supplier responsiveness rather than on the agent.

Three kinds of work belong at the back of the queue

The first is low-volume judgment work. An annual sourcing event or a strategic supplier negotiation happens too rarely to repay automation and turns on judgment a company should want people to exercise. Automating it produces a demo rather than a return.

The second is anything without a verifiable end state. If nobody can check whether an instance was completed correctly – supplier relationship management is the usual example – then zero-touch counting is impossible, and an automation program that cannot count its wins cannot defend its budget.

The third is any process whose records live in people's heads at sites you have not connected. A plant that runs receiving on a coordinator's memory and a paper log gives an agent nothing to read. Connect the site first; automate second.

A good pilot lets the evidence order the expansion

Pick one queue with a clean baseline: known monthly volume, known minutes per touch, known aging. Run the agent on that queue with zero-touch counting on from day one, and have the team review every escalation weekly, because early escalations reveal where the agent's context is thin. Expand to the next process when the counts justify it, letting the same three factors pick the next queue. The financial structure for that decision – what to count, over what period, against which baseline – is laid out in the business case for procurement automation. A pilot designed this way ends arguments with a number instead of starting them with a promise.

Fragment builds AI agents for the top of this ranking: resolving exception queues and coding invoice lines autonomously inside a company's existing SAP or Ariba environment, with resolution counts reported against the baseline, and no rip and replace. See how the workflows run or request a demo.