Requisition-to-PO conversion: the compliance step agents make fast

Requisition-to-PO conversion is the process step that turns an approved purchase request into a purchase order a supplier can act on. It covers everything between "I need this" and "it is ordered": working out what is being bought, adding the accounting and contract data, routing approvals, and creating and transmitting the PO. It is also the step that decides PO compliance – the share of spend that runs through a purchase order – because requesters judge the whole process by how long this step takes.

The wiki this page belongs to describes a world where AI agents carry the operational load – decoding requests, filling in codes, chasing approvals – and people keep the judgment calls. A typical glossary treats conversion as a buyer's data-entry chore; this page treats it as a pipeline an agent can run in hours.

Requisition-to-PO conversion is five jobs wearing one name

On a process map, requisition-to-PO conversion is a single arrow between "requisition approved" and "PO created." Inside that arrow sit five jobs, each able to stall. Conversion sits early in the source-to-pay lifecycle, so shortcuts taken here resurface weeks later as receiving, matching, and coding problems.

• Intake. Requests arrive as forms in the eProcurement tool, as punchout catalog carts (a supplier's webshop embedded in the buying system), as emails to a shared inbox, and as hallway asks typed up later. The less structured the channel, the more work later stages inherit.
• Interpretation. Someone establishes what is actually being bought: the category, the supplier who can fill it, and whether "the same sensors as last time" means the March part or its revised replacement.
• Enrichment. The request gets the data the ERP requires and the requester almost never supplies: the GL code (the ledger account the cost posts to), the cost center (the budget the spend charges against), the unit price, and the contract reference.
• Approval routing. The enriched requisition goes to whoever policy says must sign off, resolved from amount thresholds and the org hierarchy.
• PO creation and transmission. The approved requisition becomes a purchase order in the ERP – SAP, Coupa, or otherwise – and reaches the supplier by cXML, portal upload, or email.

Conversion latency decides whether anyone uses the process

Requesters experience requisition-to-PO conversion as one number: the time between submitting the request and the order reaching the supplier. Every added day recruits a few more people into the workarounds catalogued on the PO-first culture page: the direct call to a familiar supplier, the P-card swipe, the email order. Each workaround produces goods with no PO behind them and, weeks later, non-PO invoices that AP must decode from scratch. Compliance follows latency; enforcement campaigns rarely change that arithmetic for long.

Take a five-day conversion and trace where the days go. A maintenance planner submits a $4,180 requisition for conveyor rollers on Monday at 9 a.m.

1. Days one and two: the approval inbox. The amount crosses the $2,500 threshold, so a second approver is required. She is traveling; the reminder lands among forty other emails.
2. Day three: buyer triage. The approved requisition drops into a shared queue a buyer works top-down once a day, behind eleven older requests.
3. Day four: catalog-miss handling. The rollers are missing from the punchout catalog, so the buyer emails the planner for a part number and gets the answer after moving on.
4. Day five: enrichment and creation. The buyer looks up the GL code, confirms the contract price, creates the PO in SAP, and transmits it at 4 p.m.

Total human touch time across those five days is under an hour; the rest is queue time, the requisition waiting for a person to reach it. The planner's conveyor has been down since Monday, and the lesson he learns is to call the supplier directly next time. That call is how compliance erodes: one reasonable person at a time, each responding to the latency the process taught them to expect.

The pipeline stalls in four predictable places

Most long conversions trace back to four failure modes that compound each other.

• Catalog misses. A request the catalog cannot fill bounces out of the automated path into manual sourcing: the buyer hunts for the supplier, price, and part number that intake was supposed to hand over.
• Free-text requisitions. "10 of the usual brackets, ask Dave" forces a buyer to reconstruct the purchase from memory, past orders, and a conversation with Dave, who is on holiday.
• Stale routing data. Approval chains driven by an org chart last synced before the spring reorg send requisitions to a manager who left; the request waits in a dead inbox until someone asks. Errors that survive downstream return as coding and approval exceptions.
• The batch habit. Buyers under volume pressure convert requisitions weekly to consolidate the work, adding up to four days of latency to every request and making conversion time a lottery decided by submission timing.

Four numbers describe the health of the conversion step

Managing conversion means measuring how the step actually fails, in distributions and touch counts rather than averages.

• Conversion time, median and tail. A 1.8-day median with a 12-day 90th percentile means most requests move acceptably while a minority crawl. The tail is what requesters remember and retell, and the tail drives the workarounds.
• Touch count per conversion. How many times a human opens the record before transmission. Every touch above one signals a handoff, a question, or a correction.
• Catalog hit rate. The share of requisitions filled entirely from catalog content, since every miss lands in the pipeline's slowest branch.
• First-time-right coding. The share of POs whose GL code and cost center survive to invoice posting without correction. Low scores export work to AP.

The same four numbers make conversion an unusually clean procurement automation business case: high volume, a measurable baseline, results inside a quarter.

Agents run the pipeline and people approve what matters

Most of requisition-to-PO conversion is reading, matching, and assembling – the work profile that agent-based procurement automation handles well. An agent picks up the free-text request and reads it the way a buyer would: it matches "the same sensors as last time" to the March PO, finds the supplier under contract for that category, pulls the negotiated price, resolves the GL code and cost center from the requester's past purchases, and drafts the PO with the approver resolved from current HR data. Then it does the part conventional software never did: it chases, nudging the approver with the two facts she needs to say yes, and it transmits the PO the moment she does. Conversion finishes in hours, and every human touch is a decision instead of assembly.

What stays human is the judgment. A request that needs a new supplier is a sourcing decision. An amount over the sign-off threshold still needs the sign-off; the agent's job is to present the assembled case rather than approve it. A pattern that suggests contract circumvention – three $9,800 requisitions to one supplier in a month – should reach a category manager with the pattern laid out. The agent removes the waiting and the assembly; the yes or no stays where it was. Conversion ranks near the top when weighing which procurement processes to automate first: well-defined inputs, steady volume, an effect visible in the next quarter's PO coverage.

Fragment builds AI agents that run requisition-to-PO conversion this way, inside the systems a company already operates – SAP, Ariba, Coupa, the contract repository, the shared inbox – with no rip and replace. The agents read requests, assemble compliant POs, chase approvals, and hand people finished cases to decide. See the workflows Fragment covers or book a demo and walk through your own conversion latency.