How to use an AI spreadsheet generator without shipping wrong formulas

A wrong spreadsheet is worse than no spreadsheet

The failure mode is silence, not a crash

A broken document announces itself. A broken workbook does not. It opens, the columns line up, the totals are formatted to two decimal places, and the number at the bottom right is off by one month of revenue. Nobody re-derives it, because re-deriving it is the work the spreadsheet was supposed to save. Then it gets attached to an email and becomes the version of the truth everyone quotes.

This is not an AI problem that arrived in 2026. It is the oldest finding in spreadsheet research: errors are rare per cell, near certain in a large model, and very hard for the author to spot. The European Spreadsheet Risks Interest Group keeps a public list of the ones that became newsworthy, which is a small fraction of the ones that happened.

“Errors are extremely difficult to detect and correct.”

Ray Panko, EuSpRIG

Generation changes the economics of that finding rather than the finding itself. You now get a hundred formulas in ninety seconds instead of an afternoon, and you inherit every one of them without having typed a single reference. The only defence that scales is making the workbook prove things about itself.

Live formulas or it did not happen

The first question to ask of any generated sheet is whether the derived cells are formulas or pasted values. A grid of hardcoded numbers is a screenshot with gridlines. Change a price on the inputs sheet and nothing moves, which means nobody can test an assumption, nobody can update next month, and the reviewer has no thread to pull when a total looks wrong. Insist that every derived value carries the formula that produced it.

Write the spreadsheet brief before you generate a cell

Six steps that make review cheap

1. Name the decision, the period, the grain, and the currency.
2. Define every column, including its unit and its type.
3. Declare the known dirt in the source file and the rows to drop.
4. Specify the sheet structure: inputs, model, dashboard, checks.
5. Write the checks you want before you see the numbers.
6. Recalculate, reconcile against the source, then send it.

Say what the workbook is for

“Make a spreadsheet of my sales” produces a table. “Show monthly net revenue by region for Jan 2025 to Jun 2026, in USD, so I can decide which region to staff next” produces a model with a defensible shape. The grain matters as much as the metric: monthly and weekly views of the same data disagree at the boundaries, and a partial final month will quietly look like a collapse.

Define the columns and the dirt

Most wrong sheets are wrong before a formula is written. Say which column is the order date and which is the ship date. Say that amounts are text with a currency symbol and that negatives are in parentheses. Say that the region column contains three spellings of the same place. Say which rows are refunds and whether they should net out or be excluded. Every one of those left unstated is a judgement call the model will make silently.

How OpenCraft actually builds the workbook

A program writes the file, not a text box

There is no “export to Excel” button behind this. When the spreadsheets skill is active, the model writes an actual Python program that builds the workbook with openpyxl and runs it in a sandbox, saving the .xlsx under outputs/. That is why the cells can hold real formulas, number formats, filters, frozen panes, and native charts bound to ranges: the file is constructed as a workbook rather than transcribed as text. The program stays in the workspace, so a fix is an edit and a rerun rather than a regeneration from scratch.

The host recalculates before it publishes

A zero exit code is not a deliverable. Before any file reaches you, the host takes over: it inspects the package to confirm the file really is a workbook and not a renamed something-else, opens it in headless LibreOffice to recalculate every formula, and then reads the recalculated cache back out. Formula cells resolving to #REF!, #DIV/0!, #VALUE! or any other Excel error fail the job. Nothing is published; the cell-level failures go back for repair.

Recalculation costs one thing worth knowing about: LibreOffice drops frozen panes when it re-saves an XLSX. The worksheet view state is captured before recalculation and restored afterwards, so the cached values are real and the header row is still frozen when you open it.

A sheet named Checks is a gate, not a decoration

If the workbook has a sheet named Checks, QA, Validation, or Reconciliation, the host treats every row on it as an assertion: column A a human-readable label, column B a formula with a cached result. A numeric check must equal exactly zero and a boolean check must be TRUE. Anything else — a non-zero difference, a FALSE, a missing cached result, a check with no label, a check sheet with no executable formulas at all — blocks publication. Hardcoding a passing zero is the one way to defeat this, which is why the brief should name the invariants rather than asking for “some checks.”

Finally the host renders a multi-page raster preview from the exact bytes that will be published and shows it back for visual inspection: clipped labels, columns too narrow to read, a chart with no series. Publication is transactional — if the preview or validation fails, none of that job’s files are published, so a half-correct workbook never becomes a download.

Worked example: a messy export becomes a model

The input nobody wants to clean

What a good result looks like

Four sheets. Inputs holds the cleaned rows plus the assumptions — the period boundaries, the region mapping, the refund rule — each in one cell, referenced everywhere else. Model holds named columns and live formulas: a parsed order month, a normalized region, a numeric amount, and a monthly grid built with SUMIFS against the cleaned rows rather than typed totals. Dashboard shows the KPIs, each one a reference to the exact model cell for the exact period named in the brief. Checks carries the assertions.

The chart lives on the dashboard as a native column chart whose series points at the model’s monthly range, with the series named for the measure and the axis carrying “Net revenue (USD)”. Point a chart at a hardcoded list of values instead and it stops moving when the model does — the same failure as a pasted total, one layer further from view.

The cleaning report matters more than the chart. Expect a line saying how many rows were dropped, how many parsed as each date format, how many region values were remapped, and what happened to the 63 “N/A” quantities. If those counts do not add back up to 11,000, something was silently discarded. For a full financial model built the same way — assumptions, roll-forwards, and a reviewed sample workbook — see the AI business plan workflow.

The five-minute pass that catches it

Run these before you forward the file

None of these require you to understand the whole model. Each one takes under a minute and each catches a different class of silent error. Run them in the order below, because a total that does not reconcile makes the rest moot.

Do the last one deliberately: change a single input cell and watch which numbers move. Anything that should have moved and did not is a hardcoded value. Anything that moved and should not have is a reference into the wrong place. That one edit tests the wiring of the entire model in about ten seconds.

When the spreadsheet is the wrong artifact

Use a database or BI tool for anything governed and live

If the number needs a single agreed definition across teams, refreshes on a schedule, respects row-level permissions, keeps an audit trail, or feeds a dashboard from production data, you want a warehouse and a semantic layer, not a generated file. Those are systems engineering problems. A workbook emailed on the first of the month is a snapshot that starts drifting the moment it is sent, and a second recipient with a second copy is how two versions of a metric get born.

The tell is repetition. If you are generating the same workbook every week from the same source, the durable fix is a pipeline that materializes the table and a tool that queries it. Use generation for the analysis that happens once, or for the shape of a model you are still arguing about.

Use a real modelling process when the stakes are financial

A valuation, a covenant calculation, a tax position, a filed return, or a model a lender will underwrite needs more than a passing checks sheet. It needs a named owner, a documented methodology, version control, an independent reviewer who did not build it, and often a professional whose signature carries duty. Generation can produce the structure and do the arithmetic. It cannot hold the accountability.

When the workbook is only the evidence behind a written argument, keep them separate: the checked model in one file, the narrative in another. The AI report workflow covers turning a reconciled workbook into a document whose charts an outsider can audit, and the OpenCraft use-case library has the rest.