Using LLMs to review spreadsheet models

An LLM can read the formula behind each cell rather than the value printed on top, then compare that formula against its neighbours and the label in the row header beside it. It cannot certify a model. What it produces is a ranked list of cells worth a second look, each with a reason attached, fast enough to run before a number leaves the building.

A spreadsheet error is rarely loud. The file opens, every cell shows a number, and the total at the bottom looks plausible. The errors that matter never announce themselves, which is why a mechanical pass over the formula layer earns its place. The model itself is not the control. The analyst who reads its flags is the control, and the audit trail is the record that they did.

What actually breaks in a spreadsheet

Most model errors fall into a handful of shapes, and none of them show up as an error message. A #REF! at least announces itself. The dangerous ones stay silent.

• A formula copied across a row that skips one column, so month seven references the wrong precedent and every downstream total is off by a quarter’s worth of revenue.
• A hard-coded number sitting inside a formula, =B14*1.03*1200000, where the 1200000 was a placeholder someone typed during a late edit and never turned back into a cell reference.
• An inconsistent formula in a range that should be uniform, one cell in a twelve-month projection that sums a different set of rows than the other eleven.
• A sign flip, where costs are entered positive in one section and negative in another, and a subtotal adds what it should subtract.
• A broken link to an external workbook that resolved to a stale cached value after the source file moved.
• A total that no longer includes a row inserted above it, because the SUM range was hard-bounded instead of extended.

A person reviewing a large model catches some of these and misses others, mostly depending on how tired they are at quarter-end. The reviewer is not incompetent. The surface area is thousands of cells, and human attention does not scale linearly across them.

Give the model the formula graph, not a picture

The naive approach is to paste a screenshot or the printed grid into a prompt and ask what looks wrong. That fails, because the value layer hides exactly the thing you are hunting for. You cannot see a hard-coded override in a rendered number.

We extract structure instead. For every cell we pull the formula string, the resolved value, the list of precedents and dependents, and the text of the nearest row and column headers. That gives the model lineage: it can walk from a total back to the inputs that feed it, and it can compare a cell against the calculation its own neighbours use. Ranges that should be homogeneous get grouped, so a single odd formula in a block of forty stands out as a pattern break rather than an isolated string.

The prompt then asks a narrow question per cluster. Not “is this model correct,” which invites confident nonsense, but “here are twelve formulas that occupy the same row of a projection, one differs, describe how and why it might be deliberate or a mistake.” Narrow questions with the surrounding context attached are where these models are genuinely useful. Broad questions are where they invent things.

Output is structured, not prose. Each finding comes back as a cell reference, a category, a short reason, and a confidence. That lets us sort, deduplicate, suppress categories a given team does not care about, and feed the whole set into a review queue instead of a paragraph a human has to parse.

Keep the human in the loop, and keep the receipts

Two rules hold this together. The model never edits the workbook, and the model is never the final word.

Every flag is a proposal. It lands in front of a reviewer with the cell, the formula, the reason, and one-click context to jump to that location in the file. The reviewer accepts, dismisses, or corrects. Their decision is logged against the cell and the model version that raised it, which gives you an audit trail: what was flagged, who looked at it, what they concluded. If a regulator or an internal auditor asks how a figure was checked, that record is the answer, and it exists whether the flag was right or wrong.

The economics live in the false-positive budget. A reviewer will read maybe a few dozen flags before they start rubber-stamping, so precision at the top of the ranking matters more than recall across the whole file. We hold a labelled eval set of real models with known planted and natural errors, and we measure precision and recall per error category on it, not on a demo. When a prompt or model change lifts recall on sign flips but floods the queue with false hard-coded-value flags, the eval set shows it before it reaches a person. That is the difference between a tool people keep using and one they quietly switch off after the second week.

The scope is honest. This catches mechanical and structural defects: references, consistency, overrides, sign, stale links. It does not tell you whether a 3 percent growth assumption is reasonable for this business in this cycle. That judgement stays with the analyst, and it should. What the model buys them is the mechanical pass over every cell so their judgement lands on the assumptions that matter, instead of being spent hunting for a typo in row 214.