Practical AI in OpenText VIM: name what the model may change
Suggestions are not authority
Market conversation around AI in the OpenText Vendor Invoice Management space includes extraction, coding suggestions, and control examples such as assisted detection of supplier banking changes. Partner deep-dives also mention broader GenAI and agentic themes. Treat those as product and partner messaging, not as McCloy metrics and not as a reason to hand the model the posting keys.
Marketing’s Thursday radar still shows McCloy absent on “practical AI OpenText SAP” style queries while peers occupy pieces of that SERP. The useful response is not hype. It is a clear operating boundary: what the model may change or propose, versus what only a named human may change, post, or clear.
This is not a rewrite of AI extraction named owner and not Parts 1 & 2 of AI Command Leadership (keep/automate/supervise; interrogate the model). It is the narrower AP control question: permission boundaries for model output inside VIM.
The operating choice
Write a one-page boundary AP, finance, and IT can all sign:
May suggest. Field extraction, coding suggestions, duplicate hints, routing hints—where configured—always visible as proposals subject to human or rule acceptance.
May park / flag. Risk signals (for example bank-detail mismatch detection where you use it) that create a hold for human clearance - not silent master-data edits.
May not change. Vendor bank data, payment blocks lifted without dual control, Chart of Authority outcomes, posting that bypasses your park and approval rules.
May not invent authority. Confidence scores are not signatures. A high-confidence extraction is still a suggestion until your process accepts it.
Named human. Who accepts extraction/coding in validation; who clears AI-assisted holds; who may promote a model or prompt/config change to production.
Who carries it? AP process owner owns acceptance of suggestion boundaries in the live path. Finance owns anything that touches payment risk, authority, and dual control. VIM functional / capture lead owns configuration of what the model is allowed to write into which fields. Security / SoD confirms the model path does not collapse segregations. AI / automation owner owns model lifecycle and false-positive review and not payment authority. Supplier bank clear-hold ownership stays with humans even when detection is assisted.
Practical means boring on purpose
A practical boundary looks like:
Validation workplace shows proposals; posting still follows your rules and approvals.
Coding suggestions can be accepted line-by-line; they do not silently rewrite CoA.
A bank-change flag parks; clearance follows the named dual-control path.
Model or extraction upgrades get a test pack and an owner - same discipline as a mapping change.
What fails when the boundary is missing:
Teams talk about “touchless” without saying which fields the model may write.
A pilot allows posting from suggestions in QA and the same switch is never reviewed in production.
Partner slides about agentic flows are copied into a SOW with no human signer named.
Exception volume rises; someone blames “the AI” without a field-level permission map.
None of that requires an accuracy percentage. It requires a permission map.
Clean core reading
Keep AI-assisted steps inside the VIM / SAP process controls you already run. Prefer proposals into published fields and park reasons over a side bot that posts invoices outside VIM. Do not invent touchless KPIs or accuracy claims you did not measure. Do not weaken SoD because a demo looked fluent. Interrogate suggestions the same way you would interrogate a junior analyst’s first draft—then keep your authority model.
What this is not
This is not an agentic-AI manifesto. It is not a mandate to turn on every AI feature this quarter. It is not a claim that extraction eliminates AP judgment. It is not competitor blame and not a quote of peer percentages. It is not the same article as naming who owns extraction quality alone. Name what the model may change - and what it may not.
A practical checklist
Field map: which fields may be AI-proposed; which are human-only; which are rule-only.
Hold map: which AI/rule flags may park; clearance RACI; fail-closed behavior.
Forbidden list: bank master silent edit; authority bypass; unsupervised posting - written down.
Test pack: accept suggestion; reject suggestion; low-confidence path; bank-flag path; SoD break attempt.
Promotion rule: who may change model/extraction config; AP and finance sign when payment-adjacent.
Monthly sample: ten accepted suggestions - evidence of human or rule acceptance still present.
How the SOW should read
Prefer language like: “For practical AI in OpenText VIM: document fields the model may propose vs human-only fields; AI may flag and park but not silently change bank data, authority, or posting outcomes; name AP/finance acceptors and the AI config owner; no touchless KPI without a field-level permission map.” If the paper only says “enable AI,” require the boundary lines.
