Non-PO invoices need their own design in OpenText VIM
PO matching is not the whole of AP
A large share of VIM conversation is three-way match: purchase order, goods receipt, invoice. That is the path with the most software sympathy. Non-PO invoices are the path that still consumes calendars.
They are not a lesser document type. They are a different economic event: facilities, legal, subscriptions, freight that never saw a PO, after-the-fact services, intercompany charges that arrived as a PDF. If you force them through a PO-shaped exception design, the queue will always look like a matching problem. It is often a coding and authority problem.
Public VIM component notes list PO and non-PO processing together inside Invoice Solution for a reason. The product expects both. Your configuration should too.
Why non-PO work piles up
Non-PO invoices typically fail for a short list of structural reasons:
No object to match. There is no PO line to absorb variance. Someone must code.
Authority is personal. Approval is a person or a matrix, not a receiving event.
Vendors are uneven. Some send clean structured files. Some send a photo of a statement.
Tax and entity are easy to get wrong when the requester is not the person who knows the company code.
Accrual and cutoff sit next to these invoices in a way PO pipeline invoices often do not.
None of that is solved by a sharper OCR engine alone. Capture can put a vendor name and an amount on the document. It cannot invent a responsible cost center the business has not named.
Design the path on purpose
A stewardship design for non-PO in VIM is boring and durable:
Entry criteria. Which vendors and document types are allowed without a PO? Write it down. If the rule is “under a threshold, or this vendor list,” encode the rule. Do not leave it as folklore in AP.
Coding that starts from known data. Prefer defaults from vendor master, last complete posting, or a small requester form over a blank coding screen. Human agency here means a person confirms a suggested object—not that a person invents one from memory every time.
Approval that matches risk. Route on amount, account, and entity, not on whoever last forwarded the email. Keep the matrix in the product. If you need a BTP or on-stack extension, keep it small and named.
Vendor readiness. Some non-PO volume should become PO volume. Some should become a structured e-invoice. Some should stay non-PO and get a better default. Sort the vendors. Do not run one playbook.
Posting rules that do not copy MIRO folklore. Invoice Solution is where posting determination and checks live. If processors still complete the document in a SAP GUI habit that bypasses those checks, you do not have a VIM non-PO process. You have a parking lot.
What not to automate first
It is tempting to point AI at non-PO coding. OpenText’s public materials mention modular enrichments and ISLM-style scenarios as ways to replace repetitive human steps. That can be legitimate later. It is not the first move if the approval matrix is informal and the vendor master is incomplete.
McCloy Data has already written about confidence for AI inside VIM and about exception cost. The non-PO-specific point is narrower: do not train a model on a path you have not designed. You will automate folklore.
A better first month:
Measure how many invoices are truly non-PO versus “PO not found.”
Split “PO not found” back to purchasing. That is not a non-PO design problem.
For true non-PO, measure where time goes: coding, approval wait, vendor query, tax.
Fix the largest wait that is a rule, not a person.
Clean core still applies
Non-PO is where custom workflow often grows. A Z-table for every requester feels faster than a conversation with finance. It becomes the reason the next S/4HANA release is expensive.
Prefer standard Invoice Solution configuration. If you extend, extend with the same discipline you would use on a PO enrichment: few lines, a named purpose, an owner. Do not build a second AP system beside VIM for “the invoices that are hard.”
Many in this space publish add-on stories (accruals, ESG fields on utility invoices). Those are product choices some landscapes will evaluate. They are not a requirement to have a coherent non-PO path. Start with coding, approval, and vendor policy. Add adjacent automation when the core path is stable.
How we work this
We will sit with AP and a sample of last month’s non-PO documents (not a workshop about the future of finance) and map each to a rule, a default, or a vendor conversation. We will not invent a case-study cycle time. We will not tell you that non-PO can reach PO straight-through rates.
If non-PO is the quiet majority of your queue, design it as a first-class Invoice Solution process. Then let capture and, later, any AI enrichment serve that process. Not the other way around.