A master data record is not a thing you create once and walk away from. A customer, a supplier, a product, a GL account: each one has a life. It gets created, checked, approved, copied out to half a dozen systems, left alone for a year, and eventually pulled out of circulation. That whole arc is the master data lifecycle.
The stages themselves are rarely where things go wrong. The damage happens in the seams between them, the handoffs where a record changes hands and no single person is watching it cross.
The six stages, briefly
You can carve the lifecycle up a dozen ways, but six stages cover almost everything that matters.
Create
a record is born
Validate
does it meet the rules
Approve
review before it goes live
Distribute
push to other systems
Maintain
keep it current
Retire
stop using it, safely
None of that is controversial. Any MDM vendor will draw you a version of this diagram. What the diagram never shows is the gaps between the boxes, which is exactly where I want to spend the rest of this post.
The seams, where it actually breaks
Walk the lifecycle from one stage to the next and the failure modes line up neatly. Four of them do most of the damage.
Create → Validate
The duplicate that nobody caught
A record gets created before anyone looks at the existing list. The validation rules pass, because a second "Acme Corp" is still a perfectly valid company. You now have two of them, and every downstream system gets to pick one at random.
Validate → Approve
Validation mistaken for judgement
A record clears every automated rule and goes straight live. Rules check that a field is filled and formatted, not that the value is true. A correctly formatted, completely wrong tax ID sails through. Validation is a filter, not a reviewer.
Distribute → Maintain
The copy that got edited in place
The approved record lands in six systems. Then someone fixes a typo directly in the CRM instead of in the source. Now one of the six disagrees with the other five, and there is no way to tell which one the next report will trust.
Maintain → Retire
The record that rotted in place
Nothing technically broke. The record still exists, still validates, still distributes. But the company moved, the contact left, and nobody owns the job of noticing. It is clean data that happens to be false.
Create is where the duplicates are born
Almost every duplicate master data problem traces back to the same moment: someone needed a record, could not easily see whether it already existed, and created a new one to keep moving. The validation that runs next is no help here, because a duplicate is not invalid. A second supplier called "Acme" with a slightly different spelling passes every rule you can write.
The fix is not a smarter rule. It is making the existing list visible at the point of creation, so the person about to add "Acme Corp." sees the "Acme Corporation" that is already there. Once a record is the source of truth, the goal is one of them per real-world thing, which is the whole point of a golden record.
Validation is not review
This is the seam people conflate most. Validation rules are excellent at catching the obviously broken: an empty required field, a malformed IBAN, a country code that does not exist. They are useless at catching the plausibly wrong. A tax ID that is real, formatted correctly, and belongs to a different company will pass every check and still be wrong.
That is why the approve stage exists as a separate thing. A human who knows the domain looks at the record and asks a question no rule can: is this actually true? An approval step does not have to be heavy. Even a single reviewer who has to sign off before a record goes live closes the gap between "well-formed" and "correct."
Distribution is where copies start to lie
Once a record is approved, it gets distributed to downstream systems: the ERP, the CRM, the warehouse, a couple of integrations you forgot about. The record is now in seven places. As long as the source stays the only place anyone edits it, the copies stay honest.
The seam opens the first time someone fixes a value directly in a downstream copy. A salesperson corrects an address in the CRM. It is faster than going back to the source, and it feels harmless. Now one copy disagrees with six others, and the next report has no way to know which one is right. The discipline that prevents this is boring and absolute: edits happen in one place, and everywhere else is read-only.
Maintain is the stage everyone forgets
The other seams produce visible breakage. This one produces silence, which makes it worse. A record can be created cleanly, validated, approved, distributed perfectly, and still be wrong a year later, because the real world it describes moved on and nobody updated it.
Contact data decays at a couple of percent a month. I have written before about how master data goes stale in months, not years. The maintain stage is not housekeeping you do when you have time. It is a standing responsibility, and the usual reason it gets skipped is that nobody actually owns the data. A lifecycle with no owner for the maintain stage will rot in place no matter how good the first four stages were.
Retire, not delete
The last seam is the one that looks like a tidy-up and is actually a landmine. A record is no longer in use, so someone deletes it. Then a five-year-old invoice that still references it stops resolving, a historical report shows a blank where a supplier name used to be, and a downstream system throws a foreign-key error nobody can explain.
Master data is referenced by data you cannot see. That is the whole reason soft delete beats hard delete for almost every master record. Retiring marks the record inactive and keeps it in place so history still resolves; deleting tears it out and breaks whatever was leaning on it. The only safe hard delete is a genuine mistake that was never used, caught the same day it was made.
The lifecycle is a governance question, not a feature
None of those fixes are clever. See the list before you create. Put a human between valid and live. Edit in one place. Give the maintain stage an owner. Retire instead of delete. Every one is a handoff with a clear rule and someone accountable for it.
The thing that makes all of this enforceable is a single system that owns the record across its whole life, with an audit trail that records every crossing. When you can see who created a record, what rule it passed, who approved it, where it went, who last touched it, and when it was retired, the seams stop being invisible. You cannot manage a lifecycle you cannot watch.
Common questions
What is the master data lifecycle?
The stages a master record passes through from creation to retirement, commonly grouped as create, validate, approve, distribute, maintain, and retire. The value of naming them is that most quality failures happen at the handoffs between stages, not inside any one stage.
Where do master data quality problems actually come from?
The seams between stages. Duplicates from skipping the check before create. Wrong-but-valid records from treating validation as review. Drift from editing a distributed copy in place. Decay from an unowned maintain stage. Broken references from deleting instead of retiring. Each one is a handoff nobody owns.
How long does master data stay accurate?
Less time than people think. Contact data decays at roughly two to three percent a month, so a meaningful share of any dataset is wrong within months. The maintain stage is a continuous job, not one-time housekeeping. Data loaded once and never reviewed is wrong within a year regardless of how clean it started.
Is retiring the same as deleting master data?
No. Retiring marks a record inactive while keeping it in place so historical transactions still resolve. Deleting removes it and breaks anything that still references it. Master data should be retired with a soft delete or status change in almost all cases, because it is referenced by data you cannot see.
Own the record across its whole life
Primentra holds each master record from create to retire in one place: validation rules at entry, an approval step before it goes live, controlled distribution, soft-delete retirement, and a full field-level audit trail of every change. It runs on SQL Server, deploys in a day, and costs €7,500 per year flat. The 60-day trial includes everything.