50만 파운드 스프레드시트 문제

During due diligence for a Series B raise, an investor's finance team flagged a reconciliation difference at a UK professional services firm. The difference was £487,000. It had been sitting there for eleven months.

The firm's own finance team had seen the number every month-end. They assumed it was a timing difference. It wasn't. It was a formula error in a spreadsheet that calculated earned revenue differently from how the accounting system booked invoices. Eleven months of management accounts, board reports, and investor updates had flowed downstream from that error.

The funding round was delayed by six weeks. The CFO resigned.

Nobody built that spreadsheet to cause problems. They built it to solve one — to bridge a gap between two systems that didn't talk to each other. Most spreadsheets start that way.

The spreadsheet problem is not about spreadsheets. It's about what happens when the operational source of truth is a file sitting on a shared drive, managed by whoever created it, understood fully by no one, and assumed correct by everyone.

The Common Belief

Spreadsheets are fine for a business of our size. We'll move to a proper system when we get bigger.

This belief is widespread, pragmatic-sounding, and almost always wrong. The logic seems reasonable: formal systems are expensive and complex, spreadsheets are flexible and free, and the business is not yet at the scale where it needs enterprise infrastructure.

But the threshold at which spreadsheets become dangerous has nothing to do with headcount. It has to do with operational interdependency — the number of decisions, obligations, and processes that depend on data being accurate.

Why That Belief Is Wrong

A 20-person professional services firm tracking project profitability, client invoicing, contractor payments, leave, expenses, and pipeline already has more operational interdependency than a spreadsheet can safely manage. Not because of volume. Because of complexity.

Spreadsheets don't enforce data types. A cell that should contain a date will happily accept text. A formula that should aggregate a column will silently include or exclude rows depending on whether someone filtered the view before copying it. Conditional logic accumulates in hidden cells that nobody documents.

More importantly, spreadsheets don't model relationships. They model values. Finance depends on operations. Operations depends on project data. Project data depends on how time is tracked. None of those dependencies are expressed in the spreadsheet — they live in the heads of the people who built it.

When those people leave, the knowledge goes with them. What remains is a file that produces numbers that look right.

What Actually Happens

The life of a business-critical spreadsheet follows a predictable pattern.

It starts as a simple tool. One person builds it to solve a specific problem — usually to produce a report that the accounting system can't generate, or to consolidate data from two systems that don't integrate.

Over time, others need to use it. Columns are added. Tabs proliferate. A second version is created for a different purpose and ends up being linked to the first. When the person who built it leaves, someone else inherits it and adds their own layer without fully understanding the original logic.

Within eighteen months, the average business-critical spreadsheet has:

• Multiple versions with unclear canonical status
• Formulas that reference cells in other sheets that reference cells in other files
• Undocumented logic that produces correct-looking results under normal conditions
• No version control, no audit trail, no change history
• One or two people who understand parts of it, and no one who understands all of it

At this point, the spreadsheet is not a tool. It is a liability. Every number it produces carries unknown error risk that nobody is in a position to quantify.

Real-World Example

Company: Thornfield Project Services
Industry: Construction project management
Size: 34 staff, £8M annual revenue
Problem: Revenue recognition error discovered during audit

What happened:

Thornfield tracked project progress using a spreadsheet updated by project managers weekly. The spreadsheet fed a revenue recognition calculation used by finance for month-end reporting. The model was built two years earlier by a finance manager who had since left.

When the replacement finance manager updated the model to reflect a change in contract structure, she modified the wrong tab. The primary calculation continued to reference the old version of the logic. For seven months, the spreadsheet produced revenue figures that overstated work-in-progress by an average of 6.3%.

Nobody caught it because the monthly variance was within the range that felt normal. The numbers looked slightly high but not alarmingly so. It was only when a client queried a billing schedule that the discrepancy surfaced.

Outcome:

The restatement required three months of prior period adjustments. The audit bill doubled. Two project managers had to reconstruct historical records from emails and site reports. The CEO spent four days with the bank explaining why the management accounts they had shared quarterly did not match the restated figures.

Total cost: approximately £210,000 in external costs, restated management time, and lost client confidence. The indirect cost — slowed growth because the bank reduced their revolving credit facility — was harder to quantify but real.

The Cost of Ignoring It

The visible costs of spreadsheet-dependent operations are large. The invisible ones are larger.

Revenue impact: Billing errors, revenue recognition misstatements, pricing decisions made on flawed margin data, contracts negotiated without accurate cost information. A 2–3% revenue error is common. On a £10M business, that is £200,000–£300,000 moving in the wrong direction annually.

Operational impact: The time spent maintaining, reconciling, and questioning spreadsheets is rarely tracked, but it accumulates fast. Finance teams in spreadsheet-dependent businesses typically spend 30–40% of their time on data preparation rather than data analysis. That is the inverse of where financial function time should go.

Team impact: Skilled people leave environments where their job is to fight data rather than use it. The organisations that retain strong finance and operations talent tend to be the ones that give them reliable infrastructure to work with.

Customer impact: Billing errors, incorrect delivery schedules, misquoted pricing, and poor reporting all trace back eventually to operational data that cannot be trusted. Customers notice. They just don't always tell you why they left.

Scaling impact: The most damaging effect is not what the spreadsheet problem costs today. It is what it prevents. Businesses that want to grow into new markets, raise capital, acquire other businesses, or enter regulated sectors need clean, auditable operational data. Spreadsheet-dependent businesses typically cannot produce it. The constraint is not ambition — it is data infrastructure.

What Good Looks Like

The businesses that solve this problem well share certain characteristics.

They treat operational data as infrastructure, not as administration. The question is not "what tool is cheapest" but "what is the cost of data we cannot trust." The same logic applies to every form of manual process overhead that accumulates around unreliable data.

They create single sources of truth per operational domain. Finance data lives in one place. Project data lives in one place. Customer data lives in one place. Integration is managed deliberately — not through spreadsheets that bridge gaps.

They enforce data quality at input, not at report. Validation happens when data enters the system, not when someone reviews the spreadsheet output at month-end. By the time you are reconciling, it is too late to prevent the error. You are only discovering it.

They build audit trails that do not depend on human memory. Every change is recorded, attributed, and timestamped. When a number is questioned, the answer is not "someone must have changed it" — it is a three-second lookup.

And critically, they design systems so that business knowledge is captured in process, not in people. The logic that drives how revenue is recognised, how costs are allocated, or how approvals flow cannot live in one person's head or one spreadsheet. It needs to be explicit, testable, and independent of who is in the seat. This is the core of what operational complexity actually costs a business — not the visible overheads, but the invisible ones embedded in undocumented process.

ENTMAZ Perspective

The spreadsheet problem is, at its root, a system architecture problem. Businesses accumulate spreadsheets because their formal systems don't cover enough of their operational surface. The spreadsheet fills the gap. Then the gap becomes load-bearing.

ENTMAZ addresses this from the opposite direction. When a business describes how it operates — how revenue is recognised, how costs flow, how approvals work, how data connects — that logic is compiled into the system itself. It is not configured through dropdowns and toggles. It is not documented in a spreadsheet. It is the system.

When the source of truth is the compiled business model, there is no gap for spreadsheets to fill. The logic is explicit, versioned, and auditable. It cannot drift because it cannot be edited outside of the change control process.

That does not eliminate spreadsheets as analytical tools. It eliminates them as operational infrastructure — which is the only category where they cause serious damage.

Conclusion

The £500,000 spreadsheet problem is not unusual. Versions of it happen at businesses of every size, in every sector, every month. The finance director who spots a reconciliation difference in week three of a funding round due diligence is not unlucky — they are representative.

The decision to defer proper operational infrastructure until the business is "big enough" is one of the most consistently expensive decisions in business. By the time the problem becomes undeniable, it has already compounded for years.

The question is not whether you can afford to fix it. The question is how much it is already costing you that you are not measuring.

Key Takeaways

• Spreadsheets become dangerous not because of volume but because of operational interdependency — the number of decisions that depend on their accuracy
• The life of a business-critical spreadsheet follows a predictable decay: useful tool → inherited liability → unauditable risk
• The invisible costs of spreadsheet-dependent operations — talent retention, growth constraints, capital access — typically dwarf the visible ones
• Good operational infrastructure captures business logic in process, not in people or files
• The cost of deferring proper systems compounds over time; it does not wait until the business is "ready"