PO-Backed and Non-PO Spend, Explained

Most organisations run two entirely different kinds of buying, and treat them as one process because both end with an invoice.

They are not one process, and pretending otherwise is where invoice automation makes promises it cannot keep.

PO-backed spend

Somebody decided in advance what to buy, at what price, with authority to commit the money. A purchase order records that. Goods arrive and somebody counts them. A receipt records that.

By the time the invoice shows up, two independent records already exist that describe what should be on it. Checking the invoice is a comparison, and the answer is knowable without asking anybody anything.

This is the case where automation can make a strong claim. The invoice can be treated as a claim to be verified rather than a document to be entered, and the resulting purchase invoice can be constructed from the receipt and the order rather than from the PDF. A misread number causes an exception; it cannot cause a wrong posting, because no number from the invoice is used to build the document.

Non-PO spend

Nobody raised an order. There is no receipt, because there was nothing physical to count.

A tree comes down across the yard in a storm and somebody calls a contractor at 6am. A lawyer sends a bill for advice given over three months. The electricity bill arrives. A specialist repair firm invoices for a callout that was authorised over the phone.

None of these are failures of process. Some spend genuinely cannot be planned, and requiring a purchase order for a 6am emergency is a policy that gets ignored rather than followed.

But the consequence is precise: there is nothing in your system to check the invoice against. Not because the software is inadequate, but because the fact of the matter was never recorded anywhere except on the invoice itself.

What automation can and cannot promise about each

This is the distinction worth being pedantic about, because it is where marketing copy usually blurs.

On a PO-backed invoice, a system can honestly claim: a wrong number on the vendor’s PDF cannot become a wrong posting. That is a structural property. It follows from where the numbers come from.

On a non-PO invoice, no system can make that claim, regardless of how good its extraction is. If the invoice says £4,200 and the real figure was £2,400, there is nothing anywhere that disagrees. The only defence is a person who reads the document and knows what was agreed.

A product that presents these two paths as if they carried the same guarantee is either confused or being careless with the word “cannot”.

What replaces the receipt

If the posted receipt is the control on the PO-backed path, something has to stand in for it on the other. Three things, together:

A person codes it. Not the model. The G/L account, the dimensions and the amount are typed by somebody who read the document. That is slower, and it is the point: the human coding is the only judgement available.

Nothing is pre-filled from what was read. This is more important than it sounds. If a system pre-populates the amount from its own extraction and asks a person to confirm, most people confirm. Pre-filling converts a decision into a click, which is precisely the failure the manual step exists to prevent. The extracted claim can be shown beside the coding grid for reference; it should not be in it.

An approver authorises it. On the PO-backed path the authorisation happened before the spend, when the order was raised. On this path nothing was authorised in advance, so the authorisation has to happen now, and it has to be mandatory rather than a policy option. An approval that can be skipped when no rule matches is not a control.

Mark it, permanently

The two paths produce documents of genuinely different trust classes, and the difference matters long after posting.

A reconciled invoice’s figures came from your own records. A manually coded invoice’s figures came from a person reading a PDF. An auditor looking at a posted entry two years later should be able to tell which, without reconstructing the history.

That means the marking belongs on the record, not in a log — set at registration, and still there after posting.

It also means the two should never be shown the same way on screen. If a clerk cannot tell at a glance which class of document they are looking at, the distinction only exists on paper.

Reducing the non-PO share

The genuinely unplannable emergency is rare. Most non-PO spend is one of two things that can be moved onto a checkable footing:

Recurring, predictable costs — rent, retainers, subscriptions, maintenance contracts. These do not need a purchase order, but they do need an authority: a contract record with a period and a cap, so the invoice has something to be checked against. That converts a “code it by hand every month” into a check.

Spend that could have had a PO and didn’t. Somebody ordered without raising an order. That is a process problem with a process fix, and it is worth measuring: the proportion of your invoices arriving with no purchase order is a decent proxy for how much of your AP control is currently a person’s attention.

Neither of these makes non-PO spend disappear. Both shrink it, and shrinking it is the highest-leverage thing you can do — because every invoice moved onto the PO-backed path moves from checked by a person to checked by construction.