I have sat in the meeting where four people each open a different screen and read out a different address for the same customer. Everybody in the room has heard the phrase single source of truth. Two of them have it in a slide deck. Nobody can say which of the four values is the one the invoice should use.
That is the whole test, and it takes one question: when two systems disagree, which one is wrong? If the answer needs a meeting, you do not have a single source of truth. You have copies, and one of them happens to be older than the others.
Decided, not stored
The phrase gets attached to whichever system holds the most data. That is the wrong axis. A single source of truth is the place where a value is decided, not the place it is copied to.
The distinction sounds academic until you try to fix something. A warehouse holds every address you have ever loaded and can tell you what each system thought last night. Ask it which address is correct and it has no opinion, because nothing in it was ever a decision. It is downstream by design, refreshed on a schedule, and nobody edits a customer in it. We wrote about that gap separately in why your data warehouse lies.
The ERP has a better claim, and for transactions it is usually right. For reference data shared across five systems it is a bad landlord: the master tables carry fields that exist because of the ERP, the validation was written for the ERP's own processes, and one acquisition later there are two ERPs having the same argument. That is a longer post on its own: why your ERP is not an MDM system.
Four things it needs
Skip any one of these and you are back to copies, whatever the diagram says.
1. One place the value is decided
One place a person or a process is allowed to change it. Everywhere else reads, and storing a copy is not the same as being allowed to decide. The moment two systems can both change the same field, you are running a race and the winner is whoever saved last.
2. A gate on every way in
This is where most attempts fail, and they fail without anyone noticing. Somebody writes the validation into the form. The form is one of five doors. Data also arrives by paste, by file import, by a scheduled load from an ETL job, and through the API. Four of those never see the form. A rule that only lives in the screen is a rule that guards the one route careful people use anyway.
3. A history you can read
Not a log that proves a change happened, but a record of who changed it, when, what it was before, and ideally why. Without the old value, an audit trail answers the least interesting half of the question. We went into what makes one usable in the master data audit trail.
4. A way to read it that is not another copy
If every consumer takes a nightly extract, you have built a fifth copy and called it distribution. Something has to give the other systems a live read, either a view they query or an endpoint they call, so the answer they get is the answer and not last night's.
How we built it
Primentra is one database on your own SQL Server holding the entities you decide to master: supplier, product, location, whatever causes the most arguments. That covers the first requirement by construction: the value is decided there and the other systems read it.
The second one is the part we cared most about getting right. A business rule in Primentra is not attached to a screen. It lives with the entity, and every write goes through the same stored procedure, so the same rule runs whether the value was typed into the grid, pasted in, loaded from a file, staged by an overnight job, submitted for approval, or written through the REST API. An error-severity rule refuses the row on all of them. There is no back door, including for an administrator: force approve skips the approvers, not the rules.
The history is per field. Every change records the user, the time, the old value and the new one, plus the comment the person typed when they saved. Where an entity needs a second pair of eyes, a change becomes a request somebody has to approve before it is real, and the decision is recorded with it.
For the fourth, there are two reads and neither one is a copy. Integration views are ordinary SQL views in your database, so a consuming system joins to master data the way it joins to anything else. They are the replacement for what MDS called subscriber views, covered in what replaces MDS subscriber views. For everything that is not on the same server there is a REST API with per-key permissions.
What it does not fix
None of this decides which address is correct. A gate refuses a value that breaks a rule; it has no opinion about a plausible value that happens to be wrong. Somebody still has to own the domain and answer the question when two departments disagree. If nobody owns it, you get a very well documented argument and no decision. That is the subject of nobody owns your master data, and it is a people problem wearing a software costume.
It also does not retire the copies for you. The four systems in that meeting keep their own address fields; what changes is that they now have somewhere to get the right one, and a reason to stop editing their own. That migration is gradual, and pretending otherwise is how MDM projects earn their reputation.
Common questions
Is our data warehouse the single source of truth?
No, and it was never built to be. A warehouse reads from the systems that hold the data, on a schedule, and nobody edits a customer address in it. It tells you what the numbers were. It cannot tell you what the address is, because it was not where the address was decided.
What about the ERP?
The ERP is authoritative for transactions, and that is a real answer for order lines. It is a poor home for reference data shared across systems: the master tables carry ERP-specific fields, the validation was written for its own processes, and one acquisition later you have two ERPs and the same argument again.
Can we get there without a big project?
Yes, if you stop trying to do every domain at once. Pick the one that causes the most arguments, usually supplier or product, and give that one a home, a gate and a history. A domain that works is a better argument for the next one than any slide.
Is this just deduplication?
No. Deduplication is what you do because you never had a single source of truth: two records exist and somebody has to decide which survives. A single source of truth is what stops the second one being created. The cleanup is the symptom.
Pick the domain that causes the most arguments
Model it, put a gate on every route in, and let the other systems read it. Primentra runs on your own SQL Server, deploys in a day, and costs €7,500 per year flat, with a 60-day trial.