Drop in an .xlsx or .xlsm workbook and gridlint reports where it is fragile: the overwritten formula, the rate typed into a cell, the input that quietly feeds half the model. It runs entirely in your browser — the file is never uploaded anywhere.
#REF!, #N/A, #DIV/0! and friends.
An error value doesn't stay put — it propagates. One #REF! in a driver row turns every total downstream into an error, and Excel will happily let you print the result. gridlint separates the ones that mean something is broken (#REF!, #NAME?) from the ones that are often deliberate and handled (#N/A from a lookup that legitimately misses). Start with the first group; a #REF! means a row or sheet a formula depended on no longer exists.
A number sitting where a formula used to be.
This is the single most damaging thing that happens to spreadsheet models, and the hardest to see. Someone needed a figure to tie out, typed it straight into a cell that held a formula, and moved on. The model now looks right and stops responding to its own inputs — change an assumption and that one cell never moves. Nothing about the cell looks different. gridlint finds them by their neighbours: in a row or column of otherwise identical formulas, a hardcoded number is a hole.
Rates and amounts typed into the arithmetic.
A growth rate buried in =B4*1.085 is an assumption nobody can find. When it changes — and it will — someone has to know it exists, locate every formula carrying it, and update each one identically. gridlint deliberately ignores structural arithmetic like *2 or /12, which are not assumptions, and flags the numbers that look like inputs: rates, percentages, and large amounts. The fix is always the same — move it to a labelled cell and reference it.
One cell in a row that doesn't match its neighbours.
A row of formulas should be the same formula. When one cell breaks the pattern it is usually a copy-paste that landed short, a drag-fill that stopped a column early, or a manual override someone meant to remove. gridlint compares the shape of each formula against the cells around it, so a genuinely different calculation stands out even when the numbers it produces look plausible. Plausible is the problem — these rarely announce themselves.
Assumptions parked out of sight.
Hidden sheets are not sinister on their own — most models have a working tab or two. They matter because reviewers do not read them. An assumption, an override, or an old version of a calculation living on a hidden sheet is a thing your reviewer has silently agreed to without seeing. "Very hidden" sheets are worth more attention: they cannot be unhidden from the normal Excel interface at all, only through the VBA editor, which means someone took a deliberate step to put them beyond casual view.
Formulas that reach into another file.
A link to another workbook is a dependency on a file path. It breaks when the file is renamed, moved, reorganised into a different folder, or simply sent to somebody who doesn't have it — and when it breaks, Excel keeps showing the last value it saw. The model looks fine and is quietly frozen in the past. If a number matters enough to link to, it usually matters enough to bring into the model properly.
Cells that depend on themselves.
Interest on an average balance, a fee calculated on a total that includes the fee — circularity turns up honestly in financial models. The problem is that Excel resolves it by iterating a fixed number of times, so the answer depends on a setting rather than on the maths, and it can be stale in ways nothing on screen indicates. gridlint traces the dependency graph and reports the cells in the loop, so at minimum the circularity is a decision you made rather than one you inherited.
OFFSET, INDIRECT, NOW, RAND.
OFFSET and INDIRECT build references out of text and arithmetic, which means no tool — not Excel's own trace precedents, not this one — can see what they actually point at. Insert a row and they can silently start reading the wrong thing. Volatile functions have a different problem: NOW, TODAY and RAND recalculate constantly, so a model can produce different numbers on Tuesday than it did on Monday with no input having changed. Neither is wrong by itself; both make a model harder to audit.
One input feeding a large share of the model.
Some cells carry far more weight than others. A price, a headcount, an FX rate that thirty or a hundred formulas all read — if that one number is wrong, everything downstream is wrong at once and consistently, which is exactly the failure mode that survives a review. Nothing looks anomalous because everything moved together. These cells are not defects; they are the cells worth checking twice, and worth labelling clearly so the next person knows what they are touching.
VBA that can rewrite anything at runtime.
A workbook carrying VBA can do things no static scan can anticipate: overwrite formulas with values, repoint references, populate cells on open. If macros are present, treat every other finding on this page as a partial picture — the code may be creating or hiding problems that only exist while the file is running. Worth knowing before you trust an audit of the cells alone.
Alongside the risk report, every workbook gets a grade from A to E for how well it would map to a multidimensional model: A means the structure and formulas import as a cube today; B means the data is clean but lookup and conditional-aggregation logic must be rebuilt in dimensional terms; C means the layout has to be restructured first (merged headers, one tab per month); D means macros, external links or deep interdependency make migration a project; E means the sheet is genuinely freeform and Excel is the right home for it. The grade always comes with the top factors that cost points.
XCubes builds financial models on multidimensional cubes, where several of these failures cannot be expressed at all.