The Budget

What you’re looking at

Tidewell Coffee Co. is a coffee chain Claude Code made up, and it’s building a new app: order ahead, pay at the counter, collect rewards. It’s October 2026, six months into a twelve-month project. In March the steering committee approved $1.925 million. $827,000 is spent, and the forecast says the project will land at $1.871 million.

This is the project’s budget as an Excel workbook of nine sheets: a cover, a dashboard, a report by cost line and a monthly view for the people who read it; three sheets of inputs; one sheet with every calculation; and one with the checks the workbook runs on itself. It holds 3,303 formulas and not a single typed-in result. Every number on the dashboard comes from the inputs and the 64 bookings on the Actuals sheet, through a chain of formulas you can follow. Click a number above and its formula appears at the top. Click a reference in the formula and you’re there.

I wrote in my prompt that most people have never seen a really well-built spreadsheet, let alone one an AI made. So here’s the one Claude Code made, and you don’t need Excel to look inside it.

Talk it through, then have it built

You no longer have to spend days building a custom spreadsheet, or find a template that comes close and spend more days making it yours. Talk it through with an AI first, until what you need is fully specified: who reads the budget, what they decide with it, which numbers you know and which you’re guessing, what it has to answer every month. Then have it build exactly that.

I skipped the talking for this one. My prompt said “Don’t ask me questions”, because this budget was meant to show what Claude Code can do, not to run a real project. So Claude Code guessed: the company, the project, every number. For a budget you’ll actually use, let the AI ask its questions first.

I built this in Claude Code, but Claude Cowork or a chat with Claude could build it too, and ChatGPT and other models can do similar things. As far as I know, Microsoft’s own Copilot isn’t quite as strong in Excel yet. If it hasn’t caught up already, I think it will. For a budget at work, start with the assistant your company approved.

It’s a model, so change it

The four buttons above the sheet each change one input cell, the way you’d do it in Excel, and the whole workbook recalculates in your browser. Try them on the Dashboard:

• The build slips a month. One more month of the whole team costs $187,000. The forecast jumps to $2.06 million, past the approved budget, the launch moves to February, and the status turns red.
• Approve the gift cards. The one change request still waiting for a decision costs $46,000. Approve it and $8,000 is left of the contingency, the reserve set aside for surprises.
• Contractors charge 10% more. Three of the eight roles are contractors on day rates. Their rise eats all but $17,000 of the contingency.
• Close October before its costs are in. This one looks like good news: the forecast drops by $187,000, because October now counts as done and nothing was booked for it. But one of the workbook’s checks fails, and the dashboard says so in red.

Or select any blue cell, on the Inputs, Purchases or Actuals sheet, and type your own number.

Built to good spreadsheet practice

My prompt asked for the best practices of good spreadsheet design. Here’s what that turned into:

• Inputs, calculations and results live on separate sheets. Inputs are in blue, assumptions on a yellow background, and they’re the only cells that aren’t locked. Every formula is protected, without a password, so nobody overwrites one by accident.
• One timeline everywhere. Every month-by-month sheet has the same 15 months in the same columns, so column K always means September 2026.
• One formula per row. Each row uses the same formula for every month. There’s no hand-edited exception in the middle, which is the most common way a spreadsheet goes quietly wrong.
• The approved plan stays as it was. Today’s plan sits beside it in its own columns, and every difference is highlighted. Edit the approved plan anyway and a check fails.
• The actuals look like a finance system’s export. One row per booking: invoices, staff costs charged to the project, costs booked before their invoice arrives, and credits. Next month you paste the new rows at the bottom, move “Actuals through” to the new month, and everything follows.
• It checks itself. Fourteen checks: every booking has a known cost line, every closed month has actuals, the report adds up to the months, no purchase falls outside its phase, the plan fits the timeline. The result shows on the cover and the dashboard.
• It explains itself. The cover says what the workbook is for, how to update it each month, what each sheet does, what the colours mean and what changed in each version. Every assumption says where it came from.
• It prints. Every sheet is set up to print on A4, one page wide, and the long ones repeat their headings on every page.

Charts only where they answer something

My prompt said visualizations only where they help someone understand the budget or make a decision. There are three, all on the Dashboard:

• Cumulative spend answers “are we on track, and where will we land?” The approved plan in grey, actuals plus forecast in blue, the forecast months shaded, the approved budget as a dashed line on top.
• What moves the forecast answers “why?” The six cost lines furthest from their budget, largest first, plus everything else. The two approved change requests and an extra Android contractor explain most of what has used up the contingency.
• Contingency answers “how much room is left?” Of the $178,000 reserve, approved changes took $59,500, overruns about $64,000, and about $54,000 is left.

The chart colours passed a colour-blindness check, and every bar carries its number, so colour is never the only clue. The rest of the dashboard is numbers, because a single number doesn’t need a chart: six key figures at the top, and a box with the figures to bring to the next steering committee. One of them: the contingency left pays for 0.3 months of delay.

The workbook disagrees with itself

The forecast is built bottom-up: today’s team, rates and plan for every month still to come. It says the project lands $54,000 inside its budget.

The Report sheet then asks a second question: how much of the planned work has actually been done for the money spent? (Project controllers call this earned value.) The engineering lead estimates the build at 50% done. By that measure, the first six months delivered 86 cents of planned work for every dollar. If the rest of the project goes the same way, it lands at $2.1 million, $171,000 over the approved budget.

Claude Code put both on the dashboard. One says the project is fine. The other says it isn’t, if the rest goes like the first six months. A steering committee would want to know which to believe, and why.

How it was made

Claude Code wrote the workbook as code: a Python script lays out every sheet and writes every formula, and the made-up company’s data sits in a separate file, from the day rates to the 64 bookings. LibreOffice, a free office suite, then opens the file and calculates it.

The first thing to get right was the story. In the first draft of the numbers, the project was already $108,000 over its approved budget: the build had slipped a month, and a month of this team costs $187,000. Claude Code judged that too dramatic for a project halfway through, so it put the schedule back on time and made the slip one of the what-if buttons.

A formula that points at the wrong row still gives a plausible number. So the same budget is computed a second time in plain Python, and if a single total or cost line differs, the build stops. It also stops when any cell shows an error or one of the workbook’s own checks fails.

Then Claude Code turned every sheet into an image and looked at it, over several rounds. That found problems you only see by looking:

• The forecast shading was missing from the spend chart. LibreOffice didn’t draw anything placed on the chart’s hidden second scale, so the shading now sits on the main one, as tall as the approved budget.
• The bar labels showed raw numbers like 59,500 and a stray dash for every zero: LibreOffice ignored the labels’ own number format until the file said explicitly not to copy it from the data.
• One label collided with its neighbour: the label on the only bar that goes left ran into the cost line’s name. An invisible bar now keeps room for it. That fix then hid the wrong entry in the legend, because LibreOffice seems to count the entries from the other end. The invisible bar now sits in the middle, which is the same entry whichever end you count from.
• Text spilled out of its cells, labels were cut off, and column headings overlapped.

Last, it checked the file against the specification of the Excel format. Every part of it passes.

The viewer on this page

What you see above is the workbook itself: its own cells and formulas. This page can’t run Excel, so Claude Code also wrote a small calculation engine for it: it reads the workbook’s formulas and works them out with the same 23 functions, following the rules spreadsheets use for blanks, text and dates. A test compares all 3,303 results, and the text every cell shows, with LibreOffice’s, then the results again for four sets of changed inputs. They all match.

The charts are the one thing the page draws itself, from the same cells, colours and number formats. Excel and LibreOffice draw their own from the file, so there they may look a little different.

What isn’t perfect

• Excel: nothing to fix. Excel doesn’t run where Claude Code works, so Claude Code’s checks and pictures ran in LibreOffice. I opened the first version in Excel and found nothing wrong. The Google Sheets fixes below came after that.
• Google Sheets: one fix, not rechecked. In Google Sheets, the first check failed. Its formula added up the bookings for every cost line in one go, and Google Sheets doesn’t work that formula out the way Excel does. Claude Code replaced it with one plain formula per cost line. To be safe, it also rewrote the colour rules and two dropdown lists that relied on named cells, which Google Sheets handles differently. Nobody has opened the fixed version in Google Sheets yet.
• Apple Numbers: not checked. It opens Excel files, but may drop the print setup, the protection and parts of the chart formatting.
• The timeline has 15 months. A slip of more than three months runs past it. A check says so, but adding months means adding columns by hand.
• The second opinion is only as good as its estimate. “Build 50% done” is the engineering lead’s judgment, and every earned-value number depends on it.
• The protection is a trade-off. It stops accidents and annoys anyone who wants to rearrange things. Review > Unprotect Sheet, no password.
• Every number is made up. The rates and costs are plausible, not market data.
• It’s in English only, on all three language versions of this page.

What you can learn from this

• Make “no typed-in results” a rule, and test it. Change an input and watch whether the total moves. If it doesn’t, someone typed it in.
• Ask for checks. A workbook that tells you when it’s broken catches mistakes you’d otherwise only find by auditing it, and an AI can write the checks as easily as the formulas.
• For every chart, ask which decision it helps with. If nobody can say, leave it out.
• Follow a number back to where it comes from, the way the viewer above lets you. That’s how you review a workbook, whoever built it.