Purchase order system and automation: requisitions, approvals and PO matching

A purchase order system records what you plan to buy, gets the spend approved before you commit to it, and gives accounts payable a document to check the supplier's invoice against. Automation can take intake and routing, then draft the PO from the approved request. At the far end it can match the invoice. Buyers keep supplier choice, negotiation and any change that alters the commitment.

This guide covers the PO itself, from the request to the close. For the wider cycle that includes vendor onboarding and payment, see our procure to pay process guide.

#The life of a purchase order

A PO moves through six stages, and each one leaves a record you can measure.

Most of the trouble starts at stage one. A requisition that says "software for the design team, about $9k" can't be turned into a PO without a supplier, a cost center and a quote. Good intake asks for those up front, so a clerk isn't chasing the requester three days later.

#PO types, and which one fits

One ERP can issue several kinds of PO. Picking the wrong type is a common source of exceptions later.

We lean toward fewer PO types and tighter rules. Blanket POs in particular need a ceiling, an end date and a named owner, or they become a way around the approval limits.

#Approval rules for purchase orders

Approve the spend before the commitment. Approval at invoice time only checks a bill, because the money is already owed.

A workable rule set uses four inputs: amount band, cost center, category and supplier status. For example, a company might let a department head approve up to a set limit, require finance for anything above it, and always add IT review for software and security review for anything that touches customer data. New suppliers get a second approver until they have a payment history. Those values are policy decisions, so we don't suggest numbers. Write the matrix down, give it one owner, and have the system enforce it. Memory won't.

Budget checks belong here too. If the cost center has $3,000 left and the PO is for $8,000, the approver should see that on the request, not discover it at month end.

#Where purchase order automation earns its place

Four jobs repeat often enough to automate well.

Intake comes first. Requests arrive as emails, chat messages and forms. A model can read an email like "need 40 safety vests for the Leeds site, same supplier as last time" and draft a requisition with the supplier, quantity and last price pulled from previous POs. The requester confirms it.

Routing needs no AI at all. Once the requisition is complete, rules decide who approves it, using an agreed matrix and a workflow engine that handles delegation and reminders.

Matching happens at the other end. When the invoice arrives, the system finds the PO, maps lines and applies tolerances. Our three-way matching guide covers tolerances and receipts in detail.

The fourth job reaches back before the request exists. Some teams draft POs from inventory signals, such as stock falling under a reorder point. We have a use case for drafting purchase orders from low-stock signals, and the buyer reviews each draft before it goes out.

#Exceptions an agent can triage, and what needs a buyer

Exceptions are where PO processing stalls. An agent can sort and prepare them. It shouldn't settle the ones that change what you owe.

Non-PO invoices are the messiest row. Some are legitimate: rent, utilities, bank fees and professional retainers rarely have POs. The problem is invoices for goods and services that should have had one. Write a short list of categories where non-PO is fine, and treat everything else as a policy breach. The agent applies the list. A person decides what happens to the exceptions, because paying a retroactive invoice teaches the business that skipping the PO works.

Key point: A PO system only controls the spend that goes through it. Measure how much of your invoice volume arrives with a valid PO number before you tune matching. A low coverage rate points at purchasing behavior, and no amount of AP tuning will fix it.

#ERP notes

The mechanics differ by system, so check each vendor's current documentation before you design anything.

QuickBooks Online has purchase orders, but Intuit states they are only available on the Plus and Advanced plans, and a PO there is closed by linking it to a bill or expense. There's no goods receipt note (GRN) or similar record, so receiving confirmation has to come from somewhere else. Our QuickBooks Online integration page covers how we handle that gap. NetSuite, SAP and Dynamics 365 Business Central treat purchase orders and receipts as native records, which makes full three-way matching possible without extra tooling.

Whichever ERP you use, write the PO number, the approver and the approval timestamp onto the record, and attach the supplier's quote. An auditor will ask for all three.

#A starting checklist

1. Pull a year of invoices and tag each as PO-backed, non-PO allowed or non-PO breach. The split tells you where to start.
2. Write the PO policy on one page: which spend needs a PO, the approval bands, the categories that are exempt.
3. Define the minimum a requisition must contain: supplier, quantity or scope, cost center, quote.
4. Choose the PO types you will use and set a ceiling and end date on every blanket PO.
5. Decide who owns receipts for goods, and who confirms milestones for services.
6. Run intake and routing first. Add matching and exception triage once the PO data is clean.
7. Track PO coverage, requisition cycle time, price variance at match and the age of open POs each month.

#When this isn't worth automating

If you raise a few dozen POs a month with one or two approvers, the workflow inside your accounting software is probably enough. The gains show up with volume, many cost centers, several approvers or a mix of ERPs. We'd rather tell you that on a first call than build something you don't need.

If your POs are late, bypassed or full of exceptions, book a strategy call. Bring a sample of POs and invoices and we'll show you how many would match cleanly today.

#Frequently asked questions

#What is a purchase order system?

It's the software and process a company uses to request, approve, issue and track purchase orders. It links each order to the budget, the supplier, the receipt and the supplier's invoice. A good one makes it hard to commit spend without approval and easy to see what's still open.

#What is the difference between a purchase requisition and a purchase order?

A requisition is an internal request to buy something, usually raised by the person who needs it. A purchase order is the formal commitment sent to the supplier, usually issued by a buyer after the requisition is approved. Some small businesses skip the requisition and raise POs directly.

#What does purchase order processing involve?

It covers receiving the request, approving it, creating and sending the PO, recording receipt of goods or services, and matching the supplier's invoice to both. Each step should leave a record. Automation helps most at intake, routing and invoice matching.

#Do you need a purchase order for every purchase?

No. Utilities, rent, bank fees and small incidental purchases often run without one. Set a written policy that lists the exempt categories and a value threshold, and send everything else through a PO.

#Can AI create purchase orders?

It can draft them. A model can read a request, find the supplier and previous price, and prepare the PO for a buyer to review. We don't let an agent issue POs on its own above a policy threshold, since a PO is a financial commitment.