Purchase Order Automation Doesn't End at "Send"
You raised a purchase order for 400 units at EUR 18.50, delivery on the 12th. Your supplier replied to the buyer's email: they can do 250 now at EUR 19.20 and the rest in September. The buyer read it, said "fine", and moved on.
Nobody updated the PO. Six weeks later the invoice arrives at EUR 19.20 and matching rejects it, finance emails procurement asking why the price is wrong, and the answer is sitting in someone's inbox from July.
That is purchase order automation's actual problem, and almost nothing sold under that name addresses it.
What the tools automate, and where they stop
Search the term and page one is procurement platforms: Precoro, Kissflow, Order.co, plus the PO modules in Xero and Sage. They are competent at what they do, and what they do is the front half of the lifecycle.
| Stage | Automated by most PO tools? |
|---|---|
| Raise a PO from a request | Yes |
| Route for approval, chase approvers | Yes |
| Send to the supplier, log it | Yes |
| Capture the supplier's acknowledgement | Rarely |
| Reconcile a changed price, quantity or date | No |
| Record partial and over-deliveries | Partly, if you use the receipts module |
| Close the PO, or flag that it never closed | No |
The line falls exactly where the process leaves your building. Everything upstream of "send" happens inside one system with your own staff, so it automates cleanly. Everything downstream depends on a supplier replying in prose, by email, on their schedule, and that is the part that got left to a person.
You will also meet a figure claiming PO automation saves 45–65% of operational costs. It traces back to a consultancy report, gets repeated by every vendor in the category, and is attached to no methodology you can inspect. Treat it the way you would treat any number a seller quotes about their own product, and measure your own baseline instead. The honest version of the benefit is narrower and easier to verify: fewer invoice exceptions, and an open-PO list you can actually accrue from.
"Sent" is not "confirmed"
A purchase order is an offer. It becomes a commitment when the supplier accepts it, and suppliers frequently accept with amendments.
Four things come back changed, in rough order of frequency:
- The date. The most common by a distance, and the one with knock-on effects for anyone planning around the delivery.
- The price. Their system has a different price than your last quote, or a surcharge was added, or your agreed price expired and nobody flagged the renewal.
- The quantity. Partial availability, a minimum order quantity you missed, or a pack size that does not divide the way you assumed.
- The item. A substitution, an equivalent, a superseded part number.
Each of these is fine on its own. The damage comes from where the reply lands: in one buyer's personal mailbox, as prose, in a thread with eleven other messages. Procurement knows. Planning, goods-in and finance do not, and they carry on working from the original PO.
This is the same inbox triage problem that shows up everywhere in operations, with one specific twist that makes it tractable: the message almost always names the PO number. That gives you a reliable key to attach the reply to the right record, which is exactly what makes the extraction worth automating rather than reading by hand.
The right behaviour when a supplier acknowledges with changes is not to auto-accept it. It is to detect the change, quantify it against what you ordered, and put it in front of whoever owns that spend with both versions side by side. A EUR 0.70 unit price rise on 400 units is EUR 280 and probably approves itself; the same rise on a 40,000-unit annual commitment is a conversation.
The open-PO tail
An open PO is one issued but not yet fully received, invoiced and reconciled. Some are open because they should be. The rest are the problem.
The recurring reasons a PO never closes:
- Part-delivered, remainder quietly cancelled by phone or never shipped
- Short-shipped within tolerance, so nobody chased the balance, but the line stayed open
- The supplier invoiced against a different PO number and the original was left dangling
- The order was cancelled in a conversation and in no system
- Over-delivery accepted, so the receipt exceeds the PO and the reconciliation was skipped
None of these break anything on the day. They accumulate. Eventually you have a list where a real share of the value is fictional, and the list is the thing your finance team uses to accrue committed spend at month-end close. An accrual built on stale POs is a wrong number that takes hours to correct and gets corrected again next month.
The fix is unglamorous: age the open list, and treat age as a signal rather than a fact of life. Any PO past its confirmed delivery date with nothing received is a question for a supplier. Any PO fully received and invoiced but still open is a housekeeping item that should close itself. Neither needs judgment; both need somebody to look, which is why neither happens.
Why this surfaces in finance, not procurement
Procurement rarely feels this. The buyer resolved the change in the moment and considers it handled. The cost lands two systems downstream.
Invoice exceptions. 3-way matching compares invoice against PO against receipt. A PO carrying a price the supplier never agreed to produces a mismatch on every invoice raised against it, forever. Teams measure their touchless rate, conclude that matching is hard, and invest in better matching, when a meaningful slice of their exception queue was manufactured upstream by a purchase order nobody amended. Better matching cannot fix a wrong reference document; it can only route it to a human faster.
Accruals and committed spend. Covered above, and the reason this eventually becomes a finance project rather than a procurement one.
Duplicate ordering. When the open list is not trusted, people re-order rather than check. This is the failure mode that costs actual cash rather than time.
Worth stating plainly: if your accounts payable exception rate is stubbornly high after you have automated extraction and matching, look upstream before you buy anything else. Sample twenty exceptions and find out how many trace back to a PO that was never updated after the supplier replied. That number decides whether your next project is in AP at all.
What a small team should automate
The procurement suites assume a department: category managers, contract catalogues, supplier onboarding portals, spend taxonomies. If your purchasing is two people and an ERP, that machinery is overhead you will pay for and not use. The useful version has five parts.
Raise from the request, not from a blank form. Whatever the request arrives as — an email, a Slack message, a form — becomes a draft PO with supplier, item, quantity and price pre-filled from the last order to that supplier. The person confirms rather than types.
Route the approval with the context attached. The approver gets the budget line, what this supplier charged last time, and the delta. Approval latency is a chasing problem, not a decision problem: approvals sit for days because the approver would need to go and look things up. Give them the lookup and it takes seconds. Keep the decision itself human above a threshold you set, the same guardrail that applies anywhere agents touch committed money.
Read the acknowledgement. Watch the mailbox for replies naming a PO number, extract confirmed price, quantity and date, compare to what was ordered, update the PO when it matches and raise a variance when it does not. This is the single highest-value piece and the one no tool in the category does well.
Record receipts against the line, including partials. A receipt is not a binary. Part-deliveries need to record what actually arrived so the outstanding balance is real, which is what makes both matching and chasing possible later.
Close what should be closed, chase what should not. Fully received and invoiced closes automatically. Past confirmed date with nothing received generates a supplier chase. Everything else ages visibly on a list somebody owns.
Deliberately not on the list: a supplier portal. Portals fail at SMB scale for the same reason B2B ordering portals fail — your suppliers will not log into yours, and asking them to is how these projects die. Meet the email where it is.
If your POs live in an ERP with no usable API, that is the legacy integration problem, and it has the same answers here as on the invoice side.
Measure three things
- Acknowledgement capture rate. What share of POs have a supplier confirmation recorded against them, with the confirmed date and price. Most teams starting out find this is effectively zero, which makes it the easiest number to move and the one everything else depends on.
- Invoice exceptions traceable to a stale PO. The link between this work and money. If it is high, you have found your next project; if it drops after, you have your proof.
- Open POs past confirmed delivery date, by value and age. The health of the list you accrue from.
Not on the list: POs processed per day, or approval cycle time on its own. Cycle time improves the moment you start chasing approvers automatically, which feels like progress and tells you nothing about whether the orders were right.
Start here
Pull every PO raised in the last quarter and answer one question for each: is there a recorded supplier confirmation, and does it match what was ordered?
Most teams cannot answer it at all, which is itself the finding. For the ones you can check, expect a meaningful minority to differ from the PO on price or date, and then trace those forward to see how many produced an invoice exception, a duplicate order, or a wrong accrual.
That exercise costs an afternoon and usually reframes the project. The problem was never raising purchase orders faster. It was that a purchase order stops being true the moment a supplier replies, and nothing in the process notices.
Oido runs the whole PO lifecycle for small finance and buying teams: drafting orders from requests in email or Slack with supplier history pre-filled, routing approvals with the budget line and price delta attached, reading supplier acknowledgements out of the mailbox and reconciling them against the open order, raising variances to a named person instead of accepting them silently, and keeping the open-PO list honest so 3-way matching and month-end accruals have something real to work from. See how it fits finance teams, or send us a quarter of your POs and we will tell you how many were confirmed as ordered.
Frequently asked questions
What is purchase order automation?
Software that handles the purchase order lifecycle without manual retyping: raising the PO from a request, routing it for approval, sending it to the supplier, capturing what the supplier confirms back, recording receipts, and closing the PO when it is fully delivered and invoiced. Most tools sold under this name only automate the first three steps.
What is a purchase order acknowledgement?
The supplier's reply confirming whether they can fulfil the order as issued. It matters because it frequently is not a plain yes: suppliers acknowledge with a different price, a later delivery date, a split shipment or a substituted item. Until that reply is captured against the PO, your system holds a commitment the supplier never agreed to.
Why do open purchase orders pile up?
Because closing a PO is nobody's job. A PO stays open until it is fully received, invoiced and reconciled, and the ones that stall are usually part-delivered, short-shipped, or cancelled by phone without anyone updating the record. Nothing breaks immediately, so the list grows until someone needs it for a month-end accrual and discovers it cannot be trusted.
Do small businesses need purchase order automation?
You need it when informal buying stops being visible: when you cannot answer what you have committed to spend this quarter without opening a spreadsheet and an inbox. That threshold usually arrives well before anyone buys procurement software, which is why so much of this work is done manually by one person who has quietly become the system.
How does PO automation affect 3-way matching?
It decides whether matching can work at all. Matching compares the invoice to the PO and the receipt, so a PO carrying a price the supplier never agreed to guarantees a mismatch on every invoice against it. A large share of what finance teams treat as invoice exceptions were created weeks earlier by a purchase order nobody updated.
Should PO approval be automated?
Routing and chasing should be. The approval decision itself should stay with a person above a threshold you set, because it is a commitment of company money. The useful automation is making the approval arrive with the budget line, the supplier's history and the price comparison attached, so the decision takes thirty seconds instead of sitting for two days.
Can you automate purchase orders without a procurement suite?
Yes, and most SMBs should. The suites are built for procurement departments with category managers and contract catalogues. A small team needs the PO raised from the request, approved with a clear trail, sent, the supplier's reply read and reconciled against it, and the open list kept honest. That is a workflow on top of the ERP or accounting system you already run.