Emailed spreadsheet versions are a process problem before they are a software problem

Consider a fictional budget review. A spreadsheet leaves finance on Monday as Budget final.xlsx. By Wednesday, someone has corrected a labour rate, another person has added a new project, and a manager has approved a total from a copy that nobody can now find. All three files have plausible names. All three may contain useful work. Only one should inform a decision.

That situation is often described as a version-control problem. It is, but the phrase hides several different failures. Sending an editable workbook by email creates separate copies. Working in a shared workbook can still leave source data out of date. A report can be technically current yet no longer match the version a reviewer approved. And two people can edit the same live model in ways that make sense on their own but produce a bad result together.

Those failures need different controls. A document library and co-authoring solve some of them well. They do not turn a spreadsheet into an approval system or a record-by-record transaction database.

Four problems that get called “version control”

1. Email attachments create forks

An attachment is a new file object. If Priya emails a workbook to Callum and Mei, each person can edit an independent copy. A reply-all message tells people that changes happened; it cannot merge them. A filename such as Final_v8_revised is only a label, and labels are easy to copy.

This is a fork problem. The immediate fix is simple: keep the editable workbook in an agreed repository and share a permissioned link to it. Microsoft documents that Office co-authoring depends on shared storage, a compatible app, a modern file format and edit permission in its guide to document collaboration and co-authoring. For Excel, Microsoft’s co-authoring guidance specifies OneDrive, OneDrive for Business or a SharePoint Online library as the supported storage locations.

The link should be the working document’s home, not a convenience buried in one person’s email. Put it in the team site, channel or operating guide people already use. Name a business owner. Give editors edit rights and readers view rights. Send a PDF or locked Excel copy only when people need a fixed snapshot, and label it clearly as a snapshot rather than an editable master.

Downloads still happen. A client may forward one, or a director may save a copy to a desktop. That is why a published snapshot should carry enough information to identify what it was: report title, release ID or version, data-as-at date, source extract reference where relevant, and publication date. The repository link remains the place to check current work.

2. A shared workbook can contain stale source data

A single file removes competing file lineages. It does not prove that the numbers inside are fresh.

Suppose the workbook uses an export from a rostering system. Everyone may open the same SharePoint link and see yesterday’s export because nobody ran the refresh, the refresh failed, an upstream extract arrived late, or the workbook is showing a cached result. The file is current. The data is not.

Treat file identity and data currency as separate claims. A report header or control sheet can show:

the report release and workbook version
data as at date and time
source system or extract ID
last successful refresh and the person or process responsible
calculation status where that matters
approval status for a published report

This small panel changes a vague question, “Is this current?”, into useful questions. Current relative to which source? Did the refresh finish? Was this the version approved for the meeting?

The right control depends on the source. A simple workbook may need a manual refresh checklist and a named owner. A higher-risk report may need a scheduled data load, a failed-refresh alert, a reconciliation check, and a release gate that stops publication when the source date is wrong. Moving the file to SharePoint helps with copies. It does not fix an unreliable data hand-off.

3. Approval has its own version

Many teams make a report, send it for review, then continue changing the same file. A reviewer may approve the figures at 10:00. At 10:20 an analyst corrects a formula. At 11:00 the report is sent on with the reviewer’s name attached. That is an approval problem, even if the correction was sensible.

An approval should point to a defined release. The release might be a version of the workbook, a locked copy, or a PDF generated from a checked workbook. Record who prepared it, who reviewed it, when it was approved, what data it covers, and the release identifier. If a correction follows, publish another release with a short reason. Do not overwrite a file called “final” and assume the earlier approval follows it.

SharePoint and OneDrive version history are useful for recovery, provided the library’s settings meet the organisation’s needs. Microsoft explains that version limits can be set at organisation, site, library and OneDrive levels, and that older versions may expire or be trimmed under configured rules in its document library version history overview. A team should check those settings before promising that any old file can be restored. Retention and eDiscovery rules may also affect what is kept.

Version history alone does not show that a finance manager approved the business result, understood a late source file, or accepted an exception. Put approval evidence in the release process. For a modest process, that may be a recorded approval in the team’s existing system and a release register. For regulated or high-volume work, it may need a workflow that records the decision against the item.

4. Co-editing can create semantic conflicts

A fork is easy to see once you find the copies. A semantic conflict is harder. Two people work in one live workbook and neither overwrites the other’s cell. Yet their changes disagree in meaning.

One analyst changes the discount assumption from 5 per cent to 7 per cent for a pricing scenario. Another refreshes the customer list, adds a new segment, and applies the old discount rule to it. The totals calculate correctly. The model now mixes two decisions that were never considered together.

Other examples are less obvious. Someone changes a filter before a screen-share. A reviewer is checking a report while another editor changes an upstream formula. A person sorts a range that is meant to stay aligned with notes in a neighbouring column. A macro is edited while colleagues are using the workbook. Shared editing makes changes faster; it does not judge whether they belong together.

Microsoft recommends current apps and AutoSave for the best Excel co-authoring experience, and advises people to edit macros or VBA while working alone in its co-authoring best practices. Those are practical boundaries, not a review process.

Design the workbook around the work. Keep inputs in clear tables. Protect formulas and report sheets. Assign an owner to each input area. Use comments and @mentions to explain decisions. Reserve structural changes, query edits and VBA changes for a maintenance window. For a formal review, either pause editing or review a defined release rather than a moving target.

What Excel, SharePoint and OneDrive can genuinely do

Modern Excel can support concurrent editing and recovery in the right setup. It deserves more credit than the old story that spreadsheets cannot be shared safely. It also has limits worth knowing before a team treats it as an audit system.

A supported workbook in SharePoint Online or OneDrive can be co-authored by people with edit permission. AutoSave helps changes appear quickly. Microsoft’s troubleshooting guide lists conditions that can block or limit co-authoring, including required check-out, password encryption, unsupported or old formats, some workbook objects and policies. The same guidance says Excel co-authoring on SharePoint on-premises is unsupported. Test the actual workbook, storage location, security settings and client mix before making a team-wide rule.

Excel’s Show Changes feature can help investigate recent changes to cell values and formulas in supported co-authoring apps. It can also show certain move, sort, insert and delete actions. That is handy when a total changes and the owner needs a starting point.

It is not a complete change ledger. Microsoft says Show Changes does not cover formatting, charts and shapes, PivotTable operations, or hiding and filtering. Changes made through VBA or add-ins may have gaps, and use of older or non-current Excel can clear the Changes pane. Uploading, saving a copy or replacing a file can clear it too. Microsoft directs users to Version History for older changes, but that history remains subject to the library’s retention and version configuration.

SharePoint file activity is another separate view. It can help someone see recent library activity. It should not be described as a permanent audit trail for every cell, approval and source-data event. Compliance evidence may require tenant audit settings, retention controls, access restrictions, exports and a process designed for the obligation. Check those requirements with the people responsible for records, risk and technology.

There is also a deliberate choice between simultaneous editing and sequential control. Required check-out can suit a controlled handover where one person edits at a time. Microsoft lists required check-out as incompatible with co-authoring in its Office co-authoring troubleshooting guidance. Choose the mode that suits the work. Turning on check-out to stop collisions while expecting live collaboration leaves everyone disappointed.

Avoid reviving Excel’s old Shared Workbook feature for new work. Microsoft calls it an older method with many unsupported features and recommends co-authoring in its page on the Shared Workbook feature.

A concrete example: the capacity plan that went wrong

Consider a fictional operations team preparing a weekly capacity plan for eight service sites.

On Thursday afternoon, the planner emails Capacity plan final.xlsx to site managers. The north manager raises absence numbers. The west manager changes planned intake. The commercial lead alters the average service time in a separate copy after a customer call. On Friday morning, the planner receives three replies. She manually copies changes into the version she thinks is newest.

The total headcount looks high. She fixes it by changing a formula. Later, the commercial lead asks why the customer scenario disappeared. It was in a different attachment. Meanwhile, the dashboard uses a payroll export from Wednesday night, although the meeting pack says Friday. The executive who approved the pack saw neither the later formula correction nor the missing scenario.

There are four separate failures here:

The email created three forks.
The payroll extract was stale.
The scenario change and formula correction were semantic changes with no shared review.
The meeting pack was approved as a loose file, with no defined release.

A better arrangement does not need a new platform on day one. The team stores the working plan in a SharePoint Online library and shares its link. Site managers own clearly marked input tables. Formula and report areas are protected. The workbook shows the payroll extract ID, data-as-at time and refresh status. The commercial lead leaves a comment against the service-time assumption and the planner records the decision before changing the input. Before the meeting, the planner runs the checks, creates release CP-024, and publishes a read-only PDF with its as-of date. Further edits stay in the working copy and become the next release.

If a number later looks wrong, the owner first asks a precise question. Is the meeting pack an old published release? Is the live workbook based on a stale payroll extract? Did a formula change? Did an approved assumption change after release? Version History and Show Changes can help investigate the file. The release record and source details explain what the published result claimed at the time.

Recovery when people have already emailed copies

The first hour after a version mix-up matters. Avoid another round of edits while people argue over filenames.

Name a temporary file owner and tell everyone to stop editing and forwarding copies.
Collect the copies without asking people to overwrite anything. Keep the original email context where it helps establish who changed what and when.
Choose a canonical recovery workbook in the shared repository. Preserve the other copies as evidence until the reconciliation is complete.
Compare material inputs, formulas, worksheets, source dates and comments. Do not only compare the final total. Two copies can reach the same total through different assumptions.
Re-enter accepted changes deliberately, with a short record of the decision. Where the evidence is unclear, ask the change owner instead of guessing.
Recalculate, refresh relevant sources, run the normal checks and create a new release if the workbook had been published.
Send one message with the canonical link, the current release status and a clear instruction that old attachments are superseded.

Version History may restore a previous cloud version when the mistake happened in the repository. It cannot reconstruct edits made in an attachment that was never uploaded, unsaved work, or the reasoning behind a number. That limit is why email threads are weak recovery records.

Controls that prevent a repeat

Start with a short source-of-truth contract. It can fit on one page. State the canonical link, business owner, editor roles, authoritative input sources, refresh owner, definition of a release, publication channel, retention requirement and what to do when a correction is found.

Then make the routine easy to follow:

Share links for editable work. Treat editable attachments as an exception.
Keep working files and published snapshots separate.
Put freshness and release details where readers can see them.
Use permissions that match real responsibilities. Review access periodically.
Check the repository’s version and retention settings against the recovery period the business actually needs.
Protect calculation areas and document the few inputs people are meant to change.
Use a release checklist for reports that affect decisions, customers or payments.
Test co-authoring with representative workbooks, including security labels, macros, queries and external collaborators.

A team can also use Ditch My Spreadsheet to get optional ideas for structuring a workflow around a synthetic example, such as a made-up capacity request with fictional sites and approval steps. Do not upload customer workbooks, personal data, commercial figures or other sensitive material for that exercise. The tool is for structure recommendations. It does not recover lost spreadsheet versions.

When SharePoint link sharing is enough, and when it is time to change the process

SharePoint or OneDrive link sharing is often enough for a small group maintaining one model. It works well when the work is collaborative analysis, inputs are limited, the owner can set boundaries in the workbook, and publication can follow a simple release check. Add version history, permissions, current clients, visible freshness information and a clear owner. That is a meaningful improvement over attachments.

Move beyond a shared workbook when the work itself has become a queue of records. Warning signs include many people submitting rows, each row needing validation, managers approving by region or amount, deadlines and reminders, exception handling, external parties needing separate access, and approved data flowing into another system. A spreadsheet can display that work. It becomes fragile when it is also expected to collect, validate, route, approve and evidence every action.

Workflow software or a database-backed application can give each request a state, owner, rule checks, approval record and integration status. Excel may still be the best place for analysis and ad hoc modelling. It just should not be the place where a high-volume business process lives or where its official approvals are inferred from cell edits.

Pick the control based on the harm a wrong or untraceable result could cause. A weekly planning sheet for a close-knit team needs a sensible home and release habit. A pricing change that feeds an ERP system needs a process built for controlled records.

Limitations

Microsoft 365 behaviour depends on the organisation’s licences, update channels, storage platform, workbook features, security labels, permissions, version settings and retention rules. Test the proposed setup with a representative workbook before relying on co-authoring or recovery. This article does not assess a particular tenant, legal retention duty or compliance requirement.