Master data ownership

One list, one owner, one standard is the advice everywhere. It fails everywhere, because ownership is written as a name on a chart when it is really a permission in a system. An owner who cannot refuse a record does not own the list.

Guide  ·  updated 2026-10-17

Six lists decide whether a new system behaves: customers, suppliers, items and services, the chart of accounts, sites and locations, employees. Everything else in an ERP is a transaction against one of them. The advice for all six is to name an owner, and that advice is unfalsifiable as written, which is why naming owners so rarely changes anything. Here is the version that can fail a test.

The ownership test

Three questions, asked of one list at a time. They are about capability, not intent.

• Can the owner decline a record somebody wants? Not advise against. Decline, and it does not exist.
• Does a new record pass through the owner before anyone can transact on it? If a salesperson can quote against a customer the owner has never seen, the answer is no.
• Is the owner told when a record is deactivated? Owning a list includes owning what leaves it.

Run it against your six lists and count the yeses. Any single no means that list is unowned, whatever the org chart says. The usual result is three yeses on the chart of accounts, which accounting systems restrict by default, and a no on customers and items, where everybody who sells or buys can create. That is not a discipline problem. It is the permission model you already have, telling you which lists are governed and which are merely assigned.

The owner-versus-steward table every page prints, in which the owner decides and the steward does, is not wrong. It is downstream of this. Deciding what you cannot prevent is advice.

Ownership is per field group, not per record

An ownership argument is presented as a fight over a record and is usually a disagreement about fields. Sales wants the customer's name as the client writes it; finance needs the name on the tax registration. Both are right, about different fields of one record, and declaring the customer CRM-owned settles nothing. Write ownership at field-group level and the argument ends in a page.

The same split applies to items, where the cost and revenue accounts sit with finance, specification with operations and price with sales, and to suppliers, where bank details belong to finance alone and never to whoever receives an email asking for them to be changed.

Record or field: the rule that stops the list multiplying

No general guidance answers the question that creates list growth: is this a new customer, or the same customer again? A new item, or a variant? With no rule, people create a record for every description they need to see, and the list grows by description rather than by entity long before any governance arrives.

The rule: a record exists only for something that must be transacted against separately, which means invoiced, shipped to, priced, or reported on in its own right. Everything else is a field. Size, colour, department, language, the site and the phrase “the Toronto one” are fields on the record you already have. Two sites of one company billed separately are two records; two sites on one invoice are one record with two delivery addresses. Applied from day one, this is the rule that holds a list down, and it prevents at the keyboard the duplicates a deduplication tool can only find after they exist.

The create request, and the permission that makes it real

Ownership becomes operational at one point: the moment a record is created. The procedure is small enough to put on one screen.

• The request: who is asking, why, the minimum field set for that list, and the transaction it is blocking. The last one sets the priority and proves the request was real.
• The duplicate search is done by the owner, not the requester. Requesters search for the name they have in mind. Owners search for the shapes a duplicate actually takes.
• Three possible decisions: approve, decline, or merge into an existing record. The third keeps the list small, and it is the decision an unowned list never makes.
• A stated turnaround: same business day. Not a target. A commitment the owner is held to.

And the companion step without which none of it holds: create permission is removed from everyone else in the system on the day the form goes live. A form that can be bypassed is a suggestion, and a suggestion loses to somebody who needs to raise a quote before lunch. If your system cannot restrict creation on that object, that is a real constraint and it belongs in the evaluation: ask the vendor to show it in a scripted demo on your own data and grade the answer Native, Configured or Promised.

The two-minute audit

Before any design work, get the diagnosis. Export the list, sort it alphabetically, and read down it counting the five shapes a duplicate takes.

Both at once is common, and the order still matters: enforcement first, because a standard applied to a list people are routing around only produces tidy duplicates.

Retire before you deduplicate

The published cleanup order is standardise, deduplicate, validate, enrich: the same four verbs in the same order on page after page. It is backwards, and it costs money on a migration, because it spends effort reconciling records that should have been switched off first. Retirement comes before deduplication.

The two-period test is a starting rule: use two of whatever period the business cycles on, and lengthen it for a list with long natural gaps, such as annual service clients. What matters is that it is written down and applied to every row, rather than argued case by case with the person who remembers each one. The loading order for the survivors, and the reconciliations that have to tie, are in the data migration checklist. On the chart of accounts, retirement has a harder edge, because some chart changes are free, some are forward-only and some are never reversible.

The retirement procedure and its reason codes

Lists do not decay only because bad records arrive. They decay because nothing ever leaves. Create, standardise, merge and enrich are covered everywhere; deactivation is covered almost nowhere, and it is the half that keeps the list ownable.

Never delete. Always deactivate, with a date and a reason drawn from a closed list. Deleting destroys the history the record's past transactions depend on, and an open text box for the reason produces a field nobody can group on. Six to eight codes is enough: no longer trading, acquired by another account, moved to another entity of ours, lost to a competitor, duplicate merged, dormant with no transaction, created in error.

Two things follow from having them. Somebody can answer, a year later, why this record stopped. And next year's retirement pass is a review of a readable trail rather than a reconstruction from a column of blanks, which is the difference between a pass that gets done annually and one that gets postponed.

Survivorship, written before the first merge

Survivorship rules are documented by the tool vendors, as tool configuration. A business merging two customers by hand in its accounting system faces the same decision and finds nothing written for it. The decision is which field wins and what happens to the losing identifier, and it belongs on paper before the first merge, not negotiated during the fortieth.

• Most recent wins for addresses, contacts and anything that describes the present.
• Source of origin wins for legal name and tax ID, meaning the value taken from the registration document rather than the value somebody typed later.
• Most complete wins for everything else, with the owner breaking ties.
• The losing record's identifier is retained as an alias, permanently, so historic quotes, invoices and delivery notes still resolve to a record. A merge that discards the old code quietly breaks every document already in a customer's possession.

Write those four lines once and merging becomes reviewable. Without them you get merges nobody can explain and nobody can reverse, which is worse than the duplicates were.

The shadow spreadsheet is evidence about the owner

A parallel list in a spreadsheet is read as indiscipline. Read it as instrumentation. People route around the master list when the create path is slower than the work waiting on it, and when they do they are making a correct local decision.

So the diagnostic is a comparison, not a reprimand: how long does the official create path take, from request to usable record, against how long the person could reasonably wait? If the gate takes two days and the quote is due this afternoon, the spreadsheet will exist however often the policy is restated. The service level on a create request is the real governance control. State it out loud, measure it, and publish the measurement to the people you are asking to stop keeping their own list. A shadow list is evidence about the owner's turnaround, not the team's discipline, which is the same distinction as telling a process problem from a software problem.

Where the master lives

“Single source of truth” is asserted on every page about this and specified on none of them. Nobody says which system, on what rule. Here are the four arrangements that exist in practice, and what each costs.

The rule that resolves it: the master is the system where the record first has money attached to it. For customers that is the system raising the quote or the invoice; for items, the one holding cost and price. A prospect with no money attached need not be in the master at all, which is what makes ERP-as-master workable rather than obstructive: the CRM keeps prospects, and the create request fires once, at the first quote. Weighing one system against two is the same argument from the software side, covered in the middle path vendors omit.

Handover, and what ownership costs

One way a list becomes unowned is neglect. The one nobody plans for is a promotion. Ownership is written against a person's name, that person changes job, and nobody notices the customer list has no owner until the duplicates reappear a year later.

Two fixes, both clerical. Write ownership against a job title, never a person, so the one-page “what this role owns” list moves with the role. And put “reassign the master lists you own” on the offboarding and role-change checklist, next to the laptop and the keys.

Then the part usually dodged. At this size the owner has a full-time job already, and ownership is real work: create requests, duplicate searches, the annual retirement pass. Nobody has measured what that costs for your lists, so treat it as a commitment to negotiate rather than a number to look up, and agree a named slice of the week with that person's manager, out loud. Expect one owner to hold several lists, because most businesses do not have six people for six lists. That only works if the lists were retired down first, which is the second reason retirement comes before everything else.

None of this is a programme. The deliverable is one page: six lists, six job titles, six standards, six create paths. The council, forum, charter and five maturity levels imported from large enterprises are why master data governance has a reputation for producing documents instead of clean lists. Here it is a permission and a turnaround, not a forum.

§

The numbers this page refuses

Writing on this subject comes with a standard set of figures: the annual cost of poor data quality to the average company, the yearly rate at which a master list is said to decay, the cost of one bad record at three stages of its life, the share of records in a typical system that are duplicates. Not one of them appears above, and the omission is deliberate rather than an oversight. We have not measured any of them, and a borrowed figure gets a sound argument discredited by the first reader who tries to trace it.

More useful than reprinting them or debunking them one by one: four questions to put to any figure you are handed on this subject, including by a consultant.

• Who was measured, and who selected them? A survey of a vendor's reference customers, or a scan of the companies that bought a cleanup tool, samples the population most likely to have the problem the figure describes.
• Was it measured, or estimated by the respondent? Cost-of-bad-data figures are usually people estimating their own losses from memory. That is an opinion poll about a cost, not a measurement of one.
• Is there a published method? A stated population, period and definition of the thing counted. Without them the figure cannot be checked, however many times it has been reprinted with a source attached.
• Is it a finding or a mnemonic? Some of the best-known numbers here have tidy round ratios, which is the signature of a teaching device rather than of a measurement.

A figure that fails all four is decoration, and the decoration reliably argues for spending. The mechanism needs no number at all. A list with no gate accumulates records faster than it loses them, because creating one serves somebody's immediate need and removing one is nobody's job. That justifies the work on this page, and unlike any of the figures it is something you can verify on your own list this afternoon. The one rate worth knowing is the one your own retirement pass produces. The same discipline applies to failure rates, which is why the failure guide traces four real outcomes to the gate where each was decided rather than quoting a percentage.