Master data drift: the gap between the world and the record

Supplier master data is only right on the day someone checks it. Someone onboards a supplier, verifies its bank account, clears its status and the record goes green. From then on the world keeps moving and the record does not. The gap that opens is master data drift.

Nothing in a payment run shows that gap. The invoice matches the purchase order, the approvals are in, and the payment goes to a bank account that someone verified once, on a day now well behind you. Every check passes because every check compares the payment with the record. The record is the thing that has aged.

What is master data drift?

Master data drift is the gap between a supplier record and the real supplier, opened by everything that changed after the record was last validated. Supplier master data holds the details that every payment depends on: the legal name, the address, the tax details, the bank account and the status the supplier showed at onboarding. Those details describe the supplier on the day someone captured them.

Picture a supplier onboarded three years ago. Someone checked its bank details, filed its documents and marked its record complete. Since then it has changed banks twice, opened a second entity and passed to a new owner. The record still says what it said on the first day, and it is still trusted in every payment run.

Drift is not a data-entry error. Nobody keyed the wrong account number. The data was right when someone checked it, and it stopped being right without anything telling the process. That is why it is easy to miss. Data-quality work looks for mistakes, and drift contains none.

The Supplier Control Framework names master data drift as one of five failure patterns. A supplier with two records is a close cousin of it, as the duplicate payment that gets through shows: a matching engine can only compare what the record tells it.

How does supplier master data go stale?

Supplier master data goes stale through ordinary changes that the buyer rarely sees. Most happen outside your systems, which is why nothing in the process prompts a refresh. Four of them matter most.

A bank account is reissued

Banks close dormant accounts, and a bank may reallocate a closed account number to a new customer. In one UK decision, the Financial Ombudsman Service called that a common banking practice. In that case the bank closed a company’s account for dormancy in 2013 and later reallocated its number, so payments sent to the old sort code and account number in 2020 and 2022 reached an account belonging to a third party.

A supplier record that still holds old details can send money to the wrong place, and the checks will pass, because they compare the payment with the record. Information ages badly, and bank details are no exception.

Confirmation of Payee helps in the UK, but it is not a complete answer. The ombudsman noted that the name check does not entirely prevent misdirected payments, because it does not run in every circumstance and a payer can ignore a no-match warning.

A supplier’s status changes

A supplier that was clear at onboarding can later appear on a sanctions list, or become linked to a politically exposed person. The UK Sanctions List is now the single source for UK sanctions designations, and the government updates it as designations change. The question that counts is whether a supplier is clear on the day you pay, not on the day you onboarded them.

A supplier moves

A supplier can switch banks or relocate. A payment that once went to a domestic account can start going to an account in another jurisdiction. If that change reaches the record without a fresh check, nothing flags it, because the new details are simply the record.

A one-time supplier is never checked

One-time suppliers are the sharpest case. Teams can pay them without full onboarding, and even where onboarding happens, nobody may verify the bank account. The record exists, but no check stands behind it. That is a financial risk first, and a reputational one if it goes wrong.

Why do green metrics hide drift?

Green metrics hide drift because they measure the moment of approval. Straight-through processing (STP) is the clearest example. An invoice arrives, the system matches it to the purchase order and the receipt, and the payment moves on without a person touching it. Ten units ordered, ten invoiced at the right price: everyone is happy.

Then the pressure to keep the rate high builds. Teams relax some checks, extend trust to suppliers they know and move to a lighter review. Bulk select and release can become routine. None of that is careless. It is what a speed target rewards.

The result is a dashboard where all the metrics are green, like a point in time check. It tells you the payment matched what you knew at approval. It cannot tell you whether what you knew is still true. We end up acting in a bubble, because nobody refreshes the record.

This is not an argument against automation. Speed is a fair thing to measure. It is just not evidence of control, and treating it as evidence is how a green dashboard and a stale record sit together without anyone noticing.

Active or passive control: what is the difference?

Passive control checks the box once. It trusts the result from then on. Active control keeps checking: it revalidates supplier details, status and bank accounts as the world changes, on a schedule and when an event triggers it, rather than after an incident.

Passive control checks the box once. Active control keeps checking.

Many processes are passive by default, and not through neglect. A workflow built around the invoice checks the invoice. It does not ask whether a supplier approved years ago is still the supplier it was. That is a design gap, and finance teams did not create it.

The next article in this series applies the same idea to the controls themselves, many of which someone validated once and then left to run.

What should finance teams ask first?

Start with questions, not a number. A single revalidation interval would be easy to quote and hard to defend, and the right trigger depends on how your suppliers change. These five are a practical place to begin:

• When was this supplier’s bank account last validated, and what would trigger another check?
• Would we know today if a supplier we paid last month had since been added to a sanctions list?
• Which suppliers have been paid but never fully onboarded, including one-time suppliers?
• If a supplier changes its bank details, what happens before the next payment?
• If a payment has gone wrong, did the root cause trace back to a check that was only true once?

If the answer to any of these is “we don’t know”, that is useful information. Asking the questions is what moves a team from passive to active control. It is also the question an auditor will put to you sooner or later: could you explain every payment?

The Supplier Control Framework sets out nine stages of the supplier lifecycle, a control question for each, and where control usually breaks. Supplier onboarding, where the record is first created, has its own stage. Our webinar on how better supplier controls reduce fraud risk in AP covers the same ground on demand.

The question is not whether your AP is automated. It is whether you can be confident that the controls behind that automation are still valid today.