Non-PO invoices: what an automated flow can match them against instead
In short
A non-PO invoice has no commitment record behind it: nobody raised a purchase order, so there is no agreed quantity, price or delivery date to join it against. An automated flow can still clear one, but only against a substitute commitment — a contract schedule, a subscription term, a prior-period pattern, or a requester's attestation.
Key takeaways
- A non-PO invoice is defined by the record that is missing: the commitment, not the paperwork.
- 4 substitutes exist: contract schedule, subscription term, prior period, requester attestation.
- Only the first 3 let a system decide alone. Attestation records accountability, not agreement.
- For rent, retainers and utilities, the median of the last 6 periods beats any purchase order.
- Losing the PO loses 3 controls at once: the value cap, the quantity consumed, and the GL coding.
A non-PO invoice is an invoice with no commitment behind it. Somebody bought something without raising a purchase order, so no record exists of what was agreed, at what quantity, at what price, for delivery when. The document that arrives is a claim, with nothing on your side to test it against.
That precision matters, because the usual framing — an invoice that arrived without a PO number on it — points at the wrong problem. An invoice missing a reference where a PO exists is a lookup failure. An invoice where no PO was ever raised is a control failure, and better extraction fixes nothing.
Services are where it concentrates. Advisory work, a recruitment fee, an agency retainer: the deliverable is not countable, the price was agreed in an SOW, and the line reads "professional services rendered, March". That is a sentence, not a line item, and there is nothing in it for a three-way match to key on.
Four substitutes for the missing commitment, strongest first
| Substitute | What it supplies | What a system clears alone | What it cannot settle |
|---|---|---|---|
| Contract or SOW schedule | Agreed rates, milestones, term dates, a value cap | Amount against schedule, period against term, total against cap | Whether the work was performed |
| Subscription or licence term | Unit count, per-unit charge, frequency, renewal date | Seat drift against the last billed period, charges outside the term | Whether the units are still needed |
| Prior-period pattern | Trailing history for the supplier, GL account and cost centre | Amounts inside a band around the trailing median, on cadence | A price rise that is legitimate and permanent |
| Requester attestation | A named person asserting they ordered and received it | Nothing alone — it records who is accountable | Everything: it evidences approval, not commitment |
The order matters more than the list. A contract schedule is a commitment recorded before the money was spent, which is what a PO is. A prior-period pattern infers one afterwards. An attestation is a person taking responsibility for the absence of one. Treat them as interchangeable and the approval step means nothing.
Rent, retainers and utilities: last period beats any purchase order
For a recurring charge the strongest reference available is what you paid last time. It carries more than a PO would: it reflects the arrangement as it runs, and it updates itself every cycle. The work is in the band, and in what counts as breaking the pattern.
- Build the baseline from the last 6 charges on the same supplier, GL account and cost centre, using the median. One disputed month at triple the usual amount moves a mean and barely touches a median.
- Set the band as a percentage and an absolute together, accepting only when both hold. A 5 percent band on a small standing charge fires constantly; the same 5 percent on a large one passes a substantial rise unseen.
- Encode known step changes rather than treating them as anomalies. Index-linked uplifts, rate reviews and seasonal utility swings are contractual, and flagging them annually trains everyone to click through.
- Define what breaks the streak: a changed cadence, a missing cycle, a new account code, a different remit-to entity, the first invoice after a bank-detail change. Any of those means the pattern is no longer evidence.
- State the action on breach — hold, route to the budget owner, or clear and post the variance — and record which rule decided, so the flow is auditable rather than trusted.
The two places this leaks
- Duplicates. With no PO line to consume, no running total exists for a second invoice to exhaust, so the duplicate check is the only defence — and a re-billed services invoice arrives with a new number and a slightly different amount, evading an exact-match check by design. That is finding the near-duplicate your check missed.
- Amounts nobody can allocate. A services invoice can pass the amount test with no defensible home in the ledger, because the cost centre was never decided. A suspense account with an owner and an age is the honest place for it; coding it to the requester's default surfaces at year end as a reconciliation nobody can unwind.
Both share a cause. In a PO flow the commitment record does work you never see: it caps the total, it consumes quantity as deliveries land, and it carries the coding. Remove it and 3 controls disappear together.
What a non-PO flow must never decide
Two supporting records decide whether the flow works. A supplier record complete enough to know which entity is billing you and on what terms, which is the argument in the vendor master record. And a variance rule with a basis and a direction rather than one company-wide percentage, set out in what a matching engine may wave through. Non-PO invoices lean on both harder, because no commitment record is absorbing the ambiguity.
A purchase order is not paperwork. It is the only record that exists before the money is spent, and a non-PO flow is an attempt to reconstruct one afterwards.
So the first pass, when we scope this inside an MVP or product build, is a count rather than a design: what share of invoice volume, and what share of invoice value, arrives with no commitment behind it, split by category. A team finding 60 percent of lines non-PO has a procurement problem to fix before an automation problem to solve. The rest of invoice to pay: capture, matching and approvals assumes that count exists, as does our finance operations work generally.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
What is a non-PO invoice?
It is an invoice for which no purchase order was ever raised, so nothing records what was agreed before the money was committed. That differs structurally from an invoice that simply arrived without a PO number quoted: the second is a lookup failure you can resolve by finding the order, the first has nothing to find. Non-PO spend concentrates in services, professional fees, subscriptions and recurring charges.
What is the difference between a PO and a non-PO invoice?
A PO invoice has a commitment record behind it and a non-PO invoice does not. That single difference removes 3 controls: the purchase order caps what can be billed, consumes quantity as deliveries are received, and carries the account coding decided in advance. A non-PO flow has to reconstruct all three from something else, which is why it needs a substitute commitment rather than just an approver.
How do you approve an invoice without a purchase order?
Match it to the strongest substitute commitment available before it reaches an approver. A contract or SOW schedule supplies agreed rates, a term and a value cap; a subscription record supplies unit counts and a frequency; a recurring charge supplies a trailing median. Attestation should be last, because it records who is accountable rather than what was agreed.
Can an invoice with no line items be matched automatically?
Not at line level, but the amount and the period still can be. A monthly retainer billed as one line can be tested against the contract schedule for that month, the term dates, and the total already billed under the cap. That clears the common case and isolates the odd ones. What it cannot establish is whether the work happened, which is why services flows keep a named requester in the loop even when the numbers agree.
- accounts payable
- non-PO spend
- invoice matching
- approvals
The work behind this page
Builds from our portfolio that this page draws on.
Read next
- Three-way matching: the documents, and the fields the join runs onThe purchase order, the goods receipt and the invoice each assert something different. Matching them is a join on 8 fields, and every one is a place it can fail.definition
- The vendor master record: the fields that decide whether an invoice can be automated at allSix field groups, four fields almost nobody has, and the reason one supplier ends up as five rows. Most AP automation failure is a vendor master problem wearing a matching costume.definition
- Tolerance rules: what a matching engine is allowed to wave throughOne global percentage leaks on high-value lines and screams on low-value ones. A usable tolerance carries a basis, a direction, a percentage-and-absolute pair, a supplier override and a cumulative cap.definition
- The same invoice got paid twice: finding the near-duplicate your check missedThe exact-match check passed because the second document differed in one of the three fields it compares. Five ways one bill becomes two, the fuzzy key that catches each, and where the sweep belongs.diagnostic
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation