What Is a Purchase Order Invoice and How Matching Works

A purchase order invoice is a supplier invoice linked to an approved purchase order, not the purchase order itself. We pay it only after the billed lines agree with what was authorized and, where relevant, what was received.

That's less tidy than the advice we're often given. We're told to collect the bill, find a matching number, and release payment when the system turns green. We treat that advice as incomplete. A matching PO number proves a bill can be traced to an approval. It doesn't prove the price was fair, the quantity was needed, or the paperwork wasn't copied wrong in the same way three times.

So we start with control, not vocabulary. Authorization, acceptance, and payment claim are three different events. When we keep them separate, we can explain why a correct looking invoice gets held, why a service bill needs no warehouse ticket, and why the file we keep at month end matters as much as the payment we make.

Table of Contents

• What a Purchase Order Invoice Is
  • Four Records We Actually Handle
• Why the PO Number Decides Whether We Pay
  • The Same Number as a Data Field
• How Two-Way and Three-Way Matching Works
  • Six Checks We Run on the Next Bill
• A Furniture Order from PO to Payment
  • The Same Logic Without a Warehouse
• When Partials, Services, and Revisions Block Payment
  • PO Invoice Exceptions and What We Do
• Records, Payment Timing, and Bank Reconciliation
  • The File We Keep Together
  • Our Month-End Close in Four Steps

What a Purchase Order Invoice Is

A purchase order invoice is a supplier invoice connected to an approved purchase order. It's not the purchase order, and it's not a separate legal form with its own rules. Once we accept that, most confusion around what is a purchase order invoice disappears.

We, the buyer, write the purchase order before supply. It names the supplier, item or service description, quantities, agreed prices, delivery details, and payment terms, and it authorizes the spend. The supplier later issues the invoice, stating the amount owed, its own invoice number, billing details, and payment instructions. The NetSuite guide to three-way matching makes that sequence clear, with the PO created by the buyer before procurement and the invoice issued later.

Quoting the PO number on that invoice gives accounts payable the audit trail. It links the charge back to the original purchasing decision, so we can check prices, quantities, and line items against what was approved before anyone approves payment.

Four Records We Actually Handle

Record	Who creates it	When it appears	Question it answers	Effect on cash
Purchase order	Buyer	Before supply	What did we approve?	Commitment only, not a payment
Supplier invoice	Supplier	After goods or services	What is the supplier charging?	Request for payment
PO-backed invoice	Supplier	After supply, quoting a valid PO	Does this bill match an approved order?	Payable after a successful match
Non-PO invoice	Supplier	No purchase order exists	Who will approve an unplanned spend?	Separate approval, then payment

Read the first row on its own and the cash point matters most. A purchase order creates a commitment, not a debt. We haven't received anything yet, and the supplier hasn't asked for money. Budget holders see future spend coming, but accounts payable has nothing to settle.

The second row flips the author and the question. The supplier now says, in effect, this is what you're being charged. That document alone doesn't tell us whether we agreed to that price or quantity. It's a claim, and we treat every claim as something to verify.

The third row is where the phrase purchase order invoice earns its keep. The bill quotes a valid PO, so we can match it line by line. If the match succeeds, it becomes payable. If it fails, we have a specific exception to resolve, not a vague feeling that something looks wrong.

The fourth row takes another path. Where no matching PO exists, the invoice is a non-PO invoice. We can't match it to prior approval because there was none, so a budget owner or finance approver must authorize the spend after the fact. That route isn't automatically wrong, but it's slower and carries more risk.

Check our companion breakdown of what is on an invoice if you want the field by field anatomy of that supplier document. The practical point here is simpler.

Think of a shopping list and a bill. The list permits the buy. The bill asks for money. The PO number staples them into one file so we can prove the second follows from the first.

If a bill can't be linked to an open, approved commitment, we don't call it a purchase order invoice, whatever the supplier wrote in the email subject line.

That test keeps us honest. The PO answers what did we approve, the invoice answers what is the supplier charging, and payment only follows when those answers can be reconciled.

Why the PO Number Decides Whether We Pay

The PO number separates a bill we can test from a bill we have to argue about. An invoice can describe familiar work and a plausible amount, yet still arrive with no usable reference or with a number tied to a closed order. We send it back, and the supplier hears red tape. The reason is practical: without that key, we cannot route the bill, connect it to approval, or show that the spend was authorized before money left. The reference turns the supplier's bill into a purchase order invoice for our process by tying it to a commitment we already control.

Public buyers say the quiet part out loud. The UK Home Office procurement guidance tells suppliers to wait for an emailed PO, quote the PO number on the invoice, and send the bill to the designated address, and it warns that invoices submitted without a valid PO number will be rejected and payment delayed.

Treat the number as a matching key. It carries the invoice to the right department, ties the charge to an approved commitment, and lets the system retrieve ordered quantities and prices without a clerk searching inboxes. A clean key still has limits: it can prove the paperwork belongs together, not that the original price was sensible or the delivery solved the problem.

The Same Number as a Data Field

On a paper or PDF invoice, the PO number is text someone types. In structured e-invoicing, it is a defined field. The European e-invoicing directive describes core invoice semantics including process and invoice identifiers, seller and buyer data, invoice line details, delivery information, payment terms, and a contract reference, while German federal guidance maps the purchase order number to the BT-13 purchase-order-reference field.

We keep that structure even when a supplier sends a PDF. The PO number stays at header level, and each line carries enough detail to test it on its own:

• Item or service code: so a line can be matched without guessing from a description
• Ordered and delivered quantity: so partial supply stays visible
• Unit price, tax category, and currency: so price and tax checks stay separate

Where no PO exists, we use a controlled substitute instead of free text. A contract, project, cost center, or employee identifier routes the bill to a real owner. A note saying "for the office job" gives us a story, not a destination.

The format shift is already underway. Germany's January 2025 receive-capability requirement is part of that move, and European Commission eInvoicing guidance tracks the wider push toward machine-readable exchange. The commercial logic stays put. Authorization still comes first; what changes is whether the PO reference travels as readable text or as data a system can match on arrival.

How Two-Way and Three-Way Matching Works

We don't pay a supplier merely because an invoice exists. We pay because the invoice agrees with records we created before and during delivery.

A two-way match compares the invoice with the purchase order. A three-way match adds the receiving record. That single extra document changes the question from "did we order this" to "did we order this, receive it, and get billed correctly for it."

The HM Revenue & Customs procure-to-pay guidance identifies the two-way match between a PO and invoice as a key control, with a three-way match adding the goods-received note so we can compare supplier, items or services, quantities, prices, and authorized terms.

For the three-way version, the Washington State Auditor's Office accounts payable guide defines the control specifically as comparing quantities and price across the purchase order, receiving record, and invoice. Each record does a distinct job. The PO confirms what was authorized and at what price. The receiving record confirms what was delivered and accepted. The invoice confirms what the supplier is charging.

Six Checks We Run on the Next Bill

1. Confirm the PO is open and approved. A closed, cancelled, or fully matched PO isn't a valid base for payment.
2. Check supplier and line items against the PO. The legal name, item codes, and descriptions should line up without manual interpretation.
3. Check quantity and price against the PO. We compare each line, not just the invoice total, because totals can hide offsetting errors.
4. Check the receipt where one exists. Billed quantity should not exceed accepted quantity.
5. Apply tolerances. We set rules in advance for price, quantity, tax, freight, and currency, so a tiny rounding difference clears and a real variance doesn't.
6. Approve, hold, or reject. We approve the cleared amount, hold the exception for a named approver, or reject a bill that can't be supported.

We block payment automatically when the PO number is missing, duplicated, closed, or inconsistent with the receipt. Those aren't judgment calls for a busy clerk at month end. They're hard stops that protect us from duplicate payments and from paying before goods or services are due.

Practical rule: configure the tolerance before the invoice arrives. Deciding what's close enough while a supplier is chasing payment is how small exceptions become habits.

A clean result means the three records are consistent with each other. That is a strong control, and we rely on it daily. But consistency has a limit, and pretending otherwise weakens the very control we're trying to build. If the same wrong price sits on every record, the arithmetic will still agree.

A Furniture Order from PO to Payment

Say we approve an order for office chairs. The dates and amounts below show how the safe to pay figure changes as each new document arrives, and which document changes it.

On 3 March 2026, we approve PO 4418 to Northline Supplies for 20 task chairs at 180 each, April delivery, freight included, net 30. The arithmetic is simple. Twenty multiplied by 180 gives a commitment of 3,600. Nothing is payable yet. Northline has an authorization to supply, and we have a budget commitment we can report.

On 10 April, the warehouse receives 12 chairs and posts a goods-received note for 12. At the PO price, that receipt is worth 2,160. The document that matters that day isn't an invoice. It's the receipt, because it tells us what we have accepted.

On 12 April, Northline invoices 3,600 for all 20 chairs and quotes PO 4418. We run the match. Supplier agrees. PO number agrees. Unit price agrees at 180. Quantity doesn't. The invoice bills 20, the receipt supports 12, and the PO authorized 20 in total.

We don't reject the whole bill, and we don't pay the whole bill. If partial billing is allowed under the order terms, we clear 2,160 for the 12 received chairs and hold 1,440 for the 8 chairs still outstanding. The held amount is 8 multiplied by 180. The PO stays open for that balance.

On 24 April, the last 8 chairs arrive. The warehouse posts a second receipt. Now the cumulative received quantity is 20, the billed quantity is 20, and the previously held 1,440 clears. We close the PO because it's fully matched.

Payment timing follows the valid invoice under net 30, not the March PO date. March created permission. April created evidence of delivery and a payment claim. Mixing up those dates is how teams pay early for goods that haven't arrived, or accrue a liability months before one exists.

The Same Logic Without a Warehouse

Contrast that with a monthly IT support retainer of 900 billed against an annual PO. No boxes arrive, so no goods-received note exists. Inventing one would weaken the trail, not strengthen it.

We match supplier, service period, and price to the PO or contract. Then we obtain written acceptance from the budget owner confirming the service was received for that period. That's a two-way match plus acceptance. The acceptance does the job the receipt did for the chairs. It says someone accountable confirms we got what we're being billed for.

Two orders, two kinds of evidence, one discipline. At each date we can state the safe to pay amount, and we can name the document that made that amount safe.

When Partials, Services, and Revisions Block Payment

A valid invoice can sit unpaid even when nobody has committed fraud. That's not a system failure by itself. Often it's the control doing exactly what we configured it to do, just on a case nobody thought through in advance.

We separate two things that sound alike. A PO-backed invoice has been validated by a completed match. An invoice that merely contains a PO number still has to be checked against the order before anything is released. The number opens the door to verification. It isn't verification.

The Amazon Business invoice processing guide notes that difficult cases including partial deliveries, split shipments, revised POs, freight charges, unit-of-measure differences, and invoices that arrive before receiving records are posted can leave a valid invoice blocked even when no fraud or accounting error exists.

PO Invoice Exceptions and What We Do

Case	What we compare	What blocks payment	Action we take
Partial delivery	PO quantity, receipt, invoice quantity	Invoice bills the full order early	Approve only the received quantity and leave the PO open
Split shipment	One PO against several receipts and invoices	Line tied to the wrong receipt	Match each invoice line to its own receipt
Revised PO	Latest approved PO price vs invoice	Old price still billed	Pay the latest approved price or request a corrected invoice
Freight or tax	PO terms vs extra invoice lines	Extra was not authorized or exceeds tolerance	Approve inside tolerance or reject the extra
Unit of measure	PO unit vs invoice unit	Cartons vs eaches fail the quantity check	Convert units, then rematch; do not override blindly
Invoice before receipt	Invoice vs missing goods-received note	Receiving has not been posted	Hold the bill and chase the receipt; do not delete it
Service, no goods receipt	PO or contract, invoice, and acceptance	No warehouse receipt exists	Use budget-owner acceptance as the third check
Duplicate or closed PO	Invoice number and PO status	PO fully matched or closed, or invoice number repeated	Block payment and investigate before release

A few rows deserve emphasis. A revised PO means we pay against the latest approved price, not an old PDF still sitting in someone's inbox. If the supplier billed the superseded price, we ask for a corrected invoice rather than editing the amount ourselves.

A unit-of-measure mismatch fails quantity even when the goods are right. We ordered 10 cartons, the supplier billed 120 eaches, and the match sees 10 against 120. We convert the units, document the conversion, and rematch. Overriding the exception without that step teaches the system that quantity checks are optional.

An invoice before receipt gets held, not deleted. Deleting it invites the supplier to resend it, and now we have two copies and a duplicate risk. Holding it preserves the invoice number for duplicate detection while we chase receiving.

Where different billing models complicate the picture, our guide to types of invoicing helps separate the billing pattern from the matching problem. The exception logic stays the same either way.

Finally, the limit we won't talk ourselves out of. A successful three-way match is not proof that every line is correct. If the same wrong price is copied onto the PO, the receipt, and the invoice, the match still passes, because matching tests consistency among documents, not whether the underlying deal was right. We still need sane PO creation, independent receiving, and periodic price checks against contracts. A green match closes one question. It doesn't close them all.

Records, Payment Timing, and Bank Reconciliation

An invoice is accounting evidence, not just a request to send money. When an auditor or tax reviewer opens the file a year later, the invoice alone won't answer their questions.

The US Internal Revenue Service guidance on records says supporting documents include invoices, paid bills, receipts, deposit slips, and canceled checks, and that purchase documentation should identify the payee, amount paid, proof of payment, date incurred, and a description showing what was purchased.

Map each element to the document that proves it and the gaps appear. One PDF invoice covers payee, amount, and description. It doesn't prove we authorized the buy, accepted the goods or service, or paid.

The File We Keep Together

• Purchase order: proves authorization, agreed price, and terms
• Supplier invoice: proves what was charged and when payment was requested
• Receiving note or service acceptance: proves delivery or performance
• Payment evidence: proves the amount left our bank account and reached settlement

We file those four together, with the PO number as the thread an auditor can follow from approval to bank debit. We keep the set for the longer of the applicable tax rule and any contractual requirement. A file holding only the invoice shows what the supplier asked for. It doesn't show why we were allowed to pay it.

Payment timing has no universal answer either. It depends on the contract, the buyer, the jurisdiction, and whether the invoice is valid and undisputed. A disputed, unmatched, or duplicate bill isn't valid for payment just because a due date is printed on it.

For one concrete regime, the Procurement Act 2023 guidance on electronic invoicing and payment says UK contracting authorities generally must pay a valid, undisputed invoice within 30 days of receipt, or by the later contractual due date when applicable, and that receipt is distinct from validation, so the clock isn't generally postponed until validation finishes. That distinction pressures us to match promptly rather than let exceptions age.

Our Month-End Close in Four Steps

1. List open PO invoices. Every unmatched bill gets a named owner.
2. Match or raise an exception on each line. No line sits in limbo without a reason code.
3. Schedule only the cleared amount. Held quantities stay held until receipt or correction arrives.
4. Tie the bank debit back to the invoice. When the payment appears on the statement, we link it to the invoice and PO number.

That last step is where statement data earns its place in procure-to-pay. Our walkthrough of what is bank statement reconciliation covers the full tie out, but one check comes before all others. Before we trust any statement extract, we confirm that opening balance + credits − debits = closing balance. If that equation fails, we fix the extract before we chase phantom payment differences.

Conversions and previews may be created before payment, and one-time charges and subscription plan usage apply when downloading or exporting a file, so we can inspect extracted transactions before committing them to the close. That preview habit mirrors the invoice discipline we've described throughout. Verify first. Pay, post, and file second.

---

When the cleared payment finally leaves the account, we still need the bank debit in a clean table to tie it back to the PO, invoice, and receipt without manual copying. We built autobankstatement to convert PDF bank statements, including scanned and password-protected files up to 25 MB with bulk upload, into CSV or Excel, with a free guest preview before payment and uploads that auto-delete within 24 hours. Bring your next statement, check the preview against your closing balance, and close the loop from purchase order to paid invoice in one sitting.