Requisition to purchase order AI agent: a blueprint for procurement
How a governed requisition to purchase order AI agent workforce checks each request at intake, applies your sourcing rules, runs the approval matrix as configured and creates the PO in the ERP, leaving buyers only the requisitions that need judgment.
- Problem
- Routine requisitions wait days in the same buyer queue as complex sourcing work, and many arrive missing the data needed to convert them.
- Agent design
- Intake, sourcing, processing and pattern agents working from one versioned buying rulebook.
- Systems
- ERP procurement module, procure-to-pay suite, catalogs and punchout sites, contract repository, budget and cost objects.
- Hard limits
- Agents hold no approval authority, never onboard a supplier, and never place restricted or sole-source spend.
- Value levers
- Buyer hours moved to sourcing, shorter requisition-to-PO cycle time, more spend on contract, fewer after-the-fact POs.
- First release
- Intake validation alone, then PO creation for catalog and contract items in two or three high-volume categories.
Where the requisition-to-PO process stalls today
A requisition has to pass four checks before it becomes a purchase order: a valid budget line or cost object, a specification a supplier can ship against, a match to a catalog item or contract, and the right approval path for its amount and category. A buyer does that by hand: reads "pump seal, same as last time", searches the contract repository, emails the requester for the material number and WBS element, and waits. Most indirect and MRO requisitions are routine and policy already allows them, yet requesters wait days.
Friction comes from hand-offs between requester, buyer and approver, missing data at intake, and exceptions sharing one queue with routine work, so a sole-source justification and a box of gloves wait in the same line. It peaks in energy and chemicals around a turnaround, when late POs become late parts. Requesters who learn the queue is slow buy first and raise the PO after the invoice, which breaks commitment accounting and contract compliance.
| Requisition type | What drives it | What the agents do | Can agents create the PO alone? |
|---|---|---|---|
| Catalog item | Hosted catalog or punchout cart with contract pricing already applied | Checks budget and account assignment and current catalog price, routes approvals, creates the PO | Yes, within amount threshold |
| Contract release | Item covered by a framework agreement, blanket PO or outline agreement | Matches item and price to the agreement, checks remaining value and validity dates, creates the release | Yes, if agreement has headroom |
| Repeat MRO spare | Material master with a source list or purchasing info record | Applies the fixed source, checks lead time against the need date, flags expedite risk | Fixed source only |
| Free-text request | Requester could not find the item or did not look | Proposes the likely catalog or contract match and asks the requester to confirm | After requester confirms |
| Off-catalog over quote threshold | New item or spend above the competitive bid limit | Prepares the sourcing file: specification, candidate suppliers, price history, RFQ draft | No, buyer sources |
| New or sole-source supplier | Requester names a supplier not on the approved list | Assembles the justification and routes to the category manager and supplier onboarding | Never |
| Restricted category | Capex, software, hazardous materials, regulated items | Routes to the required reviewers such as IT security or EHS; takes no sourcing action | Never |
The requisition to purchase order AI agent workforce: four roles, one rulebook
The live design names two roles, intake and processing. This blueprint splits sourcing from processing, so the agent that picks where to buy never creates the commitment, and adds a pattern agent that feeds category management. All four read one buying rulebook built from category management: coverage, quote thresholds, restricted categories and the approval matrix reference. Each runs under its own task-scoped identity.
| Agent | Job | Reads | Can write | Never does |
|---|---|---|---|---|
| Intake agent | Validates each requisition at the source and returns gaps to the requester at once | Requisition header and lines, cost objects and budget availability, material and catalog data | Validation result and a plain-language gap list on the requisition | Change amounts, cost objects or items without the requester |
| Sourcing agent | Applies sourcing rules: catalog, contract, source list, or buyer sourcing | Contracts and agreements, source lists, info records, price history, approved supplier list | Proposed source of supply and the sourcing file for buyer-routed items | Select a supplier outside the approved list or the rulebook |
| Processing agent | Runs compliant requisitions through the approval matrix and creates the PO | Validated requisition, proposed source, approval status | Workflow submission, then the PO through the standard create transaction | Approve, alter the approval matrix, or split a requisition to avoid a threshold |
| Pattern agent | Reports where requisitions fail and where spend leaks off contract | Audit log, completed requisitions and POs, after-the-fact PO list | Weekly report by category, requester group and plant | Act on any open requisition |
Requisition-to-PO architecture: agents beside the ERP procurement module
The agents work beside the ERP procurement module and catalog platforms through governed interfaces, never around them. They read through published APIs and create POs only through the transaction a buyer would use, so the ERP's own checks for pricing, account assignment, tax and release strategy still run. ERP access licensing for agent identities is priced into the case at design, not discovered after go-live.
How one requisition is routed to a PO or a buyer
Two questions route each requisition after intake. Is it restricted, sole-source or tied to a new supplier? If not, is it a covered source under the category's amount threshold? Only a "no" then a "yes" leads to automatic PO creation, and that path still waits for every approval the matrix requires.
Procurement platform integration for requisition agents
The pattern holds on every platform: subscribe to the requisition event, read through published interfaces, submit to the existing approval workflow, and create the PO through the standard path. What changes is where approvals are configured and whether a procure-to-pay suite sits in front of the ERP.
| Platform | Where requisitions live | How agents read | How agents write | Design note |
|---|---|---|---|---|
| SAP S/4HANA | Purchase requisitions with release strategy or flexible workflow approval | OData APIs for requisitions, purchase orders, contracts, source lists and info records | Requisition updates and PO creation through standard APIs or functions, never table updates | Budget availability control on cost centers or WBS elements must run on agent-created POs as on manual ones |
| SAP Ariba or Coupa | Requisitions raised in guided buying or the requisition checkout | Suite APIs for requisitions, catalogs, contracts and approval status | Approval submission and requisition edits inside the suite, which then creates the ERP PO | Where a suite owns approvals, agents work inside its chains and never call the ERP directly |
| Oracle Fusion Cloud Procurement | Self Service Procurement requisitions and purchasing documents | REST resources for requisitions, purchase orders and agreements | Requisition processing into orders through the standard purchasing flow | Approval rules live in Fusion's approval configuration; the agent reads status and never edits rules |
| Catalog and punchout | Hosted catalogs and supplier punchout carts | Catalog content and cart returns via the suite or ERP | None; the agent flags stale prices and missing items to the catalog team | Catalog coverage sets the touchless ceiling more than agent design does |
Agents can be built with ERP-native agent tooling, a hyperscaler stack or an automation platform. The choice follows where requesters already work and where identity, licensing and audit controls are strongest.
Human oversight in requisition approval and PO creation
Procurement oversight is about commitments: who may commit company money, with which supplier, at what price. The agent holds no approval authority, logs every step against the requisition, and leaves supplier choice outside the rulebook to people. Rows run from most automated to never automated.
| Decision | Who decides | Agent's role | Control |
|---|---|---|---|
| Return an incomplete requisition | Agent | Lists missing fields and the rule behind each | Return only; it cannot cancel or rewrite a requisition |
| Catalog, contract or fixed-source PO under threshold | Agent | Creates the PO after required approvals | 5% sampled weekly; sample error above 1% suspends that category |
| Off-catalog or above quote threshold | Buyer | Prepares the sourcing file and RFQ draft | Buyer selects the source; agent creates the PO only after |
| New supplier, sole source or restricted category | Category and control owners | Assembles the justification and routes to required reviewers | Excluded from the automated path; no write access to the supplier master |
| New supplier or sole source | Category manager | Assembles the justification | Agents have no write access to the supplier master |
| Rulebook changes | Procurement lead | Proposes changes from the pattern report | Versioned rulebook; every PO records the version it used |
Illustrative economics of requisition-to-PO agents
The model uses example inputs for an enterprise processing 120,000 indirect and MRO requisitions a year; replace them with your own. Buyer hours released only become cash if they move to sourcing work or a vacancy goes unfilled, while spend moved onto contract pricing is cash either way. ERP access licensing is its own cost line.
Fixed assumptions: 5% of touchless POs are sampled at 5 minutes each; build cost excludes your internal team time. Example inputs only. They describe no client and are not a forecast.
The cash-only payback is long, because contract compliance moves slowly. The capacity view carries the case, so the plan must say where buyer hours go: more competitive events, catalog coverage for the next categories, or turnaround volume without temporary staff.
Deployment roadmap for requisition-to-PO agents
The path follows the live design: encode policy for two or three high-volume categories, run intake validation alone until requester behavior adjusts, enable processing category by category, then raise the touchless threshold as the record supports it. The procurement lead signs each gate.
- Weeks 0 to 4
Baseline
Classify a quarter of requisitions, measure cycle time, return rates and buyer hours, and pick two or three categories with high volume and good catalog or contract coverage.Gate: procurement lead signs rulebook v1 - Weeks 4 to 12
Intake live, processing in shadow
The intake agent returns gaps to requesters for real, with no commitment risk. Sourcing and processing agents propose a source and route for every requisition while buyers work as normal.Gate: first-time-right stable for four weeks and 95% agreement on source - Weeks 12 to 18
Controlled PO creation
Enable PO creation for catalog, contract and fixed-source items in the pilot categories at a low threshold, with 5% sampling and the pause switch tested first.Gate: zero approval-matrix bypasses, sample error under 1% - Week 18 onward
Scale
Add categories as their rules are encoded, raise thresholds per category on the record, then extend to rate-card services and further entities.Gate: per category, per entity
How requisition-to-PO performance is measured
The live page names cycle time, touchless rate, first-time-right at intake and buyer hours redirected. This blueprint adds a control metric and spend on contract, all baselined from your own data in the first stage.
| Metric | Definition | Why it matters |
|---|---|---|
| Requisition-to-PO cycle time | Median and 90th percentile hours from submission to PO, by category | What requesters feel; the 90th percentile shows where turnaround parts arrive late |
| Touchless rate on routine purchases | Share of catalog, contract and fixed-source requisitions converted with no buyer touch | Drives buyer capacity, and the hours released must be redirected to sourcing work to count |
| First-time-right rate at intake | Share of requisitions that pass intake validation on first submission | Shows whether requesters are adjusting and catalogs are findable |
| Sample error rate | Share of sampled agent-created POs a buyer would have sourced, coded or routed differently | The control metric that decides whether thresholds can rise |
| Spend on contract | Requisition spend placed through catalogs, agreements or fixed sources | The cash lever in the model |
Questions procurement teams ask about requisition agents
Can the agent approve a requisition?
No. It submits the requisition to the approval workflow your ERP or procure-to-pay suite already runs. It cannot approve, delegate or change the matrix, and it flags requisitions that look split to stay under a limit.
How is this different from guided buying or catalog tools we already have?
Guided buying steers requesters to the right channel. The agents handle what still reaches buyers: free-text requests that match an existing contract, missing cost objects, lead-time conflicts, and the conversion and routing a buyer does by hand.
Which requisitions should never be touchless?
New or sole-source suppliers and restricted categories such as capex, software and hazardous materials. They leave the automated path before any threshold check.
What happens if we pause the agents?
Open requisitions return to the buyer queue as the agents left them, with the validation result and sourcing file attached. The pause is tested before the first live PO.
Do we need a finished category management program first?
It helps, because category structure is the agents' rulebook. Two or three well-covered categories are enough to start.
Working with WGA on requisition-to-PO automation
WGA runs this as a scoped engagement, not a platform sale. It starts with a quarter of your requisitions: which types reach buyers, how many come back for missing data, which categories have the coverage to go touchless, and where source lists or the approval matrix need fixing first. The rulebook is written with your category managers, and every role follows WGA's rule for digital workers: a defined business role, task-scoped permissions, named human checkpoints and an oversight model your risk function can test.
Senior WGA consultants lead the work with fees fixed against the outcome and release targets set in advance, and your finance function counts the value. Your procurement operations and IT teams inherit the rulebook, runbooks and tested pause procedure to run the agents without us.
Discuss requisition-to-PO in your operation
Talk to our AI practice