PO-backed invoices are the easy part of accounts payable: there is a purchase order to match against, the data lines up, and automation handles them well. Non-PO invoices are the hard part, and they are a large share of most companies' invoice volume. With no purchase order, there is nothing to match against, the coding has to be determined from scratch, and the approval routing requires judgment. This is precisely why AP automation so often stalls, and why non-PO invoices are the problem worth solving. Here is why they resist automation and how AI actually handles them.
TL;DR
A non-PO invoice is an invoice that arrives without an associated purchase order, common for expenses like utilities, professional services, subscriptions, rent, and ad hoc purchases that were never run through a procurement PO process. Non-PO invoices are a large share of invoice volume at most companies, and they are the hardest invoices to automate.
They are hard for three specific reasons, all stemming from the absence of a PO. There is nothing to match against: PO-backed invoices are validated by matching to the purchase order and receipt (two-way and three-way match), but a non-PO invoice has no PO to match, so the core AP validation mechanism does not apply. The coding must be determined from scratch: a PO-backed invoice typically inherits its GL coding, cost center, and approval path from the PO, while a non-PO invoice has none of that, so the correct accounting treatment must be determined for each one. And the approval routing requires judgment: with no PO to define who approves, the system must determine the right approver based on the invoice's content, amount, and context.
This is why non-PO invoices are the main reason AP automation plateaus. Rule-based automation handles the PO-matched invoices well and routes the non-PO invoices to human queues, where they consume most of the AP team's time, because each requires reading, coding judgment, and routing decisions that rules cannot make. Non-PO invoices are, in effect, the exception that constitutes much of the unautomated remainder.
AI handles non-PO invoices by doing the reading and reasoning that rules cannot: extracting the data from any invoice format, predicting the correct GL coding from the invoice content and historical patterns, determining the appropriate approver, and flagging genuine issues, learning from each resolution so the coding and routing improve over time. This is what extends AP automation into the non-PO invoices that otherwise stall it.
This post covers what non-PO invoices are, why they resist automation, why they cause the AP plateau, and how AI handles them. For the full AP context, see Accounts Payable Automation: The 2026 Guide.
What a non-PO invoice is
A non-PO invoice is an invoice received without a corresponding purchase order. In a PO-based purchase, the company issues a purchase order before the purchase, specifying what is being bought, at what price, with what terms and coding, and the resulting invoice is matched against that PO (and the goods receipt) to validate it before payment. A non-PO invoice has no such purchase order behind it, so it arrives with no pre-existing record to validate or code against.
Non-PO invoices arise for many legitimate reasons. Some purchases do not naturally run through a PO process: recurring expenses like utilities, rent, and subscriptions; professional and legal services; ad hoc or low-value purchases; and expenses that a department incurs without raising a PO first. In many organizations, especially outside of direct materials and procurement-governed spend, a large share of invoices are non-PO, sometimes the majority, because much of indirect and services spend simply does not flow through purchase orders.
This makes non-PO invoices not an edge case but a core, high-volume part of accounts payable, and because they are structurally different from PO-backed invoices (no PO to anchor matching, coding, and approval), they require a different handling approach. Treating them as a minor exception understates the problem; for many companies, non-PO invoices are a major share of AP volume and the dominant source of manual AP effort.
Why non-PO invoices resist automation
Non-PO invoices are hard to automate for three specific reasons, all flowing from the absence of the purchase order that anchors PO-based AP automation.
There is nothing to match against
The core validation mechanism of AP automation is matching: comparing the invoice to the purchase order (two-way match) and the goods receipt (three-way match) to confirm the invoice is legitimate, agrees with what was ordered, and reflects what was received. This matching is what lets PO-backed invoices be validated and approved automatically. For more on how that mechanism works, see Best Procurement Automation Platforms for 3-Way Match Validation. A non-PO invoice has no purchase order to match against, so this entire mechanism does not apply. The system cannot confirm the invoice against an order because there is no order, so validating a non-PO invoice requires a different approach: determining whether it is legitimate and should be paid without the anchor of a PO. This is the foundational difficulty, the automation technique that handles PO invoices simply has no input for non-PO ones.
The coding must be determined from scratch
For a PO-backed invoice, much of the accounting is predetermined: the purchase order typically carries the GL account, cost center, and other coding, which the invoice inherits, so the system knows how to code it. A non-PO invoice carries none of this. The correct GL coding, cost center, department, project, and tax treatment must be determined for each non-PO invoice individually, based on what the invoice is for, who incurred it, and the organization's coding rules. This is judgment-laden work: determining that a given professional-services invoice should hit a particular GL account and cost center requires understanding the invoice content and the coding structure, which rule-based automation cannot reliably do across the variety of non-PO spend. Coding is consistently one of the most time-consuming parts of processing non-PO invoices manually.
The approval routing requires judgment
For a PO-backed invoice, the approval often happened at the PO stage (the purchase was approved when the PO was raised), and the routing is defined by the PO. A non-PO invoice has no PO-defined approver, so the system must determine who should approve it, based on the invoice's amount, the department or cost center it belongs to, the nature of the expense, and the organization's approval policy. Determining the right approver from the invoice's content and context, rather than from a pre-defined PO, requires judgment that simple routing rules struggle with, especially across the variety of non-PO spend and organizational structures.
Together, these three, no matching anchor, coding from scratch, and judgment-based routing, make non-PO invoices structurally resistant to the rule-based automation that handles PO invoices. They are not hard because the rules are not good enough; they are hard because they require reading, judgment, and reasoning that rules cannot provide.
Why non-PO invoices are the AP automation bottleneck
The three difficulties above explain a pattern most finance teams recognize: AP automation handles the PO-backed invoices well and then stalls, and the touchless rate plateaus. Non-PO invoices are the main reason.
The dynamic is straightforward. PO-backed invoices fit the matching-based automation that AP tools provide, so they automate readily, the clean three-way matches flow through without human touch. Non-PO invoices do not fit that automation, for the three structural reasons above, so they route to human queues, where AP staff read each one, determine the coding, decide the approval routing, and process it manually. Because non-PO invoices are a large share of volume, this manual remainder is substantial, and it is where most of the AP team's time goes.
This is why the AP touchless rate commonly plateaus around 70%: roughly the PO-backed share automates, and the non-PO share (plus other exceptions like PO mismatches) stalls in manual handling. The plateau is not a sign the automation is poorly configured; it is a sign that the automation handles PO invoices and that non-PO invoices need a fundamentally different capability. A company that has automated its PO invoices and is frustrated that the touchless rate will not climb is usually looking at a non-PO invoice problem, the automation has done what matching-based automation can do, and the non-PO invoices need reading and reasoning, not better matching rules. This is the same plateau dynamic analyzed in Why Most Agentic AP Pilots Stall at 70% Touchless, with non-PO invoices as a primary driver.
The implication is that getting past the AP plateau is largely about automating non-PO invoices, because they are where the unautomated volume and the manual time concentrate. A team that solves non-PO invoice automation moves the metric that matching-based automation cannot.
How AI handles non-PO invoices
AI extends AP automation into non-PO invoices by doing the reading, coding, and routing judgment that rule-based matching cannot. The best AI invoice processing platforms address each of the three structural difficulties:
Reading and extracting from any format. AI reads non-PO invoices in any layout, from any vendor, extracting the relevant data (vendor, amount, line items, dates, description of what was purchased) without requiring a PO or a per-vendor template. This handles the format variety of non-PO spend, which comes from many vendors in many forms, and gets the invoice content into a usable form, the necessary first step when there is no PO to provide structured data.
Validating without a PO. Since there is no PO to match against, AI validates non-PO invoices through other means: checking against vendor master data, detecting duplicates, validating the invoice is from a legitimate vendor and consistent with expected patterns, and flagging anomalies. Good vendor master data and supplier records are an important input here; see The Top AI Tools for Vendor Management and Supplier Onboarding in Finance for the tools that maintain this data. This substitutes a reasoning-based validation for the matching-based validation that PO invoices use, addressing the no-anchor problem by assessing legitimacy from context rather than from a PO.
Predicting the coding. This is one of the highest-value capabilities. AI predicts the correct GL coding, cost center, and other accounting treatment for a non-PO invoice based on the invoice content (what was purchased), the vendor, the requesting department, and historical patterns of how similar invoices were coded. Rather than a human determining the coding from scratch for each invoice, the AI proposes it, learning from the organization's coding history, which addresses the coding-from-scratch difficulty that is so time-consuming manually.
Determining the approval routing. AI determines the appropriate approver for a non-PO invoice based on its amount, the department or cost center, the nature of the expense, and the approval policy, routing it correctly without a PO-defined path. This addresses the judgment-based routing difficulty by reasoning about who should approve from the invoice's content and context.
Learning from resolutions. Critically, AI that learns from how non-PO invoices are coded and routed improves over time: each human correction or confirmation teaches the system, so the coding predictions and routing get more accurate, and more non-PO invoices process without human intervention as the system learns the organization's patterns. This is what turns non-PO invoice automation from a static capability into one that climbs, progressively converting the manual remainder.
Together, these capabilities address exactly the three reasons non-PO invoices resist rule-based automation, substituting reading and reasoning for the matching, predetermined coding, and PO-defined routing that non-PO invoices lack. This is what extends AP automation past the PO-invoice plateau into the non-PO volume.
The architecture point: accuracy and auditability matter
A note on doing this well, because non-PO invoice automation can be done in a way that creates problems. The coding and approval decisions AI makes on non-PO invoices flow into the financial statements (the GL coding determines how spend is recorded) and into the control environment (the approval routing is a control), so accuracy and auditability matter, not just speed.
The wrong way to automate non-PO invoices is to auto-code and auto-route aggressively in a way that is fast but opaque and error-prone, miscoding spend or bypassing proper approval, which creates accounting errors and control weaknesses that surface later, often in an audit, and cost more to fix than the manual handling would have. The 7 Places Generative AI Quietly Fails in Accounts Payable covers several of these failure modes in detail. The right way is AI whose coding and routing decisions are accurate and explainable: you can see why an invoice was coded to a particular account and routed to a particular approver, and reconstruct the decision if questioned. See AI Audit Trail Requirements: A 2026 Checklist for what an auditable AP automation setup needs to document.
This is where neurosymbolic, deterministic agentic automation fits the non-PO problem well. Kognitos approaches non-PO invoices as agentic automation that reads the invoice, reasons about the correct coding and approval routing in plain language, and applies the organization's policies deterministically, with every decision logged and explained. Because it is deterministic, the same invoice produces the same coding and routing every time, and because the reasoning is explicit, every coding and routing decision is explainable and auditable. That combination, doing the reading and reasoning to handle non-PO invoices, plus the determinism and auditability so the coding and approval decisions are accurate and defensible, is what handling non-PO invoices well requires, because those decisions feed the financial statements and the control environment. Kognitos implements this through its English as Code approach, which lets finance teams define and refine coding rules and approval policies in plain language rather than relying on developer configuration, so the rules stay current as the organization's coding structure and approval hierarchy change. For a fuller picture of how Kognitos supports AP and broader finance operations, see Finance & Accounting Automation Solutions.
Book a working session with a Kognitos solutions engineer → Try Kognitos free →
Putting it together
Non-PO invoices, invoices that arrive with no purchase order behind them, are a large share of AP volume and the hardest invoices to automate, for three structural reasons: there is no PO to match against, the coding must be determined from scratch, and the approval routing requires judgment. These difficulties make non-PO invoices resistant to the matching-based automation that handles PO invoices well, which is why they route to human queues and consume most of the AP team's time, and why AP touchless rates commonly plateau around 70%, roughly the PO-backed share. Getting past that plateau is largely about automating non-PO invoices, and AI does this by doing the reading and reasoning rules cannot: extracting data from any format, validating without a PO, predicting the coding from content and history, determining the right approver, and learning from each resolution. Done well, with accuracy and auditability rather than just speed, since the coding and approval decisions feed the financial statements and the control environment, AI non-PO invoice automation extends AP automation into the volume that otherwise stalls it, which is where most of the remaining AP value and manual time concentrate.