The supplier list is the least interesting thing in a purchase ledger and quietly one of the most consequential. Duplicate detection, spend analysis, payment terms and coding defaults all key off it. When it's messy, each of those degrades at the same time.
The failure is gradual and nothing ever looks broken, which is why it's usually only addressed after something goes wrong.
What a good record holds
Not much, but held consistently:
One canonical name. Legal name or trading name — pick a convention and apply it. "ABC Builders Ltd" and "A.B.C. Builders" must not both exist.
A single record per supplier, with alternative names as aliases rather than as separate accounts.
Payment terms, actual rather than a default 30 days you've never checked.
Default account code and tax treatment. The setting that lets most invoices code themselves.
Bank details, with a change history. Treated carefully — an unremarked change here is how invoice fraud lands.
Contact for queries, and preferably a second one, since single points of contact leave.
Company or VAT registration number where you have it. This is the only genuinely reliable deduplication key, because names vary and registration numbers don't.
Status — active, dormant, or blocked. Not deleted.
Duplicates are the main problem
One supplier existing twice is what defeats everything else. Duplicate payment checks compare within a supplier record, so two records mean two separate histories and no detection. Spend analysis splits the total in half and hides that the supplier is one of your largest. Negotiated terms sit on one record while invoices arrive against the other.
They arrive predictably:
- Different spellings and punctuation — "Ltd", "Limited", "Ltd."
- Trading name on one, legal name on the other
- A branch or division set up separately from head office
- Rushed setup for a one-off purchase, never checked against the existing list
- A supplier renamed after acquisition, with the old record left active
Cleaning the list
Worth doing once properly rather than continuously and half-heartedly.
1. Export everything with total spend and last transaction date per record.
2. Sort by name and read it. Most duplicates are visually obvious once the list is alphabetical. Normalise for punctuation and legal suffixes as you go.
3. Cross-check by bank account and registration number. Two records sharing bank details are almost certainly one supplier. This catches the pairs whose names look nothing alike.
4. Merge rather than delete. Merging preserves transaction history against one record. Deleting a record with history either fails or orphans transactions.
5. Mark dormant records inactive, don't remove them. Anything with history needs to stay for the retention period. Inactive keeps them out of the dropdown without losing the audit trail.
6. Fix terms and defaults while you're in there, since you're already reading every record.
For a list of a few hundred, this is an afternoon. It won't need doing again if the controls below hold.
Keeping it clean
One person, or one role, creates suppliers. The most effective single control. Where anyone can add a supplier mid-entry to get an invoice posted, duplicates are guaranteed.
Search before creating, on more than the name. Search the registration number or bank account. Name search misses precisely the duplicates that matter.
A required minimum. A record that can be created with only a name will be. Require terms, a default code, and a contact.
Review new suppliers periodically. A short monthly list of what was added is enough to catch drift while it's still small.
Review dormancy annually. Anything with no transactions for two years goes inactive. A dormant active record is a route for a fraudulent invoice to look plausible.
Bank details need their own control
This is the part where master data stops being housekeeping and becomes a financial control.
The standard invoice fraud is a request to change a supplier's bank details — by email, often convincingly, sometimes from a genuinely compromised supplier mailbox. If bank details can be changed by whoever is processing the invoice, the control doesn't exist.
The rules worth enforcing:
Never change bank details from an email instruction alone. Regardless of how it looks or who it appears to be from.
Verify by phone, on a number you already had. Not a number on the letter requesting the change. This is the entire control, and it's the step that gets skipped when someone is busy.
Separate the roles. Whoever can change bank details shouldn't be whoever approves payments.
Log every change — old value, new value, who, when, who verified it. Alongside the retained request.
Flag recent changes in the payment run. An invoice paid to details changed in the last 30 days is worth a second look before the money leaves.
Worth applying this to new supplier setup too, not only to changes. A fraudulent new supplier avoids the change control entirely, which is why the creation step matters as much as the amendment step.
What good looks like
You can answer these without a project:
- How much did we spend with this supplier last year — as one number, not two?
- When did their bank details last change, and who verified it?
- Which suppliers have we not bought from in two years?
- How many active suppliers do we have, and does that number look plausible?
If the last one is much larger than you expect, the list has duplicates and dormant records in it, and the controls that depend on it are weaker than they appear.
Cribble matches incoming invoices to your existing supplier records rather than creating new ones, and remembers the coding you apply per supplier. Documents are read to the line item, so what lands against a supplier is detail rather than a total.