Dictionary-based 3-way match in OpenText VIM needs a living owner
Match logic ages in production
Three-way match—purchase order, goods receipt, invoice—is still the backbone of many PO invoice paths in OpenText Vendor Invoice Management. Public discussion of VIM 25.4 has highlighted dictionary-based matching as part of how the product can resolve PO-GR-Invoice relationships with more structured logic. That is useful. It is also easy to misread as “set once at go-live.”
Dictionaries, tolerances, and match rules sit on top of living master data: vendors, plants, material groups, units of measure, price conditions, and the habits of how receiving actually posts. When those change and nobody owns the match layer, exceptions rise quietly. AP feels busy. Procurement feels blamed. The configuration still “looks fine” in a screenshot from the project.
The operating choice
Name who maintains:
Dictionary / match rule content for the PO paths in scope.
Tolerances finance still allows (price, quantity, and any path-specific bands).
Master-data triggers that force a review—new plant, new vendor class, UoM change, consignment or pipeline patterns if you use them.
Exception feedback so recurring mismatches become rule or data fixes instead of permanent queue work.
Who carries it? AP owns the exception truth (what actually blocks posting). A procurement data steward owns vendor and plant master quality that feeds the match. The VIM functional lead wires and transports rule changes. Finance signs tolerance policy. There is no single “IT owns 3-way match” sentence that survives contact with week-two volume.
What fails when ownership is missing
You do not need a dramatic outage. You need patterns like:
A plant went live; GR posting habits differ; invoices park for quantity while nobody updates the match expectation.
A vendor changed pack size or UoM; the dictionary still assumes last year’s shape.
Tolerances were copied from a pilot company code that finance no longer allows.
Two shared-services pods interpret the same exception reason differently because the rule comment is empty.
None of that is “VIM cannot match.” It is match logic without a living owner.
A thirty-day ownership rhythm
After go-live (or after a 25.4 / S/4 move that touched match), run a light rhythm for one month:
Week 1: AP lists the top mismatch reasons by volume; procurement marks which are master-data vs process habit.
Week 2: VIM functional lead proposes rule or dictionary changes for the two highest fixable reasons; finance confirms tolerances still match policy.
Week 3: Transport and re-test the ugly pack (price, quantity, missing GR, UoM).
Week 4: Retire any temporary “special vendor” workarounds that crept in during hypercare.
If the rhythm has no named attendees, it will not happen. Put the four names on the calendar invite and not a shared distribution list.
Clean core reading
Keep match determination inside the VIM / SAP process layer you standardized. Prefer configuration and published extension patterns over a shadow spreadsheet of “special vendors.” Do not promise AI extraction as a substitute for clear PO-GR-Invoice rules—extraction proposes fields; match still decides whether the business relationship holds. Do not invent touchless targets to paper over unclear tolerances.
A practical checklist
Inventory: which company codes and document processes use dictionary-based 3-way match today.
Owner map: AP lead, procurement data steward, VIM functional lead, finance tolerance signer—with backups.
Change trigger list: vendor create/extend, plant go-live, UoM or price-condition change, tolerance policy change.
Monthly thirty-minute review: top mismatch reasons, which became rule fixes, which became master-data tickets.
Test pack: one price variance, one quantity variance, one missing GR, one UoM oddity, one multi-line PO—run after any rule transport.
Exit criteria for “done”: exceptions attributable to known business holds, not to orphaned dictionary rows.
What this is not
This is not a demand to upgrade to 25.4 on a calendar. It is not a claim that dictionary matching removes AP judgment. It is not a retread of non-PO design or Chart of Authority rebuild notes—those are adjacent, not the same object. It is not competitor blame when exceptions climb. Name the operating gap and the owner.
How the SOW should read
Prefer language like: “For OpenText VIM dictionary-based 3-way match (or equivalent PO-GR-Invoice match rules in scope): document living owners for dictionary/rules, tolerances, and procurement master-data triggers; define the monthly exception-to-fix feedback loop; include a regression test pack for price, quantity, missing GR, and UoM cases.” If the paper only says “configure 3-way match,” require the owner map.