Non-PO Invoice vs PO Invoice: Meaning, Examples, Processing
Jul 26, 2026
Jul 26, 2026
Convert a purchase order to Excel, CSV, or JSON
Submit your purchase orders
Drop documents here, or click to file
Up to 50 files per batch
Uploading...
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.
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.
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.
| What differs | PO invoice | Non-PO invoice |
|---|---|---|
| Purchase order exists | Yes, raised and approved before the spend | No |
| When approval happens | Before the purchase, at the PO | After the invoice arrives |
| Validation method | Two-way or three-way match | Manual review and approver chase |
| GL coding | Inherited from the PO | Decided by AP or the approver |
| Budget visibility | Committed when the PO is issued | Not visible until the bill arrives |
| Typical touch points | Often zero if the match is clean | Several, across departments |
| Straight-through processing | Realistic | Rare |
| Duplicate payment risk | Lower, the PO anchors the record | Higher, nothing to anchor against |
| Common spend types | Goods, materials, contracted services | Utilities, subscriptions, professional fees |
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:
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.
A clean PO invoice skips steps three through six entirely. That is the whole cost difference in one sentence.
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.
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.
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:
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.
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.
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.
The goal is not zero. Utility bills do not need purchase orders. The goal is that every purchase which could have had one, did.
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.
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.
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.
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.
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.
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.
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 free25 pages free. No credit card required.