Vendor Master Data Management
Why cleanups do not hold, and what does
Every vendor master file was clean once. What matters is not how it got messy but why every cleanup project is followed, about eighteen months later, by another one.
Vendor master data management is the practice of keeping supplier records accurate, complete and free of duplicates. Data degrades because records are typically created by staff mid-task rather than collected from the supplier, so fields are partially filled and never verified. A cleanup only holds if the way records are created changes at the same time.
The cause is how records are created
This is the part cleanup projects usually skip, which is why they need repeating.
| Cause | What it produces |
|---|---|
| Records created by staff mid-task | Fields filled from whatever was to hand, with the rest left for later, which never arrives |
| No single owner | Everybody can add a vendor and nobody is accountable for the state of the file as a whole |
| No duplicate check at entry | The same supplier is added under slightly different names and nobody notices until a payment or a report goes wrong |
| Nothing verifies the fields | A tax identifier typed incorrectly looks identical to one typed correctly, until it fails |
| No expiry tracking | Documents attached to the record silently become out of date, so the record looks complete and is not |
Six things, all verifiable
A verified legal entity
Legal name as registered, registration number and addresses, matched against public records rather than taken on trust.
A validated tax identifier
Checked rather than transcribed, because a wrong identifier is invisible until a payment or a filing fails.
Current documents with dates
Insurance, certifications and tax forms, each carrying its own expiry so the record is current rather than merely populated.
A screening position with a date
When the supplier was last checked and against what, since a record that says clear without a date says very little.
A category and status
What they supply and where they are in their lifecycle, so the record can be filtered rather than only read.
A single record per supplier
Which sounds obvious and is the requirement most master files fail.
Four steps, and the fourth is the one that matters
The first three are the project everybody runs. The fourth is why it does not need running again.
| Step | What it involves |
|---|---|
| Import and deduplicate | Bring the existing list in and match duplicates before committing anything, rather than discovering them afterwards |
| Fill gaps from the supplier | Ask the supplier for missing tax identifiers and contacts through a short questionnaire rather than researching them internally, because the supplier knows and your team is guessing |
| Verify what can be verified | Check entity registration and tax identifiers against public records rather than accepting what was typed in |
| Change how records are created | New suppliers arrive through onboarding rather than being typed in mid-task. Without this, degradation restarts the day the project ends |
Five that prevent rather than correct
| Control | Prevents |
|---|---|
| Duplicate detection at entry and import | The single largest source of master file decay |
| Supplier-completed fields | Transcription errors and half-filled records |
| Expiry tracking per document | Records that look complete while containing expired evidence |
| A single creation route | Records appearing through side doors that bypass every other control |
| Periodic re-verification | Registration and identity details drifting out of date without anybody noticing |
