OpenText's May 2026 release blog lists a VIM 26.2 enhancement that sounds small and isn't: "better payment terms based on intelligent text matching." Read plainly, VIM 26.2 gets better at reading the payment terms printed on an invoice and relating them to terms your SAP system knows. Useful. It also forces a question many AP teams have never written down. When the invoice, the purchase order and the vendor master disagree about terms, whose terms win?
SAP already has a default answer. SAP Note 322430 sets out how invoice verification proposes terms of payment. With a purchase order reference, MIRO proposes the terms from the PO, and a clerk can change them by hand. Without a PO, or when only delivery cost items are invoiced, the terms come from the accounting view of the vendor master. So a standard S/4HANA invoice pays on the PO's terms unless someone overrides them.
The supplier's printed terms are a third voice. An invoice says net 30 against a PO that says net 60, or it offers a discount for early payment that nobody negotiated. Until now that text mostly stayed on the image. Better extraction turns it into a value VIM can compare.
The feature reads. It doesn't rule. Text matching tells you what the supplier claims. It can't tell you what you agreed. Purchasing negotiated the PO terms. Treasury cares about the baseline date and the discount window, because they move cash. AP owns the invoice. In our view the policy has three parts, and each needs a named owner before the feature is switched on:
The default source. For PO invoices most companies will keep SAP's order: PO first, vendor master second. Write it down anyway. An AI result arrives with a certain authority, and people will ask why the system "found" net 30 and paid on net 60.
The mismatch path. Post on the PO terms and tell purchasing, route to the buyer, or hold for AP review. Each one is a VIM exception design with a different queue owner.
Better terms on offer. If the invoice offers a discount the PO doesn't carry, someone decides whether AP may take it. That's a treasury and purchasing call, not an extraction setting.
What we'd check before the switch. The blog doesn't say how 26.2 presents a terms match: as a proposed value, as a business rule check, or both. That detail is in the release notes on OpenText My Support, and it decides the design, so read it for your release first. Then three checks:
Pull recent invoices where the posted terms differ from the PO or vendor master and find out who changed them, and why. That's your real policy, as practiced.
Look at the payment terms keys themselves (configured in OBB8). Matching can only land on keys that exist and are described clearly. Near-duplicate keys make a correct reading look wrong.
Report terms exceptions on their own line, apart from price and quantity, so you can see whether the feature finds real disagreements or noise.
Version context. When we last read OpenText's lifecycle page (10 October 2026), VIM 25.4 was the newest release listed, with Current Maintenance to 31 December 2030. 26.2 is described on OpenText's blog. Confirm with OpenText which 26.2 package fits your S/4HANA release before planning around it. The VIM release follows the SAP release, as we wrote when pairing VIM with S/4HANA.
The same 26.2 notes list a neighbor: spotting special handling instructions on invoices, such as changed bank details or a new company address. That one has a sharper control edge, and we've written about who may clear a supplier bank change hold. Terms are quieter. They change the due date, not the payee. They still move cash, so give them an owner.
