Purchase order automation for the POs you receive and the POs you send
Purchase order automation means two different jobs. Sellers want the POs their customers send turned into sales orders without retyping. Buyers want the POs they send to suppliers confirmed and chased without a spreadsheet. This page covers both, starting with the one we build first.
Incoming customer POs: from inbox to sales order
For a distributor, the incoming side is where the hours go. Each customer PO arrives in the orders inbox as a PDF, a scan, a spreadsheet or a few lines in an email. Someone opens it, works out which account it belongs to, translates the customer's part numbers into yours, checks prices and keys the sales order.
Automated, the same work runs in this order:
- Intake. The agent watches the shared orders inbox, including faxes that arrive as email.
- Reading. It reads the PO: customer, PO number, dates, addresses and every line, flagging anything it is unsure of.
- Matching. It matches the customer account and maps their codes to your SKUs.
- Checks. It prices each line from your ERP and checks stock, flagging differences.
- Draft. It writes a draft sales order, or an import file, with the original beside it.
- Approval. A person approves, and the order becomes real in the ERP.
The matching step is covered in detail in sales order automation. To see the reading step on one of your own POs, use the free PO reader.
Outgoing POs: confirmations and chasing
On the buying side, raising the PO is rarely the problem. ERPs do that well. The time goes on what comes back: order acknowledgements that change a quantity, a price that is different from the quote, a delivery date that slips by a week, and suppliers who never confirm at all.
Automating it looks like this. The agent reads each supplier confirmation as it arrives and compares quantities, prices and dates with the PO you sent. Lines that match are marked confirmed. Lines that differ are flagged for a buyer with both values side by side. POs with no confirmation after a set number of days go on a chase list, so nobody discovers a missing order on the day it was due.
Where we are: we start with incoming customer orders. The same reading engine applies to supplier confirmations. If that is your bigger problem, say so in the shadow test form.
PO automation without EDI
EDI is the traditional answer to purchase order automation, and for a few very large trading partners it works. Each link is a project: message formats agreed, mappings built and tested on both sides, and often a provider in the middle. That effort pays off with a customer who sends hundreds of orders a week.
Most of your customers are not that customer. A council, a builder or a regional manufacturer will never set up EDI with each supplier. Their procurement system emails a PDF, and that is what you get. PO automation that only works through EDI leaves those orders exactly where they are: in the inbox, waiting to be typed.
Reading the PDF is the practical route. Nothing changes for the customer, and the order still ends up as structured data in your ERP.
What to check in any PO automation tool
Whichever tool you look at, ask these questions and ask to see the answers on your own documents:
- Formats. Does it read PDFs, scans, photos, spreadsheets and plain email, or only one clean layout per customer?
- Uncertainty. What does it do when it is unsure? A tool that never says it is unsure makes you check everything.
- Approval. Where does a person approve, and can anything reach the ERP without that approval?
- Systems. Which ERPs does it write to, and how: a supported connection, an import file, or keystrokes?
- Testing. Will they run a month of your real orders and show you the share of lines right with no edit?
For the options side by side, see order entry automation. Quote requests are their own problem; see RFQ automation.
Purchase order automation questions
Is purchase order automation for buyers or sellers?
Both, and they are different jobs. Sellers automate the POs customers send them, turning each into a sales order. Buyers automate the POs they send suppliers: raising them, then reading confirmations and chasing the ones that do not come back. Most tools do one or the other.
What is PO automation?
PO automation is software that handles purchase orders without retyping. On the selling side it reads incoming customer POs and drafts sales orders. On the buying side it matches supplier confirmations and invoices to the POs you raised and flags the differences.
Can it chase supplier confirmations?
The same reading engine applies to supplier confirmations: it can read them and compare quantities, prices and dates with your PO. We start with incoming customer orders. If supplier confirmations are your bigger problem, say so in the shadow test form.
Do we need EDI?
No. EDI suits a handful of very large trading partners. For everyone else, purchase orders keep arriving as emailed PDFs and spreadsheets, and an agent reads them as they are, with nothing for the customer to set up.
Does it work with emailed PDFs?
Yes. Emailed PDFs from customers' procurement systems are the most common case, alongside scans, spreadsheets and orders typed into the body of an email. You can try one in the free PO reader.
See it on your own orders
A free shadow test runs a month of your emailed orders through the agent. Read-only, about a week.