Supplier master data is the authoritative record of who a supplier is: the legal entity, where it is registered, how it is paid, and on what terms. It sits in the systems that transact with the supplier, usually the ERP or the P2P platform, and every downstream process reads from it rather than keeping its own copy.
It is the least interesting data in procurement and the most consequential. An error in one field does not stay in that field: it reaches every transaction that reads it, and correcting it after six months of posted documents is a far more expensive job than getting it right at creation.
What the record carries
Field names vary by system, but a complete supplier record covers the same territory everywhere.
- Legal entity name and registered address. The name on the incorporation documents, not the one on the invoice header. This is the field that determines whether two records are the same supplier.
- Trading names and operating addresses. One legal entity may trade under several brands and ship from several depots. These are attributes of a single entity, not separate entities.
- Tax and VAT registration. Required for invoice validity in most jurisdictions, and the basis for tax reporting and reverse-charge treatment. Recorded wrongly, it produces invoices that cannot be posted correctly.
- External identifiers. DUNS, LEI, national company registration numbers, and the identifiers used by e-invoicing networks. Their value is that they are assigned outside the buying organisation, so they can test whether two internal records point at the same real entity.
- Ordering and remit-to addresses. Where the order goes and where the money goes are different questions with different answers: a supplier may take orders at three regional desks and be paid at one shared service centre.
- Payment terms, method and currency. Net thirty from invoice date and net thirty from month end are not the same terms, and the difference is real money at volume.
- Bank details. Account and routing identifiers plus the account holder name, which should correspond to the legal entity rather than to an individual.
- Contact roles. Not a contact but roles: the order desk, accounts receivable, the account manager, whoever owns certification renewals, and an escalation path. Recording one named person means the record degrades the day that person changes job.
- Category and commodity assignment. UNSPSC or an internal taxonomy, mapping the supplier to what they actually sell. This is the field that makes spend analysis possible, and the one most often left blank.
- Certifications and their expiry dates. Insurance, food safety schemes, ISO standards, sector licences. The expiry date is the load-bearing part: a certificate with no recorded expiry is an unmonitored liability.
- Status. Active, pending, blocked, archived, one-time. Most systems separate blocked for ordering from blocked for payment, and conflating the two is how an organisation ends up unable to pay for goods it has already received.
Why the record is load-bearing
Four processes read supplier master data continuously, and each fails differently when it is wrong.
Purchase order issuance takes the ordering address, the contact and the currency from the record, so a wrong ordering address surfaces as a delivery that never arrives rather than as a data problem. Invoice matching then has to resolve the incoming invoice to a vendor before it can compare anything at all, and if the invoice carries a VAT number or bank details that do not correspond to the vendor on the order, matching either fails or succeeds against the wrong record. That chain runs from requisition to purchase order through three-way matching, and the supplier record is read at every step of it.
Payment takes bank details, terms and currency straight from the record with no further human judgement applied, which is why it has the least tolerance for error of the four. Spend analysis groups transactions by vendor record and by category assignment, both master data fields, so the quality of every category strategy and negotiating position is capped by the quality of the master file.
The duplicate problem
The defining operational failure of supplier master data is duplication: one real supplier existing as several vendor records.
It happens for ordinary reasons. Two sites create a record because neither searched for an existing one, or searched and did not find it. A record is created in 2019 as “Rossi Forniture Srl” and again in 2023 as “Rossi Forniture S.r.l.”
The consequences compound quietly.
- Spend is split. A supplier with four hundred thousand euro of annual spend appears as four records of roughly a hundred thousand, all below the threshold that gets a category manager’s attention.
- Leverage is invisible. You cannot claim volume you cannot demonstrate. The supplier knows what the relationship is worth; the buyer, reading its own master file, does not.
- Terms diverge by record. One carries net thirty, another net sixty, a third a settlement discount nobody remembers agreeing. The buyer is quoting its own inconsistent data back at itself.
- Compliance status is per record. Due diligence performed against one record does not attach to the others, so transactions flow through a record nobody screened.
Why duplicates are hard to prevent
Exact-match blocking on name catches almost nothing, because names vary in entirely legitimate ways: legal suffixes written differently, punctuation, abbreviations, transliteration, and the trading name used in place of the registered one. Beyond formatting, the entities themselves move. Companies rebrand and the master file is not told. Acquisitions turn two records that were correctly separate into one entity, and nothing in the buyer’s systems observes that.
The reverse case is why aggressive automatic deduplication is dangerous. Subsidiaries frequently share a brand and an address while being genuinely separate legal entities, with separate tax registration, separate bank accounts and separate liability. Collapsing two real entities into one is a worse error than holding two records for one, because it produces payments to the wrong company.
Matching on an external identifier is materially stronger than matching on name, which is an argument for making one mandatory at creation rather than optional.
Why duplicates are hard to merge
Once transactions reference a record, it stops being a data object and becomes a historical reference. Open orders, unpaid invoices, goods receipts, payment history, contracts and audit trails all point at the vendor ID.
Most ERPs therefore do not offer a true merge. They offer block and redirect: mark the duplicate inactive, let open items run off against it, and map the old ID to the survivor in the reporting layer. That works, but the mapping now lives outside the ERP and everyone building a report has to know it exists. A merge performed in the transactional system but not in the analytics layer produces two versions of the truth instead of one.
Who is allowed to change the record
Governance here is not bureaucracy for its own sake. It is a financial control.
The core rule is segregation of duties: the person who can change a supplier’s bank details must not be the person who can release a payment to that supplier. If one person can do both, one person can redirect money. Where a team is genuinely too small to separate the roles, the control has to be reconstructed some other way, normally by requiring approval of bank detail changes from outside the team entirely.
The reason this field attracts specific controls is supplier bank detail change fraud, which is well established and still works. Supplier onboarding covers the attack and the control that defeats it, out-of-band verification against contact details sourced independently of the request. What is worth adding here is that the control cannot exist only at onboarding. A record is created once and amended for years, and the amendment path is the one attackers use, because it is usually governed less tightly than creation.
Beyond that, a functioning model answers in writing who may create a record, which fields require approval to change, who owns the record afterwards, and how each change is evidenced.
Data decay
Supplier master data goes stale continuously, and nothing tells you.
Certifications are the easy case, because they expire on a date written on them. Everything else decays silently. Contacts leave. Bank details change legitimately. Entities are acquired, restructured, dissolved and reconstituted. Registered addresses and VAT registrations change on reorganisation. None of it generates an event in the buyer’s systems, because the buyer is not party to any of it.
So a record that was accurate the day it was created degrades at a rate nobody measures. The workable response is revalidation proportional to exposure rather than continuous verification of everything: scheduled for strategic and high-spend suppliers, event-driven for the rest, triggered by a failed payment, a returned communication or a certificate approaching expiry. Pushing routine maintenance out to the supplier through a supplier portal helps for the fields the supplier knows best, with the caveat that it only works for suppliers who actually log in.
How it fails in practice
Four patterns account for most of it.
Creation without validation. A free-text form, no mandatory external identifier, a duplicate check that matches only on exact name, and no verification that the entity exists or that the bank account belongs to it. Everything expensive downstream starts here, and this is the cheapest point at which to intervene.
No owner after creation. Procurement creates the record, finance amends it, the requesting site uses it, and nobody is accountable for whether it is still correct. Shared responsibility for data quality reliably produces none. Ownership has to name a role.
Cleansing projects that leave creation untouched. An organisation deduplicates the master file, reports the number of records removed, and stops. The creation process is unchanged, so the file degrades again immediately and needs the same project in three years.
Classification left empty. Category and commodity fields are optional at creation, so they get skipped under time pressure. Two years later the spend analysis cannot say what the organisation actually buys, and the remedy is a manual reclassification exercise across thousands of records.
The catalog layer sits directly on top of all this. Every price, every item and every PunchOut session resolves back to a supplier record, and content arriving from many suppliers in many formats is where identity fragments: a supplier sending a spreadsheet from one depot and an EDI feed from another can easily arrive as two suppliers. Normalising supplier identity as content enters the system, rather than reconciling it afterwards in the master file, is part of the design of SupplierForge. It does not remove the need for governance in the ERP, but it stops the catalog layer from becoming an additional source of duplicates.