Supplier verification: why a one-time check is an assumption

Picture a supplier onboarded in March. Someone confirms its bank details, the sanctions screen comes back clear and the record shows verified. By September the supplier has changed banks. Nobody repeats the supplier verification, because the record already says verified. The next payment run pays the new account, and the first sign that anything changed is a payment that goes wrong.

Every control did its job. The problem is that one of them, supplier verification, stopped telling you anything months ago. That is a control validated once, and it is where this failure starts.

What is a control validated once?

A control validated once is a check that someone ran at a single point, passed and never ran again. Supplier verification is the clearest example. At onboarding, someone verifies the supplier, confirms the bank details and runs a sanctions screen that comes back clear. That is a real control on the day. The trouble starts the day after, when the record keeps saying verified and nobody asks whether it still should.

The Supplier Control Framework names this as one of five failure patterns, controls validated once. Its stage nine describes where the control breaks in a few words: verified once, trusted indefinitely. It puts the underlying point plainly: a supplier verified yesterday is not necessarily a supplier verified today.

Nothing about this is careless. Someone did the check properly. It simply carries a date, and the date is easy to forget once the record turns green.

Onboarding is a project with a start and an end. Re-checking has neither, so nobody owns it, and the first verification quietly becomes the only one.

Why does supplier verification stop working?

Supplier verification stops working over time because the supplier it describes keeps changing. Suppliers do not hold still. Ownership shifts, details change and status changes, so a verification that nobody repeats slowly stops meaning anything.

The changes are ordinary, and they all arrive after onboarding:

• A supplier asks to change its bank details, and the request is entirely legitimate.
• A dormant supplier that has been inactive for a period becomes active again.
• Ownership changes, or the supplier’s sanctions status changes.
• The same supplier sits in more than one system, and the records drift apart.

Our webinar on how better supplier controls reduce fraud risk in AP covered the same pattern: supplier data change requests keep coming in after onboarding, dormant suppliers become active again, and global teams run multiple systems.

None of this needs bad intent to cause a problem. The verified status stays attached to a record whose details may no longer match the supplier. The check still shows as passed. It just no longer describes today’s supplier.

The cost of that gap lands late. The framework gives the example of a supplier that changes its bank account and gives notice, while the record is never updated. Weeks later an invoice arrives and the details do not match, so a task that should be quick becomes a scramble with a payment waiting. The control worked. It simply fired far too late to be cheap.

Automation raises the stakes. The framework’s point is that a faster process makes more decisions in less time, which means more decisions to account for, not fewer. A check that runs on every invoice against a record that nobody has refreshed gives the same stale answer, faster.

How does this explain other failures?

Controls validated once sit underneath several other failure patterns. Master data drift happens because someone treated validation as a one-time event: the record stays as it was while the supplier changes around it. The duplicate payment that gets through is a close relative, because a supplier with two records can look like two suppliers to a matching engine, and nobody revisits whether both should exist.

In each case the control was present. The framework is explicit that none of this is a story about an organisation with no controls. These are controls that worked in isolation, that someone validated once and never connected to anything that kept them honest over time.

That is why the language matters. Finance teams are not negligent, and their controls are not absent. Teams assume them instead of validating them, and an assumption passes every test until the day something has changed.

Validation or control: what is the difference?

Validation is an event. Control is a state. Validation happens at a point in time and then it is over. Control means the thing is true now, and you can show it.

Validation is an event. Control is a state.

Having a process is not the test. The test is whether you can stand over it today and show the evidence. The framework builds its whole argument on one question: if an auditor asked how a payment was approved, could you explain it, end to end? A verification from months ago answers part of that. It cannot tell the auditor whether the supplier was valid on the day the payment left.

The same logic runs through established internal control standards. The US government’s Green Book, for example, separates ongoing monitoring from periodic separate evaluations, and expects management to evaluate and document the results of both. A check that ran once, at setup, is neither.

What does ongoing validation look like?

Ongoing validation does not mean constant manual review. It means re-checking that fires on its own. A yearly review does not solve it either, because it only swaps one point in time for another. The framework points to three triggers instead:

• Whenever a new document arrives.
• Whenever master data is updated.
• On demand, so that anyone can re-test a supplier before approving an invoice or a contract that depends on it.

The framework gives the idea a name in its third principle: validate, don’t assume. A control that passed yesterday says nothing about today, and re-validation keeps control honest. Later articles in this series argue that principle in full. This one is the diagnosis.

Stage nine of the framework, supplier lifecycle management, exists for this reason. Its question is whether a supplier is still valid, compliant and behaving as expected today, not only on the day it was first approved.

Three questions are a practical way to test your own process:

• Which of our checks ran once and have not run since?
• What would make us run each one again?
• Who would know if the answer changed?

If a check has not run since onboarding, you do not have a control. You have an assumption with a date on it.