The spreadsheet that runs your close dies only when its replacement proves itself, cell by cell.

EUC risk gets named every year. The workbook survives every year.

The pattern is depressingly stable. Close runs on inherited workbooks whose owner left two years ago. Internal audit lists "end-user computing risk" in the annual report, but nothing ranks the workbooks, so remediation has no queue. Eventually a replacement is commissioned, and testing is defined as "run both in parallel for a month and eyeball the outputs". Mid-parallel-run a residual difference appears, nobody can say which side is wrong, the project loses its nerve, and the spreadsheet lives another cycle. Meanwhile a hardcoded override pasted in three quarters ago flows into the reported numbers, because a reviewer reading values on a screen has no way to see that a SUM is no longer a SUM.

The research says the reviewer never had a chance. Panko's synthesis of spreadsheet experiments puts errors in roughly 94% of operational spreadsheets, and puts human inspectors near a 60% detection rate on seeded errors, meaning two in five planted mistakes survive a careful review. The workbook in this demo is a quarterly GST close: the tax rate hardcoded into every formula, eight legacy tie-out constants, two external links with cached values, a hidden workings column, a hidden stale sheet, and an owner listed as "left 2024, no documented handover". Every one of those pathologies came from real close workbooks I have reviewed; here they are seeded, labelled synthetic, and machine-checkable.

The hard part is proving equivalence, and eyeballs cannot carry that burden.

Rebuilding a close calculation as governed code is usually days of work. What stalls retirement is the burden of proof: the spreadsheet is the incumbent system of record, so the replacement must demonstrate it reproduces the incumbent's numbers, warts included, before anyone will sign the cutover. "Eyeball both versions for a month" cannot carry that burden, because eyeballing is exactly the 60%-detection activity the research measured.

• naive move 1Ask a model to review the workbook. A language model reading a spreadsheet sees the same rendered values a human sees, and a hardcoded 116,708.84 is a perfectly plausible number. That reproduces the failure mode of human review at higher speed.
• naive move 2Ask a model to rewrite the workbook and trust the rewrite. Now there are two artefacts that disagree somewhere unknown, and no procedure for finding where. That is the original stall with more confidence.
• the mechanical fixRecompute every cell and compare. Equivalence between a formula graph and a program is arithmetic. Arithmetic is a job for deterministic code, which catches 100% of value divergences by construction, and the demo proves that live with a 30-cell seed sweep.

Deterministic code computes the score, the diff and the gate. The model may only quote cells.

The register scores each workbook from parsed structure: formula count and nesting depth, hardcoded constants inside formulas, external links, hidden sheets and columns, volatile functions, and single-owner metadata. The weights are fixed and printed on screen; no model touches the score. The differ recomputes all 28 formula cells of the governed micro-app from the GL inputs and the two cached external rates, and compares them to the spreadsheet's stored values. The gate is one line of code: max absolute difference on the close-pack outputs, against a tolerance declared on screen at S$0.00. The model stub has exactly two jobs: explaining risk flags by quoting the offending cell and formula text (abstaining, visibly, where the static analysis kept no cell to quote), and drafting the retirement memo from register scores and diff results only.

The gate is four lines. That is the point.

Here is the deterministic core from the shipped engine: the differ walks every formula cell, compares the micro-app's recomputation with the spreadsheet's stored value, keeps the earliest divergence in calculation order (which is how it locates the override that caused the cascade), and the gate reduces to one comparison:

// the retirement differ: every formula cell, spreadsheet vs micro-app
cw.order.forEach(function (ref) {
  var c = cw.byRef[ref];
  if (!c.ast) return;
  var d = mv[ref] - ss[ref];          // micro-app minus stored, integer cents
  if (d !== 0) {
    if (!origin) origin = ref;        // earliest divergence in calc order
    if (isOutput[ref]) maxOut = Math.max(maxOut, Math.abs(d));
  }
});

// the cutover gate: a boolean over the outputs, tolerance shown on screen
function gateOpen() { return maxOut <= tolerance_cents; }  // tolerance = 0

All money is integer cents, so "equal" means equal, with no floating-point apologies. The micro-app is an independent hand-written implementation of the close logic; it never reads the spreadsheet's formulas, which is what makes agreement between the two implementations evidence rather than tautology.

Flip the toggle, then watch the differ catch what a reviewer would miss.

The demo loads with the register already scored. The synthetic close workbook tops it at 56.9 of 100, driven by 18 hardcoded constants across 31 formulas, two external links, the hidden column and sheet, and the departed owner; the eight real Enron workbooks score between 21.5 and 43.5 under the same fixed weights, and clicking any row shows its flags quoted cell by cell, straight from the corpus. One Enron cell reads =1+2.786+1.33+2.03+0.538+2.656+5.928+0.739+3.502+5.872+9.97, which is the argument for hardcode scoring made better than I ever could.

• The seeded error. The big red button replaces D12, output tax, with the stored value of three quarters ago: 116,708.84 instead of 124,158.34. The human inspection view changes by one plausible-looking number and flags nothing, which is exactly the condition under which Panko's inspectors missed two errors in five.
• The catch. The differ's next run reads max |diff| S$7,449.50, locates the earliest divergence at D12, and lists the five downstream output cells that disagree because of it. The register re-scores the workbook live, one hardcode heavier.
• The lock. The cutover lever is physically disabled: the gate boolean reads FALSE and says so in monospace. A disposition form appears, and the acceptance option demands free text; try to accept without a reason and the form refuses.
• The honest trap. Choose "fix the micro-app" and the differ obediently reads zero, the gate opens, and the app tells you plainly that the hardcode has now survived retirement inside the replacement. The boolean is enforced by code; whether zero means correct is why the disposition belongs to a named human.
• The proof. Restore the SUM instead and the diff returns to zero, the lever unlocks, and T. Goh's approval joins the ledger, downstream of the workbook hash, every diff run and every disposition. Replay re-executes the exact diff that justified retirement.

What is real, what is synthetic, and what this does not cover.

The register's eight real rows are parsed from the Enron Spreadsheets and Emails corpus (Hermans & Murphy-Hill), 15,000+ actual corporate spreadsheets recovered from the Enron email archive, published on figshare under CC BY 4.0 and fetched file-by-file via the SheetJS mirror. What ships is a 7KB structural extract with per-file MD5s and source URLs; the binaries stay at the source. The 94% and 60% figures are Panko's published research on spreadsheet error rates and inspection performance, cited as the motivation, while the 100% catch rate is computed live by the shipped engine on the synthetic workbook.

The limits, stated flatly. The Enron workbooks are early-2000s vintage and parsed statically after a LibreOffice conversion; VBA and macros are out of scope, and macro-driven EUCs are often the riskiest, so the register understates exactly the workbooks that scare auditors most. The scoring heuristics are a defensible subset of full EUC frameworks, with fixed weights I chose, and they are a ranking device rather than a certified methodology. The retirement pattern shown covers formula-driven calculation workbooks; data-entry and reporting workbooks need different treatment. And the differ proves value equivalence on the cells the workbook stores, which is the cutover question, but it cannot prove the business logic was right in the first place; it will faithfully reproduce a wrong formula, which is why the memo lists every carried-over constant for owner review after cutover.

Try to sneak the override past it.

Flip the red toggle and watch the human view stay innocent while the differ lights up. Refuse to write an acceptance reason and watch the form hold the line. Take the "fix the micro-app" bait and read what the app admits. Then restore the SUM, unlock the gate, approve the cutover as the named owner, and tamper with the ledger to watch the chain locate the exact entry.