How to process purchase requisitions with an AI agent

Requisitions stall because they arrive incomplete, off-contract or routed to the wrong approver. An agent can fix all three: it checks each requisition for missing data, matches it to a contract or catalogue item, checks budget, routes it under the approval matrix and, once approved, prepares the purchase order draft. Budget holders approve the spend and buyers release orders.

What does processing a requisition involve, and who owns it?

A purchase requisition is an internal request to buy something. Processing it means checking it is complete and sensible, finding the right way to buy, getting the right approval and turning it into a purchase order. It is the first stage of purchase-to-pay, and errors here travel all the way to the invoice and payment.

Procurement owns the process. Budget holders own approval of spend. Buyers own supplier choice and order release for anything non-routine. Requesters own the need and the description. Most delays are not approval delays; they are back-and-forth over missing information and wrong routing.

This playbook covers requisitions raised by people. Where the agent raises routine replenishment requisitions itself, see letting an AI agent raise purchase requisitions.

What are the steps, and who acts at each one?

1. Person, requester: raises the requisition. In the procurement tool, or by describing the need to the agent, which drafts it for the requester to submit.
2. Agent, depth 1: checks completeness. Description, quantity, cost centre, account, delivery address, date needed, and attachments the category requires, such as a quote or a scope of work.
3. Agent, depth 2: returns incomplete requisitions. With a specific request: "Please add the cost centre and attach the quote." Under certification, standard returns can go at depth 3.
4. Agent, depth 1: finds the buying route. Catalogue item, existing contract, framework agreement, preferred supplier, or none. Flags requests that duplicate a contract already in place under another name.
5. Agent, depth 1: checks budget. Remaining budget on the cost centre and account, including open commitments.
6. Agent, depth 2: routes for approval. Under the approval matrix, by amount, category and cost centre, with a short summary for the approver: what, why, how it will be bought, budget position.
7. Person, budget holder: approves or rejects. The agent never approves.
8. Agent, depth 2: prepares the purchase order draft. For approved requisitions, using contract prices. A buyer releases it, or a separate certified capability releases routine catalogue orders.
9. Person, buyer: handles non-routine buying. Quotes, tenders and supplier selection.

What does one requisition look like?

Take an illustrative request: "Two monitors for the new analysts, cost centre missing." The agent returns it asking for the cost centre, then finds both monitors in the catalogue under the hardware contract at 180 each. Budget for the cost centre has 2,000 left after open orders. It routes the requisition to the team's budget holder with a three-line summary. Once approved, it prepares a catalogue order at contract price for the buyer, or for the certified ordering capability, to release.

Which controls matter, and what evidence do they leave?

Approval matrix applied, not interpreted. The agent routes by the matrix in force; it does not choose a different approver because one is unavailable. Delegation during absence is set in the tool by people. Evidence: matrix version on each routing.

No self-approval. A requester is never routed to themselves, even if they are also the budget holder; the matrix escalation applies. Evidence: requester and approver identities.

Split detection. Several requisitions for the same need, each under a threshold, are linked and routed at the combined value. Evidence: linked requisition flags.

Contract compliance. Off-contract requests where a contract exists are flagged to procurement before approval. Evidence: the contract match result.

Budget position at approval. Evidence: the budget figures shown to the approver.

What should you measure?

• Requisitions returned for information, and how many come back complete.
• Cycle time from submission to approved, and to order released.
• Off-contract spend caught before approval.
• Split requisitions detected.
• Approver rejections after routing, which can show routing or summary problems.

Where does it usually go wrong?

The approval matrix is out of date. People have left, cost centres have changed, and the agent routes to an empty inbox. The agent should flag approvers who have not acted on anything for weeks, and procurement should maintain the matrix.

Free text hides the item. "Laptop for new starter" could be a catalogue item or a specialist machine. The agent suggests the catalogue item and asks the requester to confirm, rather than guessing.

Budget checks without commitments. Budget looks available because approved but uninvoiced orders are not counted. Include open commitments.

The agent becomes the approver by default. Approvers start trusting the summary so much that they approve without opening anything. Keep summaries factual and highlight anything unusual first. Whether an agent can approve purchase orders is a separate decision that needs its own case.

Order release blurs into requisition processing. Whether an agent can raise a purchase order directly is a different capability. Keep the boundary visible.

Where Pryme fits

In Pryme, checking, routing and drafting orders are separate capabilities, each certified through Attest on your own past requisitions. Requester descriptions arrive as declared and contract terms as signed, so the approver can see what the summary rests on. Approval sits outside the agent's role scope and every routing is filed. The finance bounds are in AI agents for finance.