Spreadsheets by email: which version is the right one?
Nobody knows, because the file became the system of record, and that is an architecture problem, not a technology one. When a spreadsheet is the only place the data lives, every copy sent by email is a fork, and nothing says which one counts. Storing the file in the cloud reduces the copies, but it does not say who decides the rule.
How many copies of the same spreadsheet circulate in a company?
The study comes from a large company, but it shows the pattern. Hermans and Murphy-Hill analyzed the email of 190 Enron mailboxes, 717,102 messages once the contacts and drafts folders were removed. In 44,214 of them (6.2%) there was at least one .xls spreadsheet attachment, an estimated average of about 100 a day. The authors conclude that emailing spreadsheets was common practice and point to a missing version control system (TU Delft technical report, 2014).
The same study has a second number. From 265,586 attachments came 51,572 Excel files, and only 16,189 were distinct by content. Dividing one by the other, each distinct spreadsheet appears in a little over three attachments on average. The calculation is ours, and part of those repeats is simply the same file forwarded. Another part is versions that diverged.
Later work looked at exactly that. Xu and colleagues started from the same corpus and rebuilt, by similarity, which files were versions of one another, arriving at 1,609 groups with 12,254 spreadsheets. The problem they describe is the familiar one: users rarely document the version, so versions coexist as separate, similar files (Xu et al., arXiv, 2017).
Two caveats. Enron is not a small business, and the corpus is old. The studies support the mechanism, not the rate you would find in your own company. If the mechanism is different in your operation, check it in practice: open the inbox of whoever prepares quotes and count how many versions of the same table exist.
What does cloud editing solve, and what does it leave out?
It solves the copy, which is not small. Cloud Excel lets several people edit the same file at the same time, with changes appearing within seconds, and it keeps a version history. There are conditions: the file has to be on OneDrive or SharePoint Online with AutoSave on, and someone opening it in an unsupported version can lock the file for everyone else (Microsoft documentation).
The same text states the limit. When two people change the same area, the last saved change generally wins, and the recommendation is to assign each person a sheet or a region. An older version can be restored only after everyone stops editing.
Our reading is that the feature solves the file problem and leaves the data problem where it was. The history keeps states of the file, not the reason for a change. Who may change a band in a price table, and who checks the value typed in, depends on how the team organizes the file, not on the feature. One emailed attachment is enough for the copy to exist again.
Why is "which version is right?" an architecture question?
Because it only exists when the file does three jobs at once: it stores the data, holds the rule and serves as the history. In a system with a single place for the record, those functions are separate. The data has an owner and a state, the rule has an effective period, and the history records author and date. Who owns it, which rule applies and since when are human decisions, made before any tool. That is what the system has to record. The spreadsheet stays useful, but as a view or an export, not as the source.
It is the same reasoning as spreadsheet errors: why nobody notices until they cost you, seen from the other side. There, the problem is the rule hidden in the cell. Here, it is the copy that carries the rule outside any control. Both share a root: the file was promoted to a system without being designed for it.
The size of the problem does not depend on volume. A ten-row table that sets the price of everything the company sells already raises the question. What matters is how much money runs through it and how many people use it without talking to each other.
What does this look like in a freight carrier?
A hypothetical scenario, to make the mechanism concrete. The numbers are illustrative, not a client measurement.
A freight carrier has five sales reps quoting shipping from a spreadsheet, by weight band and region. When fuel prices move, the coordinator updates the file and emails it to the team. Two reps keep opening the previous attachment, which is still in their inbox, and a third saved a copy to the desktop with a one-off discount for a customer.
For a few weeks, the company has three tables in use. Nobody acted in bad faith, and no quote looks strange. The problem shows up when a customer complains about two proposals with different prices for the same route and finance has to answer which table applied on October 12. The spreadsheet kept only the last one.
At that point the failure is no longer about a file. The company cannot say which rule was in force on each date, because an effective date was never a field.
What changes when the data stops living in the file?
Four things, and none of them requires abandoning the spreadsheet. The table gets a named owner who answers for it. There is a single source, and whoever quotes reads from that source instead of an attachment. Each change records author, date and reason, and the rule gets an effective period, with a start and an end, which makes it possible to rebuild past quotes from the recorded effective period. And the spreadsheet stays available as an export, for whoever needs to analyze.
In the Repap On case, the starting point is the same, applied to documents: manuals and internal policies scattered across emails, network folders and physical files, with no version control. The platform came to control versions and to restrict viewing by role and department. Yowpi holds an equity stake in Repap On, as the case itself discloses. In the Reatop case, Bumerangue tracked hospital waste in spreadsheets and paper notes, with delays in consolidating the data, and the record starts in the mobile app, which works without a signal.
The path to get there without stopping operations is in how to migrate off spreadsheets without stopping.
Frequently asked questions
My team is used to spreadsheets. Will they accept another way?
It helps when the spreadsheet remains as an output. The team loses the habit of editing the file but keeps the table they always opened. Start with the data that triggers the "is this the right version?" question most often, and keep the old spreadsheet running in parallel for a short period, with an agreed cutoff date.
How do I know there is a financial return?
Measure first what the doubt costs today. How many times a month someone asks which file applies, how many hours go into checking, how many quotes, payments or commissions had to be redone. If those numbers are low and the spreadsheet only serves analysis, cloud editing may be enough. If any of them has a monetary value, that is where the calculation starts.
Will integrating with what I already use be complicated?
It depends on where the data lives today and who consumes it. Starting does not require integrating everything: the first step is usually to import what exists in the current spreadsheet and offer an export in the format the team already uses. Integration with the ERP, email or finance comes later, as a design decision, one at a time.
The next step
If your company has a table or a rule that circulates as a file, the Operational Architecture Diagnostic is a 30-minute conversation to map where the data lives and who answers for it.
Related case studies
Did you recognize your operation in this article?
Book the Operational Architecture Diagnostic: 30 minutes to map where your operation's bottleneck is. No proposal in the first conversation.
Book a diagnostic