Home · Solutions · Other solutions
Solution · Other solutionsRegisters, sanctions lists and one phone call stand between a request and your payment run
No payment to a vendor nobody verified
Every vendor creation and every bank change is screened against registers and sanctions lists, verified by a call to a number already on file, and paid only after that check closes.
Executive summary
A bank account changed because an email asked is the cheapest way to lose a six-figure payment.
We build one verification workflow between the request and the ERP, and every entity uses it.
No bank account reaches SAP without a call to a number the requester did not supply, which removes the single step payment-diversion fraud depends on.
SAP S/4HANA business partner and payment run; SharePoint evidence library; Power BI screening report
Business problem
Vendor risk
Vendor master maintenance is staffed and measured as data entry, when the bank account field is the last control before cash leaves the company. An address correction, a new contact person and a new IBAN travel through the same mailbox, are typed by the same clerk and approved with the same shrug.
The confirmation loop is the part that should worry a treasurer. A request arrives by email, the clerk asks the sender to confirm it, and the sender confirms, so the whole verification runs through the channel an attacker already controls. Nothing about that is negligent; it is what a busy person does when the alternative is finding a telephone number in a system nobody has curated for years.
Screening has the same shape: a manual search at creation, rarely repeated. A supplier that becomes sanctioned, is dissolved or loses its VAT registration afterwards stays perfectly payable, because nothing looks again. Across nine entities with nine checklists, group exposure is whichever entity checks least. The pressure keeping all of this alive is ordinary: quarter-end queues, suppliers threatening to stop deliveries, and a team measured on turnaround rather than on what it refused.
How it works today
- PersonProcurement emails a new-vendor form and a scanned letterhead to the master-data mailbox
- PersonThe clerk checks the VAT number on VIES when there is time, then creates the business partner in SAP from the PDF
- Risk of errorSanctions and register checks are one manual search at creation, repeated for nobody
- WaitingMonths later a bank-change request arrives by email and joins a queue of forty
- PersonThe clerk asks the sender to confirm, the sender confirms from the same address, and the account is replaced in SAP
- Risk of errorThe real supplier chases payment weeks later; a bank recall, an insurance claim and an audit finding follow
Why the current process costs more than it appears
The most expensive part of this process has no cost line.
- One diverted payment can exceed a year of the team's salary cost, and money sitting in a foreign account for more than a few days rarely comes back.
- Screening once, at creation, leaves the base unwatched: a company sanctioned or dissolved after onboarding stays payable until somebody happens to notice, and nobody is assigned to notice.
- Invalid VAT numbers surface at the tax review rather than at the first invoice, and the deduction refused there is a cash cost nobody attributes to the process behind it.
- Nine checklists produce nine standards, and lookups across nine national registers cannot be done consistently by three people under quarter-end pressure, so the check that gets dropped is reliably the longest one.
Cost of inaction
Impersonation gets cheaper every quarter. A convincing letterhead, a cloned domain and a fluent request in the supplier's own language now cost an attacker almost nothing, and the people they aim at are chosen for the length of their queue. Change requests grow with the vendor base, the checks stay dependent on whoever is on shift, and each attempt is another draw from the same jar.
None of this fails loudly. A rescreening that never runs becomes a payment to a newly listed entity, found by the bank rather than by the company, and the audit finding about vendor master controls returns each year with firmer wording. It costs nothing visible until the day it costs a payment, a report to a regulator and a board conversation about why the control was a mailbox.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A logistics group headquartered in the Netherlands, nine legal entities across Europe, about 6,800 active vendors: hauliers, warehouses, fuel and equipment suppliers, many of them small. Master data for all entities sits in SAP S/4HANA, maintained by a three-person team.
About 90 vendor creations and 150 master changes a month, roughly 40 of them bank-account changes, most requested by email. Two entities have seen payment-diversion attempts in the last two years, one of them successful.
Requests arrive in a shared mailbox, VAT numbers are checked by hand when the queue allows, sanctions screening is one search at onboarding, each entity applies its own checklist, and bank changes are confirmed by replying to the request.
Fifty minutes per creation and thirty per change, none of it reusable, plus a confirmation that travels through the same mailbox as the request. The team is measured on turnaround, so the longest check goes first.
One verification workflow for every creation and change, whichever entity asks: automated VAT, registry and sanctions lookups, certificates read and compared, requests scored for risk signals, a mandatory call-back task in Microsoft Teams for every bank change, and a payment block until that task closes.
In the modelled case, checking work per request falls to about ten minutes, screening becomes a monthly sweep plus a pass over every payment proposal, and no changed account is paid before somebody has telephoned the number in SAP. Every figure here is a model built on the assumptions below, not something measured at a client.
Proposed solution
We build one verification workflow between the request and the ERP, and every entity uses it. For a new vendor, a robot validates the VAT number through VIES, pulls the entry from the national business register, screens the company, its owners and its directors against the EU consolidated list and the OFAC and UK lists, and compares the country and holder of the proposed account with the registration. UiPath Document Understanding reads the certificates attached, so the clerk is handed discrepancies rather than PDFs.
Bank changes get their own path, because that is where the loss lives. UiPath Communications Mining classifies each request and scores the signals that accompany payment diversion: urgency, a sending domain first seen last week, a reply-to that differs from the sender, a request to bypass the usual route, a bank in a country the vendor does not operate in. Whatever the score, every bank change creates a task in UiPath Action Center that the clerk completes in Microsoft Teams, and the task requires a call to a number already held in SAP. The number in the email is never dialled and never offered.
Two controls run on a clock rather than on a request. The base is rescreened monthly, so a supplier sanctioned after onboarding is caught within weeks instead of never, and the payment proposal is screened before every run, with a block on any vendor whose verification is still open. The stack stays small on purpose: one document engine, one classifier, one execution layer, one place where people act, and nothing writes to SAP before a named person closes the task in front of it.
UiPath Communications Mining intents and extracted fields; UiPath Document Understanding with the pre-trained Certificates of Incorporation model and Generative Extraction for the rest; UiPath Action Center tasks with SLAs, completed in Microsoft Teams; UiPath Orchestrator queues, triggers, credential store and audit log
One verification workflow for nine entities; the discrepancy rules for bank country, account holder and registered address; the risk-signal thresholds; the call-back task and its scripted confirmation; the payment-hold and proposal-screening logic; the screening log and its Power BI report
VIES, national register and sanctions-list APIs through UiPath Integration Service Connector Builder; SAP S/4HANA business partner reads, updates and payment blocks through the SAP BAPI and OData connectors; the master-data mailbox through the Microsoft Outlook 365 connector
How the automated process works
- AutomationA message in the master-data mailbox triggers intake; Communications Mining classifies it as a creation, a change or something else, and scores the risk signals in the text
- AutomationThe robot validates the VAT number, pulls the registry entry, screens company, owners and directors against the sanctions lists, and compares bank country and holder with the registration
- AutomationDocument Understanding reads the attached registration and tax certificates and compares them field by field with what the request claims
- PersonEvery bank change, and every creation with a discrepancy, becomes an Action Center task in Teams: the clerk calls the number in SAP and records what was confirmed
- SystemVerified changes are written to SAP; refused ones close with a reason code and go to compliance, and any vendor with an open verification carries a payment block
- AutomationThe full base is rescreened monthly, and the screening log feeds a Power BI report by entity, vendor and date
Human-in-the-loop model
Automation handles
- VAT, registry and sanctions lookups on every creation, and the monthly rescreening of the whole base
- Reading certificates and comparing them field by field with the request
- Scoring incoming messages for the signals that accompany payment diversion
- Setting the payment block, writing verified changes to SAP and screening each payment proposal
People decide
- The call-back itself, dialled from the number on file and never from the request
- What a discrepancy between registry, certificate and form actually means
- Sanctions matches, refusals and the supplier conversation that follows one
- The thresholds: which signals raise a task, which entity may waive what, reviewed quarterly
Before and after
Systems and integrations
We do not add technology to make an architecture look serious. Every element below has a specific job in this process.
Inputs
- master-data mailbox in Outlook
- vendor request form in Microsoft Forms
- registration and tax certificates as attachments
- VIES and national business registers
- EU consolidated, OFAC and UK sanctions lists
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Communications Mining
- UiPath Document Understanding
- UiPath Integration Service
- UiPath Action Center
Target systems
- SAP S/4HANA business partner and payment run
- SharePoint evidence library
- Power BI screening report
Human touchpoints: Action Center call-back tasks in Microsoft Teams; refusal and escalation route to compliance; quarterly threshold review with the control owners
Technologies used
classifies vendor requests and extracts the risk signals carried in the message
Areads registration and tax certificates, including the pre-trained Certificates of Incorporation model
Arun the lookups and the monthly sweep, hold the queue, keep secrets in the credential store and log every step
Aregister, VAT and sanctions APIs; the master-data mailbox as a trigger
Athe call-back task, its SLA and the recorded confirmation
Abusiness partner reads and updates, payment blocks, payment proposal
Ascreening log and exception report by entity, vendor and date
AIllustrative economic model
What it is worth, with the arithmetic shown.
Creations and changes cost different amounts of time, so the calculator runs on the difference between today and the target state rather than on either job alone: 90 creations at 50 minutes plus 150 changes at 30 minutes is 9,000 minutes a month, the same 240 requests at about 10 minutes each is 2,400, and the 6,600 minutes between them average 27.5 released minutes per request. €39 an hour is an assumed fully loaded master-data cost. The averted payment stays out of the calculator: a probability and a quantity of minutes do not belong in the same box.
Run the numbers on your data
An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.
Business benefits
- No bank account reaches SAP without a call to a number the requester did not supply, which removes the single step payment-diversion fraud depends on
- Sanctions exposure becomes continuous instead of a moment at onboarding: the base is rescreened monthly and every payment proposal is screened before it leaves
- Onboarding stops depending on which entity asks, and an invalid VAT number is found before the first invoice, not at the tax review
- The master-data team moves from lookups to verification, the part of the control that genuinely needs a person
- Audit testing becomes sampling a log: each change carries its evidence, its score, who called whom and what was confirmed
The management view
- The treasurer signs a payment run already screened, with every changed account either verified or blocked
- Compliance answers a regulator from a screening log by vendor, entity and date, not from a reconstruction
- Procurement sees onboarding turnaround and the reason behind every refusal, and group exposure stops being the weakest local checklist, because there is one workflow and its exceptions are visible by entity
Board-level KPIs
Security and governance
Security is designed with the process, not after it.
- Channel separation is the control, so the design enforces it: the number the clerk dials comes from SAP, and no bank change is written until a named person closes the task in front of it
- The robot's SAP account reads and updates business partners and sets payment blocks, nothing else; its secrets live in Azure Key Vault through the Orchestrator credential store rather than in a workflow
- Access to the master-data mailbox is granted per mailbox through Microsoft Graph application permissions rather than across the tenant, and screening results, call records and decisions are retained in SharePoint under Microsoft Purview retention labels
- Personal data on directors and owners is processed for screening only, masked in any generative step by the UiPath AI Trust Layer with an allow-listed model; processing stays in the EU region of UiPath Automation Cloud and in your own Microsoft 365 tenant
Why now
Payment diversion is run as a business, not as an experiment: letterheads, cloned domains and fluent supplier correspondence are bought rather than made, and the target is the quarter-end queue
Sanctions obligations reach through the name to the ownership behind it and the lists move weekly, which no manual search across nine entities keeps up with, while API access to VIES and most European registers turns the lookup that justified skipping the check into seconds
The capacity argument is the smaller one and still holds: the modelled €4,290 a month runs for as long as the process does, and buys none of the control
Relevant executive roles
A diverted payment is an uninsured loss and a board conversation; this turns a habit into a step that cannot be skipped
Every run goes out against a screened proposal, with each changed account either verified or blocked before payment
Continuous screening with a log answers a regulator without a reconstruction project
Onboarding becomes quick and identical across nine entities, and every refusal arrives with its reason
Common questions and objections
On quiet days, and usually to the number printed in the message that asked. Here the call is compulsory and goes to the number already in SAP, and the change cannot exist in the ERP until the task recording it is closed.
It screens the payment file on its way out. This screens the vendor at creation, every month, and again against the payment proposal, tying the result to the master record where the exposure is created.
Lookups that took a day take minutes, so most requests move faster than today. Only the call-back waits, and the payment hold applies to the changed account alone, not to everything else the vendor has invoiced.
When this is not the right solution
- A few hundred long-standing suppliers whose bank changes are agreed in person; the workflow would add ceremony to something that already works
- A procurement platform already enforcing verified onboarding and bank changes for every entity, where the gap is coverage rather than tooling
- No appetite for holding a payment while a verification is open; without that lever the control is only advice
A question for the next management meeting
If the next bank-change request arrives at quarter-end and looks entirely genuine, which step in our process stops it, and could anyone in this room name that step today?
Implementation approach
What we deliver, and what we need from you to start.
We deliver
- A review of one year of bank-change requests and nine onboarding checklists, ending in one written control standard
- The verification workflow: VAT, registry and sanctions lookups, with discrepancy rules for bank country, holder and address
- A Communications Mining model for classification and risk signals, trained on your own correspondence, with the register, sanctions, SAP and Outlook integrations, the Teams call-back task and the payment-hold logic
- Monthly rescreening, screening of the payment proposal, the screening log and its Power BI report, then a controlled start with bank changes only, training and hypercare
We need from you
- Twelve months of vendor requests with the correspondence, so the classifier has something to learn
- A service account in SAP that can read and update business partners and set payment blocks, in test and production
- Access to the registers and sanctions sources your policy requires
- Telephone numbers on file for your vendors, and a named owner in compliance for sanctions matches
Stages
Discovery
One year of change requests and nine checklists, reviewed with treasury, compliance and procurement
Design
One control standard: rules, risk signals, thresholds, call-back script, hold policy
Build
Lookups, classification, certificate reading, SAP updates and the Teams task in your environment
Pilot and scale
Bank changes first, across all entities, then creations, monthly rescreening and pre-run screening
Departmental. Effort follows the number of registers and sanctions sources in scope, how far nine checklists have to move to meet one standard, and the state of the telephone numbers in your vendor master.
The next request will arrive at quarter-end and will look completely genuine.
Send us three recent bank-change requests with the details redacted. We come back with the risk signals a classifier would have raised on each, and the point at which the payment would have been held.
Test three of your change requestsThe neighbouring process usually has the same problem
One convincing email is all it takes to send a six-figure payment to a fraudster's account.
View solution ProcurementSupplier onboarding and due diligence in days, not weeksStop losing three weeks and the compliance evidence every time a plant needs a new supplier.
View solution Other solutionsInvoices read, coded and routed; people see only exceptionsSomebody still types the PDF into the ERP, guesses the cost centre and chases the approver.
View solution Other solutionsThe same invoice by e‑mail, portal and post, paid onceA hyphen, a rescan or a reissued number is enough for the same invoice to be paid twice.
View solution Case studyB2B client onboarding in 24 hoursA new client does not stop being “hot” just because your process has nine steps.
View case study Case studyInvoice disputes without escalationA disputed invoice is not one task — it is an investigation: order, delivery, contract, correspondence.
View case studyIndustries we deliver this in most oftenManufacturing & industryRetail & e‑commerceServices & ITShared services