After interviewing six finance leaders about how they’re actually using AI, one advantage keeps showing up among the most advanced FP&A teams.
It’s speed.
The best finance teams are *massively* compressing the time between something happening in the business and informing the people running that business.
Most teams still find out they missed a number weeks after the fact. The best AI-native FP&A teams are delivering budget versus actuals 1 day after close, and rebuilding forecasts 3 days after close.
AI helps. But the teams pulling this off all have something else in common: clean data, trusted definitions, and systems that let AI work on top of them.
After six interviews, I’ve started to see a pretty clear map of what works, what doesn’t, and what separates the teams experimenting with AI from the ones actually changing how FP&A works.
So instead of an interview this week, I’ve pulled together everything I’ve learned so far.
I’ve grouped this into two sections:
Do’s & Don’ts: all the ‘free lunches’ that AI-forward FP&A teams are doing today…and all the dead ends that you should avoid.
Levels: We’ve seen 3 different levels of AI adoption in FP&A. I talk about what it takes to get to each level, and the outcomes that each level unlocks.
As always, I’ve tried to err on the side of being precise, clear, and hype-free.
Let’s dive in!
Do’s and Don’ts
DO get a Claude Team plan and put every finance person on a seat. A standard seat is twenty dollars a month. The Team plan also means your data isn’t used for model training by default, which you absolutely must do. Literally every person I interviewed is doing this.
DO create shared projects for anything you do every month. Budget versus actuals, reconciliations, board reporting, etc.
Ray Anderson at Claremedica runs a project called Monthly Variance Analysis that carries the output template, the table mappings, the formulas, and a running list of everything that had to be fixed by hand last month.
Austin Hostetler at Alpine Energy loaded every bond document and equipment lease schedule into one, so he can ask about a covenant or an interest date without opening a single PDF.
DO use Claude to write SQL and Python code. Ray’s team regressed two years of historical KPI data against past financial outcomes and built a quantitative forecasting model with a tighter standard deviation than anything else they’d tried, and they did it without hiring a data scientist.
DON’T vibe code. It’s a dead end (for now), at least for anyone who isn’t an engineer. Ashkon Farmand built a working billing engine in a weekend, looked at what it would take to maintain, and went and bought Tabs instead. I have yet to meet a finance team that’s successfully using their own self-built software.
DON’T let anything go out without a human reading it first. Austin asked Claude to fix a three statement model that was out of balance by $19,156, and Claude fixed it by hardcoding $19,156 into the cell. Every person I’ve interviewed carefully reviews *all* AI output before it goes out to a stakeholder.
Those are the easy wins. Every finance team can start doing them tomorrow.
But there’s a ceiling to how far better prompting and Claude Projects can take you. Eventually, the bottleneck stops being the AI and becomes the infrastructure underneath it.
That’s where the levels start to separate.
This game has levels
I’m seeing FP&A teams reach 3 different levels of automation & efficiency.
Most teams are at Level 1: hand feeding inputs to Claude and letting it quickly produce output.
Level 2 is less common. Those teams have a unified data warehouse and semantic layer. This means Claude always has access to all their data (skip the CSV imports and rickety MCPs!), and has human-verified metrics and data dictionaries to make sure outputs stay trustworthy. Outcome: automated inputs, in addition to Claude speed-running outputs.
Level 3 is the rarest of all. These teams have everything that Level 2 has, but also use AI to write Python and SQL that produce monthly reforecasts in just a few hours each month.
And just for fun, I added a Level 4, which automates all reporting and reforecasting, and also crushes annual planning / budgeting down to just a few business days. To be clear: nobody is at Level 4 (yet).
Level 1 - use Claude for reporting
Every finance leader I’ve interviewed is on a Claude Team plan, with projects set up for the work that comes back every month. Their day to day looks like a mix of MCP connections into the systems that have them and a lot of exporting CSVs out of the systems that don’t, and then Excel analysis and HTML dashboards and slide decks coming out the other end.
Everyone should be doing this at a minimum. For twenty dollars a month you can automate a pile of analysis, write genuinely good code, put together board prep, and answer the ad hoc questions that used to eat an analyst’s afternoon. I don’t know of a better return anywhere in the finance stack right now.
Where this gets you: budget versus actuals about five days after close. But reforecasting is still mostly manual (meaning it takes a few weeks of each month), and budgeting is 100% manual (~three months of work).
But Claude is only as useful as the data you can hand it, and in Level 1 you are the one handing it over. Everything Claude touches at Ray Anderson’s company still arrives as a general ledger export out of Sage Intacct, or a scrubbed pull from their internal warehouse, or an Excel file that somebody de-identified before it went in.
The analysis is fast. Getting to the analysis is not. Level 2 solves that problem.
Level 2 - unified data warehouse + semantic layer connected to Claude
Level 2 is everything in Level 1, except the CSV exports and the MCP patchwork are gone, replaced by one unified data warehouse that every system writes into and a semantic layer sitting on top of it that Claude queries through.
A unified data warehouse is when every record from every system lands in one place and stays live. That includes your general ledger, payroll, CRM and whatever operational data you actually run the business on.
The semantic layer does two jobs. The first is deciding that a vendor called AWS in one system and Amazon Web Services in another are the same vendor every single time. The second is holding your definitions, so revenue means one thing and gross profit means one thing, and when a department head asks how many customers you had last month there is one clear answer.
Gusto’s data team spent about a year on theirs, going product by product, defining which field means what, and then set up an MCP into Snowflake that filters every query through it, so anyone in the company can ask a plain English question and it knows where to go.
Where this gets you: budget versus actuals 1 day after close, with the manual steps gone and the recurring work running on a schedule instead of running when somebody remembers. Reforecasting still takes weeks and budgeting still takes three months, because the warehouse changes where the numbers come from and not how the models get built.
The important part here is that there is one dataset and everyone trusts it by default, and you stop spending the first fifteen minutes of every review meeting figuring out why two people brought two different revenue numbers.
But that trust only holds if the mapping is deterministic rather than generative.
Classic software is deterministic, which means you click a button and it does a thing, and if it doesn’t do the thing there’s a bug. Generative means you click a button and you’re not really sure what’s going to come out. Data mapping has to be the first kind. Ray had a budget versus actuals come back saying he was two hundred thousand dollars favorable on a line item, and he knew that wasn’t true. Claude had missed a vendor because the name had a space in the wrong spot. You want it stored as a clean table that doesn’t get rewritten, and you want the probability taken out of it.
Gusto’s revenue models are the opposite, since they’re all Python. There’s no LLM anywhere inside them. They built the Python with Claude, and then Jeff’s team checks the Python. That’s the shape I’d copy. Use AI to build the deterministic thing and don’t let it be the deterministic thing.
At Level 2, you’ve solved the input problem. The data is centralized, clean, and trustworthy.
But you haven’t solved the reforecasting/modeling problem. That’s what Level 3 changes.
Level 3 - unified data warehouse + semantic layer + AI-powered reforecasting (what Gusto built)
Level 3 is everything in Level 2, plus the models themselves move out of spreadsheets.
At Gusto that means the finance code lives in a GitHub repo, the models run as Python inside Streamlit inside Snowflake, and they write their results back into the same database the actuals come from, so the models talk to each other instead of being thirty separate files on thirty separate laptops.
The old version of that job was hitting execute on a query, downloading the CSV, pasting it into a Google Sheet, dragging the formulas across, checking every little number that moved, reforecasting the future periods, and then combining all of it into another sheet that fed everything else. That was about a week of work every month for Jeff’s team. It is now roughly twenty minutes of someone reading the output.
Where this gets you: budget versus actuals 1 day after close, reforecasting and modeling 3 days after close, and budgeting still at three months.
What it costs is people who can read code. Somebody on that team has to look at what Claude wrote and know whether it does the thing they asked for, and that is a different skill from being able to prompt for it. It also helps enormously to be at a company where nobody makes you argue for centralizing the data in the first place (Gusto spent 10 years perfecting their data warehouse, and 1 year building their semantic layer).
When I was a CFO at a tech company there was already a data team and already a warehouse, which made the conversation for adding accounting and payroll data much easier than at a non tech company. At a manufacturer or a services roll up that same conversation starts with whether it’s worth the money and whether anyone in the building knows how.
Level 3 gets you close to the end state for monthly reporting and forecasting.
But there’s still one major missing piece: annual planning.
Level 4 - unified data warehouse + semantic layer + agentic budgeting (tomorrow’s world-class)
I have yet to see anyone improve the timeline on the annual planning process.
What Jeff’s team built is a modeling engine, and modeling is equations, guesses about how things move. Planning and budgeting are the other kind of forecast, the one where you build a table with a name on every vendor and every customer and every employee you expect to have. I’m not convinced the Level 3 setup does that job.
Also, Gusto prefers monthly reforecasting over annual bottoms-up budgeting. Most teams would choose the latter.
The goal here is to get budget versus actuals 1 day after close, reforecasting 1 day after close, and annual planning done inside 2 weeks.
Those two weeks should be coordination with budget owners rather than building templates, mailing them out, and consolidating the backup by hand. I believe it is going to have to come from purpose built software, because the self build path runs into the vibe coding that’s not working and the existing planning tools that are twenty five years old.
We’re building an Agentic Budgeting product at Cashboard that will handle both the modeling and the budgeting, sitting on top of the Level 2 platform that we already offer. Watch this space :)
Speed to insights drives compounding growth
Right now, most department leaders understand their org’s performance late or never find out at all.
They don’t find out that a vendor came in over budget. They don’t find out that a raise landed a quarter earlier than it was planned for. They don’t find out they’re tracking to miss their number until it’s a number they’ve already missed. If you’re finding out about any of that within a month of it happening, you’re doing better than most finance teams I talk to.
The analysis should be automated and pre-scheduled and pointed at the person who owns the number, with a human reading it before it goes out. What stops that happening at most companies is that the data is still sitting in six systems under six different names.
The companies that fix this are going to compound away from the ones that don’t. Speed of reporting and analysis turns into speed of decisions. A multi site operator sees which clinics are drifting on labor cost while there’s still a month to staff differently. A software business catches a pricing change working in one segment and rolls it everywhere before the quarter closes. A roll up finds out that the location it just bought is missing plan in month two rather than month five, when the earnout is already priced.
That’s the entire argument for Level 2. Level 3 is faster and Level 4 is coming, but the difference between finding out in a day and finding out in a month is one unified data warehouse and one set of definitions, and you can start on it now.
What I’m still not sure about
The direction we are heading in feels clear to me: finance is moving toward faster, automated, continuously updated reporting and forecasting.
What’s much less clear is exactly how we get there. Here’s what I don’t know:
Whether anyone can productize what Gusto built. The GitHub repo and the Python models in Streamlit work, and they work well, but you have to be genuinely technical to understand what’s happening in there. Somebody needs to turn that into a thing a finance team can buy, and I’m not sure whether that ends up looking like what Jeff’s team assembled or like something else entirely. I’m also not convinced what they built solves annual planning, because a model built out of equations is a different animal from a table with a name on every vendor and customer and employee you expect to have next year.
Where the SQL people will come from. SQL and Python matter more now than they did five years ago, and at the same time nobody has any reason to learn them. I got good at SQL by writing a hundred thousand bad queries, reading Stack Overflow, and irritating a lot of engineers, and none of that happens anymore because the output isn’t blocked by the education. But Level 3 needs someone who can read what Claude wrote and know whether it does what they asked. I don’t know where that person comes from in five years. Ashkon and I are not a large cohort and the people behind us are thinner on the ground.
When vibe coding gets good enough. I’m confident it isn’t an effective path today for a CFO trying to do any of this, and I’m equally confident that’s a statement with a shelf life. It works right now for engineering teams moving fast, and it does not work for people who can’t audit the output, which is most of finance. I don’t know whether that gap closes in a year or five, but definitely worth keeping an eye on.
Julian Rowlands is the founder and CEO of Cashboard, the AI enablement platform for FP&A. He was previously CFO of Xendit (last valued at $3bn) and Head of Finance at Spruce (exited to Zillow in 2023). You can learn more about Cashboard at www.cashboard.co.
another excellent piece on AI + Finance. would love to see who/when/how a team gets to level 4.
I fully agree with the data warehouse/one source of truth we can plug AI on.
For the rest I feel that the use of Claude still requires a lot of checking for monthly closing that a strong well thought process and excel avoids. For adhoc analysis, however.. a game changer