Ask any Head of Accounts Payable which invoices keep them up and it's almost never the ones with a purchase order. Those arrive with a supplier, a price, an owner and an approval history already attached. The ones that wait are the others: the consultant who invoiced without a PO, the utility bill for a site no one remembers, the software renewal that landed in a shared inbox.
They're a small share of the volume and most of the chasing, and they don't wait because the document is difficult to read. OCR handles them in seconds. They wait because everything a purchase order would have carried, from the spend owner to the account code to the approval threshold, has to be rebuilt by a person one invoice at a time, and that reconstruction is what your month-end actually pays for.
What the invoice is actually asking
Strip away the PDF and a non-PO invoice is five questions in a trench coat: who owns this spend, which entity pays, how it should be coded, who can approve at this amount, and whether there's a tax, duplicate or bank-detail problem hiding somewhere in it.
A purchase order answers four of the five before the invoice even exists, which is why no one notices how much work those answers represent until an invoice turns up without one. Your team has been answering them by email for years.
SAP makes the gap visible rather than hiding it. Logistics Invoice Verification lets AP enter invoices without a purchase order reference when the posting goes to a G/L account or a material account, which means the coding has to come from somewhere other than the order. Somewhere, in most AP teams, is a person's memory.
The four ways an invoice is allowed to finish
Before you change any tooling, agree on how an invoice ends. Four outcomes cover the whole population:
- It moves. The evidence is complete and it continues down the approved path.
- It goes to an owner. A named person supplies the missing context, usually whoever committed the spend.
- It goes to a control owner. A specific risk needs a decision: changed bank details, a possible duplicate, a tax question.
- It goes back. The supplier gets it returned with a reason.
That list does more for a non-PO programme than any automation target. It tells finance which work can shrink and which decisions stay with a person, and it gives your team shared words for the exceptions that used to be handled by asking around.
Coding has to be a proposal, not a verdict
The usual fear about automating non-PO invoices is that software will code them wrong at scale. It will, if you let it decide alone.
The design that holds is narrower. The agents propose, a named person decides, and the record shows what was checked. Every correction feeds the next proposal, so after a few weeks your team is confirming far more often than correcting. And the corrections cluster. When they keep landing on the same two or three cost centres, you're usually looking at a policy gap rather than a model problem.
Keep supplier changes on their own track. An invoice carrying new bank details should never update the master record on its own, however confident the extraction was. It goes to the control owner with the old and new details side by side. Noticing is automatable. Deciding isn't.
What the first month looks like
Look at policy before tooling, because policy shrinks the population itself: a no-PO-no-pay rule pushes buyers to raise the order first, and framework orders cover the recurring spend that will never carry one. Automation comes after that work, not instead of it.
Then resist the temptation to start with the clean subset. Start with the invoices that are a challenge today, from the suppliers and sites that generate the most chasing, because a pilot run on easy invoices will tell you nothing your team didn't already know.
Watch three numbers from the first week: how many invoices reach an owner with the context already attached, how long each exception waits before anyone acts once you break it down by reason, and which reasons keep repeating. That last one matters most, because a repeating reason is a process defect that automation has just made visible for the first time.
By the second close, the questions in your team's stand-up change from where is this invoice to why does this supplier keep invoicing without a PO.
What Hypatos rebuilds when the PO is missing
The missing purchase order is exactly the context the Hypatos Invoice Processing Workforce reconstructs. It identifies and enriches the supplier against your master data, assigns the legal entity from the ERP, proposes GL coding learned from your own historical coding, checks for duplicates before posting, and routes by spend owner and approval authority.
The instructions behind all of it are yours. AP writes them in plain language and AP changes them, on the condition that every change is recorded, dated and owned like any other policy change.
Hypatos fits when the work you want back is the reconstruction instead of the decision, and when your controller needs to see what was read, what was proposed and who approved it.
Give it the invoices your team dreads. Then ask which of them still needed a person, and why.
