Ask five people what a purchase order is and you'll hear some version of "the form you fill out before you buy something." That answer explains why so many companies send suppliers POs that can't be matched or enforced and cause administrative issues.
So, what is a PO? A purchase order (PO) is a document a buyer issues to a supplier to request goods or services at stated quantities, prices and terms. Once the supplier accepts it, it becomes a binding agreement. Inside your ERP, it also becomes a financial commitment against your budget.
This ProcureTech Foundations guide covers what that definition leaves out. You'll see what a PO holds, why your PO number format matters less than you think, when a PO becomes legally binding, and the PO types you'll meet in an ERP. It includes a 16-field checklist to audit the PO your suppliers receive.
What is a PO? The 30-second answer
PO stands for purchase order. A purchase order is a commercial document issued by a buyer to a seller. It lists the goods or services requested, the quantities, the agreed prices, and the terms for delivery and payment. It authorizes the purchase on the buyer's side and, once accepted by the vendor, commits both parties to the transaction.
PO meaning (and the other things "PO" stands for)
In business, "PO" almost always means purchase order. If a supplier or customer asked you for a "PO number," that's the one they mean.
Outside procurement you'll also run into post office, product owner (in agile software teams) and probation officer. None of them will get your invoice paid.
What is a purchase order, really? A record and a document
Most definitions stop at "document." In any company running an ERP system or a procure-to-pay suite, a purchase order lives two lives at once. It's a record in your system and a document (probably PDF) in your supplier's inbox, and the two rarely contain the same information.
For more sophisticated and integrated supplier relationships, your purchase orders may be transmitted electronically from ERP to ERP through something like EDI (Electronic Data Interchange).
The record: header, lines and a budget commitment
Inside SAP, Oracle, Coupa or whatever you run, a PO has two layers.
The header holds everything that applies to the whole order:
The supplier and the buying legal entity
Currency, payment terms and Incoterms
The buyer, the creation date and the approval status
The line items hold what you're buying:
The item or material code and its description
Quantity, unit of measure and unit price
Delivery date and ship-to location
Account assignment: the cost center, project or GL account the spend lands on
Account assignment is where finance gets involved. Once a PO is approved, most ERPs record a commitment (the public sector calls it an encumbrance) against the budget. The money hasn't left the building yet, but it's no longer available to spend.
That's why POs matter to finance as much as to procurement. It's also why POs that never get closed make every budget report wrong. More on that below.
The document: what your supplier actually sees
A supplier typically never logs into your ERP. They get an output: a PDF by email, a cXML order through a network like SAP Business Network or the Coupa Supplier Portal, or an EDI 850 if they're a larger trading partner.
Whatever that output contains is the PO, as far as the supplier is concerned. If your Incoterms location sits in a header field that never prints, the supplier doesn't have it. If the unit of measure lives in the record but not on the PDF, you'll find out when 10 cases arrive as 10 units.
On most projects we've worked on, the team spends months configuring the purchasing workflow in the system but only a few days on the output template, usually the week before go-live. But that PDF template is the only part the supplier ever sees.
The purchase order form checklist: does yours pass?
Pull up the last PO your team sent a supplier. Skip the screen in your ERP and open the PDF or message the supplier received. Then check it against these 16 fields.
Click the image to download the poster.
Identity and control
A clean PDF (or equivalent) the supplier can open and read. A record trapped in your ERP doesn't count.
The PO number on the face of the document. Suppliers quote it back on every invoice. No number, no three-way match.
A revision or version number. After a change order, everyone needs to know which PO is live.
A buyer contact for questions. Leave it off and the supplier guesses, or calls the wrong person.
Logistics (for goods)
Ship-To, Deliver-To and Bill-To addresses. Collapse them and goods land at the wrong dock while invoices land at the wrong desk.
A requested delivery date. Without one, there's nothing to hold the supplier to.
Incoterms with the named place. "FOB" means nothing without a location. Incoterms set who pays freight and where risk transfers.
Commercial lines
Unit of measure: each vs. case vs. pack vs. kg. Otherwise you order 10 "cases" and receive 10 "units."
Quantity, order unit (if different from the UoM), unit price and currency. An unlabeled "1,000" invites a dispute across borders and entities.
Supplier part number mapped to your item or material code. Both sides need to mean the same thing.
Expected tax treatment and tax IDs. That means tax codes or amounts, exemption status and your registration number. Get this wrong and AP jams.
Fixed-price vs. time and materials lines (for services). An "hours × hourly rate" line reads nothing like a fixed deliverable, and your form has to carry both.
Terms and communication
A contract reference. Without it, there's no link to the overarching terms you negotiated.
Payment terms and terms and conditions. Payment terms start the clock on cash. T&Cs set the rules when something goes wrong.
The form in the supplier's language. A PO your supplier can't read is a PO that gets misread.
Internal notes kept separate from external notes. Mix them and you either leak context to the supplier or bury the instructions they need.
Not every field applies to every purchase, so adapt the list to your context. It isn't exhaustive either: regulated or cross-border purchases may need more.
Want this as a printable poster with the yes/no boxes? Download the Purchase Order Form Checklist and run it against the last PO your team sent.
The PO number, and why "smart" numbering is a bad idea
A PO number is the unique identifier your system assigns to each purchase order. The supplier puts it on the invoice, the receiving dock references it on the delivery for goods receipt, and Accounts Payable (Finance) uses it to match all three.
Some guides recommend building meaning into the number: the year, the category, even the quantity ordered. Something like PO2023-ELEC-100.
Please don't.
The fields on a PO change. A change order bumps the quantity from 100 to 120, a line moves to a different category, or the order crosses into a new fiscal year. The number stays fixed, so within a few months your "smart" number is wrong.
People also start trusting the number instead of the data. Someone filters a report on "ELEC" in the PO number and misses every electronics PO a buyer created with a typo.
Let the ERP hand out plain sequential numbers automatically from a number range per document type. SAP's default range for standard POs starts at 4500000000. That's enough intelligence for a PO number: you can tell a PO from an invoice at a glance. Everything else belongs in fields you can report on.
Is a purchase order legally binding?
Short answer: a PO is an offer. It becomes binding when the supplier accepts it.
Acceptance can take several forms: a signed acknowledgment, an order confirmation, or the supplier starting to ship or perform the work. Until then, you can usually cancel or change the PO without much drama.
(We're not lawyers, and your legal team will have opinions on your specific jurisdiction. Ask them to confirm.)
Offer, acceptance and the battle of the forms
Your PO probably carries standard terms and conditions, printed on the back or linked in the footer. Your supplier's order acknowledgment carries its own. They almost never agree on liability, warranties or payment terms.
So whose terms apply? That's the battle of the forms, and the answer depends on where you are and what you're buying. In the US, the Uniform Commercial Code covers goods and often knocks out the conflicting terms, replacing them with default rules. Other jurisdictions tend to favor whoever fired the "last shot."
Either way, you don't want a dispute settled by whose boilerplate showed up last. The practical fix is a master agreement that states it takes precedence over any PO or acknowledgment terms, with every PO referencing that agreement. That's the contract reference field on the checklist.
PO vs. contract: when you need both
A PO alone works fine for:
One-time purchases of standard goods
Low-risk, low-value services with a clear deliverable
Catalog buying against pre-negotiated prices
You need a contract behind the PO when:
The work involves liability, IP, data access or safety risk
Spend recurs over months or years
The supplier's standard terms are unacceptable and you need negotiated ones
In that setup, the contract sets the rules and each PO releases spend against them.
The purchase order lifecycle, from requisition to closed PO
Every ERP draws this differently, but the sequence holds:
Someone identifies a need.
They raise a purchase requisition: an internal request to buy, with no supplier commitment yet.
The requisition is approved against budget and your delegation of authority.
A buyer creates the PO, or the system converts it automatically from an approved catalog or contract requisition.
The PO goes to the supplier, who acknowledges it.
Someone records a goods receipt or service entry to confirm what arrived or was performed.
The invoice arrives and is compared against the PO and the receipt: the three-way match. (If this is where your process breaks, start with AP Automation: Where to Start.)
Payment goes out on the PO's payment terms.
The PO is closed, releasing any leftover commitment.
Step 9 is often the one that gets skipped, causing issues in financial reporting.
Change orders and the open-PO graveyard
POs change after they're issued. Quantities go up, delivery dates slip, prices get corrected. Each change should create a new revision, and increases beyond your tolerance should go back through approval.
Then there are the POs that never close. Someone receives 95 of 100 units, the supplier never ships the last 5, and nobody closes the line. Multiply that by a few thousand POs and your open commitments are fiction. Budget owners see money tied up that will never be spent, and every year-end turns into a cleanup project.
The fix is boring: auto-close rules. Close a line when the final invoice posts, or after a set number of days with no activity. Pick a rule, configure it, and stop cleaning up by hand every December.
Types of purchase orders you'll meet in an ERP
Each vendor names these documents differently, so it helps to sort them by what they do:
Standard PO: a one-time order for specific items, quantities, prices and dates. This is what most people picture.
Blanket PO: a single PO covering repeated purchases from one supplier over a period, capped at a total value. Suppliers invoice against it many times. Coupa and many mid-market suites call it exactly that. SAP's closest equivalent is the framework order, and in Oracle you'd use a blanket purchase agreement with releases.
Contract or agreement PO: it carries negotiated terms but no specific items. Standard POs then reference it. Oracle calls it a contract purchase agreement, and SAP handles the same idea through outline agreements.
Planned PO or scheduling agreement: a long-term commitment to one supplier, with deliveries called off on a schedule. It's common in direct materials.
Limit or service PO: a value cap for services where you can't predict quantities upfront, like repairs or ad hoc consulting. SAP's limit items do this job.
When a vendor demos their "PO types," ask what each document does. The label on the screen tells you very little. And watch your blanket POs: once they become a catch-all bucket for anything a requester can't be bothered to raise properly, you've lost the visibility the PO was supposed to give you.
These can amount to blank checks… which defeats the purpose of a PO.
PO vs. requisition vs. sales order vs. invoice
These four documents are easy to confuse. Here's who creates each one and what it does:
Document | Created by | What it does | Binding? |
|---|---|---|---|
Purchase requisition | Requester (internal) | Asks for permission to buy | No, internal only |
Purchase order | Buyer | Offers to buy on stated terms | Once the supplier accepts |
Sales order | Supplier | Records your order in the supplier's system | Supplier-side record |
Invoice | Supplier | Requests payment | Matched against PO and receipt before payment |
Your PO becomes their sales order. Their invoice points back to your PO number. All four describe the same transaction from different seats.
When a PO is the wrong tool
Some spend doesn't belong on a PO. Forcing one onto it adds processing cost and annoys requesters without adding control.
POs are a poor fit for:
Low-value purchases that cost more to process through a PO than the goods themselves. A P-card handles these better.
Recurring bills with no real decision behind them, like utilities, rent, charity, taxes and some subscriptions. A non-PO invoice with an approval workflow, or a contract, does the job.
True emergencies. Buy first, then document through an emergency process you defined in advance.
After-the-fact POs do the most damage. They're sometimes called retro or confirming POs. The invoice arrives, there's no PO, so someone creates one to make the invoice payable. That PO controls nothing: the money was committed the moment the requester called the supplier. It's useless admin work at this point 😅
"No PO, No Pay" policies often make this worse. Suppliers learn to demand a PO number upfront, which is good. But if requesters have no easy channel to raise one for small or odd purchases, they buy anyway and backfill later.
Track the share of POs created after the invoice date. It tells you how much of your "PO-backed" spend was committed before anyone approved it. If that share is high, build better purchasing channels before you tighten the policy. (For more on handling low-value spend, see Solving the Tail Spend Management Problem: Part 1.)
What purchase orders do for buyers and suppliers
For buyers, a well-run PO process gives you:
Approval before the money is committed
Budget commitments that show what's really available
An audit trail from request to payment
Invoices that match automatically instead of landing in an exception queue
For suppliers, a good PO means:
Written proof of what was ordered, at what price
Faster payment, since invoices that quote a valid PO number clear matching sooner
A document some lenders will finance against, through purchase order financing
Purchase order FAQ
What does PO stand for?
PO stands for purchase order: a document a buyer sends a supplier to request goods or services at agreed quantities, prices and terms.
What is a PO number?
A PO number is the unique identifier assigned to a purchase order, usually generated by the buyer's ERP. Suppliers include it on invoices so the buyer can match the invoice to the order and the receipt.
Who issues a purchase order?
The buyer. A requester raises a requisition internally, and procurement or the system converts it into a PO sent to the supplier.
Does an invoice need a PO number?
For PO-backed purchases, yes. Many companies run a "No PO, No Pay" policy and return invoices without a valid PO number. Some spend, like utilities or P-card purchases, is handled without a PO.
What's the difference between a purchase requisition and a purchase order?
A requisition is an internal request for permission to buy. A purchase order is the external document sent to the supplier once that request is approved.
Your supplier only sees the form
A purchase order is an offer to your supplier and a commitment against your budget, and your ERP can hold every detail of it. Your supplier works only from what makes it onto the form. That's where three-way matches fail, trucks show up at the wrong dock and payment terms get argued about.
Print the checklist, pull up your last PO, and count the "no" answers.