Rebar

Spreadsheet errors don't announce themselves. A formula copied down a column with one row pasted over as a hard number still shows a plausible number. A range that stops one row short of the data still sums. A lookup that falls back to the wrong match still returns something. Field audits of real-world spreadsheets have repeatedly found errors in a large share of them, and the ones that matter are the ones nobody has looked at in years.

The usual fix, someone senior clicking through cells, doesn't scale past a few tabs. Inspecting a 40-tab model by hand means holding a dependency graph of tens of thousands of cells in your head.

A modern .xlsx file is a zip archive of XML. Rebar reads it directly, not through Excel, and recovers the formulas, defined names, tables, data validation and cross-sheet references, including the shared formulas that Excel compresses on save. Each formula is parsed into an abstract syntax tree using a full grammar for Excel's formula language, covering array formulas, structured references and LAMBDA and LET.

From those trees Rebar builds a directed graph of every cell-to-cell dependency in the workbook. That graph is what makes everything else possible. It shows which inputs actually drive a given output, which cells nothing depends on, and the exact order in which the model calculates.

The static analysis looks for seven kinds of problem. Hard-coded numbers sitting where a formula should be. Formulas that break the pattern of the rows around them. Ranges that miss part of the data they're meant to cover. Circular references, intended or not. Lookups that can silently return the wrong match. Inputs that feed nothing, and outputs that rest on a single unchecked assumption.

Each finding is shown on a map of the workbook and ranked by how much downstream value depends on it. A wrong number feeding the total bid price outranks a wrong number in an unused scratch tab.

Once the graph is clean, Rebar generates code from it: typed functions with named inputs and outputs, in place of cell addresses. Typed Python or TypeScript is the default. The generated model is then run against the original workbook across many input sets and has to reproduce the same numbers before it is handed over, so the translation is proven rather than assumed.

What comes out can live in version control, be covered by tests, run behind an API, and be read by someone who wasn't there when it was built. The business keeps its logic and loses the fragility.

Parsing, dependency-graph recovery and the core error checks work on large real-world workbooks. The code generator handles the large majority of common functions and is being extended to the long tail, including volatile functions, dynamic arrays and the odder corners of the date functions.

Next is the interactive graph explorer: click any number in the original workbook and trace exactly what produced it, down to the input cells, as a single view.