Claude for Financial Modeling: Where the LLM Ends and the Model Layer Starts
Claude is one of the best tools a finance person has ever had. Describe a business and it drafts a model in seconds. Paste a messy tab and it works out what the lines mean. Ask why margin moved and it reasons through the drivers better than most analysts. If you build financial models, you have felt this, and it is real.
You have probably also felt the wall. Ten prompts in, the model has quietly drifted. A new session forgets the conventions you set yesterday. One small change costs a large slice of your token budget. The instinct is to blame the prompt or the model. It is neither. You are running into a boundary: the line between what a large language model is built to do and what a financial model needs. This article is about where that line sits, and what belongs on each side of it.
Claude is a brain, not a calculator
A large language model is a reasoning engine. It predicts, it interprets, it drafts. It is probabilistic by design, and that is exactly why it is so good at the messy, human parts of finance: reading an ambiguous input, proposing a structure, explaining a result, writing board-ready commentary. On that side of the line, Claude is extraordinary, and you should lean on it hard.
A financial model is the opposite kind of object. It is deterministic. Revenue equals price times quantity, every time, with no variance. A dependency either holds or it does not. A number traces to its source or it is wrong. This is a calculator's job, not a brain's, and it is precisely where a probabilistic engine struggles.
The mistake almost everyone makes is asking the brain to also be the calculator: to hold the exact arithmetic, remember every linkage, and keep the whole structure straight across a long session. That is not a prompting failure. It is asking the wrong faculty to do the job.
What happens when the LLM does the calculator's job
Point Claude at a raw spreadsheet and ask it to own the whole model, structure and math and memory, and you hit the same three failures every AI-plus-grid setup runs into.
It drifts. A spreadsheet stores results, not logic. The rule "revenue equals price times quantity" exists only as an arrangement of cells, implicit and undocumented. When Claude rewrites cells for a new assumption, the dependency chain can break silently. It does about 80% of the work well, then drifts on the 20% that decides whether the model is right: the linked variables, the propagation, the edge cases. Independent benchmarks put a number on it: the best model on FinSheet-Bench reaches just 82.4% accuracy on financial spreadsheets, and barely 20% on complex aggregation tasks (AI financial model accuracy statistics). (More on this in How to Build a Financial Model with AI That Doesn't Drift.)
It forgets. The structure, the conventions, the reason behind each choice, none of it is written down anywhere the model can reliably read. So each new session re-reads the grid and re-infers what the model means, slightly differently each time. Yesterday's decisions do not carry over.
It burns tokens. A spreadsheet is an opaque grid with no map. To change one thing reliably, Claude re-reads large parts of the file first. The cost tracks the size of your whole model on every turn, not the size of your edit, and you hit the wall fast. (The full mechanism: How to Save Tokens When Building Financial Models with AI.)
None of these are things a better prompt fixes, because the cause is structural. In a spreadsheet, logic and data are fused in the same cells, and the brain is being asked to also be the calculator and the memory. It slips on all three.
The boundary, drawn cleanly
Here is the division of labor that actually works:
- The LLM (Claude) is the brain. It interprets your intent, proposes structure, explains results, drafts narrative, and drives the whole session. It reasons about the model.
- The model layer is the calculator and the memory. It holds named variables, an explicit dependency graph, timeline semantics, and your conventions. It computes deterministically, it persists between sessions, and it stays auditable.
Claude reasons on top of the model layer instead of trying to be it. The brain proposes, the layer holds and computes. Each does what it is built for.
What a model layer gives Claude
Concretely, a model layer replaces the anonymous grid with a real workspace Claude can address and trust. Three things change.
Named variables and an explicit graph
Instead of scanning a range of cells to guess what they mean, Claude addresses "revenue" or "headcount cost" by name, and the relationships between them are explicit. When it changes an assumption, the change propagates through the dependency graph instead of breaking it. Ask "what depends on this?" and the answer comes from the graph, not from a scan. (Why this matters in depth: Why Finance Agents Need a Model Layer, Not Just Spreadsheet Access.)
Conventions written down once
Your sign convention, how you compute working capital, your EBITDA definition, your sector assumptions, these belong in one file the model reads at the start of every session, not rediscovered through correction. Layerz uses an open standard, FINANCE.md: a structured file that encodes your conventions in a format any agent can read before it touches a number. Claude operates inside your rules from the first prompt.
Persistence and a clean export
The structure is versioned and persists, so the next session resumes instead of restarting, and every change has an audit trail. And Excel stays the deliverable: your counterpart, your board, and your auditor all open a standard .xlsx. You build in the structured layer and export a clean, reproducible file on demand. The spreadsheet is a compatibility format on the way out, not the place the logic lives.
In practice, Claude connects to that layer through MCP, so all of this happens inside your normal Claude workflow rather than as a separate app.
What this looks like in practice
The naive workflow: open Claude on a raw spreadsheet, prompt it to build or change the model, watch it edit cells, hit the token wall, and next week start a fresh session where it re-infers the structure from the grid and drifts a little further.
The bounded workflow: Claude reads your FINANCE.md for conventions, connects through MCP to a model layer that holds named variables and an explicit graph, and edits the model by operating on its structure. You change one assumption and it propagates. You ask what depends on a line and get an answer from the graph. The structure persists across sessions. At any point you export a clean Excel file anyone can audit.
Same Claude. Completely different outcome. The difference is not the model. It is whether Claude is reasoning on a model or fighting a grid.
When plain Claude on a spreadsheet is enough
This boundary only matters when the stakes and the horizon are real, and it is worth being honest about when they are not.
For a one-shot task, "read these ten values and write a summary," Claude on a raw spreadsheet is entirely sufficient. It reads, computes, writes, done. For understanding a model you received, asking what a formula does, drafting a sensitivity table, explaining structure, plain Claude is genuinely excellent, and you should use it that way.
The model layer becomes necessary when Claude has to modify the model and respect its logic, work across sessions without rebuilding context each time, honor conventions and not just formulas, and produce output that is defensible to a board or a data room. For anyone building an ongoing model, a budget, a deal model, unit economics, those conditions are almost always present.
The bottom line
Claude is a superb reasoning engine and a poor calculator, and financial modeling needs both. The wall you keep hitting, drift, forgetting, burned tokens, is what happens when you ask the brain to also be the calculator and the memory. Draw the line instead: let Claude reason, and let a model layer hold the structure, the math, and the conventions. Keep Excel as the export. Then Claude stops slipping on the 20% that matters and starts producing models you can actually defend.
If you work in the terminal, the practical setup is in Claude Code for Finance. For the full approach to AI-built models, start with The Right Way to Generate a Financial Model with AI.
Layerz is the finance workspace that gives Claude that model layer. It holds the structure so Claude doesn't have to, keeps your conventions in a FINANCE.md, versions every change, and exports clean Excel anytime, all via MCP. Explore Layerz →
