Excel can't give master data a real audit trail. Its change-tracking features — Track Changes, the newer Show Changes, and file version history — are opt-in, incomplete, and stored in the same file the people being audited can edit or delete. None of them records, permanently and per field, who changed a value, when, and what it was before. For master data, that is the one question that matters, and it is the one Excel can't answer.
Here is the situation that makes it concrete. A payment goes out to the wrong account. Finance pulls up the supplier spreadsheet everyone edits, and the IBAN for one vendor is different from what it was last month. Someone changed it. Now answer three questions: who, when, and what was the old value. In Excel, you usually can't answer any of them.
The one question a spreadsheet can't answer
The file's properties will tell you it was last modified by someone, at some time. That is the last person who saved anything in the workbook — not the person who touched that specific cell, and not the moment they touched it. If ten people have edit access and the file gets saved twenty times a day, “last modified by” is noise.
This is the kind of change where the answer matters. A supplier's bank details, a customer's credit limit, a product's hazard classification, a GL account's status — these are exactly the fields a fraud investigation, an auditor, or a regulator will ask about. And a spreadsheet has no answer that would survive either of them.
What Excel offers — and why each option falls short
Excel isn't nothing here. It has four different ways to track changes. The problem is that all four were built for the wrong job — catching edits in a document, not maintaining a governed record of who owns which value.
Why this is worse for master data than for a budget model
A spreadsheet you use for a one-off forecast can lose its edit history and nobody cares. Master data is different in four specific ways, and each one turns a weak audit trail into a real liability.
The auditor and the audited are the same people. Master data is edited by the same stewards who would need to be held to account. When the log lives in a file they can open and change, it isn't evidence — it's a suggestion.
Deleting a row deletes its history. Remove a discontinued product or an offboarded vendor, and whatever change record was attached to that row is gone. The moment you most want the history — after the record is removed — is the moment Excel throws it away.
There is no concept of approval. A real audit trail records not just who changed a value but who signed off on it. Excel has no idea what an approval is, so the trail stops at the edit and never reaches accountability.
“The file says so” is not a control. GDPR, SOX, and standard supplier-onboarding controls expect an immutable record of change. A spreadsheet that any editor can rewrite is the opposite of immutable. This is one of the quieter costs of managing master data badly — you don't feel it until the audit, and by then it's too late to reconstruct.
What a real audit trail actually records
Strip away the tooling and the requirement is simple. For every change to a governed value, you need to be able to read back:
- Which field changed — down to the attribute, not the workbook.
- Who changed it — an authenticated identity, not a filename or a “last saved by.”
- When — a server timestamp nobody can backdate.
- From what, to what — the old value and the new one, side by side.
- Who approved it — because a change and its sign-off belong together.
- And all of it has to survive the row being deleted and stay out of reach of the people it tracks.
How Primentra records it
Primentra logs every field change on the server, not in the file. When a data steward edits a value, it records that change to an audit log in your SQL Server database and stamps it with the authenticated user, a server timestamp, and both the old and new value. The log is a separate record from the data itself, so deleting the row does not erase its history.
Because it lives in SQL Server, the log is just a table your DBAs can query. No hidden sheet, no macro to strip, no version to overwrite. And it ties into the approval workflow: for changes that require sign-off, the trail shows who proposed the edit and who approved it, which is the part Excel has no way to represent at all. We go deeper on the mechanics in our post on the master data audit trail.
The audit trail isn't the only place a spreadsheet quietly breaks for this work — it's one of several. If you're weighing whether you've outgrown it, we wrote a broader piece on why Excel fails as a master data tool, and a specific one for teams whose MDS Excel add-in stopped working.
Frequently asked questions
Does Excel have an audit trail?
Not a real one for master data. Excel offers Track Changes (legacy shared-workbook mode), Show Changes (Excel on the web, ~60-day window), file version history on OneDrive or SharePoint, and do-it-yourself VBA logging. Each is opt-in, incomplete, and stored in the same file the audited users can edit or delete. None keeps a permanent, per-field record of who changed a value, when, and what it was before.
Can I see who changed a specific cell in Excel?
Only within narrow limits. Show Changes in Excel on the web lists cell edits with the author for about 60 days, but not for local desktop files. Version history compares whole-file snapshots, so you diff entire workbooks by hand. The file’s Last Modified property shows the last person who saved anything, not who touched a given cell.
How long does Excel keep change history?
It depends on the feature. Show Changes on the web keeps roughly 60 days. Version history depends on your OneDrive or SharePoint retention settings and captures the whole file, not individual fields. When a row is deleted, any change record tied to it is deleted with it.
What gives master data a proper audit trail?
A database-backed master data tool that logs every field change server-side: the authenticated user, a server timestamp, and the old and new value, in a record the audited users cannot edit and that survives deletion of the row. In Primentra that log lives in SQL Server, is queryable directly, and ties into the approval workflow.
See every change, and who approved it
Primentra logs every field edit in your SQL Server — who, when, old value, new value — in a record your stewards can't rewrite and a deleted row can't erase. Import your data into the 60-day trial and try to lose track of a change.