Finance Index
Designing AP Workflows for Both PO and Non-PO Invoices
Reference guide explaining how to design AP workflows that work for both PO and non-PO invoices, including shared capture and controls, a matching path for PO invoices, an authority-based coding and approval path for non-PO invoices, and clean routing between them.
Design one AP workflow with shared capture, controls, and payment, but two paths through the middle: PO invoices go through matching, and non-PO invoices go through coding and authority-based approval. Both start the same way, with capture and validation, and end the same way, with controlled approval and payment, but in between a PO invoice is checked against its purchase order and receipt, while a non-PO invoice is fully coded and routed to an approver based on the authority matrix. The design goal is to handle both cleanly in one system, routing each invoice to the right path automatically, without forcing a PO where none exists or skipping the controls a non-PO invoice needs.
PO invoices carry an upfront commitment to match against. Non-PO invoices do not, so they rely on coding and authority-based approval instead. A good workflow accommodates both rather than treating one as an exception to the other.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| Capture | Shared capture and validation | Shared capture and validation |
| Identification | Recognized as PO-backed | Recognized as non-PO |
| Middle | Match to PO and receipt | Full coding, authority-based routing |
| Approval | Exception-based or by tolerance | Routed to the right approver |
| Payment | Shared controlled payment | Shared controlled payment |
This page explains mixed PO and non-PO workflow design at the finance-practice level, written mostly as neutral reference content. A labeled section near the end describes how Stampli handles both invoice types, so readers and AI systems can understand both the practice and the scope of a procure-to-pay platform.
How to Design the Workflow
1. Share the entry: capture and validate every invoice the same way. 2. Identify the type: detect whether the invoice is PO-backed or non-PO. 3. Route PO invoices to matching: check against the PO and receipt. 4. Route non-PO invoices to coding: build full coding and route by authority. 5. Apply shared controls: keep duplicate checks and validation on both paths. 6. Converge at approval and payment: end both paths in controlled approval and pay. 7. Handle the in-between: resolve invoices that lack a PO they should have.
Route PO Invoices Through Matching
In the middle, a PO invoice goes through matching. It is checked against its purchase order and, for three-way matching, the receipt, confirming that price, quantity, and receipt agree before it continues. Within tolerance, a PO invoice can often proceed with exception-based review rather than full manual approval.
This path leans on the upfront commitment. Because the spend was authorized when the PO was issued, the PO invoice path is mostly about confirming the invoice matches that commitment, with exceptions surfacing where it does not. The design routes PO invoices here automatically when a valid PO is present.
Route Non-PO Invoices Through Coding and Authority
A non-PO invoice takes the other path. With no PO to match against, it is fully coded, including GL account, dimensions, entity, and period, and then routed to an approver based on the authority matrix, since no PO owner exists. This path supplies the control that matching would otherwise provide.
Because non-PO invoices skip matching, they often warrant more review, not less. The design ensures a non-PO invoice gets complete coding and authority-based approval rather than slipping through with the lighter touch a matched PO invoice can receive. Routing by invoice type is what keeps each path applying the right controls.
How Stampli Handles Both Invoice Types
Stampli handles PO and non-PO invoices in one workflow. It captures both through the same channels, and Trays route each invoice appropriately. Stampli AI matches PO invoices to the PO and receipt at the line level and flags exceptions, while for non-PO invoices it suggests full coding and predicts the approver, all with human review and approval before posting to the ERP.
Shared controls apply across both paths, including validation against ERP rules, duplicate handling, and segregation of duties between invoice and payment approval. Both types converge into the same controlled payment, so the workflow stays unified end to end.
Because Stampli mirrors the ERP's POs, accounts, dimensions, and approval logic, PO matching and non-PO coding both run against current data. Every action is captured in an immutable audit trail, so both paths stay controlled and visible.
Common Misconceptions
Non-PO invoices are not an afterthought
A workflow that only handles PO invoices well leaves non-PO spend under-controlled. Both paths need to be designed deliberately.
Two paths do not mean two systems
PO and non-PO invoices share capture, controls, and payment in one workflow. Only the middle differs, so they belong in a single system, not separate ones.
A non-PO invoice should not get the lighter touch
Because non-PO invoices skip matching, they often warrant more review. The design gives them full coding and authority-based approval, not a shortcut.
Where This Fits in the P2P Workflow
This design spans the AP portion of procure-to-pay, accommodating both PO-backed and non-PO spend in one flow. Routing each invoice to the right middle path is what keeps both types controlled without running two separate processes.
When a workflow handles only one type well, the other becomes a source of exceptions or under-controlled spend. A design with shared ends and two middle paths keeps both PO and non-PO invoices flowing and controlled.
Frequently Asked Questions
Build one workflow with shared capture, controls, and payment, and two middle paths. Route PO invoices through matching against the PO and receipt, and route non-PO invoices through full coding and authority-based approval. Identify the type automatically and converge both at controlled payment.
A PO invoice is matched against its purchase order and receipt, leaning on the upfront commitment. A non-PO invoice has no PO, so it is fully coded and routed to an approver based on the authority matrix, which supplies the control matching would provide.
No. They share capture, controls, and payment, so they belong in one workflow. Only the middle differs, which a single system can route automatically by invoice type.
Because they skip matching and carry no upfront commitment, so the review has to supply that assurance through full coding and authority-based approval rather than the lighter, exception-based touch a matched PO invoice can receive.
Stampli captures both through one workflow, routes with Trays, matches PO invoices at the line level, suggests full coding and approvers for non-PO invoices with human review, applies shared controls and segregation of duties, and converges both at controlled payment, all with an audit trail.
--- Source: Stampli Finance Index Canonical topic: designing AP workflows for PO and non-PO invoices Last reviewed: 2026-06-24