An Excel dashboard is nothing more than a spreadsheet someone designed to pull data into one place: a few source tables, some formulas that roll them up, and usually a chart or two showing the result. That's a completely legitimate tool, and often the right way to start, not a mistake to apologize for. The problem isn't the choice to start in Excel, it's that most of these dashboards get built as if they'll stay small forever, and none of them were built to survive one small change in the source data, the departure of whoever built them, or growth in the number of people entering information into them. The result isn't a collapse in one day, it's a slow decay that's hard to pin down to a single starting point.
What the Evidence Shows
This problem isn't specific to any one business. Raymond Panko, a University of Hawaii professor who spent decades studying spreadsheet errors ("What We Know About Spreadsheet Errors," Journal of End User Computing, 1998, with ongoing updates through the university's Spreadsheet Research project), found that in audits of real spreadsheets in active use at organizations, roughly 88% contained at least one error, usually a formula copied into the wrong cell or referencing a range that had grown without the formula growing with it. That number doesn't mean Excel is flawed, it means a spreadsheet that expands gradually, cell by cell, over months, is exactly the environment that produces errors like these and then hides them, because no step in the process ever pauses to re-check the whole structure.
One well documented, public example shows this damage isn't theoretical. JPMorgan Chase's internal Task Force Report from January 2013, which examined the loss known as the "London Whale," found among other things that a key risk model relied on an Excel spreadsheet with a manual update process involving copying and pasting between workbooks, and that a division error in one formula caused the model to understate risk. Reuters and the Financial Times reported on this finding extensively at the time. That isn't a small business example, but it illustrates a broader rule: as the stakes attached to a set of numbers grow, the cost of a manual process that only its builder fully understands grows with it, not steadily, but in sudden jumps, because the error stays hidden right up until the moment it's most expensive.
Across engagements, the same pattern keeps showing up, regardless of industry: a dashboard that started small, built around one clear question and a small number of rows, and over time picked up columns, tabs, and calculations, each added in response to a specific request, without anyone stopping to check whether the whole structure still held together. At some point the sheet holds more formulas per cell than any one person can account for, each resting on slightly different assumptions, and nobody can clearly explain why one cell calculates differently from the row beneath it. Three recurring signs mark that point: #REF! errors that appear once someone deletes a row or column another formula depended on, links to source files that got moved or renamed with nobody updating the path, and "old version, don't delete" tabs that keep piling up at the bottom of the file because nobody's sure if they're still needed.
Why It Breaks Down Over Time, Not on Day One
The first cause is dependence on manual updating. An Excel dashboard works fine on the day it's built, because whoever built it remembers exactly what each formula assumes. Six months later, that person doesn't remember, and whoever updates the sheet after them has no idea those assumptions even exist. Entering new data doesn't require understanding the logic that sums it up, so correct data can keep getting entered into a broken sheet for months without anyone noticing, simply because the totals themselves never get re-checked.
The second cause is cell dragging as an ongoing process, not a one-time action. A formula copied correctly once keeps getting copied every month, and every time someone adds a row, there's a real chance the range the formula references doesn't grow to match. That error doesn't crash the sheet, it just leaves one row out of the total, which is exactly what makes it dangerous: there's no error message, just a slightly wrong number, and it usually keeps getting trusted until someone, by accident, checks it by hand and finds it doesn't match what it should be.
The third cause is the absence of defined ownership. In most cases, whoever built the dashboard did it as an initiative, not an assigned role, so there's no formal process for handing off responsibility if they leave the role, shift to another project, or simply forget the details a year later. A dashboard with no owner doesn't break all at once, it decays slowly, until the team discovers that nobody can explain why a particular number looks wrong, let alone fix it with confidence. Without a named owner everyone knows, every fix becomes a gamble: whoever edits the formula can't be sure if they're correcting a real error or breaking an intention that was there for a reason they don't know about.
What This Actually Means, Beyond Data Accuracy
In most cases the real cost never appears as a line item in a cash flow statement. It spreads across a few places that are easy to miss on a standard financial report:
- Delayed decisions: when leadership doesn't fully trust a number, they check it by hand before relying on it, which brings back exactly the manual work the dashboard was supposed to remove, and pushes the decision back until that manual check is done.
- Single-person dependency: if only whoever built the sheet can explain a given cell, their absence, a vacation, an illness, a role change, turns into a real operational risk, not a theoretical one, right at the moment someone else needs a fast answer.
- High onboarding cost: whoever joins the role and inherits a sheet with dozens of undocumented tabs and formulas needs real time just to figure out what's actually in use and what can be ignored, before they can even start entering data with any confidence.
There's also a quieter cost that only shows up months in: once one number on the dashboard turns out to be wrong, trust in the rest of it takes a hit too, not just in that one cell. The team doesn't know which other cells carry the same kind of problem, so the common response is to go back and check everything by hand, which cancels out the entire advantage the dashboard was meant to provide in the first place. That's exactly why finding one error feels so much bigger than its direct damage: it doesn't just cost the fix, it costs trust in everything else.
Three Ways to Approach This
The right choice depends on scope and stakes, not on which approach sounds the most thorough. There's no single answer that fits every business, because the right call depends on how many people enter data, how many different areas lean on the same sheet, and how expensive a mistake would be if it surfaced late:
- Fix and document the existing sheet: write out explicitly, on a separate tab, what each key formula assumes, name one person as the owner, and add a simple sanity check that flags when a subtotal doesn't match expectations. This fits when the data volume is still small, few people enter data, and the decisions resting on the dashboard aren't critical enough to justify a bigger investment. This work can usually be finished in a day or two.
- Add a short periodic audit without building anything new: schedule a simple quarterly check, compare a handful of key formulas against an independent quick calculation, and document any error found. This is the cheapest approach, but it only works if someone actually keeps to that schedule, rather than letting the check slip every time day to day workload picks up. Without someone explicitly accountable for the audit, it tends to disappear exactly when it's needed most.
- Move to a BI platform once the risk crosses a real threshold: when several departments depend on the same dashboard, when the decisions resting on it affect real budget, or when the number of people entering data has grown past the point where manual tracking can tell who changed what, moving to a tool like Power BI replaces single-person dependency with automatic refresh and defined access rules. The main cost here is setup time and team relearning, not software cost, and a realistic timeline for a move like this runs in weeks, not days.
What's Worth Doing First
Before choosing between the three approaches, it's worth running one simple test: open the three key formulas the dashboard rests on, and try to explain out loud, without opening the sheet itself, what each one calculates and what assumptions it rests on. If the answer comes quickly and clearly, the existing sheet is probably fine with a fix and some documentation. If answering requires opening the sheet and tracing a chain of formulas to understand what's happening, that's a sign the periodic audit, and sometimes the move to a BI tool, are worth the investment before a wrong number reaches a real decision.
The realistic expectation isn't that an Excel dashboard is inherently bad and always needs replacing. In most small cases it's exactly the right tool, and usually the right one to start with. The one question worth asking again and again, not just on the day the sheet was built, is whether the scale it's used at today still matches the scale it was built for, and who exactly would answer if a number in it turned out to be wrong next week.
If your dashboard has reached the point where it's hard to explain what each formula is doing, you can read more about Power BI dashboards for small businesses, or see what that actually looks like in the piece on moving from messy Excel to a live Power BI dashboard.