How to let an AI agent create purchase orders in your ERP

Start the agent at depth 2: it converts approved requisitions into purchase orders saved in draft, and a buyer releases them. Once certified, it may create and release orders at depth 3 for one narrow class, catalogue items from contracted suppliers at contract price under a set value. Transmitting anything else to a supplier stays with a buyer.

What is a purchase order commitment, and who owns it?

A purchase order is the document that commits you to buy. Once a supplier receives it, cancelling may cost money or goodwill, and in some contracts it is binding on acceptance. That makes creating an order in draft very different from sending one. The ERP usually reflects this with separate statuses: created, approved, released, transmitted.

Procurement owns purchase orders. A buyer or purchasing team converts approved requisitions, chooses the supplier where there is a choice and checks terms. Finance owns budget control, and the ERP checks commitments against budget when an order is approved.

The agent's job is the conversion work that fills a buyer's day: copying requisition lines, finding the contracted supplier and price, splitting by supplier and delivery address, and filling in the fields the ERP requires. The general bounds for this kind of work are in AI agents for finance.

Which ERP permissions do you grant, and at what depth?

ERP roles are broad by default. A "purchasing clerk" role often includes creating suppliers and changing prices, which the agent must not have. Build the agent's role from nothing, as connecting an AI agent to your ERP without over-permissioning it describes.

1. Agent, depth 1: reads approved requisitions, catalogue, contracts and supplier list.
2. Agent, depth 2: creates purchase orders in draft. One order per supplier and delivery, with requisition references, contract price and account coding. A buyer reviews and releases.
3. Agent, depth 3 once certified: creates and releases orders in the routine class. Catalogue item, contracted supplier, contract price, value under the limit, requisition approved by the right budget holder.
4. Agent, held: anything off-contract, new supplier, price differing from contract, or over the limit. The draft goes to a buyer with the reason.
5. Agent, refused: creating or changing suppliers, contract prices or catalogue items.
6. Agent, refused: approving the requisition behind an order it creates. Approval of the spend belongs to the budget holder; whether an agent can approve purchase orders at all is a separate question.
7. Person, buyer: releases held orders and handles supplier communication on exceptions.

How do you hold, revoke and record?

Held orders stay in draft status with a note: "price on requisition differs from contract by more than tolerance", "supplier not on contract for this category", "value above agent limit". A buyer sees the draft, the requisition and the contract side by side.

Revocation lives in two places. In the ERP, the agent's role can lose the release permission while keeping draft creation; this is a role change the ERP security team makes. In the agent's bounds, the procurement lead can withdraw the depth 3 capability for one category or plant immediately. Test both before go-live, because ERP role changes often wait for a security change window.

Every order the agent creates carries its identity in the created-by field, the requisition reference and the contract reference. The filed verdict adds the bound that decided, the limit in force and the certificate in date.

Which controls matter, and what evidence does each leave?

No order without an approved requisition. Evidence: requisition reference and its approval record on each order.

Contract price only. The agent copies the price from the contract, never from the requisition text or a supplier email. Evidence: contract line reference per order line.

Duplicate check. Same item, same supplier, same requester within a short window. Evidence: duplicate flags in the held queue.

Split-order check. One requisition split into several orders under the limit is held as one. Evidence: linked drafts.

Separation from receipt and invoice. The agent that creates orders does not book receipts or match invoices to purchase orders for the same orders. Evidence: identity on each document.

What should you measure?

• Orders created by the agent later cancelled or amended, by reason.
• Price variances at invoice on agent-created orders compared with buyer-created ones.
• Off-contract spend caught at the draft stage.
• Time from requisition approval to order release.
• Held drafts by reason. A recurring reason often means a contract or catalogue needs updating.

Where does it usually go wrong?

The role was copied from a person. The agent inherits a buyer's role, including supplier creation. One bad email later, it creates a supplier. Build the role from the actions it needs, line by line.

Catalogue prices are stale. The contract was renegotiated, the catalogue was not updated, and the agent creates hundreds of orders at the old price. Make the agent compare catalogue price with the contract record and hold on mismatch.

Free-text requisitions. "Same as last time, but more" cannot be converted safely. Require structured lines for the routine class and send free text to a buyer.

Upstream quality. Requisitions that the agent itself raises for replenishment then flow into orders it creates, and nobody looks at either. If you also let an agent raise purchase requisitions, keep a budget holder's approval between the two.