Fiori Capture Validation Workplace is a workplace choice, not a skin
Two tools, one job
Someone has to look at a document when extraction is unsure. For years that job sat in OpenText’s Windows Validation Client for SAP Solutions. It still can. Public upgrade guidance says the important rule has not changed: keep the Validation Client on the same release level as VIM Foundation and the OCR/Capture component.
The alternative is now first-class in those same notes: the Fiori Capture Validation Workplace, browser-based, without a local Windows install. OpenText’s product messaging puts validation inside SAP Fiori when you use Core Capture for SAP Solutions. Partner write-ups describe the same shift: no desktop software, invoice selection in the browser, administration that looks like the rest of Fiori.
This is not a skin. It is a workplace, an operations model, and a Basis packaging choice.
What actually changes for the person doing the work
Validators are not “users of a UI.” They are the last human gate before VIM treats header and line fields as trustworthy. If the workplace is slow, poorly scoped, or missing a check they relied on, they invent a side process. Spreadsheets appear. Teams email PDFs.
A measured comparison, based on what is public and not on a lab we did not run:
Windows Validation Client
Familiar to long-running ICC/IC4S teams.
Requires desktop deployment, version alignment, and Windows lifecycle management.
Must stay on the same release level as Foundation and capture. Drift here is a common upgrade defect.
Still a valid path when the Note set allows it and when you have a desktop management practice that can keep pace.
Fiori Capture Validation Workplace
Runs in the browser. No local OpenText validation install.
Aligns with a Fiori-first S/4HANA workplace and with Core Capture’s “validate in Fiori” story.
Changes how you grant access, how you train, and how you support people who only work in SAP GUI today.
Still requires version alignment with Foundation and capture. Browser-based is not version-optional.
Another public feature notes also describe a VIM Accounts Payable Workplace that can sit closer to validation so processors do not bounce between a Fiori app and a Windows tool. If you already live in Fiori for approvals, splitting validation back to a desktop client is a daily tax. If your validators are a small, dedicated capture team, the Windows client may still be the calmer path for one more release.
Choose. Dual-running both for a short coexistence is sometimes necessary. Dual-running both as a strategy is how you get two incomplete skill sets.
ICC is not the workplace
People still say “we validate in ICC.” ICC was a capture generation. Validation is a client (or a Fiori app) sitting on top of extraction. When BCC/ICC fall off the 25.4 support list, the workplace question becomes unavoidable: what will humans open on Monday?
Do not answer it with a screenshot. Answer it with:
Who validates (AP generalists, a capture cell, shared services)?
From where (office image, VDI, home browser)?
How you install or do not install software?
Which user exits and checks you actually use today?
Whether Fiori apps will be on-premise or on BTP?
That last item is on the public landscape checklist for a reason. A Fiori workplace you cannot deploy is not a workplace.
Keep the job small
Validation should correct extraction and pass a clean document into VIM process control. It should not become a second coding desk, a second approval, or a place to “fix” vendor master data by typing around it.
If validators are entering cost objects because the non-PO design is thin, you have a process problem. If they are fixing the same vendor’s tax ID every day, you have a master data problem. Changing to Fiori will not hide either one. It will only make the clicks look more modern.
McCloy Data’s bias is stewardship: pick the workplace that your validators can operate without a dedicated desktop package, unless you have a real reason to keep the Windows client. Then lock versions. Then measure correction effort for a month before you retune rules.
A practical transition
If you are leaving the Windows client:
Confirm target VIM Foundation, capture, and Fiori UI versions together.
List the validation checks and exits in use. Confirm each has a home in the Fiori workplace or a deliberate retirement.
Pilot with the people who validate the hardest documents, not the easiest.
Retire the desktop client on a date, not “when we are comfortable.”
Keep a short hyper care window aimed at extraction and access, not at rewriting AP policy.
If you are staying on the Windows client for this release:
Still inventory it as a component with a version.
Assign someone to patch it when Foundation is patched.
Write down the condition that would trigger a Fiori move (lost desktop packaging, capture product change, S/4HANA 2025 pairing).
We are not selling a UI. We are asking that the human gate stay aligned with the add-on. If you want help making that choice without a demo theater, say so.