Settyl
← All insightsOperational Fragmentation
INSIGHT 09Operational Fragmentation

PO Created Is Not Procurement Completed

SSettyl2 min read
A runner leaving the PO created flag must clear supplier response, promise date and quantity change hurdles before completion
THE THESISA purchase order records buyer intent. Procurement isn’t complete until the supplier’s commitment is verified.
THE BRIEF

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.

WHY IT MATTERSTreating PO creation as done hides the coordination still happening between ERP, suppliers, approvals and logistics.
KEY TAKEAWAYA PO shows recorded intent. Real procurement progress is confirmed supplier commitment.
All insights →
FROM FRAGMENTED WORK TO VERIFIED EXECUTIONStart with one transaction that still needs human relay.
Start one execution