PO Created Is Not Procurement Completed

A PO can sit in ERP while the transaction still depends on a person to get it resolved.
A purchase order can exist in ERP while the procurement transaction is still waiting on a person.
That distinction matters because most procurement automation is measured at the wrong finish line. A requisition is approved. A PO is generated. The document is transmitted. The workflow turns green.
But the supplier may still need to confirm the quantity, reject the requested date, propose a substitute, challenge a commercial term or acknowledge only part of the order. When that happens, the system has recorded intent. It has not yet secured commitment.
PO creation is a system event. Supplier commitment is a business outcome.
ERP is exceptionally good at maintaining the official purchase-order record. It was never designed to own every email, call, attachment, revision and exception required to move that order from buyer intent to supplier commitment.
That work usually falls back to the buyer: send the PO, wait for the response, interpret the supplier message, compare what changed, seek approval, amend the record, follow up again and finally tell logistics what is actually going to happen.
The person becomes the execution layer between the record and the outcome.
The transaction should continue until commitment is verified
A more useful procurement state model is:
Purchase intent → PO issued → Supplier response → Commitment verified → Execution ready.
The important state is not “PO created.” It is “commitment verified.” At minimum, that means the transaction has evidence for the price, quantity, promise date and governing terms that the supplier has actually accepted.
Consider a PO for 10,000 units due on Friday. The supplier replies that only 8,000 can arrive Friday and the balance will arrive Monday. Detecting that message is useful. Extracting the new dates is useful. But neither completes the transaction.
Execution requires the change to be interpreted against business rules, the downstream impact to be understood, any required approval to be obtained, the supplier commitment to be confirmed, and the verified outcome to be written back to the System of Record.
This is where procurement autonomy becomes measurable
The same logic behind Autonomy Rate applies here. The question is not how many procurement steps were automated. The question is whether the eligible transaction reached a verified supplier commitment without a buyer carrying the work between systems and parties.
That is a much harder standard than PO automation. It is also closer to the business outcome procurement actually needs.
