The operational difference
A purchase order gives the invoice a reference point: authorised supplier, quantity, unit price, delivery location, tax treatment and budget coding. Matching can then release clean invoices automatically and route only genuine variances.
Without that reference, accounts payable must reconstruct the decision. The team may need to identify the requester, confirm receipt, obtain coding, apply approval rules and create a supplier record. Each hand-off increases cycle time and the risk of duplicates or late payment.
| Stage | PO-matched invoice | Non-PO invoice |
|---|---|---|
| Commitment | Approved order exists before supply. | Commitment may be implicit or documented elsewhere. |
| Coding | Inherited from the request and order. | Often added manually after receipt. |
| Validation | Match against order and receipt within tolerances. | Identify owner, purpose, coding and approval retrospectively. |
| Data | Line detail remains connected to the purchase. | Header-level posting may hide item and category detail. |
Find the root cause before adding approval steps
Report non-PO invoices by reason, supplier, category, requester, business unit and value. A generic “missing PO” label cannot distinguish a legitimate tax or utility exception from a preventable bypass.
Urgent or unplanned demand
The business commits directly because the standard request route appears too slow.
Service categories
Users believe a PO cannot describe variable fees, milestones or recurring professional services.
Usability and access
The requester cannot find the supplier, item, cost centre or approver in the purchasing tool.
Policy ambiguity
Thresholds, exemptions and responsibilities are not understood consistently across teams.
Process unavoidable non-PO invoices safely
- Validate the supplier and invoice. Check identity, duplicate risk, bank-data controls and statutory fields.
- Identify the business owner. Require evidence of who requested and received the goods or service.
- Apply coding and approval. Use the same budget, authority and segregation principles as the normal process.
- Record the reason. Select a controlled exception category and capture evidence rather than free text alone.
- Create a corrective action. For recurring demand, establish a blanket PO, catalog, rate card or suitable recurring workflow.
Prevent recurrence at the point of demand
- provide a simple guided request for services and low-frequency purchases;
- support blanket or framework orders with limits, periods and responsible owners;
- make approved suppliers and buying channels easy to search;
- set realistic approval times and delegated cover for absence;
- tell suppliers which PO reference is required before they start work or invoice;
- review repeat exceptions with business owners and procurement.
Measure improvement without creating perverse incentives
Track non-PO invoice rate by count and value, approval cycle time, touchless match rate, duplicate attempts, late payments and repeat suppliers. Segment the result: a lower rate can be positive, but not if users delay urgent work or create nominal POs after the invoice merely to satisfy the metric.
The desired outcome is earlier visibility and cleaner commitments. Review exceptions with procurement and finance so that a repeated workaround becomes a redesigned buying path rather than a permanent manual queue.
Should every invoice have a PO?
Not necessarily. Taxes, certain utilities, statutory payments or other controlled categories may use a different route. Define exemptions explicitly and apply equivalent ownership and approval controls.
Can a retrospective PO solve the problem?
It may create a reference for processing, but it does not provide preventive control. Track retrospective orders separately and remove their root causes.