# One supplier, five names - why procurement cannot see its own spend

> Why procurement cannot see its own spend with a single supplier, what a governing record is, and how to size the problem in your organisation without a project.

- Source: https://snok.ai/en/news/blog/one-supplier-five-names-supplier-master-data/
- Author: Michał Korzeń
- Published: 2026-09-17

---
The week before a major negotiation, the same work starts again. Someone pulls spend out of the ERP. Someone adds the orders that only ever went through the sourcing platform. Someone remembers that a subsidiary buys from the same supplier separately, on its own contract. Two days later there is a spreadsheet that is, briefly, the only place in the business that knows the truth about that supplier.

Then the spreadsheet stays in an inbox, and in six months it has to be built from scratch.

This is not a story about sloppiness. It is a description of the normal state of an organisation that has grown, acquired, changed systems, and had to keep buying throughout. It is worth naming what the work actually costs, though - because the cost is not the days spent assembling the spreadsheet.

## You negotiate with a record, not with a supplier

Procurement does not sit down with a company. It sits down with whatever the systems know about that company. If the same legal entity exists in five places under five spellings of its name, the organisation is holding five conversations with five mid-sized suppliers instead of one conversation with a large one.

The spend is identical. The negotiating position is not.

![Five spend amounts with one supplier across five systems, and a single combined amount once the records are linked](https://snok.ai/images/blog/mdm-dostawcy-piec-kwot-jedna-kwota-en.webp)

*Spread across systems, the spend looks like five unremarkable suppliers. The same total in one place changes the conversation.*

The drift comes from small, entirely reasonable things. The legal form written four different ways. A trading name alongside a registered one. A tax number entered once with separators, once without, once in the notes field. A branch, a head office and a subsidiary as three separate records. The same entity appearing once as a supplier and once as a customer. And a record created late on a Friday because the order was urgent, and searching for the existing one would have taken longer than creating a new one.

Each of those decisions made sense on its own. Only their sum, after fifteen years, produces a database in which nobody can answer the question of how many suppliers the company has.

## What this hides

**The corporate group.** Six entities under one owner appear in the database as six independent suppliers. You are dealing with a group, though, and the group looks at combined turnover. Without ownership links, the organisation does not know it is a strategic customer to that group, and it sits down at the table as six unremarkable ones.

**The category.** The same service lands in three different categories across three systems, because each system has its own taxonomy. Until there is a shared classification, nobody can say what the company spends on a given category. Category strategy is the basic instrument of procurement work - and you cannot build one on a number that does not exist.

**The contract.** A buyer could not find the governing contract, because they searched under a different name. They ordered outside it, in good faith and in line with procedure. The negotiated rate stayed in the document, and the company paid list.

**Money that went out twice.** The same invoice booked against two records of the same counterparty looks like two separate liabilities.

## A record with no owner

Procurement creates the supplier record. Finance changes the bank account number. Accounts payable fills in the gaps when an invoice arrives. IT moves the whole thing during the next system project. Every one of those steps is justified, and yet nobody owns the record as a whole.

In Poland that gap carries a very specific price. The bank account number is a field on the supplier record, and for business-to-business transactions above PLN 15,000 gross, paying into an account outside the register maintained by the Ministry of Finance means the amount cannot be treated as a tax-deductible cost, and it brings joint liability for VAT the supplier has not paid. Notifying the head of the tax office within seven days lifts the sanction - but somebody has to catch the mistake first.

If a supplier has five records across your systems, the account check has to fire five times. One stale record is enough.

Sanctions screening and ultimate beneficial ownership checks work the same way. You cannot screen an entity properly if you cannot count it.

## The year this stops being manageable by hand

Two things change in 2026 at once.

First: there is more work in procurement and fewer resources to do it. The Hackett Group, in its 2026 procurement agenda study, reports an eight per cent increase in workload alongside falling headcount and operating budgets. Work that used to disappear into an analyst's overtime simply will not happen under those conditions. The pre-negotiation spreadsheet will either be worse, or it will not exist.

Second: agents are arriving in procurement. The same Hackett study reports that 76 per cent of organisations see AI-driven improvements of 25 per cent or more in key performance metrics as adoption scales. However those metrics are counted inside any one company, a number like that no longer describes a pilot.

A person will recognise that "ABC Sp. z o.o." and "A.B.C. Polska" are probably the same entity. They will hesitate, check, ask a colleague. An automated process will do the same only if it is given a way to resolve entity identity and a point at which a human approves the decision. Without those two things it will act on whichever record it happens to receive - and it will do so faster than a buyer. Automation built on a database full of duplicates does not fix the drift; it reproduces it at scale.

## Does SAP S/4HANA not solve this

Partly, yes. The data model in SAP S/4HANA has been tidied up: Business Partner replaced separate supplier and customer records, and the built-in duplicate check warns whoever is creating a record that a similar one already exists. That protects you against the next duplicate, and it is worth switching on.

It does not solve two things. Converting to Business Partner carries the existing state into the new model, so duplicates travel across with everything else. And no control inside SAP can see what lives in the sourcing platform, the invoice workflow and the buyers' spreadsheets. SAP Master Data Governance goes further and is sometimes the right answer - we say so openly. It is also sometimes too heavy an answer where a meaningful share of what you know about counterparties lives outside SAP, which [after an acquisition](https://snok.ai/en/news/blog/sap-mdg-vs-informatica-mdm-after-acquisitions/) is very nearly always.

## The governing record, concretely

"Golden record" has been circulating in the market for years and has worn thin, so it is worth naming without the jargon.

A governing record is a single supplier record designated as authoritative, assembled from the best data across all systems, in which every field carries where it came from and who last changed it. Source systems carry on unchanged. They gain exactly one thing: the knowledge that they are describing the same entity.

![A governing supplier record with four fields and the source system shown for each](https://snok.ai/images/blog/mdm-dostawcy-rekord-pochodzenie-pol-en.webp)

*Field provenance is part of the record, not a separate document. It is what lets you reverse a decision and defend it to an auditor.*

What it is for, counted concretely:

- totalling spend with one entity and across its whole corporate group, which is to say: negotiating,
- checking a bank account number before payment in one place instead of five,
- screening an entity for sanctions, VAT status and ultimate beneficial ownership,
- supply chain reporting, including for sustainability disclosure,
- automation and agentic scenarios, so the process does not have to guess who it is dealing with,
- [conversion to SAP S/4HANA](https://snok.ai/en/news/blog/secure-sap-s4hana-conversion-rise-with-sap/), which requires entity identity to be unambiguous,
- audit, because the origin of every field and the history of changes are on record.

And three things a governing record is not. It is not a new ERP. It is not a data warehouse. It is not a one-off clean-up after which everything returns to its starting state within a year.

## A layer above the systems, not instead of them

This is how we do it in [SNOK MDM](https://snok.ai/en/products/snok-mdm/): we add a layer that recognises one entity across many records and holds that state over time. Source systems stay where they are and carry on working. Merge proposals come from a matching engine and are approved by a person - a data steward on your side - and every such decision goes into the audit trail.

We start with a [diagnostic workshop](https://snok.ai/en/offer/master-data-management/) of roughly two weeks. You come out of it with a map of sources, a report of suspected duplicate pairs with their count, and an assessment of how many of them a rule can settle and how many need a person. That is the first moment at which "how many suppliers do we have" gets a number rather than an estimate.

Then comes a pilot on one domain, four to eight weeks. It ends with a working governing record for that domain, matching rules described in the language of your process, an ownership hierarchy for the entities in scope, and acceptance criteria agreed before the start - on your own data, not on a slide. Fixed fee per phase. The data and the model remain yours.

## Four things we settle before we start

**How much work stays on your side.** In a pilot that is usually one person from procurement as data steward, a few hours a week adjudicating contested pairs, plus access to sources from IT. Without that person the project stops at the first contested pair, whatever the technology.

**What happens to a wrong merge.** A merge is a recorded decision, not an overwrite. Source records stay untouched, and the link can be reversed together with the reasoning, and with who approved it and when. A rule that raises doubt goes into a queue for a person rather than acting automatically.

**What happens to data security.** We work on the scope needed to resolve entity identity, in an environment agreed with you, with an access log. Account numbers and personal data of contacts are treated as production data, including during the diagnostic phase.

**Who maintains the record after the pilot.** Maintenance is part of the solution, not its absence: rules, a queue of cases to adjudicate, and a periodic review. That is the difference between a governing record and a one-off database clean-up, after which the duplicates return with the first urgent Friday afternoon order.

## When this is not worth doing

Honestly, because it does not pay off for every company.

If the entire landscape sits inside one ecosystem and the strategy is to stay there, the answers are worth looking for in that ecosystem's own tooling first. If the supplier base runs to a few hundred entities in one system and one legal entity, discipline in record creation and a quarterly review will do - the project would be a cost without an addressee. If the scale runs to tens of millions of records with a real-time requirement, that is a different class of solution.

## Three questions to start with

You do not need a project to find out whether this problem applies to you.

First: how many active suppliers do you have, and how many entities does that actually represent.

Second: what does the company spend with its largest supplier, counting every legal entity on both sides - and how long does it take to produce that number. The response time says more than the number itself.

Third: who approves a change to a supplier's bank account number, and in how many places does it have to be entered.

If any of those answers requires assembling data by hand from several systems, start with the smallest possible step: take one purchasing category, compare its sources, and count how many records describe the same entity. That is two weeks of work and no decision about replacing a system. Only that number tells you whether it is worth going further.