Quick Answer: Measure your PO cycle before you choose what to automate. Capture four timestamps — requisition submitted, final approval recorded, PO dispatched to the vendor, vendor acknowledgement — and look at the three gaps between them. In most teams the largest gap by an order of magnitude is submission to approval, and the smallest is approval to dispatch. Approval-to-dispatch is also the stage that demos best, because it is visual and instant. Automating it first shortens a step that was never the constraint and pushes the queue upstream, where it is now less visible than it was before.

The demo you have booked

The vendor demo will almost certainly open the same way. A requisition is approved on screen, a formatted purchase order appears with the right legal entity and payment terms, and it lands in a vendor inbox, all in about four seconds. It is a good demo, because document generation is fast, visual, and obviously better than a person retyping a spreadsheet row.

It is also, in most purchasing operations, a demo of the stage that was already the shortest.

Purchase order process automation is not one decision; it is four, with very different payoffs depending on where your own time is going. They are worth doing in the order your cycle data dictates, not the order they appear in a product tour.

Why automating the wrong stage moves the queue instead of removing it

A worked shape rather than a benchmark. Suppose a requisition sits four days waiting for an approver, then someone spends twenty minutes creating and sending the PO. Total: four days and twenty minutes.

Automate the creation step perfectly and you have four days and ten seconds. Nobody in the business will be able to detect the change. Requesters will still say the PO process takes about a week, because it does.

Worse, the queue does not disappear — it relocates. When dispatch becomes instant, the pile of approved-but-unsent requests vanishes from view, and the pile of unapproved requests grows to absorb the same demand. Before automation you could see the work waiting on a desk. Afterwards it is waiting inside an approval inbox, where it produces no visible artefact at all and nobody is counting it.

The rule that follows is unglamorous: automate the stage with the largest gap, not the stage with the best demo. And you cannot know which that is without measuring.

Measure your cycle first: four timestamps, three gaps

You need four timestamps per purchase order, for a sample of the last 60 to 90 days. Most ERPs hold three of them and lose the fourth.

Timestamp	Where to find it
T1 — requisition submitted	Requisition record creation date
T2 — final approval recorded	Last approval action in the audit log, not the first
T3 — PO dispatched to vendor	Email send time or EDI transmission log, not the PO document date
T4 — vendor acknowledgement	Vendor reply, portal confirmation, or order confirmation document

Two traps worth naming. T2 must be the last approval, not the first — multi-level chains hide most of their latency in the second and third hop. And T3 must be when the vendor received it, not when the PO record was created; in plenty of systems those are days apart because the document was generated and then sat waiting for someone to attach it to an email.

The three gaps read like this:

T1 to T2 — approval latency. This is the binding constraint in most teams, and it is usually not one slow approver. It is queue time: requests waiting for someone who approves in batches on Friday, or a chain where each hop adds a fresh wait. If this gap is more than half your total cycle, everything else on this page is a distraction until you fix it.

T2 to T3 — document creation and dispatch. The demo stage. If this gap is measured in minutes, automating it will not change your cycle time. If it is measured in days, something structural is wrong — usually one person is the only route to the vendor, or POs are batched into a weekly send.

T3 to T4 — vendor acknowledgement. Not yours to automate, but worth measuring, because a long or missing acknowledgement gap is where duplicate orders come from. If you cannot tell whether a vendor received the PO, someone eventually re-sends it.

There is also a gap you cannot get from the system: the time between somebody needing something and a requisition existing at all. If your requisition intake is a form people find annoying, that gap can be the largest of the lot and it is invisible in every report. The only way to measure it is to ask five requesters when they first knew they needed the item.

The four stages, ordered by where delay usually sits

1. Approval routing — usually the constraint

What it does. Rules-based routing sends each request to the right approver by amount, department and category, tracks response time, and escalates to a delegate when an approval stalls past a threshold.

The signal this is your constraint: T1 to T2 is more than half of total cycle time, and the distribution has a long tail — most requests approved in a day, a minority taking a week or more. A long tail means queue time, not decision time.

What to do if it is: simplify the thresholds before you automate them. Automating a four-tier approval matrix encodes four tiers of waiting into software. Most teams operate well on three: auto-approve low-value repeat orders against a pre-approved vendor and category, single approval in the middle band, multi-level only for genuine commitments. Deciding where those bands sit is a finance decision that takes an afternoon and does more for cycle time than any product.

What to do if it is not: leave it alone. An approval chain that already clears in under a day is not costing you anything worth a project.

2. Requisition intake — the invisible one

What it does. Replaces free-text email requests with structured forms that vary by spend category, so budget code, cost centre and vendor arrive complete on the first submission instead of after two rounds of questions.

The signal this is your constraint: requesters routinely bypass the process, or a large share of requisitions get sent back for missing information. Both show up as rework rather than as cycle time, which is why this stage is under-diagnosed. Count how many requisitions in your sample were amended after submission.

What to do if it is: fix the form before you buy anything. Most intake friction is field count, and every field you require from someone who does not know the answer turns a two-minute task into a two-day one.

What to do if it is not: an intake process with few amendments needs no software.

3. PO creation and dispatch — the stage that demos best

What it does. Generates the formatted purchase order from the approved requisition, pulling legal entity, payment terms and vendor details from master data, assigns a number, writes to the audit trail, and sends by email, EDI or portal.

The signal this is your constraint: T2 to T3 measured in days rather than minutes. That usually means batching or a single-person bottleneck rather than slow typing.

What to do if it is: automate it, and clean your vendor master first. Automation applied to duplicate vendor records and stale payment terms produces correct-looking POs sent to the wrong entity, which is a more expensive error than the one you were fixing.

What to do if it is not — and it usually is not: buy it anyway if it comes bundled, but do not sequence the project around it and do not build the business case on it. The genuine value here is not speed, it is that the PO now exists as structured data, which is what stage four needs.

4. Receipt and matching — where the savings actually are

What it does. Compares the purchase order, the goods receipt and the invoice, releases the ones that agree within tolerance, and raises the rest as exceptions.

The signal this is your constraint: your AP team spends more time resolving match exceptions than purchasing spends creating POs. For most teams above modest volume, it does.

What to do if it is: this is where PO automation pays for itself, and the payoff comes from PO data quality rather than PO speed. A structured PO with resolvable item codes is what makes three-way matching work; a PDF emailed to a vendor is not. Before configuring tolerances, read the exception taxonomy in PO matching exceptions handling — the distinction between an exception waiting on a signature and one waiting on a fact decides whether a tolerance or a routing rule is the right fix.

What to do if it is not: you probably have low PO volume, which is the case in the next section.

Costing it from your own numbers

The previous version of this page opened with a per-PO processing cost attributed to Deloitte. That figure was cited to a vendor blog post quoting Deloitte rather than to any Deloitte publication, and we could not locate the primary source. It has been removed rather than re-cited, along with the other second-hand benchmarks the page carried. A number you cannot trace is not a business case; it is a decoration on one.

Your own number is more useful anyway, and it takes about twenty minutes:

Count POs raised in a representative month.
Time one PO end to end, for the stage you are considering automating only. Include the chase: the messages asking an approver to look, the call to check whether the vendor got it. Chase time is usually larger than handling time and is never in anyone's estimate.
Multiply by a blended hourly cost for the people doing it — salary plus employer costs divided by roughly 1,800 working hours.
Multiply by monthly volume, then by twelve.

That gives an annual cost for one stage. Do it for the two stages with the largest gaps and compare. If the arithmetic does not justify a project, that is a finding rather than a failed exercise, and a better place to learn it than after implementation.

Two costs sit outside the calculation and are worth counting separately in your own data: purchases made off-contract because the process is too slow, and duplicate orders raised when nobody could tell whether the first PO reached the vendor.

When PO automation is the wrong project

The honest case: if your PO volume is low, invoice-side automation pays back faster.

The reason is structural. PO automation earns its return per purchase order, so its payback scales with PO count. Invoice automation earns per invoice, and invoice volume is almost always higher — every PO eventually produces at least one invoice, and a great deal of spend arrives as an invoice with no PO behind it at all: utilities, subscriptions, professional fees, freight.

So the test is a ratio rather than a threshold. Pull last quarter's counts. If invoices substantially outnumber purchase orders — and in most finance teams they do — the same effort spent on invoice processing automation and invoice approval workflow touches more transactions per unit of work. Start there, and come back to purchasing once invoice handling is no longer the queue.

Three other cases where the project is wrong for now:

Your vendor master is not clean. Automation amplifies bad master data. Deduplicate first; this is a prerequisite, not a phase.
Approval policy is genuinely unsettled. Encoding a matrix that is still being argued about produces software you will reconfigure in a quarter.
The constraint is a single person's availability. No workflow tool fixes an approval chain that routes everything through one director who travels.

Purchasing and payables are one cycle, which is the scale the sequencing argument finally makes sense at: a purchase order is worth automating largely because of what it does for the invoice that follows it. That end-to-end view is in procure-to-pay automation, and the AP automation business case framework covers the numbers you will need for an approval.

What to ask the vendor about your stage

Take your measured constraint into the demo and ask them to prove that specific thing.

If your constraint is	Ask the vendor to demonstrate
Approval latency	Escalation on a stalled approval, and the report showing time-in-queue per approver
Requisition intake	A category-specific form, and what happens when a requester does not know a required field
Creation and dispatch	Vendor acknowledgement capture — how you know the PO arrived
Matching exceptions	Tolerance configuration per exception type and category, not one global percentage

If the answer to any of these is a roadmap item, that is useful information about which stage the product is actually built for.

Where Ken fits

Ken works the payables side of the cycle: invoices arrive, get matched against the purchase order and receipt, and route to the person who can resolve what does not agree. That means Ken benefits directly from structured PO data and is largely indifferent to how fast your POs are created.

Which is the honest version of the advice on this page. If your purchasing cycle is slow because approvals queue, a payables product will not fix it, and neither will the PO creation module that demos so well. Measure the gaps first, and let the largest one choose the project.

FAQ

What is purchase order process automation?

Software that handles the purchase order lifecycle without manual re-keying at each step: structured requisition intake, rules-based approval routing with escalation, PO generation from the approved request, electronic dispatch, and matching of the PO against the goods receipt and invoice. In practice these four stages are bought and implemented separately, and the order you do them in matters more than which product you choose.

Which stage of PO automation should I automate first?

The stage with the largest measured gap in your own cycle. Capture four timestamps — requisition submitted, final approval recorded, PO dispatched, vendor acknowledgement — over a 60 to 90 day sample. In most teams the submission-to-approval gap dominates, which makes approval routing the first project. PO creation and dispatch demos best but is usually already the shortest stage, so automating it first changes the cycle very little.

How much does PO automation save?

Calculate it from your own volume rather than a published per-PO benchmark. Count POs in a representative month, time one end to end for the stage in question including chase time, multiply by a blended hourly cost, then by monthly volume and twelve. We removed the industry cost figures this page previously quoted because they were second-hand citations we could not trace to a primary source.

When is PO automation the wrong project?

When invoice volume substantially exceeds PO volume, which is the usual case — invoice-side automation then touches more transactions for the same effort and pays back sooner. Also when your vendor master has duplicates, when approval policy is still being argued about, or when the real constraint is one person's availability rather than any process step.

How does PO automation connect to AP automation?

The purchase order is the reference document the invoice is checked against. Structured PO data is what makes three-way matching possible; a PDF emailed to a vendor is not. This is why the payoff from PO automation tends to appear in payables rather than in purchasing, and why the matching stage is usually where the savings actually sit.

Purchase Order Process Automation: Which Stage to Automate First, and Why the Usual Order Is Wrong