How Excel Risk Check Works

What counts as a problem

We report what your spreadsheet actually contains right now, not what it might contain after a recalculation. If a cell displays #REF!, that is reported — because the person you send the file to opens it and sees #REF!. A stored error is a real error, whether or not recalculating would clear it.

The same principle runs the other way. We do not guess at values we cannot verify. If a cell stores a result that disagrees with its own formula, we only say so when the formula is simple enough to settle without a calculation engine — because calling a workbook falsified is a serious claim, and a wrong guess is worse than silence.

What is deliberately not flagged

A check that fires on everything is useless, so several things are excluded on purpose — and the exclusions are as much a part of the method as the checks.

Calendar and percentage constants. A formula like =B3/12 converts an annual figure to a monthly one. Twelve is a fact about the calendar, not an assumption anyone should have to justify or move into an input cell, so it is not reported as a hardcoded value. The same applies to 24 hours, 7 days, 52 weeks, 365 days and 100 for percentages.

The list is kept deliberately short. 1000 is not on it — a kilowatt-to-megawatt conversion looks universal but is a unit assumption someone may one day need to change. Nor is a rate like 0.005: an unlabelled number buried in a formula is precisely the thing this check exists to find. Adding a number to the exempt list asserts it can never be a business assumption, which is a high bar.

This one is genuinely contested, and worth saying so. Formal modelling standards take the opposite view: every assumption, including a day count, belongs in a labelled input cell, and =B3/365 is a defect however ordinary 365 looks. That position is defensible — day-count conventions are a real and argued-about assumption in finance and energy, and a model auditor would flag it.

We had three independent language models review a sample of these findings without knowing which tool produced them. On calendar constants they split almost perfectly along that line: one judged every single one a genuine defect, another judged almost none of them so. That is not a disagreement about spreadsheets. It is a disagreement about what a risk score is for.

So we measured what the stricter policy would change. Across 80 real workbooks it produced 12% more findings and moved no file into a different risk band — because the score counts the weight of problems rather than the number of them, and the workbooks affected already carried dozens. The stricter rule would have added report lines without changing a single verdict.

We chose the narrower rule: report the numbers a reader would not expect, and stay quiet about the calendar. If you need the stricter standard — because you are auditing against one — say so and we will tell you where the line sits, since it is a list in the code rather than a matter of opinion.

Summary rows under a column. A column of figures with “Total” and “Average” beneath it is one of the commonest layouts in a real spreadsheet. That short block of text at the end is a section heading, not inconsistent data entry, and it is not reported. Mixed types scattered through a column still are — that is data entry going wrong rather than a footer.

Findings that appear in almost everything. Author metadata is present in 99.6% of real spreadsheets. A signal that common cannot separate a good file from a bad one, so it is shown to you but does not affect the score.

These exclusions were not chosen from intuition. Findings from real workbooks were put to three independent AI models from different vendors, none of them the model that wrote the detectors, and the exclusions are the cases where all three independently said the tool was wrong. Where they disagreed with each other, the finding was kept and the disagreement recorded for review rather than resolved by whichever answer was more convenient.

From issues to a number

Every issue carries a severity: Error, Warning, or Info. Those are added up into a weighted total we call burden, and measured a second way as density — burden relative to the size of the workbook, so a large model is not punished simply for being large.

Your score is the worse of the two. That is deliberate. Density alone can be gamed: padding a file with junk rows grows its size faster than it grows its problems, so a purely density-based score would fall when you made a spreadsheet worse. Taking the worse of the two readings means adding a problem can never make a workbook look safer.

Both readings are interpolated on a logarithmic scale, because spreadsheet problems are extremely heavy-tailed — real files range from a single issue to well over a hundred thousand. A linear scale would spend its entire range on the worst few files and give everyone else the same number.

Where the thresholds come from

The band edges are not numbers somebody picked. They are anchored to a corpus of 15,929 real business spreadsheets — the Enron corpus published under CC BY 4.0 by Hermans & Murphy-Hill — so that the median spreadsheet lands near the Low/Medium edge, the 80th percentile near Medium/High, and the 95th near High/Critical.

The thresholds are then frozen, so your score never moves unless your file does. That is deliberate, and it has a consequence worth stating: as the checks get more accurate they report fewer things, so scores drift downwards over time and the bands stop matching the percentiles they were originally fitted to.

Measured across that whole corpus as of engine 2.7.0, the split is 57.7% Low, 31.8% Medium, 7.0% High and 3.5% Critical. So today “Critical” means worse than about 96% of real business spreadsheets — close to the 95% it was fitted to. “Low” has drifted further: it was fitted to mean the better half, and now covers about 58%, so it is a weaker signal than it was.

Those figures come from a full run of that corpus. Since then engine 2.10.0 has changed circular-reference reporting in both directions: it now catches cycles on sheets whose names contain a space and cells that sit inside a range their own formula reads, it no longer mistakes a link to another workbook for a loop inside yours, and it reports one finding per repeated mistake instead of one per filled-down copy.

Rather than quietly reattribute the old numbers to the new version, we re-measured. Across a 496-workbook sample spread across the corpus, 4% of files changed score, five changed band, and no band moved by more than 0.6 points — slightly more files rated Low, because collapsing repeated findings removes volume that was never extra evidence. The figures above still describe the engine to within a point, but they were measured on 2.7.0 and a full re-run is what will replace them.

We publish the measured numbers rather than the fitted ones because the measured ones are what your score actually means. Re-fitting the thresholds would restore the neat percentages, but only by pushing scores back up to compensate for problems we correctly stopped reporting — which would undo the accuracy that caused the drift.

The thresholds were then checked against a completely unrelated corpus — 10,591 workbooks from the FUSE collection, harvested from the public web across thousands of organisations. The two are never added together: one was used to fit the scale, the other to check it, and pooling them would destroy the only property that makes the check meaningful.

Some findings override the arithmetic

A few things are serious enough that volume should not decide them. A workbook containing personal data, an auto-executing macro, hidden text, or a value that contradicts its own formula cannot be reported as Low, no matter how clean the rest of it is. A macro that both runs on open and reaches out to the network or the operating system cannot be reported below High.

These are floors rather than penalties, because a penalty would be swallowed. When the typical spreadsheet already carries a burden in the hundreds, adding fifteen points for “this file runs code the moment you open it” changes nothing. Only a floor can express “this specific thing has no innocent reading.”

What we report but do not score

Some findings are worth showing you and worthless for ranking. Author metadata appears in 99.6% of real spreadsheets; a signal present in almost everything cannot separate a good file from a bad one, and scoring it would quietly push borderline workbooks across a band edge for no reason. It is still reported. It simply does not move the number.

When we could not check something

If part of a workbook cannot be read — an unreadable sheet, a structure we do not recognise, an analysis that hit a complexity limit — we say so explicitly, and the file cannot be reported as Low. “We could not finish looking” must never be presented as “we looked and it was fine.”

The same file always gets the same score

Analysis is deterministic. There is no sampling, no model, and no randomness anywhere in scoring — the same workbook produces the same number every time, and every score is reproducible from the file alone. When the method itself changes, the engine version changes with it, so a score can always be traced to the rules that produced it.

What this does not tell you

The score measures how unusual your spreadsheet's problems are compared with thousands of real ones. It does not know what your model is for, which numbers matter, or what a mistake would cost you. A Critical file may be a scratch workbook where nothing is at stake; a Low one can still be wrong in a way no automated check can see — a correct formula pointed at the wrong column stays invisible to every tool of this kind.

The calibration corpora are real business spreadsheets, but they are not your spreadsheets, and they predate the newest Excel features. Treat the score as a fast, consistent second opinion that tells you where to look first — not as a verdict, and not as a substitute for someone who understands the model reviewing it.