Master Data Management business case papers are turned down more often than almost any other data investment, and rarely because anybody doubts the problem. Everyone already knows the customer list disagrees with itself, that three systems hold three different addresses for the same account, and that finance closes the month with a spreadsheet nobody else can rebuild. The paper still fails, because it prices a platform, forgets the stewards who will run it forever, and never says where the recovered hours actually went.
This guide gives you the working rather than the argument. It sets out the costed investment schedule a reviewer expects, the five benefit streams that carry almost every case, the payback and net present value maths finance asks for, a fully worked three-year model for a 400-person company, the benchmarks worth quoting, and the specific errors reviewers use to reject a funding request. It sits alongside our data management and analytics and data warehousing practice.
It is written for mid-sized companies specifically, because the arithmetic that works at 20,000 staff does not survive at 400. Master data management is the discipline of holding one governed, authoritative version of the entities a business runs on — customers, suppliers, products, sites and people — and feeding that version back to every system that needs it. If you have not yet measured the condition of your records, our data governance framework guide is the right starting point, because a return calculation without a measured baseline is just an opinion with decimal places attached.
Table of contents
- What a Master Data Management business case must prove
- Build the Master Data Management business case cost baseline
- The five benefit streams in a Master Data Management business case
- The Master Data Management business case formula
- A worked Master Data Management business case for a 400-person company
- Choosing the MDM style your Master Data Management business case funds
- Benchmarks worth quoting in a Master Data Management business case
- Sensitivity testing the Master Data Management business case
- Master Data Management business case mistakes that get a paper rejected
- Phasing a Master Data Management business case for early benefits
- Reporting the Master Data Management business case after approval
- Frequently asked questions about the Master Data Management business case
- References
What a Master Data Management business case must prove
A Master Data Management business case makes four claims, in order, and a reviewer tests each one separately. That the current way of working costs real money. That governed master data removes a named portion of that cost. That the released capacity and recovered cash have somewhere specific to go. And that the number survives when the central assumption is halved.
It is a finance paper, not a data architecture paper
The audience is a finance director and an executive sponsor, not a data architect. Every technical claim needs a monetary translation and an evidence source. Anything that cannot be translated belongs in an appendix rather than in the headline ratio, and a diagram of the match-and-merge pipeline belongs nowhere near page one.
The four questions every reviewer asks
What would have happened anyway without this spend? Which system stops being the source of truth, and who agreed to that? Where does the released capacity go, and who signed up to receive it? What happens if the central assumption is half as good as claimed? A Master Data Management business case that answers all four in advance is approved far more often than one with a larger headline percentage.
Why “data quality” is not a benefit
A completeness score is a leading indicator, not a line in a budget. Nobody banks a percentage. The benefit is what the corrected records produce: invoices that are not credited, deliveries that arrive first time, campaigns that are not sent twice, a month-end that closes without a reconciliation spreadsheet. A case that stops at quality dashboards asks the finance function to finish the argument for you, and it usually declines.
What a credible case contains
Six artefacts: a costed baseline of the effort currently spent reconciling records, an itemised investment schedule that includes the standing stewardship team, five quantified benefit streams with named owners, a three-year cash flow, payback and net present value figures, and a sensitivity table. Anything less is a preference dressed as a proposal.
Build the Master Data Management business case cost baseline
Start a Master Data Management business case with cost, not benefit. It is the half most teams understate, and an understated denominator collapses the moment a reviewer adds the missing lines back in. Mid-sized companies get this wrong in a particular way: they price the hub and forget the humans who feed it.
The stewardship team is the cost that never ends
A master data hub is a product, and products have standing costs. Somebody arbitrates when two systems disagree, approves new records, tunes the matching rules, and answers the queue. A data owner lead, two stewards and an integration engineer cost roughly three times the platform licence, and leaving them out of years two and three is the single most common structural error reviewers look for.
Platform, licences and hosting
Count the hub itself, the matching and data quality engine, the integration middleware, the reference data subscriptions and the environments the platform consumes. Price year two at the contracted uplift rather than the introductory discount, because launch pricing is exactly why a model looks better in the deck than in the ledger eighteen months later.
Data remediation is the line everyone halves
Deduplicating 340,000 customer records is not a weekend of scripting. Somebody defines survivorship rules, reviews the ambiguous matches a machine will not decide, chases owners for missing tax numbers, and re-keys what cannot be salvaged. Price those hours at the same rate you use on the benefit side, or your Master Data Management business case values an hour spent differently from an hour saved.
Source system integration and dual running
Every system that publishes or subscribes needs a feed, a mapping and a reconciliation report. Worse, the old local record stays authoritative until the last consumer moves, so you fund both for a year. That overlap is real money and it belongs in the denominator of the Master Data Management business case rather than in a footnote nobody reads. Our data migration checklist covers the cutover mechanics this line pays for.
| Cost line | What it must include | Year 1 | Year 2 | Where the figure comes from |
|---|---|---|---|---|
| Stewardship team | 1 data owner lead, 2 stewards, 1 integration engineer, fully loaded | £320,000 | £330,000 | HR cost-per-head, not base salary |
| Platform and licences | Hub, matching engine, middleware, reference data, environments | £96,000 | £104,000 | Contract schedule at renewal pricing |
| Data remediation | Survivorship rules, manual match review, gap chasing, re-keying | £145,000 | £48,000 | 2,600 then 860 hours at the blended rate |
| Integration and dual running | Publish and subscribe feeds, mappings, reconciliation reports | £132,000 | £44,000 | Per-system estimate, 11 systems in scope |
| Training and change | Steward training, process rewrites, comms, floor-walking | £38,000 | £16,000 | Hours at the same rate used for benefits |
| External implementation partner | Reference model, matching design, assurance review | £85,000 | £0 | Statement of work, plus contingency |
| Total investment | All of the above, one scope, one window | £816,000 | £542,000 | The denominator of the ratio |
The five benefit streams in a Master Data Management business case
Almost every credible case draws from the same five streams. Naming them separately matters, because each has a different owner, a different evidence source and a very different realisation risk. Blending them into one “efficiency” number is how a paper gets sent back for rework.
Manual reconciliation and duplicate resolution
Hours that finance, sales operations and customer service stop losing to comparing two records, merging them by hand and explaining the difference to a customer. This is the largest effort stream and the most contested, because released time only becomes money when somebody shows what it produced instead. Treat it as the stream needing the most evidence, not the least.
Revenue leakage and credit notes recovered
Wrong ship-to addresses, wrong price lists attached to duplicate customer records, and products invoiced under a retired code all generate credit notes, and a share of those are never re-billed. This stream is invoice-visible, which makes it the number a finance director trusts fastest, and in most mid-sized Master Data Management business case models it is the largest single line.
Supplier consolidation and procurement leverage
The same supplier appearing four times under four spellings means four contracts, four payment terms and no volume position. Deduplicating the supplier domain hands procurement a spend picture it can negotiate against. The saving is modest as a percentage and large in absolute terms, because it applies to spend under management rather than to headcount.
Reporting, analytics and AI readiness
Analysts stop rebuilding the same customer mapping for every report, and models stop training on entities that are three people wearing one identifier. Count the analyst population separately from the operational one or you will book the same hour twice. Our guide to preparing business data for AI covers why this stream is now the one executives ask about first.
Marketing waste, compliance and audit effort
Duplicate contacts inflate campaign and print costs, dead addresses inflate them again, and two overlapping data quality tools can usually become one. Alongside that, subject access requests, retention decisions and audit evidence all get faster when there is one governed record to point at. Quantify the effort reliably and the risk reduction conservatively.
| Benefit stream | What you measure | How it converts to money | Evidence source | Realisation risk |
|---|---|---|---|---|
| Reconciliation and duplicates | Hours per person per week spent matching records by hand | Hours × blended rate × realisation factor | Time study plus service desk tickets | High — needs a named destination |
| Revenue leakage | Credit notes and write-offs caused by master data errors | Direct reduction in credits raised | Credit note reason codes in the ledger | Low — appears in the accounts |
| Supplier consolidation | Fragmented spend across duplicate supplier records | Percentage recovered on consolidated spend | Accounts payable and contract register | Medium — needs procurement to act |
| Reporting and analytics | Analyst hours spent reconciling before reporting | Hours × rate × realisation factor | Project timesheets and report inventory | Medium — separate population required |
| Marketing, compliance, audit | Duplicate contacts, tool overlap, audit and request effort | Direct spend removed, plus days × rate | Campaign invoices and licence register | Low — largely contractual |
The Master Data Management business case formula
The arithmetic is deliberately simple. All of the judgement sits in what you allow into each side of it, which is why reviewers spend their time on your assumptions rather than on your spreadsheet.
The core calculation
Return equals net benefit divided by total investment, expressed as a percentage over a stated period. Net benefit is total benefit minus total investment. A Master Data Management business case costing £1,838,000 across three years and returning £2,367,000 produces a net of £529,000 and a return of 29%. Always state the window in the same breath as the percentage, because a 29% three-year return and a 29% annual return are entirely different propositions.
Choosing the measurement window
Two years is the conventional default and, for master data work, it is almost always the wrong one. Coverage ramps slowly because each domain has to be agreed before it can be governed, so a two-year window pays the full team cost while collecting partial benefit. Three years is the honest ask. Say so in the paper rather than letting a reviewer discover it.
Pricing an hour without double counting
Use the cost per head finance already recognises: salary, employer national insurance, pension, benefits, equipment and an allocated share of overhead. A UK mid-market operations role commonly lands near £72,600 against a £54,000 base, which is £44 an hour over roughly 1,650 productive hours. Analysts and engineers are costed separately at £92,400, or £56 an hour, and the two populations never overlap in the model.
Applying a realisation factor
Removing 12,276 hours of reconciliation a year is not the same as banking £540,144. Some released time enters the roadmap, some absorbs into slack, and some funds the stewardship work itself. Sixty per cent is a defensible default for effort streams, and it is applied to nothing else — invoice-visible savings are already real. A visible haircut survives questioning precisely because it is not hidden inside an optimistic assumption.
A worked Master Data Management business case for a 400-person company
Abstract formulas do not get funded. What follows is a complete Master Data Management business case for a fictional but deliberately ordinary company, with every figure traceable to the tables above. Change the inputs to match your own position and the structure still holds.
The company and the starting position
A 400-person UK distributor turning over £180m, running one ERP, one CRM, a warehouse system, an e-commerce platform and seven smaller applications. It holds 340,000 customer contact records with an estimated 19% duplication rate, 8,400 supplier records, and 62 people across finance, sales operations and customer service who each lose about 4.5 hours a week to reconciling records by hand.
The investment side
From the schedule above, £816,000 in year one and £542,000 in year two. Year three drops to £480,000 because remediation and integration are finished and only the platform, the stewardship team and modest ongoing rule tuning remain. Three-year total investment is £1,838,000, and the standing run cost from year three onward is the figure the board will actually live with.
The benefit side
Coverage is the pacing item: 30% of master records governed by the end of year one, 75% by the end of year two, and effectively complete in year three. Benefit realised follows that curve — £350,000, then £878,000, then £1,139,000. The full-coverage run rate of £1,139,000 a year is the number that matters after the programme ends, and it comfortably exceeds the £480,000 standing cost.
Payback, net present value and the headline number
Cumulative position is negative £466,000 at the end of year one, still negative £130,000 at the end of year two, and positive £529,000 at the end of year three. Payback lands in month 27. Discounted at 8%, the three-year net present value is £380,000. Present all four numbers together, because a Master Data Management business case that quotes only the return invites the question it cannot answer in the room.
| Cash flow line | Year 1 | Year 2 | Year 3 | Three-year total |
|---|---|---|---|---|
| Master records governed | 30% | 75% | 100% | Coverage paces everything |
| Investment | £816,000 | £542,000 | £480,000 | £1,838,000 |
| Benefit realised | £350,000 | £878,000 | £1,139,000 | £2,367,000 |
| Net position in year | −£466,000 | £336,000 | £659,000 | £529,000 |
| Cumulative position | −£466,000 | −£130,000 | £529,000 | Payback in month 27 |
| Return and NPV | — | — | — | 29% return, £380,000 NPV at 8% |
Choosing the MDM style your Master Data Management business case funds
The four implementation styles are not interchangeable, and they carry very different cost and benefit profiles. A Master Data Management business case that does not name its style is asking for a blank cheque, because a reviewer cannot tell whether they are funding a matching service or a rewrite of how the business creates records.
Registry: match and link, change nothing
The hub stores identifiers and matches, and source systems keep authoring their own records. It is the cheapest and fastest style, it produces a trustworthy joined view for reporting within a quarter, and it fixes nothing at source. Choose it when the pain is analytical rather than operational, or when you need an early number to defend the rest of the programme.
Consolidation: one golden record for reporting only
The hub builds a merged record downstream of everything, which the warehouse and the analytics layer consume. It delivers the reporting and analytics stream in full and the operational streams barely at all. Our comparison of a data warehouse, data lake and lakehouse explains where the consolidated record should actually live.
Centralised: author master data in the hub
Records are created and maintained in the hub and published outward, which is the only style that removes duplicates at the moment of creation. It carries the largest benefit and by far the largest change cost, because every process that creates a customer or a product has to be rewritten and every affected team retrained.
Coexistence: govern centrally, keep local authoring
Systems continue to author, the hub arbitrates and publishes the governed version back. It captures most of the operational benefit without a full process rewrite, which is why the majority of mid-sized programmes land here. It also has the most demanding integration bill, so a Master Data Management business case built on coexistence must not skimp on the feed count.
| Style | Where records are authored | Relative year-1 cost | Time to first benefit | Share of benefit reachable | Main risk |
|---|---|---|---|---|---|
| Registry | Source systems only | Low | 1 to 2 quarters | About 25% | Nothing is fixed at source |
| Consolidation | Source systems, merged downstream | Low to medium | 2 to 3 quarters | About 40% | Operations see no change |
| Coexistence | Source systems, arbitrated centrally | High | 3 to 5 quarters | About 85% | Integration count is underestimated |
| Centralised | The hub | Highest | 5 to 8 quarters | About 100% | Process rewrite stalls adoption |
Benchmarks worth quoting in a Master Data Management business case
Reviewers discount figures that arrive without provenance. These are the benchmarks worth putting in an appendix, each with a note saying whether it came from your own systems or from published research, because a Master Data Management business case built entirely on industry averages is a template rather than a proposal.
Duplicate rates by domain
Customer and contact data duplicates worst because it is created by the most people under the least control. Supplier data follows, product data is usually better because a catalogue imposes discipline, and employee data is normally cleanest because payroll enforces uniqueness. Measure your own rates with a sample of 2,000 records before quoting anyone else’s.
Time to first governed domain
Six to nine months from funding to the first fully governed domain is a realistic mid-market figure for a coexistence build, and three to four months for a registry. Anything faster in the plan is usually a domain that nobody disputed, which is worth saying out loud rather than presenting as pace.
Team size against company size
Below roughly 250 staff, part-time stewardship attached to existing roles is the honest answer. Between 250 and 1,000, three to four dedicated people is the usual shape. Above that, stewardship distributes into the business functions and the central team shrinks to arbitration and tooling.
Sensitivity testing the Master Data Management business case
A single-scenario paper reads as advocacy. Publishing the downside yourself converts the meeting from an interrogation into a decision, and it is the cheapest credibility you will ever buy. Test three variables, because those are the three a reviewer will reach for anyway.
Halve the largest stream
Revenue leakage carries a third of the benefit, so halving it is the first test. The three-year net falls from £529,000 to £142,000, the return from 29% to 8%, and payback moves from month 27 to month 33. The case still stands, which is the point of running the test in public.
Move the realisation factor
Drop the effort realisation factor from 60% to 40% and the three-year net becomes £217,000 at a 12% return, with payback in month 31. Reviewers respect this test more than any other, because it directly answers the objection that saved hours are not saved money.
Slip the coverage ramp
This is the variable that actually breaks a Master Data Management business case. Push the ramp back twelve months and the three-year position turns negative at £344,000 with no payback inside the window. Coverage, not technology, is what determines whether the paper was right, and that is worth saying explicitly on the page.
| Scenario | Three-year net | Three-year return | Payback | What it tells the reviewer |
|---|---|---|---|---|
| Base case | £529,000 | 29% | Month 27 | The proposal as submitted |
| Revenue leakage stream halved | £142,000 | 8% | Month 33 | Survives the biggest single doubt |
| Realisation factor 60% to 40% | £217,000 | 12% | Month 31 | Saved hours are not the whole case |
| Platform and licence cost +30% | £436,000 | 23% | Month 29 | Tooling price is not the risk |
| Coverage ramp slips 12 months | −£344,000 | −18% | Beyond month 42 | Adoption pace is the real risk |
Master Data Management business case mistakes that get a paper rejected
Rejections cluster around four errors, and all four are visible in the draft before it is ever submitted. Reading your own paper looking for them is the cheapest review round you will ever run.
Counting the platform and not the stewards
The hub licence is not the largest line in the schedule and should never lead. A case that opens on tooling cost tells a reviewer immediately that nobody has thought about who arbitrates a disputed record in year three, and the question that follows is one you cannot answer in the meeting.
Claiming the same hour twice
The most common arithmetic failure in a Master Data Management business case is counting an analyst’s reconciliation hour in the effort stream and again in the reporting stream. Name the populations, state their headcounts, and show that they do not overlap. A reviewer who finds one double count stops trusting every other figure on the page.
Baselining against the worst month
Choosing the month with the failed migration, the audit and the pricing error inflates the benefit and invites a reviewer to ask what a normal period looked like. Use a rolling twelve months. It is lower, it is defensible, and it survives the second meeting intact.
Selling a hub instead of an outcome
Executives do not fund golden records, survivorship rules or match scores. They fund fewer credit notes, faster month-end close, a supplier list procurement can negotiate against, and analytics nobody has to caveat. Lead the Master Data Management business case with the outcome and keep the architecture where it belongs, which is in the appendix.
Phasing a Master Data Management business case for early benefits
Sequencing decides the payback month, and the payback month decides the approval. Two Master Data Management business case papers with identical totals can land two quarters apart on cumulative position purely because of the order in which domains were tackled.
Start with the domain that touches cash
Customer or supplier, whichever generates more credit notes and disputed invoices in your ledger. Product data is intellectually tidier and pays later. Starting where the money leaks gives you an auditable number at the first review, which buys patience for the slower domains behind it.
Take the invoice-visible savings first
Duplicate contact suppression, dead address removal and retiring an overlapping data quality tool are all contractual, all fast, and all appear on a bill rather than in a survey. Putting them early gives a Master Data Management business case a hard number at the three-month mark that nobody argues with.
Match and link before you rewrite
Get the matching service running and publishing identifiers before you change how anyone creates a record. Process change competes with the day job and stalls; a matching service does not. Our Power BI implementation guide covers how to surface the linked view while the operational work continues.
Leave the hardest domain until coverage pays
There is always one domain — usually product variants or legacy contracts — that will consume a quarter of the remediation budget for a twentieth of the benefit. Schedule it last, or exclude it explicitly and say why. Reviewers respect a named exclusion far more than an optimistic total that quietly assumes everything gets cleaned.
Reporting the Master Data Management business case after approval
Approval starts the measurement obligation, it does not end it. The teams that get funded again are the ones that reported honestly on the last thing they were funded for, including the parts that underperformed.
Set the measurement contract before approval
Agree in advance which five measures will be reported, from which systems, at what frequency and to whom. Retro-fitting measurement to a Master Data Management business case six months in produces numbers nobody trusts, and the argument about methodology consumes the meeting you needed for the decision.
The monthly pack
One page: records under governance against plan, duplicate rate by domain, credit notes raised for master data reasons, supplier count against contracts, and benefit actual against forecast by stream. Pull it from the ledger and the hub directly, which our data analytics practice can automate in a fortnight.
Quarterly re-forecasting
Re-forecast every quarter against the same model structure. Change the inputs, never the method, or the comparison stops meaning anything. If a stream underperforms by more than 20% for two quarters running, revise it down publicly — credibility built by an honest downgrade pays for itself at the next funding round.
When to stop reporting
Stop programme-level reporting once master data is business as usual and its measures have moved into normal service reporting, typically after eleven or twelve quarters. Continuing past that turns a decision tool into administrative overhead, and the operational metrics survive perfectly well on their own merit.
Frequently asked questions about the Master Data Management business case
How big does a company need to be before MDM pays?
Around 250 staff, or roughly £60m turnover, is the practical floor for a dedicated build. Below that the fixed cost of stewardship and a hub licence overwhelms the benefit, and the better answer is disciplined data quality tooling with part-time ownership, reviewed again in a year.
How long before the investment turns positive?
Expect the cumulative position to cross zero between month 24 and month 36. Year one is always negative, because remediation and integration land before coverage does. Any model showing a positive first year deserves a careful look at whether the stewardship team was costed for twelve months rather than from the month they were hired.
Can we build the case without historical data?
Mostly. Credit note reason codes, accounts payable records and a duplicate scan across a 2,000-record sample will give you three of the five streams within a fortnight, even with no prior reporting. The reconciliation baseline needs a two-week time study, so if that is genuinely unavailable, build the Master Data Management business case on the other streams and note the omission.
Should we count data quality scores as a benefit?
Report them, never bank them. Completeness and duplicate rates are how you prove the mechanism is working, not what it is worth. The exception is a regulatory commitment with a defined penalty attached, where a measured improvement against a stated threshold is a legitimate and separately evidenced line.
What if we are already running a data warehouse?
Then part of the reporting benefit is already booked, and claiming it again will be spotted. Rebase the analyst measurement on the position after the warehouse, and the Master Data Management business case narrows to the operational streams: records fixed at source, credit notes avoided and suppliers consolidated. Our cloud migration business case guide shows the same rebasing logic applied to infrastructure.
References
Gartner Glossary: Master Data Management
DAMA International: Data Management Body of Knowledge
ISO 8000-61: Data Quality Management Process Reference Model
GOV.UK: The Government Data Quality Framework
Microsoft: Master Data Services Overview
Microsoft Purview Documentation
EDM Council: Data Management Capability Assessment Model
Informatica: What Is Master Data Management
