Purchase order vs. invoice: Key differences and how AP matches them

- Purchase order vs. invoice: What's the difference?
- Purchase order vs. requisition vs. invoice
- Who handles POs and invoices in a mid-sized company?
- How AP matches purchase orders to invoices
- How to resolve a PO and invoice discrepancy
- What happens when the PO number is missing or wrong?
- PO vs. non-PO invoices: When to require a purchase order
- Match POs to invoices automatically with Ramp

The difference between a purchase order and an invoice comes down to timing. A purchase order is the buyer's document authorizing a purchase before delivery, and an invoice is the vendor's request for payment after delivery. They're two separate documents from two separate parties, and AP's job is to match them, along with the receiving record, before any money goes out.
Most of the work is in matching, from 2- and 3-way comparisons to tolerances, line discrepancies, and bad PO numbers, each with a repeatable standard fix.
Purchase order vs. invoice: What's the difference?
A purchase order commits you to a purchase on set terms, and the invoice bills against that commitment. One comes before the goods ship, and the other comes after.
A purchase order is the document your company sends a vendor to authorize a specific purchase. It lists what you're buying, how many, at what price, and on what terms. Once the vendor accepts it, those terms bind both sides.
An invoice is what lands in your AP inbox once the vendor has delivered. Before approving it, AP checks the vendor name, invoice number, PO reference, line items, quantities, unit prices, payment terms, and due date. Every one of those fields should trace back to the PO or the contract behind it.
| Dimension | Purchase order | Invoice |
|---|---|---|
| Who issues it | The buyer, usually purchasing or procurement | The vendor or supplier |
| When it's issued | Before goods ship or work starts | After delivery or at a billing milestone |
| Purpose | Authorizes a purchase and sets price, quantity, and terms | Requests payment for what was delivered |
| Legal effect | Becomes a binding contract once the vendor accepts it | Records the transaction and the amount owed, but sets no new terms |
| Unique identifier | PO number, assigned by the buyer | Invoice number, assigned by the vendor |
| What AP uses it for | The baseline for what you agreed to pay | The claim AP verifies before payment |
| What triggers it | An approved purchase requisition | Shipment, delivery, or completed work |
| Which system owns it | Procurement or purchasing system | AP or accounting system |
Treat the PO as the source of truth and the invoice as the claim against it, and you'll know which document wins when the two disagree.
Purchase order vs. requisition vs. invoice
Three documents move a purchase from request to payment: an internal purchase requisition, the purchase order, and the vendor's invoice. Each one has a different author and a different audience.
- Purchase requisition: An employee's internal request to buy something. A budget owner approves it, and it never goes to the vendor.
- Purchase order: The approved, external commitment. Purchasing turns the requisition into a PO and sends it to the vendor.
- Invoice: The vendor's bill. It closes the loop in the purchasing process and triggers payment, but only after AP checks it against the PO.
| Dimension | Purchase requisition | Purchase order | Invoice |
|---|---|---|---|
| Created by | Employee or requester | Purchasing or procurement | Vendor |
| Sent to | Approver or purchasing team | Vendor | Buyer's AP team |
| Internal or external | Internal | External | External |
| Approval needed | Yes, from the budget owner | Yes, before it's issued | Yes, AP approves for payment after matching |
| Legally binding | No | Yes, once accepted | No new obligation on its own |
| Stage in procure-to-pay | Request | Commitment | Payment |
If an invoice arrives for something that never went through a requisition and a PO, it means no one approved that spend before it happened.
Who handles POs and invoices in a mid-sized company?
In a mid-sized company, five roles touch purchase orders and invoices, and each one owns a different check. AP sits at the end of the chain, which means it inherits every error made upstream.
In accounts payable, the PO is the record of what someone approved you to pay. Purchasing creates it upstream in the purchase order process, and AP checks every invoice against it.
| Role | Document they own | What they check | Where errors start |
|---|---|---|---|
| Requisitioner | Purchase requisition | That the item, quantity, and vendor match the need | Vague descriptions or a missing budget code |
| Approver (budget owner) | Requisition approval | That the spend fits the budget | Approving the request but never seeing the invoice |
| Purchasing or procurement | Purchase order | Vendor terms, price, and PO accuracy | PO prices that differ from the quote, or POs issued after the fact |
| Receiving | Goods receipt or packing slip | What arrived, how many, and in what condition | Receipts logged late or never sent to AP |
| Accounts payable | Invoice | That the invoice matches the PO and receipt, then codes and pays it | Paying without a receipt, or keying the wrong PO number |
Most matching failures trace back to a handoff, so fix the point where data stops moving between roles before you blame the invoice.
How AP matches purchase orders to invoices
Matching confirms you're paying only for what you ordered, at the agreed price, and with 3-way matching, only for what arrived. The method you choose decides which errors you catch before payment.
2-way matching
Two-way matching compares the invoice to the PO alone. AP checks the vendor, item, quantity ordered, unit price, and total.
It confirms that the vendor billed what you ordered at the price you agreed to. It doesn't confirm that anything arrived. That gap is acceptable for services, subscriptions, and low-risk purchases where there's no physical receipt to check.
3-way matching
Three-way matching adds the receiving record, either the goods receipt or the packing slip, to the comparison. The invoice has to agree with both the PO and what your team logged at the dock.
That third document catches vendors billing for goods that were short-shipped or never delivered. It's worth the extra step for physical goods, inventory, and high-value orders, where paying for missing units costs real money.
| 2-way match | 3-way match | |
|---|---|---|
| Documents compared | PO and invoice | PO, invoice, and receiving record |
| What it catches | Price and quantity billed beyond the order | Price and quantity errors, plus short shipments and undelivered goods |
| What it misses | Whether goods or services were received | Quality issues not logged at receiving |
| Best for | Services, subscriptions, low-risk purchases | Physical goods, inventory, high-value orders |
| Effort for AP | Lower, with two documents to line up | Higher, since receiving data must reach AP |
Invoice tolerance thresholds
Tolerance is the variance you'll accept between the PO and the invoice before the invoice gets flagged as an exception. Without it, a 40-cent rounding difference would stop payment just as surely as a $4,000 overcharge.
Teams usually set different tolerances by category or vendor. A long-standing freight carrier might get more room than a new supplier of capital equipment. A sample rule is: auto-approve if price variance is within 2% or $250, whichever is lower. You can set a few types of tolerances:
- Percentage variance: Controls how far the invoice total or unit price can drift from the PO as a share of value. Tighten it on high-value orders, where 2% can mean thousands of dollars.
- Fixed dollar variance: Caps the absolute difference, regardless of order size. Tighten it when small orders keep slipping through with overcharges that add up across the month.
- Quantity tolerance: Controls how many units over or under the PO or receipt you'll accept. Tighten it for inventory items where overbilled units distort stock counts.
Set tolerances by category, review them each quarter against your exception data, and you'll stop spending review time on variances that don't matter.
How to resolve a PO and invoice discrepancy
Most PO and invoice mismatches fall into a few predictable types, and each one has a standard fix. Working through them in the same order every time keeps one messy invoice from turning into three emails and a late payment.
Take a PO for 200 cases of printer paper at $42 per case, or $8,400. The vendor ships 150 cases, then invoices for 200 at $45.50 per case, a total of $9,100. The invoice also lists quantity as "5 pallets" instead of 200 cases.
1. Compare the invoice to the PO line by line
Check each invoice line's item, quantity, unit of measure, unit price, and extended total against the PO line it references. Totals alone hide offsetting errors.
In the printer paper example, three fields fail: the unit price is $3.50 high, the billed quantity is 200, and the unit of measure is pallets instead of cases.
2. Check the receiving record
Confirm what arrived before deciding what to pay. Receiving logged 150 cases, so 150 is the most you owe for right now.
With a partial delivery, you pay for the quantity received and leave the PO open for the 50-case balance. The vendor bills that remainder when it ships.
3. Classify the variance
Name each mismatch so it goes to the right fix. The common types are partial delivery, price variance, unit-of-measure mismatch, duplicate billing, and tax or freight that wasn't on the PO.
The printer paper invoice carries three of them at once. Each needs its own resolution, even though they arrived on a single document.
4. Apply your tolerance rules
Measure each variance against your thresholds. Within tolerance, approve it and record the difference. Outside tolerance, route it as an exception.
A $3.50 increase on a $42 case is about 8.3%, well past a 2% rule. That line goes to exception review, and the quantity line is limited to the 150 cases received.
5. Route the exception to the right owner
Send each exception to the person who can fix it. Price issues go to purchasing or the PO owner, quantity issues go to receiving, and billing errors go back to the vendor for a corrected invoice or credit memo.
For the paper order, purchasing confirms the agreed $42 price with the vendor, and the vendor reissues the invoice in cases for 150 units at $6,300.
6. Document the resolution
Record what changed, whether that's a PO amendment, a credit memo, or a short-pay. Your audit trail should show why the amount you paid differs from the original PO or invoice.
Six months later, an auditor shouldn't need to call anyone to understand why you paid $6,300 against an $8,400 PO.
| Discrepancy type | How it shows up | Who resolves it | Typical fix |
|---|---|---|---|
| Partial delivery | Invoice quantity exceeds the receiving record | Receiving and AP | Pay for received units and keep the PO open for the balance |
| Price variance | Unit price on the invoice differs from the PO | Purchasing or the PO owner | Corrected invoice, credit memo, or PO amendment if the new price is approved |
| Unit-of-measure mismatch | Invoice uses a different unit than the PO, like pallets vs. cases | Purchasing and the vendor | Reissued invoice in the PO's unit, or a documented conversion |
| Duplicate invoice | Same vendor, amount, and invoice or PO number already paid or in queue | AP | Reject the duplicate and notify the vendor |
| Unexpected freight or tax | Charges on the invoice that weren't on the PO | Purchasing or AP, per policy | Approve within tolerance, or request a corrected invoice |
When every discrepancy gets classified, routed, and documented the same way, your exception queue gets shorter and your audit trail explains itself.
What happens when the PO number is missing or wrong?
An invoice without a valid PO number can't be auto-matched, so it drops into an exception queue. Payment slows down, and the risk of paying a duplicate or unauthorized bill goes up because the invoice has no approved commitment behind it.
The usual causes are a vendor who leaves the PO number off, references a closed or wrong PO, or uses a blanket PO number for a one-off purchase. Vendors also confuse purchase order and invoice numbers, entering their own invoice number in the PO field. Each one calls for a slightly different response.
- No PO number on the invoice: Look up open POs by vendor, amount, and date. If nothing matches, contact the requester to confirm the purchase.
- PO number references a closed PO: Check whether the invoice is a late bill for already-received goods or a new purchase. New purchases need a new PO before payment.
- PO number belongs to a different vendor or order: Return the invoice to the vendor for reissue with the correct reference if your policy requires it.
- Blanket PO number used for a one-off purchase: Confirm with the PO owner that the item falls within the blanket PO's scope. If it doesn't, route it for separate approval.
- Repeat offenders: Apply a no PO, no pay policy so vendors learn that invoices without a valid PO number come back unpaid.
A clear no PO, no pay policy, enforced consistently, does more to fix missing PO numbers than any amount of manual lookup.
PO vs. non-PO invoices: When to require a purchase order
A non-PO invoice is a bill that arrives without a preceding purchase order. Utilities, rent, subscriptions, professional services, and small one-off purchases often work this way.
Not every purchase needs a PO, and requiring one for everything slows buying without adding much control. Strong candidates for a PO requirement include spend above a dollar threshold, new vendors, physical goods, capital purchases, and categories with budget risk. Each company sets its own threshold based on its volume and risk tolerance.
Non-PO invoices still need controls. Route approvals by amount and department, keep a vendor allow-list, and review recurring bills regularly. For predictable repeat spend, a blanket or standing PO from the available types of purchase orders can give you PO-level control without issuing a new PO every month.
| Purchase type | Require a PO? | Why? | Control if no PO |
|---|---|---|---|
| Inventory and physical goods | Yes | Needs 3-way matching against receipts | N/A |
| Capital equipment | Yes | High value and capitalized on the balance sheet | N/A |
| New vendor | Yes | No payment history or verified terms yet | N/A |
| SaaS subscription | Often, or a blanket PO | Recurring charges and auto-renewals add up | Contract on file and renewal review |
| Utilities and rent | Usually no | Fixed or contract-based recurring bills | Recurring-bill review against the lease or prior months |
| Professional services | Depends on size | Scope and hours vary by engagement | Signed engagement letter and approval by department head |
| Small one-off purchases | No, below your threshold | A PO costs more time than the risk it controls | Approval routing by amount and vendor allow-list |
Draw your PO line where the risk sits, and put lighter controls on everything below it so non-PO invoices don't become a blind spot.
Match POs to invoices automatically with Ramp
Line-by-line matching, exception routing, and chasing missing PO numbers eat most of an AP team's week. When procurement and AP run on separate systems, every handoff between them is another place for a receipt or price change to get lost.
Ramp Procurement turns approved requests into purchase orders with 3-way matching built in. Those POs connect directly to Ramp Bill Pay, so invoices reconcile against the PO without a manual handoff between systems.
Here's what purchase order and invoice matching looks like with Ramp:
- Issue POs from approved requests: Employees submit requests in plain language, and approved requests become POs without rekeying.
- Match invoices against POs and receipts: Three-way matching runs inside one procure-to-pay workflow, from intake through payment.
- Code invoices from your own history: AP Agent auto-codes invoices using your past coding decisions. Fix an invoice once and AP Agent remembers.
- Catch duplicates and fraud before payment: AP Agent flags duplicate bills and checks for fraud across 60+ signals.
- Process invoices faster: Teams process invoices 2.4x faster and with 86% fewer clicks than legacy software.
Try an interactive demo to see how Ramp matches purchase orders to invoices, and why more than 70,000 businesses have saved 27.5 million hours with Ramp.

FAQs
No. The buyer issues a PO to authorize a purchase before delivery. The vendor issues an invoice to request payment afterward. AP matches the two before paying.
The purchase order. It's issued and accepted before the vendor delivers, and the invoice follows delivery and references the PO number.
The buyer. Usually purchasing or procurement sends it after a requisition is approved, and the vendor receives it.
Not on its own. An invoice records a completed transaction and requests payment. The accepted PO or a signed agreement sets the binding terms.
No. A vendor issues a sales order to confirm it accepted the buyer's PO, and it issues the invoice later to bill for delivered goods or services.
“I assumed I would have to choose between speed and control. What I found is that you can have both. A well-designed system takes friction out, for the finance function and for everyone else.”
Justin Webster
CFO, Denver Broncos

“A well-run district should not have to choose between getting work done at the school site and keeping control of the dollars behind it. We're not hiring more people to do more jobs, so we have to be smarter about the process. With Ramp, the purchase, the receipt, and the record stay together from the start. ”
Nick Brizeno
Director of Purchasing, San Marcos Unified School District

“In senior living, scale only works if the communities still feel personal. We needed the back office to carry more of the complexity, not the people serving residents. Ramp helped us build that infrastructure, so the experience in the community could stay human.”
Ryan Cole
CFO, Agemark Senior Living

“AI is moving faster than the finance context around it. Prices change, models change, and the value is not always obvious from an invoice. We needed enough detail to know which bets deserved more investment — and which ones did not.”
Greg Cooley
Controller, AngelList

“Invoices, cards, tokens. The categories change but the principle doesn't: know where the money is going, remove the work around it, and make sure the spend is worth it.”
Maciej Mylik. Finance
ElevenLabs

“We weren’t trying to retrofit an old finance system. We had a blank canvas, and Ramp gave us the foundation to build a global finance function of the future.”
Justin Dourado
Director of Finance, Othership

“There's just no surprises anymore. No more waiting two months to find out how a job did. We know how it's doing as it's happening.”
Erich Kuss
Financial Systems Manager, Infinity Home Services

“More token spend isn’t proof that AI is working. Less isn’t proof that it isn’t. What matters is whether we’re buying the right level of intelligence for the work. Ramp lets us make that judgment in the same place we manage every other type of spend.”
Cody Nutt
Senior Director of Business Systems, Daxko



