AI Financial Modeling

A year or two ago, I spent more time wondering whether AI could build a financial model. That's mostly settled now. It can, at least well enough that the more useful questions are what we should ask it to build, what we should give it before it starts, and how we know whether the result is right.

ChatGPT, Claude, Copilot, and specialized tools can write formulas, create forecasts, modify existing workbooks, trace calculations, find errors, and explain why an output changed. Some work directly inside Excel. Others can create a workbook from a prompt. Coding agents can go a step further and build the forecasting application around the calculations.

All of that gets described as AI financial modeling, which makes the category less useful than it sounds. These tools are doing different jobs, and the differences matter if you're deciding whether to start with a spreadsheet, a template, forecasting software, or a custom application.

What is AI financial modeling?

AI financial modeling is the use of AI to create, modify, analyze, or operate a financial model.

That can mean at least four different things:

Approach	What AI does	Where the model lives
AI-generated spreadsheet	Builds a model from instructions	Excel or Google Sheets
AI-assisted spreadsheet	Modifies and analyzes an existing model	Excel or Google Sheets
AI forecasting software	Helps operate a model built into a software product	FP&A or forecasting application
AI-built financial application	Builds the software and financial logic	Custom web or software application

If you ask ChatGPT to build a three-statement model in Excel, you're still using a spreadsheet as the financial model. AI is changing how the spreadsheet gets built. If you use an FP&A application, the financial model is largely defined by the application. AI may make the application easier to use, but you are working within its model and workflow.

If you ask an AI coding agent to build a forecasting application, you're replacing the spreadsheet interface entirely. The underlying financial logic still has to exist somewhere; now it exists in code.

I find it more useful to think about the model underneath these interfaces: the assumptions, relationships, calculations, and checks that describe how the business works financially. AI can help create or operate that model in several different ways. That's also the distinction behind how Hemrock models are built: the spreadsheet is organized around explicit inputs, calculations, and presentation rather than treating the workbook as an undifferentiated set of cells.

Can AI build a financial model?

Yes. Current AI tools can create assumptions, schedules, forecasts, financial statements, and formulas from natural-language instructions. They can also work across multiple worksheets and understand relationships between formulas and assumptions.

ChatGPT for Excel and Google Sheets, for example, can create spreadsheets from scratch, update existing spreadsheets, and explain large multi-tab files with formulas, references, and assumptions. OpenAI also includes reusable Skills for financial modeling and corporate-finance formatting.

Microsoft has taken a similar approach with Copilot in Excel. Copilot can work directly in a workbook, and Microsoft now provides finance Skills for repeatable processes such as building a DCF or three-statement model. Users can also define workbook rules and custom Skills that tell Copilot how a particular modeling process should work.

Wall Street Prep tested four AI financial modeling tools in 2026 by giving each the same assignment it gives analyst trainees: build a fully integrated three-statement model for Apple.

The results are a better description of the current state of AI financial modeling than a feature list. Every tool completed meaningful parts of the assignment, and the strongest tools were considerably faster than a human analyst at getting an initial model together. They also made mistakes: incorrect historical data, hardcoded values that should have been calculated, problems with debt and circularity, and plugs where the statements should have been properly integrated.

That's a more useful description of where AI financial modeling is today than either "AI can build financial models" or "AI can't be trusted with financial models." So I don't spend much time on the yes-or-no question anymore. The more practical question is reliability, and that depends on the task, the tool, and the context the AI has before it starts.

What AI is good at in financial modeling

I find it easier to look at the work rather than the tools. Give an AI a set of assumptions and a description of a business and it can create an initial revenue forecast, expense schedule, hiring plan, cash forecast, or set of financial statements quickly. Inside an existing model, it can extend formulas, add periods, change assumptions, trace references, explain calculations, format outputs, and make targeted changes.

Explanation may be one of the more immediately useful capabilities. It doesn't require the AI to redesign the model; it requires it to understand what is already there. A complicated financial model can require tracing through several worksheets to answer a question like, "Why does cash drop so much in September?" An AI agent that can read the workbook can trace the formulas, identify the assumptions driving the change, and explain the result without requiring the user to manually follow every precedent.

I'm more interested in modification than generation, because most real financial modeling isn't starting from a blank workbook. The company changes pricing, a financing round gets delayed, customers move from monthly to annual billing, hiring gets pushed out, or a debt facility gets added. The modeling work is understanding how that change affects the existing system and modifying the right parts without breaking everything else. That's a different problem from generating a spreadsheet.

Where AI financial models go wrong

There isn't one useful category of "AI error" in a financial model. The failure can happen at several different levels.

The data can be wrong

An AI can put the wrong historical value into the correct cell. This is particularly dangerous because the model may still look perfectly reasonable. Wall Street Prep found this in its testing: some of the strongest tools generated plausible but incorrect historical data.

Giving the AI source documents or structured financial data can reduce this problem. It doesn't eliminate the need to verify the inputs.

The formula can be wrong

A formula can point to the wrong period, omit a component, use the wrong sign, or fail to roll forward correctly. These errors aren't unique to AI. Humans make them constantly. The difference is that an AI can create a large number of formulas very quickly, which means it can also create a large number of mistakes very quickly.

The architecture can be wrong

A workbook can calculate without being a good financial model. Revenue might be hardcoded directly into the income statement instead of driven by an operating forecast. Cash might be used as a plug to force the balance sheet to balance. Assumptions might be embedded inside formulas rather than separated so they can be reviewed and changed.

The output can look right today while making the model difficult to understand or modify tomorrow. I've written more about the design choices behind this in best practices for financial modeling, including separating inputs, calculations, and presentation and treating structure as part of the model rather than decoration.

The business logic can be wrong

Suppose a SaaS company switches new customers from monthly billing to annual contracts paid upfront. Writing a formula for annual billing isn't particularly difficult. The actual modeling question is what annual billing means. When does cash arrive? When is revenue recognized? How does deferred revenue roll? Which customers move to the new terms? Do existing customers stay monthly? How do those decisions flow through cash and the balance sheet? The SaaS modeling guide shows one implementation of those relationships, including separate monthly and annual segments, churn, billing, MRR, and deferred revenue.

An AI can implement those relationships, but the instruction has to contain or imply the relationships first.

The model can be internally correct and still be useless

A perfectly functioning model built on unreasonable assumptions is still a bad model. If churn is wrong, hiring plans are unrealistic, margins don't reflect the business, or the financing assumptions don't make sense, getting every Excel formula right doesn't solve the problem.

This is one reason I think the discussion about AI replacing financial modeling gets muddled. Building formulas is part of financial modeling, but so is deciding what the formulas are supposed to represent.

The hardest part of financial modeling isn't writing formulas

For a long time, a meaningful part of financial modeling skill was knowing how to translate an idea into spreadsheet formulas. AI makes that translation much cheaper.

If I can tell an AI:

Beginning in July, assume all new customers sign twelve-month contracts and pay annually in advance. Existing customers should remain on monthly billing. Recognize revenue monthly over the contract term.

the AI can write the formulas. But notice how much of the model is already contained in the instruction. I've defined the affected customers and the billing terms, separated billing from revenue recognition, and said what happens to existing customers. The formulas implement those decisions.

This is why I think AI changes the value of a financial model template rather than making templates irrelevant. Historically, part of the value of a template was avoiding the work of building every formula yourself, and AI reduces that value considerably. A good model also gives you an architecture: how assumptions are organized, how revenue connects to cash, how the statements interact, how scenarios work, how errors are checked, and where new logic belongs. That part of the value hasn't gone away.

The Standard Financial Model is the broadest example of that approach at Hemrock; for a narrower revenue-only use case, the SaaS Forecasting Tool uses the same idea with much less model around it.

Starting from scratch or starting from a model

There are advantages to asking AI to build a financial model from scratch. You aren't constrained by somebody else's design. The model can reflect the exact business you're describing. And for a relatively simple analysis, generating the workbook may be faster than finding and adapting a template.

The tradeoff is that you're also asking AI to make every architectural decision. It has to decide how the workbook is organized, where assumptions belong, how schedules connect, how statements are integrated, which checks to build, and which conventions to follow.

Starting from an existing model changes the job because the architecture already exists. The AI can spend more of its effort understanding and modifying that architecture rather than inventing one. That doesn't automatically make the result better. A bad starting model is still a bad starting model. And an AI can misunderstand a good one.

It does reduce the amount of the problem that has to be solved at once, and I think it's notable that this is increasingly how the AI products themselves are being designed. OpenAI's spreadsheet Skills are reusable playbooks that can specify workflows, standards, formatting rules, and output structures.

Microsoft's finance Skills serve a similar purpose. Microsoft describes them as a way to guide Copilot through repeatable workflows instead of starting from scratch each time. Custom Skills can specify how a three-statement model or board package should be built.

The models are getting better at financial work while the tools around them are also giving them more explicit instructions about how that work should be done. I don't see those developments as contradictory. Better models still benefit from better context.

Do you still need a financial model template if you have AI?

Sometimes, although I think the reason to use one is changing. If the only value of a template is that it contains formulas you don't want to write yourself, AI makes that template much less valuable. If it captures a useful financial-model architecture, the answer is different.

Instead of deciding between a rigid template and a completely custom model, you can start with an existing architecture and ask AI to adapt it. That can work particularly well when the underlying relationships are common but the implementation varies.

Most SaaS companies, for example, need to model some combination of customers, pricing, churn, revenue, billing, deferred revenue, headcount, operating expenses, cash, and financial statements. The details vary enormously, and those details are exactly where AI can be useful if it understands how the underlying model works.

This is the approach we're taking with Hemrock. The financial model provides the structure and calculation logic; AI can be used to understand, modify, and extend it. The objective isn't to prevent customization. It's to make customization easier without requiring every model to begin with an empty workbook. The Edit with AI guide provides model-specific context and prompts for doing that, while Bring Your Own Model covers the other direction: keeping the base architecture and replacing or adding the parts of the forecast that are unique to the business.

Why AI tools are adding Skills, rules, and context

One of the developments I find most interesting is how much structure the AI vendors are adding around increasingly capable models. OpenAI has added Skills to its spreadsheet products. A Skill can encode a workflow, modeling standard, formatting convention, or expected output. Microsoft has done something similar with Copilot. Finance teams can define Skills for recurring processes and workbook rules for conventions specific to a model.

A prompt is useful for telling an AI what you want right now. It is a poor place to repeatedly explain how your organization builds models, where assumptions belong, how formulas should be formatted, what checks are required, and which parts of a workbook shouldn't change. That information starts to look more like documentation or a specification.

Financial models have always contained some of that context implicitly. A good model has patterns. Similar schedules work similarly. Inputs are treated consistently. Statements follow recognizable relationships. Giving those patterns to AI explicitly makes the model easier for an agent to operate.

I expect this to matter more as AI takes on larger changes. The larger the task, the more conventions and relationships the agent has to infer if they aren't stated somewhere.

Spreadsheet, forecasting software, or AI?

AI changes the spreadsheet-versus-software tradeoff, but it doesn't make the decision disappear.

A spreadsheet still makes sense when the model itself needs to be flexible

Spreadsheets are unusually good at exposing the model. You can see the assumptions, inspect formulas, add a schedule that didn't exist yesterday, and change the structure because the business changed. AI reduces the effort required to make those changes, which may extend the useful life of spreadsheets rather than shorten it.

Forecasting software makes sense when the workflow is the bigger problem

There are companies where creating another formula isn't the problem. Connecting accounting data, managing permissions, collecting department budgets, maintaining versions, approving forecasts, and producing the same reporting package every month are the problem.

A purpose-built FP&A or forecasting application can be much better at those workflows. AI makes those applications easier to use as well, but it doesn't turn a spreadsheet into a workflow-management system.

A custom application makes sense when the model becomes infrastructure

There's also an option that is becoming much more practical: build the application yourself. AI coding tools have dramatically reduced the cost of creating software. A financial model that once would have been distributed as a spreadsheet can now be turned into a web application with inputs, calculations, charts, scenarios, saved data, and user accounts.

That can be the right answer when many people need to use the model but shouldn't be editing its formulas. The tradeoff is that you now own more than a financial model. The calculation logic still has to be specified, tested, and maintained, and you also have application code, data storage, authentication, deployment, and a user interface. AI makes building that system much easier; it doesn't remove those responsibilities.

Can AI replace Excel for financial modeling?

For some modeling tasks, yes. You don't need a spreadsheet to calculate a financial forecast; the same relationships can be represented in Python, JavaScript, a database-backed application, or a dedicated forecasting platform.

But "can the calculations exist somewhere other than Excel?" has never really been the reason Excel remains useful. Excel combines a calculation engine, programming environment, interface, data table, charting tool, and debugging surface in one file that a finance professional can inspect and modify.

AI changes how we interact with that environment. You can describe a change instead of writing the formula cell by cell, ask why an output changed instead of manually tracing several worksheets, or ask an agent to extend a schedule rather than rebuilding it yourself. In many cases that makes Excel easier to use, not obsolete.

The more consequential change, to me, is that the same financial model no longer has to have one interface. You might edit it in a spreadsheet, change assumptions in a browser, query it through natural language, or expose calculations through an API.

At that point, the spreadsheet is one way of interacting with the model rather than the definition of the model itself.

How I would use AI for financial modeling today

I wouldn't give an AI a vague prompt to "build me a financial model" and assume the result is finished. I'd treat it more like working with another modeler, starting with the business logic.

If you're modeling a subscription business, specify how customers are acquired, how pricing works, when customers churn, when they pay, and when revenue is recognized. If those decisions aren't clear, asking AI to write formulas just hides the ambiguity inside the workbook.

When a known architecture fits the problem, I'd use it. That might be an existing company model, a well-designed template, or a model built specifically for the business. The more context the AI has about how the model is supposed to work, the fewer architectural decisions it has to invent. For Hemrock models, the Edit with AI guide is meant to supply exactly that context before the agent starts changing the workbook.

For a substantial change, I'd also ask the AI to explain its plan before making it. OpenAI recommends telling ChatGPT what must be preserved and asking it to plan larger workbook changes before editing. Microsoft's Copilot similarly supports a planning step that can show which worksheets, ranges, formulas, and assumptions it intends to change.

That is useful even if you could make the edit yourself. It gives you a chance to catch a misunderstanding before it spreads across the workbook.

After the change, recalculate the model and review the outputs as a financial model, not just as a spreadsheet. Did cash move when it should? Does the balance sheet balance? Does revenue respond correctly to the operating assumptions? Are cash receipts different from recognized revenue where they should be? Did anything outside the intended area change? Most importantly, does the result make sense?

Can you trust an AI-generated financial model?

Not without checking it, although that isn't unique to AI-generated models. I wouldn't trust an important financial model built by a person without checking it either. AI does change the speed: it can produce a large, polished model quickly, and polish can make completeness look like correctness.

Verification should happen at several levels. The financial statements should reconcile. Cash should roll correctly. Balance-sheet relationships should work. Formulas should be present where formulas are expected. Assumptions should be explicit rather than hidden inside calculations.

Changes should also be tested against the instruction that caused them. If the task was to change billing terms only for new customers, confirm that existing customers didn't change. If the task was to add debt, confirm the debt schedule, interest expense, cash flow, and balance sheet all respond correctly.

Finally, review the economic result. A model can pass every mechanical check and still describe the business badly. Faster construction doesn't remove that review; it just changes how much of your time needs to be spent on construction versus verification.

Where financial modeling is going

I don't think financial models are going away. I do think the distinction between the model and the spreadsheet is becoming more obvious.

The model is the set of financial relationships: how customers create revenue, how hiring creates expenses, how invoices create cash and receivables, how capital expenditures create assets and depreciation, how financing affects cash and the balance sheet.

A spreadsheet is one way to represent those relationships. Increasingly, it can also be one interface to them. The same model can be edited in a spreadsheet, queried in natural language, exposed through an API, or put behind a web application.

That changes a lot about how financial models are built and used. It doesn't change the need to decide what the relationships should be and to know whether they're working correctly. That's the part I still think of as financial modeling.