Purchase Order vs Invoice: The Bookkeeper's Decision Tree (2026)

Purchase Order vs Invoice: The Bookkeeper's Decision Tree (2026)

It's Tuesday morning. You open your client's inbox and there's a vendor email with three attachments: two invoices and something labeled "PO Confirmation." You pull up QuickBooks. No PO anywhere in the system. The client has 22 vendors, no procurement policy, and an owner who approves purchases by forwarding emails with a thumbs-up emoji.

That's not a dysfunction. That's a typical small-business client. And it raises a real question: do they need purchase orders at all?

Most small-business clients under 50 vendors don't issue POs. The owner knows every vendor, approves every spend personally, and has no purchasing department to route paperwork through. In that setup, a PO adds a step without adding control. But there's a threshold where that changes, and knowing where it is will save you hours of dispute resolution and month-end mystery invoices.

What's the difference between a purchase order and an invoice?

A purchase order (PO) is a document the buyer issues to a vendor before the purchase. It authorizes the transaction, specifies quantity and price, and creates a legal commitment. An invoice is a document the vendor issues to the buyer after delivery. It demands payment and records a liability. One document starts the deal; the other closes it. For bookkeepers: a PO sits in the buyer's records as a commitment that hasn't hit AP yet. An invoice creates the AP entry. Small businesses that don't issue POs skip straight to invoice-as-authorization. That works fine until invoices arrive for purchases nobody remembers approving.

Key Takeaways

• Most small-business clients under 50 vendors don't need formal POs: the 2-document model (invoice + owner approval) gives adequate control without procurement overhead.
• The $5K average vendor invoice is a practical PO trigger: once a single vendor averages $5,000+ per transaction, verbal approvals create enough exposure that a written commitment document is worth the friction.
• Purchase orders are buyer-issued, invoices are vendor-issued: they flow in opposite directions, carry different legal weight, and live on different sides of the same transaction.
• 3-way match (PO + receipt + invoice) is enterprise practice: for most bookkeeper clients, 2-way match (invoice + evidence of receipt or approval) is the right level of control without adding a PO step the business won't maintain.
• PO numbers on invoices cut dispute resolution time roughly in half: when a vendor references a PO number, you can trace back to original authorization in under 60 seconds instead of chasing email threads.
• Every approved vendor interaction is a 1099-eligibility moment: at the PO or invoice stage is when you confirm the W-9 is on file; waiting until December means chasing vendors under deadline pressure.

Purchase Order: Who Issues It, What It Authorizes, Legal Status

The buyer issues the purchase order. Not the vendor. If your client sends a PO to their printer, they're saying: "I authorize you to deliver 500 letterhead sets at $0.38/sheet. Here's a document number for reference."

That matters legally. An accepted PO is a binding contract in most jurisdictions. Once the vendor acknowledges it, both parties have committed. The buyer can't walk away without a cancellation process; the vendor can't change the price.

For bookkeeping, a PO does something specific: it creates a commitment record before money moves or goods arrive. Enterprise finance teams track open POs as commitments (not yet AP) on their books. Small business clients rarely do this because they don't carry enough concurrent open orders to warrant it.

What a PO authorizes:

• Which vendor is approved for this purchase
• The specific goods or services (description, quantity, unit price)
• The total authorized amount
• Any delivery terms or timing

What a PO does NOT do: it doesn't create an AP entry. Money hasn't moved. Goods haven't arrived. It's a green light, not a ledger transaction. The AP entry comes when the invoice arrives and gets matched against the PO.

One practical note: some vendors use the word "purchase order" loosely to mean "your order confirmation." That's not the same as a formal PO that your client issued. If the document originates from the vendor, it's not a PO in the accounting sense.

Invoice: Who Issues It, What It Demands, Legal Status

The vendor issues the invoice. After delivery, not before. An invoice is a demand for payment that says: "We delivered what you ordered. Here's what you owe and when."

That's the legal distinction. A PO is the buyer's commitment; an invoice is the vendor's claim. Two separate documents, two separate legal instruments, traveling in opposite directions.

For bookkeeping, the invoice is what creates the AP entry. When you enter a vendor invoice in QuickBooks, you're recording a liability: the client owes money. That liability lives in accounts payable until the payment clears.

What an invoice should include:

• Vendor's name, address, and contact info
• Invoice number (for your reference and theirs)
• Invoice date and payment due date
• Description of goods or services delivered
• Amount due, broken out by line item
• Payment instructions

A well-formatted invoice also references the buyer's PO number, if one exists. That PO reference is what makes 3-way match possible. No PO number on the invoice means matching has to happen by amount, vendor, and date, which is slower and more error-prone.

One recurring problem: vendors sometimes re-send invoices with modified headers or slightly different dates when payment is late. That creates duplicate-payment risk. If your client paid invoice #4417 and the vendor resends it as invoice #4417-R or just changes the date, the owner may approve it again without recognizing it. Having a PO number on file lets you catch this immediately.

The Document Lifecycle: PO to Receipt to Invoice to Payment

When POs are in play, the lifecycle runs in a specific order. Breaking it down:

1. PO issued. Buyer sends the PO to the vendor. No GL entry yet. Commitment is logged internally if the client tracks open POs.

2. Vendor acknowledges. Vendor accepts the PO terms. Now both parties are committed. Still no GL entry on the buyer's side.

3. Goods or services delivered. Vendor ships the order or completes the service. Buyer receives and verifies what was delivered. This is the "receipt" step in 3-way match.

4. Invoice received. Vendor issues an invoice referencing the PO number. This is where the AP entry gets made. Date the bill by invoice date, not receipt date.

5. Match occurs. For 3-way: PO, receipt, and invoice must align in item, quantity, and price. Any discrepancy stops payment until resolved. For 2-way (the small-biz default): invoice matches either the receipt or the owner's approval, without a formal PO in the loop.

6. Payment authorized and released. Bill approved, payment scheduled. Once payment clears, the AP liability closes.

7. 1099 roll-up. All payments to that vendor flow into the annual total. If the vendor is 1099-eligible and you've had their W-9 on file since their first invoice, the roll-up is automatic. See the 1099 filing workflow for how vendor payment totals feed into January filing.

When there's no PO, the lifecycle starts at Step 4. That's fine, as long as the approval step is explicit before payment.

When Small Business Actually Needs Purchase Orders

This is where most content on purchase orders gets it wrong. It treats POs as universally best practice. They're not. For small businesses, they're a tool for a specific problem.

Use the following decision tree:

Does the client have fewer than 50 vendors? If yes, and the owner reviews every invoice personally before payment: no PO required. Invoice + owner approval is your control.

Does any single vendor average more than $5,000 per transaction? If yes: consider a PO or at minimum a written quote/approval before the vendor starts work. At $5K+, verbal authorization creates real dispute and cash-flow exposure if the vendor delivers something different from what the owner expected.

Does the client have more than one person approving purchases? If yes: you need documented authorization. Who approved this? When? For how much? Without a PO, you're relying on email threads that may or may not get forwarded to you at month-end. A simple PO (even a one-page template the owner fills out) creates a paper trail.

Does any single vendor account for more than 20% of total vendor spend? If yes: that vendor relationship carries enough financial weight to warrant formal purchase documentation. A disputed invoice at that scale can affect your client's cash position meaningfully.

Does the business operate in a regulated industry with audit requirements? If yes: POs may be required regardless of volume. Construction, healthcare, and government contractors often need them for compliance, not just operational control.

Does the client regularly receive invoices for amounts they don't recognize? If yes: this is the clearest signal. Mystery invoices happen when purchases are verbal and the owner forgets what they ordered. Adding a PO step creates a record the owner has to generate before the vendor starts work, which eliminates the "what is this for?" conversation at month-end.

If none of these apply: the 2-document model (invoice plus approval) is probably the right fit. Adding POs to a 15-vendor, owner-operated business that doesn't need them creates paperwork the owner won't maintain, which means you'll end up chasing PO documentation that doesn't exist.

The 2-Document Bookkeeper Version: Invoice and Approval

For most small-business clients, the practical AP control system has two documents: the invoice and the approval.

The invoice comes from the vendor. The approval comes from whoever has authority to commit company funds. Together, they tell you: "Someone authorized this, a vendor delivered it, and here's what we owe."

How this works in practice:

The vendor emails an invoice. The owner forwards it with "ok to pay" or signs off via whatever system they use. That approval email, screenshot, or digital sign-off is your authorization record. You enter the bill, flag it for payment in the next cycle, and move on.

The bookkeeper's job in this model is to make the approval explicit before payment, not to reconstruct approval after the fact. Set up a simple workflow: bills don't get paid without a documented approval. How that approval is captured can be an email, a text, a note in the bill description in QuickBooks, or a lightweight approval tool.

What makes this model break:

• Owner approves verbally and forgets
• Multiple people can authorize payment without a central log
• Vendor sends a revised invoice and owner approves the same purchase twice
• New vendors get added without a W-9 collected at onboarding

If you see any of these patterns with a client, it's a signal to add lightweight PO or pre-approval documentation before spend happens, not after.

The 3-document enterprise version adds a formal PO before all of this. For clients crossing $50K+ in annual vendor spend with multiple approvers, that structure starts to pay off. Below that threshold, it usually creates more overhead than it resolves.

PO Numbers on Invoices: Why You Want Them

Even when your client doesn't formally issue POs, you want vendors to put a reference number on their invoices. It doesn't have to be called a PO. It can be a project number, a job code, or a quote number. Any reference that ties the invoice back to an authorized purchase.

Here's why:

Dispute resolution. When an invoice amount doesn't match what the client expected, a reference number lets you pull up the original quote or authorization in under a minute. Without it, you're searching email threads for context that may be buried under three months of other messages.

Duplicate detection. Two invoices with the same vendor, same amount, and same reference number are easy to flag. Two invoices with the same vendor and amount but no reference are harder to distinguish, especially if the vendor uses sequential numbering and you're not tracking their numbers in your system.

AP aging accuracy. When you're reconciling the AP aging report against vendor statements, a reference number on each line makes matching straightforward. The vendor's statement shows PO-2024-089; your subledger shows the same reference. Matched. Without references, you're matching by amount and date, which breaks on partial payments and credits.

Audit trail. If a client gets audited or a vendor dispute goes to collections, a reference number creates a documented chain from authorization to payment. That's useful when "we agreed to $3,200 for the website" turns into a $4,800 invoice with add-ons nobody approved.

You can implement this without requiring your client to issue formal POs. Ask vendors to include a reference number on their invoices, tied to whatever the client uses to authorize work (email subject lines, project names, quote numbers). It costs the vendor nothing and gives you a traceable chain.

How POs Feed AP Aging and 1099 Roll-Up

Two downstream systems get cleaner when PO discipline (or even just reference numbers) is in place.

AP aging. The AP aging report sorts outstanding vendor balances by how long they've been open. When invoices have PO or reference numbers, aging disputes resolve faster because you can trace back to the original authorization. A $3,800 invoice sitting in the 61-90 bucket is either legitimately disputed (the vendor delivered something different from the PO) or an oversight (payment was missed). A reference number tells you which one in seconds.

When a client's AP aging has balances with no reference number and the owner doesn't remember the transaction, those often age into the 90+ bucket and sit there. Not because they're in dispute but because nobody can figure out what they were for. Reference numbers prevent this.

1099 roll-up. Every time a new vendor sends an invoice, that's your moment to confirm two things: is the vendor 1099-eligible, and do you have their W-9? The 1099 filing workflow depends on vendor data captured at onboarding, not December. If a vendor's first invoice lands without a W-9 collected, you're either tracking them down in January or filing without a valid TIN, which creates backup withholding exposure.

POs formalize the vendor onboarding moment. If your client issues a PO to a new vendor, that's the trigger to collect the W-9 before the vendor delivers or invoices. For clients without POs, the invoice receipt is that trigger. Either way, the W-9 must be collected at first transaction, not at year-end.

The payment reconciliation workflow connects on the other end: once a vendor invoice is paid, the payment needs to hit the right bank account, clear against the right AP entry, and land in the right GL account. PO or reference numbers help trace this accurately, especially on partial payments or multi-installment vendor arrangements.

Set It Up Once, Not Every Month-End

The bookkeeper's relationship with POs and invoices isn't about memorizing the theory. It's about knowing which questions to ask when you onboard a new client.

Does the owner approve every purchase personally? How many vendors? What's the average transaction size? Does anyone else authorize spend? Any vendors over $5,000 per invoice?

Answers to those five questions tell you whether to implement a 2-document or 3-document AP model, what reference system to use for invoices, and where the 1099 risk sits.

If you're managing that AP work for 12+ clients and spending hours each month matching invoices without reference numbers or chasing down approvals after the fact, that's the kind of routine work Growthy is built around. The AP reconciliation hub covers the full monthly workflow. The glossary at /topics/glossary has definitions for every term in this workflow if you need a fast reference.

Get started with Growthy