Nobody decides to use Excel for master data management. It just happens. Someone needs a list of valid cost center codes. There is no system set up for it yet. Excel is already open. So they make a spreadsheet, put it in a shared folder, and send the link around. That is the whole decision — thirty seconds, no meetings, no approval needed.
For a while, this works fine. The point of this post is not to make you feel bad about how you got here. The point is to help you recognize when you have outgrown it — because the transition from "this is fine" to "we have a real problem" tends to be gradual and then sudden.
How it starts — and why it makes sense
Excel is the most widely deployed data tool in the world. Everyone already has it. There is no budget to request, no procurement process, no vendor contract, no IT ticket. For a small, stable dataset with a single owner and no downstream consumers, a spreadsheet is genuinely a reasonable choice. A lookup table that one analyst maintains for one report, that never changes, that nobody else touches — that is fine. Keep using Excel.
The problems start accumulating quietly. The list of valid product categories gets emailed to three people. Someone adds a tab for country codes. Another person creates a separate file for legal entity codes because they needed a slightly different structure. One of the files ends up on SharePoint. One stays in a personal OneDrive. Now you have four files, five owners, and the first seeds of a reference data problem.
The signs Excel is no longer enough
These are not hypothetical failure modes. They are things that happen, at real organizations, more or less exactly as described.
Version drift
Two people maintain what they believe is the same spreadsheet. At some point there was a merge, but it was never quite complete — someone had made changes in the interim. Now there are two versions with different values for the same codes. Neither person knows. You find out which one was current when something downstream breaks on a Friday afternoon.
No history
Someone needs to know what a field value was three months ago. The cost center was reclassified. What was the old region assignment? The answer is gone. A cell was overwritten. There is no version history in Excel — at least not the kind that lets you audit individual field changes across thousands of rows. SharePoint versioning gives you snapshots of the whole file, not a row-level changelog.
Downstream brittle fragility
An ETL job reads the spreadsheet every morning. It expects column C to contain a field called "Region" in a specific text format. Someone renames it to "Region Code" and reformats the values from "EMEA" to "EU-ME-AF" because the new standard says so. The ETL job silently loads nulls for three days before anyone notices. The Power BI dashboard has been showing nothing for a week. Nobody connected the two events.
No governance
Anyone with access can change anything. There is no approval workflow. No change request. No review step. A cost center code gets a typo introduced — one digit transposed. It replicates into the ERP through the nightly load. It takes two weeks to surface, because nobody looks closely at master data unless something explodes. Then the audit trail question comes: who changed this, and when? The answer is that nobody knows.
The DBA who owns eleven spreadsheets
A SQL Server DBA gets assigned to "maintain the reference data." This sounds reasonable. They end up as the de facto owner of a collection of spreadsheets they did not write, do not fully understand, and cannot easily validate. They know the data is wrong in places. They have no good way to fix it systematically, and no authority to impose a better process. So they maintain the spreadsheets. This is not a good use of a DBA.
Onboarding new team members
A new analyst joins. They need to understand what the valid values are for a field. The answer is: here is a spreadsheet, the relevant tab is probably the third one, but check with Sarah because she modified it last quarter and the tab labels are a bit inconsistent. Sarah is on leave. The analyst makes a reasonable guess. It is wrong. Three reports now have a data quality issue that will take a week to trace.
Excel is a personal productivity tool
This is the root issue. Excel was designed for individual analysis — building models, crunching numbers, producing charts. It was not designed for concurrent editing, row-level access control, audit trails, schema enforcement, or integration with downstream systems. Using it for master data management means engineering around its limitations indefinitely. Every workaround you add is technical debt on a foundation that was never built for this.
What it actually costs you
The costs of spreadsheet-based master data management are real, but they are distributed and easy to dismiss individually. They only become visible when you add them up.
DBA time. If a technical person is maintaining reference data spreadsheets, that time is being spent on something they are overqualified for and that does not require their expertise. That is opportunity cost — work that is not getting done because someone is checking whether "APAC" and "Asia Pacific" should be reconciled in column G.
Report inconsistencies. A lookup table gets updated but the downstream ETL does not pick it up immediately. Two reports now show different numbers for the same metric. It takes hours — sometimes days — to trace the discrepancy back to a stale reference file. The investigation cost is invisible because it appears on the budget as analyst time, not as a data quality failure.
The single spreadsheet keeper. One person understands a particular reference file deeply — they know why certain codes are grouped the way they are, what the exceptions mean, which values are deprecated versus active. When that person leaves, the file becomes increasingly unmaintainable. The knowledge is gone. Anyone who touches it afterward is guessing.
Audit and compliance exposure. In regulated industries — financial services, healthcare, pharmaceuticals, any sector with reporting obligations — "the data was in a spreadsheet on SharePoint" is not a satisfying answer to an auditor. If you cannot demonstrate who changed a value, when, why, and who approved it, you have a compliance gap. Spreadsheets do not close that gap. They are the gap.
What reference data management looks like in a proper tool
The contrast with a purpose-built MDM tool is not about complexity — it is about having the right structures in place so the failure modes above simply do not occur.
A structured data model means your entities — cost centers, product categories, country codes, legal entities — are defined with typed attributes and validated domain references. You cannot accidentally put free text in a field that should be a code. You cannot reference a value that does not exist. The structure enforces what the spreadsheet only suggested.
Version history on every record means you know exactly who changed a value, when they changed it, and what it was before. This is not a file-level snapshot — it is a row-level, field-level audit trail. When the auditor asks what the region assignment was on a specific cost center in Q3, the answer is a query, not a search through SharePoint revision history.
Approval workflows mean changes go through review before they are applied. A data steward proposes a change. It goes into a changeset. A reviewer approves or rejects it. Nothing lands in production without going through that gate. The approval is recorded. The process is auditable.
Integration views mean downstream systems — ERPs, BI platforms, ETL pipelines — read from SQL views with stable, consistent schemas. The format does not change when someone rearranges columns. The view contract is explicit. If something changes upstream, the view is updated deliberately, not accidentally.
Staging tables give ETL pipelines a validated loading path. Data comes in through staging, gets validated against the entity schema, and only moves to production once it passes. Bad rows are rejected with a clear error message, not silently loaded as nulls.
Access control at the entity level means you can give a data steward write access to cost centers and read-only access to legal entities — without managing file-sharing permissions or hoping the SharePoint folder structure holds. Permissions follow the data model, not the file system.
One more thing worth saying plainly: the grid editing experience in Primentra works like a spreadsheet. Arrow keys, tab to advance, paste from Excel, multi-row edits. Data stewards who have never touched a database tool get productive immediately. The difference is that the data lives in SQL Server, not in a file. The familiarity is preserved. The fragility is not.
When Excel is actually fine
There are situations where a spreadsheet is genuinely the right answer. Being honest about this matters — the goal is not to replace Excel everywhere, it is to use the right tool for the scope of the problem.
A very small dataset with a single owner that almost never changes and has no downstream consumers — use Excel. A personal lookup table that one analyst maintains for one report they own entirely — use Excel. Prototyping: you are figuring out what the data structure should look like before implementing it properly. Excel is fine for that. Sketch it out, get the column structure right, understand the domain values, then move it.
The moment any of these conditions changes — more than one owner, downstream systems depending on it, a compliance requirement to track changes, a team that needs to understand what the valid values are — the spreadsheet has outgrown its role. It is not that Excel gets worse. It is that the problem has grown beyond what Excel was designed to handle.
Questions to ask before you decide
If you are trying to work out whether your current setup has become a problem, these are the questions worth answering honestly.
Questions to ask
There is no magic threshold — no row count or system count that automatically means you need MDM. But if you answered "yes" to three or more of the items above, the spreadsheet is probably costing you more than you realize. The failure modes described in this post are not edge cases. They are the normal trajectory. If you are evaluating what comes next, our comparison of MDM alternatives covers the main options with pricing.
If your reference data has outgrown Excel, Primentra runs on your existing SQL Server and keeps the spreadsheet-style editing your team already knows. The 60-day trial requires no credit card. Try it free →
- Grid editing that works like a spreadsheet — no retraining required
- Full version history and approval workflows — on your own SQL Server
- No credit card required for the trial