Version control for Excel
Version control for Excel: has anyone actually solved this?
Search the question and you land on a forum thread full of half-answers. Here’s an honest tour of every approach people try — Git, SharePoint history, compare utilities — what each one really gives you, and what to do instead.
Everyone wants the same thing, and nothing quite delivers it
The need is simple to state. You have a workbook that matters — a forecast, a pricing model, a board pack — and several people touch it. You want to see who changed what, when, and why, roll back if something breaks, and ideally have someone check a change before it’s trusted. The same thing a developer gets from a code repository, for a spreadsheet.
Then you go looking and the answers don’t fit. The tools built for code assume you’ll push to Git. The thing you already have — SharePoint — quietly saves copies but won’t tell you what’s inside them. So most teams settle for a shared drive, a naming convention nobody follows, and the hope that a number going wrong gets caught before it ships. It usually doesn’t.
The four things people try, honestly
Each of these is genuinely good at something. The trouble is that no single one of them is good at the whole job.
SharePoint / OneDrive version history
Good backup. Not version control.
Keeps a list of saved versions you can restore, and most teams already have it. But it versions the file, not the changes — you can roll the whole workbook back to Tuesday, yet still can’t see which formula moved or who moved it. To find what changed, you open two versions and compare by eye.
Git / Git LFS
Great for developers. Finance won’t use it.
Real history, real review, real approvals — if the people editing the model live in Git. They don’t. An accountant is not going to commit and push an .xlsx, and even if they did, `git diff` just prints “binary files differ.” You get a timeline of changes you can’t read.
Desktop compare utilities
Fine for one file. No memory.
A Windows compare tool will show you the difference between two specific files when you sit down and run it. There’s no history, no record of who changed what, nothing that watches for the next change. It answers “what’s different right now,” then forgets.
Dedicated tools (xltrail and similar)
Closer — but Git-or-upload only.
Purpose-built Excel tools get the comparison right. Most of them still expect you to push to Git or upload files by hand, and they stop at the comparison: no SharePoint watching, and usually no comments, sign-off, or approval gate on top. You change your whole workflow to get half the answer.
Where each approach actually lands
Nobody safely merges binary workbooks, so that row is empty for everyone — including us. The honest gaps are elsewhere.
| SharePoint history | Git / Git LFS | Compare utility | SheetDelta | |
|---|---|---|---|---|
| Keeps a history automatically | On push | — | ||
| Shows which cells & formulas changed | — | Binary only | ||
| Who changed each value | File-level | Commit author | — | |
| Nothing new for finance to learn | — | |||
| Watches SharePoint / OneDrive | — | — | — | |
| Review comments & sign-off | — | Text PRs | — | |
| Exportable audit trail | — | — | — | |
| Branch & merge workbooks | — | — | — | — |
Git is the right answer for developer-owned workbooks; SharePoint history is a solid backup. The missing piece is the cell-level comparison, the who-changed-what, and the review — and a tool that watches the place finance already saves.
What to actually do
Don’t try to move a finance team into Git, and don’t pretend a backup is review. Keep saving to the SharePoint or OneDrive library you already use, and add the one layer everything else is missing: SheetDelta watches that library, compares each new version against the one before it, and attaches who changed each cell. When a formula becomes a hard-coded number, you see it — along with the name of the person who did it and the version it happened in.
On the workbooks where a mistake is expensive, you can go further: comment on the exact cell, require a reviewer, and block a change from being trusted until it’s signed off. Everything lands in an audit trail you can export when finance, risk, or an auditor asks. You get the outcome people wanted from “version control for Excel” — history, who-changed-what, and a review step — without changing how anyone saves a file.
And we’re honest about the one thing it doesn’t do: it never branches or merges a workbook, because that corrupts the file. It makes changes reviewable, not automatic.
Frequently asked questions
Can you actually use Git for version control of Excel files?
git diff prints “binary files differ” instead of showing the change. And the people who edit most finance and ops models won’t commit and push from Excel. If your workbook lives in a repo, see Git diff for Excel to make those diffs readable; if it lives in SharePoint, watch it directly instead. Does SharePoint or OneDrive version history count as version control?
What’s the best approach for a finance team that won’t adopt Git?
Does SheetDelta branch and merge workbooks like Git does?
We already have a folder of final_v2_FINAL.xlsx copies. Where do we start?
Keep reading
The same story, from the team-setup angle.
Why SharePoint history rolls back but can’t compare versions.
Make `git diff` readable when the workbook is in a repo.
Watches SharePoint instead of forcing Git or uploads.
Review every change to a forecast before it ships.
Provable who-changed-what-when for audits.
Stop guessing what changed in the model
Point SheetDelta at the SharePoint library you already use and the next change becomes a readable, reviewable, audited event.