The short answer: the buyer issues the purchase order, the seller issues the invoice. The PO comes first and authorises the purchase. The invoice comes after delivery and collects on it.
Most explanations of purchase order vs invoice stop there. What happens next matters more, because these two documents are built to be compared against each other, and the comparison is where payment gets held up.
Side by side
| Purchase order | Invoice | |
|---|---|---|
| Issued by | The buyer | The seller |
| Issued when | Before the work | After delivery |
| It says | We agree to buy this | We delivered, now pay |
| Legal effect | An offer until accepted | A demand for payment |
| Tax document | No | Yes |
| Lives in | Procurement | Accounts payable, and your ledger |
The row that matters most is the last one but one. A purchase order is not a tax document. You cannot book revenue against it, you cannot claim VAT on it, and your accountant will not accept it in place of an invoice. It is a commitment, not a record of a transaction.
What they have in common
The overlap is deliberate. They are meant to match.
Both carry line items, quantities, unit prices and a total. Both name the buyer and seller. Both usually carry payment terms. When your invoice reaches accounts payable, somebody or something compares those fields against the PO before releasing money.
If they line up, the invoice is approved. If they do not, it stops.
What happens when they disagree
The resolution is not symmetrical, which is why this is better known in advance than discovered.
In practice, the purchase order usually wins. Not because it has greater legal force, but because accounts payable is measured on paying against approved spend. An invoice for more than the PO authorised sits in an exceptions queue until somebody raises a variation, and that somebody works for the buyer, not for you.
The common mismatches, in the order you will meet them:
The invoice exceeds the PO value. Scope grew, nobody updated the PO. The excess does not get paid until a new or revised PO exists.
Tax handled differently. The PO is net, the invoice is gross, and the totals differ by exactly the VAT. Common on cross-border work, where the EU VAT number rules decide who accounts for the tax.
Line items described differently. Your invoice says “discovery phase”, the PO says “consultancy, 4 days”. A human can see they are the same thing. A matching system cannot.
Payment terms conflict. Your signed agreement says net 15, their PO says net 60. Whichever you fail to challenge before starting is the one you will be paid on. What the terms mean is in net 30 payment terms.
No PO number on the invoice. The invoice cannot be matched at all, so it waits for manual handling.
The fix is upstream, not at invoicing time
Every mismatch above is created before the invoice exists, and repaired most cheaply there.
Make the PO come from the accepted proposal. When the client raises their PO from a proposal with itemised lines, the descriptions and amounts already agree. When they retype it from an email, they do not.
Check the PO the day it arrives, not the day you invoice. What to look at is in what a purchase order is.
Invoice from the same source as the proposal. If your invoice inherits its lines from the accepted work rather than being rebuilt by hand, the descriptions stay stable across documents. That is the argument in proposal to invoice.
Put the PO number in a field. Not in the email, not in a note. On the invoice, where a machine can read it.
One PO or many: the retainer problem
Project work usually gets one purchase order for the whole engagement. Recurring work does not, and this is where service businesses lose money quietly.
A PO per period. The client raises a PO each quarter or each year for the retainer. When the period ends and nobody raises the next one, your invoice has nothing to match against. It does not bounce loudly; it waits. Meanwhile you keep delivering.
A blanket PO. One order covering a value or a period, drawn down by successive invoices. Better for you, because there is one thing to track rather than four. The risk is running past its value mid-period without noticing.
A PO per phase. Common on long projects with staged delivery. Each phase needs its own, and the gap between finishing one and receiving the next is dead time.
The practical habit for all three: know the remaining value on the PO, not just the amount invoiced. A retainer whose PO is nearly exhausted is a payment delay you can see coming a month out.
That is the same discipline as tracking a recurring billing schedule with a live balance rather than a list of past invoices, which is the argument in recurring billing for service businesses.
Do you need a purchase order at all
For most service businesses selling to small and mid-sized clients, no. POs appear when the buyer is large enough to separate spending approval from spending, which is usually somewhere above a hundred people.
When there is no PO, the documents holding the agreement are the master service agreement and the statement of work. They do the same job for you: written scope, written price, written terms, agreed before you start.
If you want to put numbers in front of a client before issuing a tax document, that is a proforma invoice, not a purchase order. The proforma comes from you; a PO would come from them.
The one-line version
If you remember nothing else: the purchase order is their permission to spend, the invoice is your demand to be paid, and the number linking them is the only thing standing between you and a manual approval queue.
Where the PO sits in the wider sequence, from proposal through to matched payment, is mapped in what a purchase order is. Getting the invoice half right the first time is how to write an invoice, and the sequence that has to stay unbroken for step six to work at all is invoice numbering.