Most definitions of a golden record stop at the outcome: one trusted record for every customer, supplier, material or employee. Accurate enough, and of little help to the team that has to build that record alongside SAP S/4HANA, a CRM and an HR system. In practice a golden record is the product of three separate decisions, each with its own rules and its own owner. Which records describe the same real-world thing? Which value wins when the sources disagree? And who approves the result before it reaches the systems that depend on it?
Get any one of them wrong and your “single version of the truth” becomes one more version. On SNOK MDM projects, each of these decisions runs on its own set of rules.
Record matching: when two entries are the same company
The same company sits in the ERP under its registered name, in the CRM under a trading name and in the procurement system with no tax ID at all. A material carries one description in the warehouse and another in the purchasing catalogue. Before anything is merged, the master data layer has to establish which of these records point to the same thing.
Deterministic rules settle the cases where an identifier decides: a matching tax ID, company registration number or manufacturer part number. Ambiguous cases - variant spellings, abbreviations, reordered words, a legal form written three different ways - are referred by SNOK MDM to a data steward for review.
We do not merge automatically, for two reasons. A false merge of two distinct companies can be harder to spot and costlier to unwind than a duplicate left in place, because it can lead to transactions being posted to the wrong party. And where personal data is involved, review by a data steward reduces the risk of linking records that belong to different people.
A valid identifier is no excuse to relax. In a ruling of 24 March 2026, Poland’s National Tax Information Director confirmed that KSeF, the country’s mandatory e-invoicing platform, checks an invoice against the schema but not whether the buyer’s tax ID belongs to the right company. An invoice carrying another firm’s perfectly valid tax ID is accepted and delivered to that other firm. Two customer records that look like one company but are in fact two can end up in someone else’s accounts.
Survivorship: which value wins
Once a group of records is confirmed as a single entity, the golden record has to be assembled from them. Sources rarely agree. One holds the current address, another the correct bank account, a third the correct billing contact.
Survivorship rules decide, field by field, which source is authoritative. The usual criteria are how far a given system is trusted for a given field, how recently the value was confirmed and whether it passed validation. The tax ID might come from the system that checks it against the official register, the delivery address from logistics and the payment terms from finance.
These rules belong to the golden record model. We document and version them, so that decisions do not depend on whoever tidies the data before month-end close. That is what separates a one-off cleanse from a master data layer. A cleanse fixes the file on migration day; validation rules applied to every new record limit the return of the errors they cover. Our report Master data in Polish enterprises lists cleansing without entry rules as one of four patterns that sink data quality programmes.
The data steward: data governance in practice
A golden record with no owner ages as fast as the sources it came from. We therefore set governance rules for each domain separately: who owns the data, who approves a change, which fields are access-controlled or masked, and how data quality is measured.
The organisation’s own procedure sets who approves changes in a given domain. SNOK MDM records the change history of every golden record and the reason for each change. Article 5(1)(d) of the GDPR requires personal data to be accurate and, where necessary, kept up to date - and the people who represent your customers and suppliers are data subjects too.
Deciding whether two records describe the same company takes business knowledge. Without a data steward who has the authority to settle it, each unresolved case waits for the next committee meeting.
A golden record alongside SAP, without replacing the ERP
In SAP-centric organisations the first question is usually SAP Master Data Governance. Where data is created and maintained mainly in SAP, SAP MDG is a sensible choice. It gets harder when important domains live outside SAP (in the CRM, the HR system, the systems of acquired companies), or when the master data layer has to survive a future ERP replacement. We set out where each option fits in our comparison of SAP MDG, Reltio and SNOK MDM.
We design the master data layer to be independent of both ERP and CRM, working with SAP S/4HANA and ECC, Microsoft Dynamics 365, Salesforce, Oracle Cloud ERP, Workday and custom sources. The scope of integration and the direction of data flows are agreed for each implementation, and the source systems keep their operational role. The golden record and its rules stay in the master data layer, so replacing a source system is mainly a matter of changing an integration.
The trigger for this work is often the move to SAP S/4HANA. Business Partner is mandatory there, and Customer Vendor Integration moves customer and supplier records onto it. CVI carries data into the new model; it does not improve it. Duplicates and missing mandatory fields either travel into the target system or block the conversion until the exceptions are resolved. We describe the sequence of work in our piece on Business Partner in SAP S/4HANA. Building the customer and supplier golden record before conversion means the project starts with data that is already matched and approved.
A first result in one domain
Starting too broad is the first of four recurring patterns we see in failed master data programmes. In December 2021 Gartner predicted that more than 75 per cent of master data management programmes would fail to meet their business objectives by 2025 (Magic Quadrant for MDM Solutions). In a pilot we start with one domain and one measurable success criterion, such as the share of duplicates among customer and supplier records or the number of records missing critical fields.
We usually complete a single-domain pilot within four to eight weeks, depending on the state of the data and the number of systems that need to receive it. That is the time to a first measurable result; further domains follow. It is how we work with Medicover on employee master data, among others: 18 countries, around 45,000 employees and roughly 100,000 data events a year, with validation, an approval workflow and a full change history.
You can size the problem in one domain yourselves before any project decision. An extract of your customer and supplier master data is enough, plus a few questions: how many records share a tax ID under different names or addresses, how many are missing fields your processes treat as critical, and how many differ between ERP and CRM for the same company. The measurement method, pilot metrics and market data on master data in Polish companies are in our report Master data in Polish enterprises, which you can download free of charge, with no form to fill in.
The scope of work, pilot deliverables and the request form for a duplicate measurement are on our Master Data Management page. The product we build golden records on is described on the SNOK MDM page.