OpenText's May 2026 release blog lists a VIM 26.2 enhancement that sits next to payment-terms matching and matters more for payment risk: "Identify special handling instructions on invoices such as changes in bank details or company address." The product can now surface what used to live only in the image or a free-text note. Useful. It also forces a process question that detection alone never answers.
Who owns the hold when the invoice itself is the thing that flagged the change?
This is not the vendor-master post. We already wrote about who may clear a supplier bank-change hold: dual control, evidence standards, and when the durable fix belongs in the vendor master rather than on one document. That piece still stands. The 26.2 line is narrower. The instruction is on the invoice. The hold starts there. Someone has to decide whether AP can clear it from the document path, whether vendor master must move first, and whether an address change is treated with the same severity as a bank change.
Two flags, two consequences. A bank-detail change redirects money. An address change can redirect remittance advice, legal notices, or the place a dispute letter lands. Treat them as related controls with different owners if your SoD requires it. In our view:
- Bank change on the invoice. Payment risk. Finance owns the policy. Vendor-master / procurement data owns the durable bank data. AP owns the document hold. Security/SoD confirms segregation. The clear is never a single shared inbox.
- Company address change on the invoice. Master-data integrity and correspondence risk. Vendor master owns the durable address. AP owns whether the current invoice may post while the master ticket is open. Legal or tax may care when the address is used for notices.
OpenText's blog names the capability. It does not assign those roles. Write them down before the flag starts parking invoices in a queue nobody owns.
How this differs from payment terms. The same 26.2 notes cover intelligent payment-terms matching. Terms change when you pay. Bank and address changes change who gets paid and where the paper goes. Do not fold both into one exception reason labelled "AI special handling." Separate hold reasons keep the queues honest and the audit trail readable.
What we'd settle before go-live. The public blog does not say how 26.2 presents the instruction: as a hard hold, a soft warning, a proposed field, or a note on the image. That detail is in the release notes on OpenText My Support, and it decides the design. Until you read it for your release, treat these as open:
- Trigger. What text or field change raises the flag, and against which baseline (vendor master, last payment, both)?
- Fail-closed path. If the hold sits past its SLA, does payment stop, or does the invoice age into a different queue? A hold that times out into payment is not a control.
- Evidence. Same standard as the bank-change post: what is never enough, and where the proof must live (not a personal mailbox).
- One-time vs master. When an invoice-only exception is allowed, who signs it, and who still opens the master-data ticket.
Version context. When we last read OpenText's lifecycle page (10 October 2026), VIM 25.4 was the newest VIM release listed, with Current Maintenance to 31 December 2030. 26.2 is described on OpenText's public SAP solutions blog. Confirm with OpenText which 26.2 package fits your S/4HANA release before you plan the pilot.
Detection is the easy part. Name the clear, name the master-data path, and keep bank and address holds apart from terms mismatches. Then the 26.2 flag earns its place.
Where does your landscape stand?
Take the free Assessment. It's about 10 questions, and you get a one-pager with your estimated level of effort and suggested next steps.
