A spreadsheet shows you values, but it runs on formulas, and the gap between the two is where spreadsheet trouble lives. A cell displaying 60 might contain the number 60 typed by hand, or the formula =SUM(A1:A10) adding ten other cells, or a formula that references another sheet, another workbook, or a function whose behaviour you have not checked. When the inputs change, the first cell stays 60 and the others update, and nobody can tell from the display alone which kind is which. When a formula breaks, the display may show an error, or worse, it may show a plausible wrong number, because a reference shifted, a range stopped one row short, or a lookup silently matched the wrong row. The XLSX Formula Inspector looks at the formulas themselves rather than the values they produce, so you can audit what a workbook actually does before you trust it, change it, or hand it to someone else.

Understanding formulas starts with their anatomy. A formula begins with an equals sign, followed by an expression built from cell references, operators, functions and constants. References like A1 point to a single cell, ranges like A1:A10 point to a block, and references with dollar signs, like $A$1, are locked so they do not shift when the formula is copied. Functions like SUM, AVERAGE, IF, VLOOKUP and INDEX take arguments and return results, and they can be nested, with one function's output feeding another's input. Precedence rules decide the order of evaluation: parentheses first, then powers, then multiplication and division, then addition and subtraction, just as in ordinary arithmetic, with function calls evaluated as part of the expression. A formula that ignores precedence, writing =A1+A2B2 when it means =(A1+A2)B2, computes something different from what its author intended, and the display will not confess.

How the tool works

The inspector reads the formula layer of a spreadsheet file, the .xlsx format, and presents the formulas in a readable form, usually alongside their locations, so you can review them without opening the file in a spreadsheet application and risking accidental edits. That read-only stance is a feature, not a limitation. Opening a workbook to inspect it invites the classic accident: a stray keystroke overwrites a formula with a value, a recalculation changes results before you have seen the originals, or an application "helpfully" converts a formula it does not support. Inspecting the formulas as text, separately from the values, avoids all of that, and it also reveals things a spreadsheet application hides by default, such as formulas in cells you would not think to click, external references to other files, and formulas that differ from their neighbours in a column that should be uniform.

The most valuable inspection is the consistency check. In a well-built sheet, a column of calculations usually contains the same formula pattern copied down the rows, with relative references shifting row by row. A single cell that breaks the pattern, because it was overwritten, because a row was inserted, or because a copy went wrong, is a defect hiding in plain sight, and it is invisible in the value view if the wrong value happens to look reasonable. The inspector makes the pattern visible by listing formulas together, so the odd one out stands out. A second valuable check is dependency tracing: which cells does this formula read, and which other formulas read this cell? A formula at the end of a long chain inherits every error upstream of it, and a change to a single input cell can ripple through dozens of dependents. Knowing the chain before you edit is the difference between a controlled change and a surprise.

A worked example

Consider a small sales sheet. Cells A1, A2 and A3 contain 10, 20 and 30. Cell A4 contains =SUM(A1:A3), which evaluates to 60, since 10 + 20 + 30 = 60. Cell B1 contains =A4*2, which evaluates to 120. Cell C1 contains =IF(B1>100,"Large","Small"), which evaluates to "Large," because 120 is greater than 100. Inspecting these three formulas tells you the whole logic: a total, a doubling, and a threshold test. It also tells you what could go wrong. If a fourth value is added in A4's place, overwriting the formula with a number, the total freezes and B1 and C1 stop updating. If the range in A4 is extended to A1:A4 by a careless edit, the formula becomes self-referential and errors. If the threshold in C1 is changed from 100 to 1000, the label flips to "Small" without any input changing. Each failure is obvious in the formula view and invisible, or at least unexplained, in the value view.

A second example shows the lookup trap. A formula =VLOOKUP("Widget", A1:B100, 2, FALSE) searches the first column of A1:B100 for "Widget" and returns the value from the second column of the matching row, with FALSE requiring an exact match. If the lookup value is misspelled, or if the table's first column is not the one containing the search keys, the formula returns an error or a wrong row, and the displayed result may still look like a plausible price. Inspecting the formula reveals the search key, the table range, the column index and the match mode, which are the four things to verify in any lookup. A third example involves external references: a formula containing a reference to another workbook will fail or freeze when that workbook moves, is renamed, or is unavailable, and the inspector's listing of external references is often the first time the workbook's owner learns they exist.

Common mistakes

The most common mistake is overwriting a formula with a value during editing, which freezes a calculation that should stay live. The second is a range that stops one row short, so new data added at the bottom is silently excluded from totals; this is why structured tables and whole-column references are safer than hand-typed ranges. The third is relative versus absolute reference confusion: copying a formula that should lock onto a single rate cell, but letting the reference drift down the column instead. The fourth is a lookup without exact matching, where an approximate match returns the nearest row below the search key rather than an error, producing a wrong answer that looks right. The fifth is circular references, where a formula depends, directly or indirectly, on itself, which either errors or iterates to a meaningless result. The sixth is trusting displayed values after an edit without recalculating or re-inspecting; values update on their own schedule in some applications, and a stale display is a false report.

Honest limitations

A formula inspector reads formulas; it does not run the workbook's full calculation engine, and it cannot guarantee that a formula which looks correct will evaluate correctly in every spreadsheet application, since functions and behaviours differ slightly between them. It cannot judge whether a formula implements the business rule it was meant to implement: a tax calculation with the wrong rate is a valid formula and a wrong answer, and only a human who knows the rule can catch it. It cannot detect errors in the input values themselves, and it cannot recover a formula that was overwritten with a value, because the formula no longer exists in the file. It also cannot audit macros, scripts or external data connections beyond noting their presence; those are separate layers of logic with their own risks. Within its scope, though, it turns an opaque workbook into a readable document, which is the precondition for every other kind of audit.

Closing

Trust a spreadsheet the way you trust any calculation: read the formulas, not just the values. Check that copied columns share a pattern, that ranges cover the data they claim to cover, that lookups require exact matches when exactness matters, and that external references are known and intended. Do that before you edit, before you share, and before you act on the numbers. For neighbouring jobs, the CSV Viewer and Editor handles tabular data without formulas, and the Spreadsheet Column Profiler summarises what a column actually contains, while CSV Data Quality Checker: Find Bad Rows Early covers the data-quality pass that should precede any formula audit, since correct formulas on bad data still produce wrong answers.