Non-PO Invoice vs PO Invoice: Meaning, Examples, Processing

Jul 26, 2026

Convert a purchase order to Excel, CSV, or JSON

PDF, JPG, PNG, BMP, HEIC, TIFF

Submit your purchase orders

A non-PO invoice is a supplier bill that arrives with no purchase order behind it, so there is nothing for accounts payable to match it against. Somebody has to work out what the charge was for, code it to a general ledger account, and find the person who authorized the spend before it can be paid. A PO invoice carries a PO number, matches automatically against the order and the goods receipt, and often needs no human approval at all.

Last updated July 2026.

That difference sounds administrative. It is actually the single biggest driver of how long an invoice sits in your AP queue and how much it costs to process. Below is what each type is, where non-PO invoices legitimately come from, how AP handles one end to end, what the journal entry looks like, and how the two routes differ inside SAP.

What is a non-PO invoice?

A non-PO invoice is an invoice a supplier sends without a corresponding purchase order in your system. Nobody raised a requisition, nobody approved a PO, and no commitment was recorded before the money was spent. The first time finance learns about the purchase is when the bill lands. Because there is no order and usually no goods receipt, the standard matching controls have nothing to compare against.

Non-PO invoices are sometimes called non-PO based invoices or non-PO backed invoices. The terms mean the same thing. There is no formal "full form" beyond the obvious one: an invoice not backed by a purchase order.

What is a PO invoice?

A PO invoice references a purchase order that was raised and approved before the purchase happened. The approval already occurred at the PO stage, the budget was committed then, and the invoice is simply the supplier asking to be paid for something you already agreed to buy. AP validates it by matching, not by re-approving it. If the invoice agrees with the PO and with the receipt, it can go straight to payment.

This is why the two document types are governed differently. The control on a PO invoice sits at the front of the process. The control on a non-PO invoice has to happen at the back, after the money is already committed. Our explainer on purchase order vs invoice covers the underlying documents in more detail.

PO and non-PO invoice difference

What differsPO invoiceNon-PO invoice
Purchase order existsYes, raised and approved before the spendNo
When approval happensBefore the purchase, at the POAfter the invoice arrives
Validation methodTwo-way or three-way matchManual review and approver chase
GL codingInherited from the PODecided by AP or the approver
Budget visibilityCommitted when the PO is issuedNot visible until the bill arrives
Typical touch pointsOften zero if the match is cleanSeveral, across departments
Straight-through processingRealisticRare
Duplicate payment riskLower, the PO anchors the recordHigher, nothing to anchor against
Common spend typesGoods, materials, contracted servicesUtilities, subscriptions, professional fees

Non-PO invoice examples

Non-PO invoices are not a failure by definition. Plenty of legitimate spend does not justify raising an order first. The usual categories in a US business are:

  • Utilities and telecom. Electricity, gas, water, internet, and mobile bills that recur monthly at a variable amount.
  • Rent, property charges, and insurance premiums. Governed by a lease or policy rather than a PO.
  • Professional fees. Legal counsel, audit fees, and tax advisory work billed against an engagement letter.
  • Software subscriptions. Especially anything a department bought on a card and finance meets at renewal.
  • Employee expense reimbursements and travel. Booked and incurred long before AP sees the paperwork.
  • Freight surcharges and customs charges. Amounts nobody could have known in advance.
  • Small ad hoc purchases. The office coffee order, a replacement part, a one-off repair.
  • Genuine maverick spend. Somebody bought something they should have raised a requisition for. This is the category worth measuring, and it is covered in maverick spend.

The first six categories are usually fine. The last two are where policy is quietly leaking, and separating the two is the point of tracking non-PO volume at all.

How accounts payable processes a non-PO invoice

  1. Capture the invoice. Pull the header and line data off the document, whether it arrived by email, portal, or mail.
  2. Check for a duplicate. With no PO number to key against, this depends on supplier, invoice number, amount, and date. It is the weakest control in the whole non-PO flow.
  3. Work out what it was for. Sometimes obvious from the description, often not. This step frequently means emailing the supplier or guessing from history.
  4. Assign the GL account and cost center. AP either codes it or asks the requester to.
  5. Identify the approver. Find whoever had the authority to commit that spend, which is harder than it sounds when nobody recorded who bought it.
  6. Route for approval. Usually multi-tiered by amount, expense type, and location.
  7. Post and schedule payment. Only once coding and approval are both settled.

A clean PO invoice skips steps three through six entirely. That is the whole cost difference in one sentence.

Non-PO invoice approval: finding the right approver

Because the spend was never pre-authorized, approval on a non-PO invoice is a hunt rather than a lookup. Most organizations run a tiered delegation of authority: a department manager can approve up to a threshold, a director above that, a VP or CFO above that again, with extra rules by expense category or entity. AP has to establish two separate things, who requested the purchase and who has the authority to approve that amount, and they are frequently not the same person.

The practical failure mode is not rejection. It is silence. Invoices stall in inboxes, discounts lapse, and the supplier calls. Setting a standing rule for recurring non-PO categories, for example that the facilities manager owns every utility bill under a set amount, removes most of the chasing. For the PO side of the same problem, see the purchase order approval process.

Non-PO invoice coding: choosing the GL account

On a PO invoice, the coding was decided when the requisition was raised, and the invoice inherits it. On a non-PO invoice, someone decides at the moment of entry, which is why the same recurring charge sometimes lands in three different accounts across a year and the expense analysis stops being trustworthy.

Two things keep it consistent. First, a supplier-level default: if this vendor only ever supplies one kind of thing, the account should be pre-set rather than chosen. Second, a short, well-labeled account list for AP to pick from, because a 400-line chart of accounts guarantees inconsistency. Everything that gets coded by hand eventually shows up as a variance somebody has to explain, and cleaning that up at month end is exactly the work that automated account reconciliation exists to absorb.

Non-PO invoice journal entry

The entry itself is simple, and simpler than the PO route, because there is no goods receipt step and no GR/IR clearing account in the middle. On posting:

  • Debit the expense account, or the asset account if it is capitalizable
  • Credit accounts payable

Then on payment, debit accounts payable and credit cash. Sales and use tax is handled per your normal treatment for the state in question.

The complication is timing, not mechanics. A non-PO expense incurred in one period whose invoice arrives in the next has to be accrued, and there is no open PO report to tell you it is coming. That is a genuine month-end risk that PO-based spend does not carry. The full comparison sits in purchase order journal entry, and the accrual mechanics in purchase order accrual.

Non-PO invoices in SAP: FB60 and MIRO

SAP splits the two routes across two modules, which is the clearest illustration of how different they really are.

MIRO is Logistics Invoice Verification and lives in MM. You use it for invoices that reference a purchase order. It updates the vendor, the material master, and price difference accounts, and it handles planned and unplanned delivery costs against the order.

FB60 is the FI vendor invoice and posts directly through Financial Accounting with no PO reference. It updates the vendor and the expense accounts only. This is the transaction for printing and stationery, telephone, power, and audit fees, which is to say the classic non-PO categories.

Two details worth knowing. MIRO can be used for non-PO postings if direct posting to G/L account, material, and asset is activated in Customizing, so the split is a configuration choice rather than a hard wall. And there is a real duplicate-check gap between the two: if an invoice is first posted through FB60 and the same invoice is later entered through MIRO, SAP does not flag it, because the check inside MIRO looks at MM-posted documents rather than FI-posted ones. An invoice that entered through the "wrong" path sits outside the detection scope entirely. If your organization pays a meaningful volume of non-PO invoices, that is worth a periodic report rather than a standing assumption.

Why non-PO invoices cost more to process

Every step a human touches adds cost and days. A matched PO invoice can clear with no touches at all. A non-PO invoice needs coding, an approver hunt, and at least one round trip, and the round trips are what push it past the discount window.

Exceptions are the measurable version of this. Ardent Partners' AP benchmarking has put the average invoice exception rate at roughly 22 percent against about 9 percent for best-in-class teams, with the average improving in recent years. Invoices tied to a purchase order match at higher rates, process faster, and generate fewer of those exceptions, because the reference data already exists in the system. The gap between the two groups is largely a gap in how much spend runs through POs in the first place.

How to reduce the share of non-PO invoices

The goal is not zero. Utility bills do not need purchase orders. The goal is that every purchase which could have had one, did.

  • Define which categories require a PO and write the exceptions down, so AP is not adjudicating case by case. When do you need a purchase order walks through where the line usually falls.
  • Use blanket or standing orders for recurring suppliers. One approved order covering a period turns a stream of non-PO invoices into matched releases.
  • Report non-PO spend by department, not in aggregate. Aggregate numbers change nobody's behavior. A named list does.
  • Make raising a requisition faster than not raising one. Most maverick spend is a workflow problem wearing a compliance costume.
  • Enforce "no PO, no pay" only after the first four are in place. Applied early it just moves the argument from AP to the supplier.

Frequently asked questions

What is the full form of non-PO invoice?

There is no acronym to expand. "Non-PO" simply means not backed by a purchase order, where PO stands for purchase order. You will also see the same document called a non-PO based invoice or a non-PO backed invoice. All three refer to a supplier invoice that has no corresponding purchase order in the buyer's system.

Who approves a non-PO invoice?

Whoever holds the spending authority for that amount and expense type under your delegation of authority, which is usually a department manager below a threshold and a director, VP, or CFO above it. Because the purchase was never pre-authorized, AP has to identify both the requester and the correct approver after the fact, and they are often different people.

Can a non-PO invoice be paid without approval?

It should not be. A PO invoice can legitimately skip human approval because the approval already happened when the purchase order was issued. A non-PO invoice has had no approval at any point, so paying it unreviewed means paying for something nobody in the organization formally authorized. Recurring utility bills under a set threshold are the usual controlled exception.

Is a non-PO invoice legal?

Yes. There is nothing improper about paying a supplier invoice with no purchase order behind it, and US businesses do it every day for rent, utilities, and professional fees. It is an internal control question, not a legal one. The risk is weaker duplicate detection, unbudgeted spend, and inconsistent GL coding rather than any regulatory exposure.

Can you convert a non-PO invoice into a PO invoice?

You can raise a retrospective purchase order and reference it, and some organizations require this to close the audit trail. It does not recover the control, because the money was already committed before anyone approved anything. Treat retrospective POs as a documentation fix and as a signal about which department needs a faster requisition path.

What is the difference between a non-PO invoice and an expense report?

A non-PO invoice is billed by the supplier to the company and paid to the supplier. An expense report is a reimbursement claim from an employee who already paid a supplier personally, usually on a personal or corporate card. Both bypass the purchase order route, but they run through different workflows and hit different liability accounts.

Where clean purchase order data fits

Shifting spend from non-PO to PO only pays off if the PO route is genuinely faster, and for a lot of teams it is not, because the purchase orders arrive as PDFs and somebody retypes them. PurchaseOrders reads a purchase order PDF, scan, or photo and returns the header fields and the full line-item table as Excel, CSV, JSON, or an API response, so the order reaches your ERP as data instead of as a typing job. Upload one at the top of this page to see the output.

To be clear about the boundary: we capture purchase order data from documents. We do not create purchase orders, route approvals, hold budgets, perform three-way matching, or post to your ledger. Those stay in your ERP and your P2P system.

Related reading: what is a 3-way match covers the control that PO invoices get and non-PO invoices cannot, invoice matching automation looks at how the match is run at volume, and the purchase order to invoice process traces the full path from order to payment. If the bottleneck is document entry rather than policy, purchase order automation software explains where extraction sits in the workflow.

Stop retyping purchase orders

Upload a PDF, scan, or photo of any PO and get clean Excel, CSV, or JSON line items in seconds.

Try it free

25 pages free. No credit card required.