A non-PO invoice is a supplier invoice that has no purchase order behind it. Nothing was formally ordered through procurement, so when the invoice arrives there is no order to match it against. It has to be validated a different way, and it frequently becomes an exception.
Non-PO invoices are a routine part of buying. They are how most companies handle services and small, one-off purchases.
A non-PO invoice arrives with no promises attached
A PO-backed invoice can be checked automatically because the purchase order states what was agreed. A non-PO invoice has no such reference. The company knows it received a bill, but the system has no prior record of what was promised, at what price, or who authorized it. Everything the match would normally verify has to be reconstructed after the fact.
There is nothing for the match to check
Three-way matching needs three documents. A non-PO invoice usually has one. There is no order, and for services there is often no goods receipt either, because nothing physical arrived to confirm. That removes the automated check entirely and puts the burden on a person to decide whether the invoice is legitimate and correct.
Services and tail spend will always produce them
Most non-PO invoices are services and tail spend: a consultant's monthly fee, a legal bill, a utility, a facilities repair, a subscription. These are hard to put on a purchase order in advance because the amount is not known until the work is done. They also come from maverick spend, where someone buys outside the normal process and the invoice is the first the AP team hears of it.
Validation falls on whoever holds the context
Without a match, validation falls back on approval. The invoice goes to the person who requested the service to confirm it is real, that the amount is right, and that the work happened. It then needs general ledger coding, because there is no order to inherit the coding from. Both steps depend on a person who has the context, which is why non-PO invoices sit longer than matched ones.
Push spend onto orders, then resolve the rest autonomously
Companies push spend onto purchase orders where they can, using blanket orders for recurring services and catalogs for common buys. This lowers the count but does not remove it, because some spend genuinely cannot be ordered in advance. For the invoices that remain, the work is reading the contract, the approver, and the history of similar invoices to validate and code them, which is exactly the context a person applies by hand today.
Fragment validates and codes non-PO invoices autonomously by reading the contract, the approver, and prior invoices for the same service, without ripping out or replacing your existing systems. See how it works or request a demo.