How to Automate Purchase Approvals

Ask a purchase team why a request took five days and the answer is usually about a specific person being busy. Look at the data afterwards and the answer is almost always different: for four of those five days, nobody knew the request was waiting for them.

That distinction matters, because the two problems have completely different solutions. One requires a conversation about workload. The other requires a queue.

Step 1 — Write down the authority matrix

This is the real work, and it is business work rather than software work. For each department and category, at what value does approval move to the next level? What are the exceptions — capital items, consumables, items against a specific customer order?

Most companies find that their authority matrix has never been written down completely, and that two senior people describe it differently. That discovery alone is worth the exercise.

Step 2 — Give every pending item an owner and a clock

A request that is 'sent for approval' is nowhere. A request in a named person's queue with a visible waiting time is somewhere, and it can be measured.

Add an escalation rule: after a defined period the item reminds its owner, then moves to the next authority level, then appears on the management exception list. Escalation should be part of the rule, not a matter of somebody's persistence.

Step 3 — Attach the context to the decision

The reason approvers ask questions instead of deciding is that the request arrives without the information needed to judge it. Attach it automatically:

• The last three purchase rates for the item, with vendor and date.
• Current stock, reserved stock and stock on order.
• Consumption trend over the last few months.
• The order or job driving the requirement, if there is one.
• Budget position for the category, if you run budgets.

An approver with the last purchase rate on screen decides in seconds. An approver without it either asks and waits, or approves blind. Most approval delay is an information problem wearing the costume of a discipline problem.

Step 4 — Handle absence explicitly

The single most common cause of approval delay is an approver being unavailable with no defined alternate. Build delegation into the rule: when an approver is marked away, their queue routes to a nominated person for that period, and the record shows who actually approved it.

Step 5 — Build the urgent path deliberately

Urgent purchases will happen. If the system has no legitimate fast route, they will happen outside it — a phone call to a vendor and an invoice that appears later with no purchase order behind it.

Give urgency a defined path: a named authority who can approve it alone, a mandatory reason, and a flag on the record. You will then have something you have never had before — a monthly report on how often the emergency route is used, by whom, and for what. That report is often the most valuable output of the whole project.

Step 6 — Generate the PO from the approval

Re-typing an approved request into a purchase order introduces differences between what was approved and what was ordered. Generate the order from the approved request, and keep the link visible so the two can always be compared.

Step 7 — Hold received material until it is inspected

Goods receipt should match against the purchase order with tolerance rules, and put material into a held state until inspection is recorded. The failure this prevents — rejected material already consumed in production — is expensive and unpleasant to unwind.

What you can measure afterwards

One thing not to do

Do not add approval levels because the system now makes them easy. Automation makes each level cheaper, which is exactly why it tempts companies into adding more. Every level is still a delay and a diffusion of responsibility. If anything, a good automation project should let you remove one.