The Spreadsheet Problem: When Excel Becomes Your Company's Unofficial Database

Most businesses that eventually need to move beyond spreadsheets did not make a mistake by starting with them. The spreadsheet was usually the right tool at the time. The challenge is that spreadsheets are so good at what they do that most businesses keep using them past the point where they remain the right tool, often without noticing the transition has happened.

Spreadsheets Deserve More Credit Than They Get

The Business Tool That Does Everything Almost Without Requiring Anyone to Learn Anything

A spreadsheet is simultaneously a calculation engine, a database, a reporting tool, and a communication medium. It requires no IT department to set up, no vendor relationship to maintain, and no licence beyond what most businesses already pay for. It can model a financial projection, track inventory, manage a payroll, record customer interactions, and monitor project progress, sometimes in the same file.

The learning curve is shallow enough that a competent staff member can build something useful in an afternoon. The output is portable that any colleague or client with Microsoft Office or Google Sheets can open it. The tool forgives structural experimentation: if the layout does not work, you rearrange it. No database schema needs to be redesigned. No developer needs to be called.

For a business in its early stages, or any business running a process that does not yet have a clear, stable shape, these properties are genuinely valuable. The right tool for an emerging process is one that can change shape as the process is understood better. Spreadsheets do this better than almost anything else.

Why Running on Excel Is Often a Rational Architecture Decision

The businesses that built their operations on spreadsheets did not do so because they did not know better alternatives existed. Many of them evaluated alternatives and found that the setup cost, the training requirement, the vendor dependency, or the inflexibility of purpose-built software outweighed its benefits at the time.

A business with twenty clients and three staff members does not need a CRM with sales pipeline automation, lead scoring, and custom reporting dashboards. It needs a way to record who its clients are, what was agreed, and what is owed. A well-structured spreadsheet does this adequately.

The spreadsheet becomes a problem not when it is used, but when it is asked to do things for which it was not designed like enforce data relationships, manage simultaneous multi-user access with permissions, produce audit trails, and serve as the authoritative record for a business whose volume and complexity have grown past what a single file can reliably hold.

The First Category of Spreadsheet Problems: File Fragmentation, Partly Solved by Cloud Tools

When the Problem Is Version Proliferation From File Sharing

In Zimbabwe's business environment, spreadsheets are commonly shared via WhatsApp. A staff member completes an update, exports the file, sends it to the relevant group or contact, and the recipients save a local copy. From that moment, there are at least two versions of the file: the one the sender has and the one each recipient saved.

When any of those recipients makes changes to their local copy and redistributes it, the number of versions multiplies. By the third cycle, "the spreadsheet" is a family of files, each representing a different snapshot in time, held on different devices, with no clear indication of which one reflects the current state of the business.

The "final_v3_UPDATED_forJohn.xlsx" filename is not a joke. It is the documentation system of a business managing version fragmentation by appending to filenames.

What Google Sheets and Microsoft 365 Fix

Google Sheets solves the version problem perfectly. When you share a Google Sheets file, you share a link to a single live document, not a copy. Everyone who opens the link sees the same file, edited in the same browser environment, with changes visible in real time. There is one version because there is one file. Changes are saved automatically. A built-in version history records every edit.

Microsoft 365 with SharePoint or OneDrive provides the same capability for Excel. A file stored in SharePoint can be opened in the browser, shared by link, and edited collaboratively in real time by multiple users. The file-on-a-drive-emailed-as-an-attachment model is not the only way to use Excel anymore, and businesses that have not explored the cloud-collaborative version of Excel are comparing the wrong thing when they compare it to Google Sheets.

Both platforms solve the problem of files proliferating across inboxes and devices. The practical differences between them are largely about which suite the business already uses for email and productivity. A business already on Google Workspace will find Google Sheets more natural. A business on Microsoft 365 already has collaborative Excel available.

What Cloud Collaboration Does Not Fix

Moving to Google Sheets or SharePoint-based Excel eliminates version fragmentation. It does not eliminate the structural limitations that emerge when a spreadsheet is used as a database. Those limitations are not about which platform the file lives on. They are about what a spreadsheet is architecturally capable of doing, regardless of where it is stored.

The Signs That Volume and Complexity Have Outgrown the Spreadsheet

The "Which Row Is the Right One?" Problem

A growing business begins entering data in a spreadsheet. A client appears once in the system. Then the client is entered again by a different staff member who did not find the first entry. The reconciliation that identifies duplicates is a manual process. If nobody runs it consistently, the spreadsheet contains contradictory records for the same entity, and decisions made from that data are made from a contaminated source.

In a properly structured database, this does not happen. A client record exists once and is referenced by every other record associated with it. If you try to create a duplicate, the system either prevents it or flags it. A spreadsheet has no mechanism to prevent a second row for the same client. Both rows sit in the file with equal apparent validity.

When Two People Working at the Same Time Produce Different Answers

Even with cloud-based collaborative editing, a spreadsheet has no concept of transaction locking. If two people are editing related parts of a file simultaneously, and one person's changes affect the calculations the other person is reading, both can complete their work believing they are working from accurate data, and the file will reconcile to a state that neither of them intended.

This is not a cloud platform problem. It is what happens when a tool without transactional integrity is used for data that requires it.

The Formula That Nobody Understands But Everyone Depends On

In most spreadsheets that have been in active use for more than two years, there is at least one formula that has accumulated enough complexity that modifying it requires either the person who built it or significant reverse-engineering time. When that formula breaks, and the way it breaks is often silent, producing a wrong answer rather than an error, the business continues operating on incorrect data until someone notices the numbers look wrong.

Spreadsheet formulas have no tests. There is no system that alerts you when a formula's output falls outside expected parameters because the formula itself is the only documentation of what was expected. The formula is the specification, the implementation, and the test simultaneously.

The Manual Copying That Becomes a Full-Time Role

The property agency that exports a report from one spreadsheet to paste into another. The accounts team that copies payment records from the bank statement spreadsheet into the reconciliation spreadsheet each Monday. The operations manager who transcribes delivery confirmations from a WhatsApp-forwarded list into the tracking spreadsheet.

These are not unusual workflows in a Zimbabwean SME. They are the operational cost of running data processes across multiple spreadsheets without a connecting layer. Each manual transfer is a point of error and a unit of time that produces no business value beyond correcting for a structural gap in the system.

The Structural Limitations That No Spreadsheet Upgrade Resolves

Referential Integrity: The Relationship That Cannot Be Enforced

A spreadsheet has no way to enforce that a relationship between two records must exist. If a client record is deleted, the sales records referencing that client do not break. They continue to show a client name that no longer exists in the client list, or they show nothing, or they produce an error. The relationship between the data was implicit in the structure the person who built the spreadsheet intended. The spreadsheet itself has no awareness of it.

A properly structured database enforces these relationships. You cannot delete a client who has outstanding invoices without explicitly deciding what to do with those invoices first. The relationship is structural, not dependent on the person who built the system remembering that it needs to be maintained.

Permissions: Controlling Who Sees What in a Document Built for Universal Access

A spreadsheet is designed to be opened and read by anyone who has access to the file. Granting access to a specific sheet within the file, hiding rows, and protecting cells are workarounds, not permission systems. A determined user, or simply a careless one, can access data they should not see. A staff member can accidentally overwrite a formula in a protected area if the protection is not configured correctly. Hiding a sheet does not prevent an export that reveals all data.

In a business where different roles need different levels of access to different data, this is an architectural mismatch. The HR manager should not need to navigate around salary data when accessing the leave tracker. The sales coordinator should not have incidental access to cash flow projections while updating the client list.

Audit Trails: Knowing What Changed, Who Changed It, and When

The version history in Google Sheets records every edit. This is a meaningful improvement over local Excel files, and it is genuinely useful for recovering from accidental deletions. It is not a business-grade audit trail.

An audit trail that meets business needs tells you: which specific record was changed, what the value was before the change, what it is after the change, which user made the change, and at what time. It should be queryable: "show me every change made to the client pricing table in the last thirty days." Google Sheets version history shows document snapshots that you navigate manually. It does not produce a queryable log of field-level changes.

For businesses where data accuracy carries regulatory, financial, or contractual weight, the distinction matters.

Data Validation at Entry: Preventing the Problem Before It Exists

Spreadsheets support data validation rules that restrict what can be entered in a cell. A dropdown list, a date format requirement, a numeric range. These are useful and underused in most business spreadsheets.

They are also not enforced at any system level. A user who pastes data from another source can override validation rules. A user who types a value directly can, in many cases, dismiss the validation warning and proceed. The validation is advisory rather than structural.

A database enforces constraints at the point of write, not at the point of display. Data that violates a constraint cannot be saved. The clean data that comes out of a properly constrained database is clean because the entry point prevented dirty data from entering, not because a human reviewed it afterwards.

The Operational Risk Moment in a Zimbabwean Business Context

The moment spreadsheet limitations produce a concrete business consequence varies by operation. Common versions in Zimbabwe include:

A client invoiced twice because two staff members working from different file versions both recorded the same job as outstanding. The client queries the second invoice. The business spends several hours reconstructing what happened from two files that now contradict each other.

A staff member accidentally deletes a formula column in the reconciliation sheet. The month-end report is produced from a sheet that silently dropped a calculation. The error is found three weeks later during an audit.

A procurement decision made on stock-level data from a spreadsheet that was last updated four days earlier, because the person who updates it was on leave and nobody else had the habit of doing it. The order is placed for stock that was already received on the day the update was missed.

Each of these is recoverable individually. Each of them also represents a business that has passed the point where the spreadsheet is the right tool for the process it is running.

Four Options and How to Know Which One Your Business Actually Needs

The conclusion most articles reach at this point is "you need a database" or "you need custom software." That is the wrong conclusion for most businesses most of the time. The right question is which category of problem is actually present, because the right answer follows directly from an honest answer to that question.

Option 1: A Better Spreadsheet With Better Conventions and Process Design

If the problems are version proliferation, unclear ownership, inconsistent naming conventions, and mixed data types in the same column, these are not spreadsheet architecture problems. They are process problems that happen to show up in a spreadsheet.

A single designated owner per file. A naming convention enforced by policy. Dropdown validation for categorical entries. Separate files for separate purposes rather than one file doing everything. A clear schedule for who updates what and when.

These changes cost nothing and fix a significant category of spreadsheet dysfunction. They are worth trying before concluding that a more complex solution is required.

Option 2: Cloud Collaboration as the Specific Fix for Sharing Problems

If the dominant problem is multiple people working from different copies of the same file, the move to Google Sheets or Microsoft 365's cloud-collaborative Excel resolves it directly. Both platforms provide a single live document accessible to authorised users, with real-time editing, automatic save, and version history.

The choice between them should be based on what the business already uses, not on platform advocacy. A business on Google Workspace has Google Sheets integrated with its email and calendar. A business on Microsoft 365 has collaborative Excel integrated with Teams and SharePoint. The functional difference for most Zimbabwean SME use cases is minimal.

Option 3: A Database-Backed Internal Tool

When the problems are referential integrity, permissions, audit trails, or the need to query data in ways a spreadsheet cannot support, the right step is a tool that structures data properly.

This does not mean a custom-built system. Airtable, Notion databases, and Google AppSheet can build database-backed internal tools with minimal technical expertise. These platforms provide proper relational data structures, role-based permissions, audit trails, and form-based data entry with validation, while remaining accessible to a non-developer who understands the business process.

For a business whose data needs have outgrown Excel but whose processes are not so complex or specific that they require a purpose-built application, this is the most appropriate next step. It is significantly less expensive than custom software and significantly more capable than a spreadsheet.

Option 4: Custom Software

Custom software is the right answer when the business process is complex enough, and specific enough to how that particular business operates, that no existing platform adequately serves it. When the workflow involves integrations with external systems, non-standard data structures, or user-facing interfaces that need to serve customers rather than internal staff, custom development becomes justified.

It is the least common right answer, not the default one. Most businesses that believe they need custom software actually need a database-backed internal tool. Most businesses that believe they need a database tool actually need a better spreadsheet with clearer conventions. Working through the options in this order saves time, money, and the significant operational disruption that accompanies premature investment in complex solutions.

The Honest Assessment Most Businesses Do Not Make

The spreadsheet that grew into the company database did so because it was allowed to take on more than it was built for, usually one small addition at a time. The extra column added for a new variable. The new tab added for a new process. The formula added to calculate something that used to be counted manually.

No single step felt like a decision to make the spreadsheet the company database. The accumulation of steps did not announce itself as a transition. The spreadsheet worked fine yesterday, and it works fine today. The operational risk it carries becomes visible only when something goes wrong.

The right time to assess whether the tool matches the job is before something goes wrong, which means periodically asking: has the process this spreadsheet is running become complex enough that the tool's structural limits are producing workarounds? Are those workarounds adding risk that the business should not be carrying?

If the honest answer is yes, the next step is not automatically custom software. It is the least complex solution that removes the specific risk identified. Usually that is simpler than expected. Occasionally it is not. Either way, the assessment starts with the process, not the tool, for exactly the same reason that all solutions engineering in this series has started with the operation rather than the technology.

Sources

1. DataCamp. (2025). Excel vs Google Sheets: Which Is Better for Your Business? Comparative analysis of collaborative features, offline capability, formula support, and enterprise integration.
2. Coupler.io. (2025, November). Google Sheets vs Excel: A Detailed Comparison. Version history, real-time collaboration, and cloud storage differences between platforms.
3. Intelliboard. (2025). Google Sheets vs Microsoft Excel: Side-by-Side Comparison for Business. Collaboration, offline functionality, add-on ecosystems, and enterprise use.
4. Airbyte. (2025). Google Sheets vs Excel: 9 Key Differences. Platform feature comparison; SharePoint/OneDrive collaborative Excel; Google Sheets sharing model.
5. Airtable. (2026). When Should You Move From Spreadsheets to a Database? Referential integrity, relational data, and permission models as the transition criteria.
6. Flatfile.com. (2024). Spreadsheet vs Database: Core Differences and When to Use Each. Structural limitations of spreadsheets vs databases; use case analysis.
7. Vertex42 / Joel Spolsky. The Joel Test for Spreadsheets. Classic analysis of when spreadsheets become an organisational liability rather than an asset.
8. Harvard Business Review. (2013, October). Stop Using Excel, Finance Chiefs Tell Staff. The operational risk consequences of spreadsheet-dependent business processes at scale. HBR.
9. Google Workspace. (2026). Google Sheets for Business: Collaboration Features. Real-time editing, sharing model, version history, and AppSheet integration.
10. Microsoft. (2026). Excel in Microsoft 365: Collaborative Editing on SharePoint and OneDrive. Cloud-based collaborative Excel features.
11. Sparkline Labs. (2026). What Does a Zimbabwean Business Actually Need From Software?
12. Sparkline Labs. (2026). Why So Many Zimbabwean Businesses Still Run Critical Operations Through WhatsApp.