AI Answer Summary

A non-PO invoice is a supplier invoice with no purchase order behind it. Common examples are utilities, repairs, phone bills, subscriptions, professional services and one-time purchases.

With no purchase order to match against, the business has to establish another way that the purchase was authorized and delivered: a contract, an approved request, an established recurring arrangement, or a budget owner's confirmation. Before treating an invoice as non-PO, check whether a purchase order exists and the supplier left the reference off.

A workflow can classify the invoice, find the purchase order or contract, gather the evidence and route it to the right approver. The approval itself stays with a person who has the authority to give it.

What Is a Non-PO Invoice?

A non-PO invoice, or non-purchase order invoice, is a supplier invoice that arrives with no purchase order behind it, so there is no approved order to match it against.

Many legitimate purchases never go through a purchase order. SAP's own training lists utilities, repairs, phone bills and entertainment as typical examples, along with one-time transactions. Most companies add professional services, software subscriptions and rent. For these, raising a purchase order before every bill would add work without adding much control, because the price or quantity is set by an existing arrangement or outside the buyer's control.

The term is used in two ways, and it helps to know which one a system or colleague means. Some companies call any invoice without a purchase order "non-PO." SAP Ariba recognizes three invoice types: PO-based, contract-based and non-PO. A contract-based invoice has no purchase order either, but it is matched against a contract's terms, and SAP's own course notes that the "non-PO" label can be misleading for exactly that reason. In SAP's narrower sense, a non-PO invoice is a standalone invoice with no purchase order or contract to validate it against.

This article uses the broad sense and treats contract-backed invoices as one of the situations below.

Two misreadings are worth avoiding from the start. A non-PO invoice is not evidence that anything went wrong, since much of a company's legitimate spend never needs a purchase order. And an invoice from a familiar supplier is not valid just because that supplier has been paid before.

PO vs Non-PO Invoice: What Changes When There Is No Purchase Order

Without a purchase order, the evidence that a purchase was authorized has to come from somewhere else, and the approval has to come from someone with the authority to give it.

The last row is the important one. For a PO invoice, the question is whether the invoice matches what was already approved, which is what three-way matching answers. For a non-PO invoice, the question is whether anything was approved at all, and by whom. Coding changes too: a PO invoice usually carries its codes from the order, while a non-PO invoice has to be coded from what the invoice and the business know, which our guide to invoice coding covers in detail.

Five Situations Behind an Invoice Without a Purchase Order

The same missing purchase order can hide five different situations, and each needs different evidence. Identifying which one applies is the first decision, before the invoice goes anywhere.

The order is deliberate, and the first situation deserves the closest look. SAP's guidance to suppliers says a non-PO invoice should be submitted only when there is no purchase order and no contract number, so an invoice that arrives without a reference has often lost one along the way. Searching open purchase orders by vendor, amount and date takes seconds, and when it finds a match the invoice goes back to normal matching instead of starting an approval chase that was never needed.

The second situation is what SAP calls a contract-based invoice. The third covers spend the company has decided does not need a purchase order, under a policy someone approved. The fourth is legitimate spend that arrived ahead of its paperwork. The fifth is the one control failure among them, and it needs a different response from the other four.

This gives a practical rule for deciding where purchase orders belong. Use them where the company needs authorization before money is committed. Use a controlled non-PO process where the purchasing model does not need one, as with utilities or contracted services. And investigate any purchase that went around an established policy. The aim is less unverified spend. A falling count of non-PO invoices proves little on its own, because forcing purchase orders onto utility bills lowers the count without making anything safer.

These five situations are a practical framework of our own, built on how systems such as SAP classify invoices. No accounting standard defines them.

How to Process a Non-PO Invoice, Step by Step

Process a non-PO invoice in nine steps, with the situation identified before anyone is asked to approve it.

1. Capture and validate the invoice. Record the supplier, the legal entity billed, the invoice number and date, the amounts and the tax.
2. Check the supplier and look for duplicates. Confirm a known vendor record with payment details that were verified independently, and search for an earlier invoice with the same number, amount or description.
3. Search for a purchase order or contract. A match puts the invoice in situation 1 or 2 and back on its proper path.
4. Identify the situation from the five above.
5. Gather the evidence that situation needs: the business purpose, proof of delivery or completion, and the authorization on file.
6. Code the invoice. Assign the general ledger account and dimensions from the context gathered. Our invoice coding guide covers the rules that decide a code.
7. Route it to an authorized approver under the company's delegation of authority, which sets who can approve what amount for which kind of spend.
8. Hold or escalate when evidence is missing, with a named owner and a recorded reason.
9. Post and release payment only after approval.

Four of these steps are easy to blur together: coding the invoice, recording the liability, approving the expense and releasing payment. They are separate acts, and none of them authorizes the others. Systems order them differently, and some record the liability before approval so the books stay complete at month end. What matters is that a coded or recorded invoice is never treated as an approved one, and that payment waits for the approval.

Non-PO Invoice Example: A Consulting Invoice Over Its Agreed Scope

A consulting provider sends an invoice for $7,800. The signed agreement covers $6,000 of work. The supplier has added $1,800 for extra services, and no approval for the extra work is on file. The example is fictional, and it shows the decision non-PO invoices most often create.

A workflow can do a great deal of the preparation here. It can read the invoice amounts, find the signed agreement, see that the invoice exceeds it by $1,800, pull any related correspondence, and present the approver with one package: the agreement, the invoice, the difference and the open question.

What it cannot do is decide that the extra work was authorized because the line item sounds plausible. "Additional advisory services" might be work the client asked for and forgot to approve in writing, or it might be scope creep the client never agreed to. Someone with authority over that budget has to say which, and the decision needs recording either way.

The example is not a recommendation to pay the agreed $6,000 and dispute the rest. Whether part-payment is appropriate depends on the contract's terms and the company's policy.

Why Non-PO Invoices Need Controls

Most non-PO invoices are legitimate, and the controls exist for the ones that are not, which an invoice without a purchase order is well placed to hide.

The ACFE's Occupational Fraud 2026: A Report to the Nations examined 2,402 cases across 143 countries, with more than $3.4 billion in losses and a median loss of $104,000 per case. Asset misappropriation appeared in 90% of cases, and the ACFE's key findings name billing schemes among the most significant fraud risks once frequency and financial damage are weighed together. A billing scheme runs on a fictitious or inflated invoice, and an invoice with no purchase order has skipped the control that would normally catch it.

Timing matters as much as detection. The ACFE found that fraud detected within six months had a median loss of $40,000, while schemes that ran for more than five years caused median losses exceeding $1.1 million. Checking a non-PO invoice before it is paid is the earliest point at which a problem can be caught.

The risks to design for are specific:

• Duplicates, where the same invoice arrives twice in different formats
• Missing authorization, where nobody with authority agreed to the spend
• The wrong approver, where someone approves spend outside their authority
• Weak evidence, where nothing shows the work was delivered
• Changed payment details, where a request to change a supplier's bank account arrives with or before an invoice
• Policy bypass, the fifth situation, where purchasing controls were ignored

Controls should match the situation. A recurring utility bill within its usual range needs a light check. An invoice for unexpected extra work needs evidence and an approver. Our guide to vendor statement reconciliation covers invoices that first appear on a supplier's statement, and our comparison of AP automation software includes a non-PO invoice in its test for evaluating products.

What to Automate in Non-PO Invoice Processing

Rules can enforce policy, a workflow can assemble the context, and people with financial authority make the decisions.

The first column is where most of the time savings come from, because it handles the checks that are the same every time. The purchase order search alone, run before anything is treated as non-PO, removes the invoices that only looked unmatched.

The middle column needs the most care in design. A suggested approver or a suggested code is useful when the reviewer can see why it was suggested, such as a past invoice from the same supplier or a clause in the contract. A suggestion with no reason attached has to be worked out again by the person reviewing it.

Not every invoice needs a fresh approval each time. A recurring bill under an established, approved policy, such as a utility invoice within its usual range, can follow a defined path, because the policy itself carries the authorization. The workflow's job is to confirm the invoice fits the policy and to send anything outside it to a person. Our guide to automating accounts payable covers how to tier decisions across the whole AP process.

Non-PO Invoices When an Accounting Firm Handles Client AP

An accounting firm handling AP for clients applies each client's own rules, and for clients it also audits or reviews, the approval belongs to the client.

Each client has its own policy on what can arrive without a purchase order, its own approvers and limits, and often its own systems. One client lets utilities and contracted services run without purchase orders; another requires a purchase request for nearly every discretionary purchase. A firm's workflow has to apply the right client's rules to the right client's invoices, and keep each client's data separate.

The approval question has a firmer answer than most firms realize. Under the AICPA's independence rules, approving vendor invoices for payment is among the activities that impair a firm's independence for a client it audits or reviews. A non-PO invoice is where this matters most, because no purchasing approval exists to rely on. The firm can classify the invoice, gather the evidence and propose the coding. The client's designated person approves, and the workflow records who did and when. Our guide to vendor statement reconciliation sets out the rules in full.

Non-PO Invoice Approval Checklist

Before a non-PO invoice is approved for payment, confirm each of these:

• The supplier is verified, and its payment details were confirmed independently
• No duplicate of the invoice exists
• The correct legal entity was billed
• A search for a purchase order and a contract was done
• The situation is identified
• The agreement, approved request or delivery evidence is attached
• The business owner is identified
• The coding is applied
• The approver has authority for this amount and type of spend
• Any policy exception has its own approval
• The payment-ready status is recorded

Adapt the list to your company's delegation of authority. A company that lets recurring utilities follow a policy path might apply only the first four checks and the last one to those invoices, and the full list to everything else.

How to Measure Your Non-PO Invoice Process

The number of non-PO invoices says little about whether the process works. These measures say more:

Time to identify the owner is usually the first number worth fixing, because a non-PO invoice with no known owner waits in a queue until someone recognizes it. Repeat policy bypass is the one to watch over time: the same department or supplier appearing in situation 5 month after month points to a purchasing problem that invoice processing cannot solve.

Start small. Measure one recurring invoice category, or one department or client, before automating anything, so the effect of any change is visible.

How Codebridge Builds Non-PO Invoice Workflows

The AP invoice resolution workflow described on our professional services page reads invoices, matches them to the ledger, runs bookkeeping checks and routes exceptions for approval.

A non-PO workflow could be built on that pattern as a tailored project: the purchase order and contract searches, the classification into the five situations, approval rules for each department or client, and an exception queue with the evidence attached. We describe it as a possible build, since the published workflow does not list these features, and the scope would depend on the company's systems and policies. The approvals stay with the people who hold the authority, and each decision is recorded.

The company owns the repository, the prompts and the configuration from day one. The closest reference we can offer, labelled for what it is: Knowledge Cloud, built for a Big Four tax and legal practice, runs an expert review queue with an immutable audit log, so a senior practitioner approves each output before the firm acts on it. A knowledge platform rather than an AP system. What it demonstrates is the review and approval-record pattern.

Our founding team spent more than a decade at KPMG.

If you want to look at where your non-PO invoices stall, book a 30-minute call.