OpenText VIM best practices that still hold after go-live
After the project binder closes
Most “best practices” decks are written for the week before go-live. They age badly. The practices that matter are the ones that still hold when the SI has left, the hypercare channel is quiet, and AP is simply running the work.
OpenText VIM (Vendor Invoice Management for SAP Solutions, also storefronted as SAP Invoice Management by OpenText) is an operating system for invoices inside SAP. It rewards steady ownership more than a second wave of configuration. This note is about that steadiness. It is not a closeout slide. It is not a sales checklist dressed as operations.
Practices that still earn their keep
Named exception owners. Every exception type that appears in volume needs a person or a small named queue, not a shared inbox that everyone assumes someone else watches. Who carries it: AP process ownership, with IT only for technical failures. If “vendor master” and “price variance” land on the same anonymous queue, you have not finished design. You have postponed it.
Chart of Authority maintained. Approval limits change when people change jobs. A Chart of Authority that was perfect at cutover and untouched for eighteen months is a control gap. Who carries it: finance operations (or the controller’s delegate), with security or Basis applying the system change. The operating choice is whether COA is a living control or a project artifact.
Capture learning with a named owner. Extraction quality drifts when suppliers change layouts and when nobody owns the feedback loop from validation back into learning. Who carries it: a capture owner (often AP ops paired with a technical admin), not “the project team” that no longer exists. Do not reopen every capture profile because SAP moved. Reopen the ones that fail with evidence.
Archive retrieval tested. An invoice that posted without a retrievable image is not a success you will enjoy during audit. Schedule a small, boring retrieval test. Who carries it: Basis or content admin for the technical path, AP for business confirmation. Test after upgrades, after repository work, and on a quiet quarterly rhythm.
Master data as process input. Vendor, PO, tax, and company-code quality are not “master data projects over there.” They are inputs to VIM outcomes. Who carries it: the data owners already on the hook for vendor and procurement master data, with AP feeding concrete failure examples instead of vague complaints.
Do not reopen every rule when SAP moves. Release and add-on upgrades are poor moments to redesign policy. Stabilize the platform first. Change rules when the business rule changed, not because the transport window is open.
Measure corrections, not vanity
A single “touchless” percentage hides the work. Prefer field-level correction views: which fields validators change, how often, for which document types and channels. That tells you whether the problem is capture, master data, or a rule that never matched reality. It also keeps you honest when someone wants a headline number for a slide.
You can run a health-style review without turning the whole program into a productized “health check story.” Inventory owners, COA currency, capture ownership, archive proof, and the top correction fields. Fix the thin spots. Move on.
What “best practices” are not
They are not a reason to rip out working process types every year. They are not a competitor comparison. They are not a mandate to buy another module this quarter. Search results for “OpenText VIM best practices” are crowded with partner pages. Your job is simpler: keep the operating model true after the banner comes down.
Clean core fits here without slogans. Prefer configuration and named ownership inside the add-on you run. Prefer small, explained extensions when you must extend. Prefer not to grow a shadow spreadsheet that becomes the real approval system.
A Tuesday operating rhythm
Pick one hour a month. AP lead, capture owner, and the Basis or content person who can prove retrieval. Review exception volume by type, COA change log, top corrected fields, and the last retrieval test date. Write three actions with names. Stop.
Ownership map you can paste into a runbook
Keep the map short enough that people will read it.
| Practice | Primary owner | Supporting owner | Cadence |
|---|---|---|---|
| Exception queues by type | AP process lead | Functional config | Weekly glance, monthly cleanup |
| Chart of Authority | Finance operations | Security / Basis | On org change, plus quarterly review |
| Capture learning | Capture owner | AP validators | Weekly profile notes, monthly review |
| Archive retrieval proof | Content admin / Basis | AP sample checker | After changes, plus quarterly |
| Vendor / PO / tax inputs | Master data owners | AP (failure examples) | Continuous, with a monthly top-10 |
If a cell is empty in your landscape, that is the finding. Fill the name before you buy another workshop.
When SAP or OpenText moves a release under you, use the map. Confirm the platform still works. Change process rules only when the business rule changed. That single discipline is how clean-core programs avoid accidental redesign.
Also separate inbound channels when you measure. A structured e-invoice and a photographed utility bill should not share one success story. Best practice after go-live is honesty about work types, not a single blended score for the steering pack.
If that rhythm is missing, McCloy Data can help you stand it up. We implement and optimize OpenText VIM and the capture and archive pieces that touch it. We will not rewrite your AP policy for theater. We will help you keep the practices that still hold after go-live.