Established onGoogle Sheets, web: designed for it, per-cell historyExcel 365: co-authoring on vendor storage with autosaveExcel 2016 local files: locked by another user
Both products allow several people in one workbook at the same time. They arrived at it from opposite directions and the differences matter for anybody choosing between them.
The one built for it
Google Sheets was designed around simultaneous editing from the beginning. There is one copy, edits appear as they are typed, and there is no locking and no conflict dialogue: an edit to a cell replaces what was there.
Per-cell edit history is available, which is the most useful auditing feature in either product and has no equivalent on the other side: right click a cell and see who changed it, when, and from what.
The one that added it
Excel gained co-authoring for files stored on the vendor's cloud services, in the desktop and web applications, with automatic saving turned on. Under those conditions it works.
Outside them it does not, and the conditions are more numerous than people expect. A file on a local drive or an ordinary network share does not co-author. Certain features in a workbook prevent it, including some older data connections and some legacy objects, and the failure is a message saying the file is locked by another user, which is the behaviour from before co-authoring existed.
The older feature that is not this
Excel has long had a separate shared-workbook feature, now deprecated, which merged changes on save and produced conflict dialogues that were notoriously difficult to resolve. It is not co-authoring, it is still present for compatibility, and enabling it disables co-authoring.
Anybody who remembers shared workbooks being unusable is remembering that feature rather than the current one.
What simultaneous editing solves
The entire previous entry. There is one copy, so there is no fork, no merge by eye and no lost correction. That is a substantial gain and it is the main reason to prefer this arrangement.
What it does not solve
Anything between typing a change and that change being live for everybody reading the file. There is no draft, no proposal and no review: the moment a cell is edited, every person looking at the workbook sees the new value, including whoever is presenting from it.
So the copy problem is replaced by a different one, and the answer to it is the protection and comment arrangements described in the entries around this one.
Proposing rather than editing
Both products support comments attached to a cell, and using them to propose a change rather than making it is the practice that reintroduces a review step.
It relies entirely on discipline, since nothing prevents editing. In practice it holds where the calculated regions are protected, which turns the convention into a mechanism for everything that matters.
Who changed this
Answerable per cell in one product and not in the other. Excel's change list covers a period on files in the vendor's storage and is a list rather than a per-cell lookup; Google Sheets answers the question directly for any cell, at any time.
For anything where that question will be asked — and in finance, operations and compliance it always is — that difference is worth more than any feature comparison of the formula languages.
The failure mode nobody plans for
Two people editing the same region at once, each seeing the other's changes arrive, each assuming the other has finished. The result is a region that neither of them would have produced, arrived at by alternation.
The remedy is social: say who is working on what, in the file, in a cell. It is the least technical recommendation on this site and it prevents more damage than most of the others.
What we cannot verify
Co-authoring requirements, the deprecated shared-workbook feature and the per-cell history are documented by the vendors and were confirmed on current builds. The list of workbook features that prevent co-authoring is published by the vendor and changes between versions; it should be checked rather than remembered.
What happens on a poor connection
Both products keep working offline to different degrees and reconcile afterwards. Reconciliation is per-cell and last-write-wins in one and a merge with occasional prompts in the other, and in both cases a person who worked offline for an hour may find some of their edits gone.
Nothing announces which ones. Where offline work is expected, the safer arrangement is to work in a separate file and transfer deliberately, which reintroduces the copy problem in exchange for knowing what happened.
The question to ask before choosing
Whether anybody will ever need to know who changed a particular cell. If yes, that single requirement decides the product, and it decides it before any comparison of formula languages.
Presenting from a live file
A workbook on screen in a meeting is a workbook somebody elsewhere can edit while it is being discussed. Figures change mid-sentence, and the version everybody agreed on is not recoverable afterwards.
Take a snapshot before presenting, present from that, and name it for the meeting. This is the legitimate copy described in the previous entry.
In short
- One product was designed around simultaneous editing and the other added it later.
- Excel co-authoring requires the vendor's storage, automatic saving, and no blocking features.
- The deprecated shared-workbook feature is a different thing and disables co-authoring.
- It solves the copy problem completely: one file, no fork, no merge by eye.
- It provides nothing between typing a change and everybody reading it seeing the change.
- Per-cell edit history exists in one product only, and it answers the question people ask.