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.

I got off this call and thought, I have just seen the future.

But I want to be careful here because I started this series to push back against AI hype. My whole complaint about AI content is that somebody stands on a stage, says the word “transformative” nine times, and every CFO in the room is sitting there thinking but what button do I press? What’s actually worked for someone?

So let me be specific about what I mean.

Jeff Cobourn leads product and go-to-market finance at Gusto. His team owns 30-plus revenue models across 40-plus products. A year ago, he scored his team’s automation at zero. Six months ago, still zero. Today, close to 80%. Their monthly forecasts are moving out of Google Sheets into Python.

Business partner meetings start at the problem solving. Actuals populate automatically from Snowflake, models automatically reforecast, an agent drafts the performance commentary and a human reviews it, and the partner has read both before anyone gets on the call.

His team is within weeks of having granular reforecasts produced one day after accounting close. The monthly grind behind that, hitting execute on a query, downloading the CSV, pasting it into a sheet, dragging formulas, re-forecasting the future periods, is something a lot of companies can’t do at all at this level of detail. At Gusto it used to take a week. Now it can be a few minutes of human review.

So when I say I saw the future, it’s because of the outcomes Jeff has achieved. They have every record from every system landing in one warehouse. They spent a year tying data labels to a single master meaning. They put their finance code in GitHub, which solves a coordination problem around individual Claude workstreams on different people’s computers that most teams haven’t even noticed they have yet. And they have speed to insight, because the day after the books close, every operator knows exactly what happened in their business.

This was a fun one. I talk to CFOs about AI 50 hours a week and Jeff’s team is doing things I’ve never heard anyone else talk about. Let’s get to it.

If you only read one thing, my top 5 highlights

• Zero to 80% in six months. It started with monthly hackathons, OpenAI one month, Anthropic the next, Cursor after that. A full day, teams competing, just building things. Gusto’s team spent a year experimenting before any of it turned into production work, and then automated ~80% of their FP&A tasks in just six months.

• Spreadsheets have earned eternal peace. They’re calling it Project SHEEP. Gusto’s revenue models are moving out of Google Sheets and fully into Python that runs in Streamlit inside Snowflake, writing back to a shared finance data table where the models talk to each other. A week of work becomes twenty minutes of review. Forecast delivery can move from five days after accounting close to one.

• The agents that check the work matter more than the agents that write it. Vibe-coding a model gets you 80% fast, and the last 20% is where the time goes, because you no longer know every cell. You didn’t build every cell. So Jeff built an agent that scores a model, flags could be wrong, and renders every calculation as a flowchart that is easy to understand visually.

• Their finance team runs version control through GitHub. If everyone on your team is building with AI, all that work ends up scattered across individual desktops. Gusto put their finance code in a shared repo instead, so every tool the team has ever built sits in one place everyone can reach.

• None of it works without the data foundation underneath it. The semantic layer took many months of unglamorous work with Gusto’s data team, defining canonical fields one product at a time, so that “how many customers did we have last month” resolves the same way for everyone who asks. That sits on top of a unified warehouse that colocates all of it, which has probably been evolving for the better part of a decade. The AI work of the last six months is the visible part of a much longer build.

Jeff’s path, and what he owns

Julian: Let’s start with your background and your career path.

Jeff: I’m from Toronto. I started my career in traditional finance, found myself investing in software companies in San Francisco, and then realized I should go learn what it’s actually like to build one. I joined Gusto about eight and a half years ago.

My focus has always been how we accelerate revenue growth. My team covers both product and go-to-market. We help think about what products we build, in what order, for whom, how we price them, how we get them into customers’ hands, how we resource the teams, how we think about ROI across teams. Tactically, we own all the revenue models. We’ve got 40-plus products, so we maintain 30-plus revenue models.

It looks and feels more like a product finance team than a traditional FP&A team. We spend a little time on cost, but it’s much more business cases, unit economics over time, program economics, and R&D investment, helping our leadership make resource allocation decisions.

Julian: Before we get into systems, what’s the technical baseline on your team?

Jeff: A core skill set on the team was always SQL. Everyone on my team knows SQL. We had to be able to go write and edit queries so that we didn’t have to wait on the data team.

And we’ve got some people on our team who came from GitHub’s finance team, so they already knew how it all worked. I think that helped.

The stack

Julian: I always like to ask about data systems. Where the data you care about lives, and what the tooling is, before we even get to the AI piece.

Jeff: Snowflake is where the warehouse sits. That’s our primary tool, and the source of truth for historicals, meaning all actual data. A year ago we were using Redash a lot, but we’ve since moved pretty heavily into Streamlit apps within Snowflake. That’s where we’re primarily building dashboards, data visualization, and now all our financial models.

We’ve got NetSuite, which flows one way into Snowflake. We use Pigment on the cost side, and that’s really the source of truth for cost forecasting. Pigment and Snowflake are two-way. Snowflake feeds Pigment, and Pigment feeds back. We send GL lines over, and we feed operational metrics into Pigment to run ratios on teams and staffing. For cost detail that isn’t in Snowflake, we just use the Pigment MCP.

Sales CRM and payroll flow into Snowflake too.

Julian: And what were Redash and Streamlit doing? I used to do data warehouse work for hedge funds, and that job was made obsolete by ChatGPT 3.5. I was the stable keeper and now they have cars. But I don’t know these tools.

Jeff: Redash is basically how we queried our tables. That’s how we got data out of Snowflake and into a CSV. We did a lot of visualization and charting there, and in Tableau, and that’s all moving into Streamlit now.

Streamlit is an application layer within Snowflake where you can build dashboards and build models. It also lets us write back into Snowflake. So there’s a daily update on daily data, and read and write. That’s where all our revenue models are now, so they’re instantly updated and automatically forecasted.

For anything the team builds, the code lives in a repo in GitHub, and we keep performance commentary and monthly context for every product in Notion.

Julian: How are you handling data mapping and master data management?

Jeff: We already had a unified data warehouse, and then we spent about the last year working with our data team creating a semantic layer of definitions. This is the field to use for customers. This is the field to use for this product’s ARR. This is the field, and this is the definition.

It’s been a lot of work over the last year building that layer on top, just to point people to the right data fields. Our data team set up an MCP into Snowflake that filters through the semantic layer, so anyone in the company can ask “how many customers did we have last month” and it knows to go through the semantic layer and pull the right data field. Huge kudos to our data team to enable this - we wouldn’t be here without them.

That’s how my team interacts with Snowflake, through the semantic layer. There’s a lot of work to set up all those definitions and go one by one by one through each of the products.

A year of hackathons

Julian: I’d love to hear about your journey with AI.

Jeff: About a year ago, as a team, we started doing monthly hackathons. We brought in OpenAI, we brought in Anthropic, we brought in Cursor. A full day working with a particular vendor, teams set up, a bit of a competition, just seeing what we could build. From a year ago we were really trying to push the envelope, or at least try lots of new solutions and rethink how we work.

Heading into January this year we were using a bunch of new tools, and then we got our hands on Claude. The immediate thing was the proliferation of dashboarding and visualization. Our ability to get to insight went from weeks to a minute. Access the data we wanted, run all sorts of slices, create dashboards.

Hosting was the challenge for a while. This was before artifacts really existed, and then there was a size limit on them. So we used a combination of Google Apps Script, Switchboard, and now Streamlit, which has become the big one for us.

Two or three months in, it was part of our every day. Something like 70% of everyone’s time on my team was working with Claude, creating dashboards. That’s how we made planning artifacts. We used it for board decks. We were writing HTML decks and communicating through pull requests in GitHub, which is how we did version control. By March or April, that was a genuinely new way of working.

Then we said, this has been amazing for personal productivity, we’ve stopped moving pixels on Google Slides, and we’re working our way out of spreadsheets. Now let’s capture the big work streams.

Project SHEEP (Spreadsheets Have Earned Eternal Peace)

Jeff: So for the last three months we’ve been focused on one thing. How do we move our revenue models out of spreadsheets. The project is called Project SHEEP, which stands for Spreadsheets Have Earned Eternal Peace - credit to the team leading the project who coined this.

We spent three months proving we can read and write into Snowflake, that we can replace what we were doing in Google Sheets, and that we can move all of our revenue model infrastructure into Streamlit.

The old workflow was hit execute on a query in Redash, download a CSV, copy and paste the data into a revenue model in Google Sheets, drag the formulas across, check all the little numbers that changed, then re-forecast the future periods. Then we used another google sheet to combine all outputs from these models into a consolidated view, which fed other reporting infrastructure. That was about a week of work for the team. Now it’s roughly twenty minutes of human-in-the-loop review.

The models are all just Python code. There are no LLMs in them. We built the Python with Claude.

Julian: What’s the time saving been, the number of days it used to take per month versus now?

Jeff: We used to deliver our forecast every month on business day 10. We’re aiming for business day 5 to be fully done with all revenue forecasts.

Julian: And are the historicals ready to go on day one? Is that half the time saving, or is that actually most of it?

Jeff: Accounting close moved from business day 7 to business day 4. My team will get down to accounting close plus one. So one day after close, we’ll have it.

Julian: So it was close plus three, and now it’s close plus one.

Jeff: Close plus three, yes.

Julian: 3x faster, for a business your size, is completely bananas.

Jeff: It’s remarkable just to hear my team talk about it. The aha moment of, oh my god, this thing that used to take me a couple of days takes a couple of minutes.

How the numbers get to people

Julian: How do you get the right data to the right people at the right time? My experience with finance business partnering is that you can write to a dashboard, but people don’t always look at the dashboard.

Jeff: Everyone on my team owns different revenue models and products, and they’ve got a workflow. The models now have performance versus actuals populated automatically, because it’s all coming from Snowflake. There’s about 20 different performance reviews across our 30 or so models and 40-plus products.

The performance commentary is automated with an agent that spins up, writes the commentary, a human reviews it, and it writes into Notion. Then that can be sent over Slack to the business partner. By the time they have their meeting, they’ve already reviewed the actuals and the commentary, so the meeting is just problem-solving.

Julian: And the agent is a plugin? Is it another company’s, or did you write your own?

Jeff: We made our own Claude plugin that sits in our team’s Claude Code marketplace. We’re training that agent all the time on what to focus on and what to dig into. I think of a plugin as a shared skill, so my team can leverage it the same way.

The hard part moved to the back end

Julian: What have you had to babysit, or double-check, or that’s been harder than you expected?

Jeff: The work has flipped. The first 80% is easy, and the last 20% is where everything is. It’s a common thing people say about AI now.

When you used to build a model, you were in every cell, every formula. You knew it. There was less to scrub, because you’d built it. Now the work has shifted to the back end, and there are a lot of iteration cycles to get comfortable with a model.

So we built another plugin that my team can run on their models any time. It deploys 8 agents to complete tasks that you would otherwise do in an excel workbook manually but with the power of AI. So this includes sensitizing every assumption, visualizing trends in line charts, highlighting what’s wrong and what to fix, and creating a flowchart map of the entire model, so you can see every calculation in a flowchart.

Julian: The flowchart thing caught my ear. The thing that sucks about models is all the nested functions. You’re saying you’ve built flowcharts that show the whole thing?

Jeff: Think about trace dependents in Excel. What this agent does is create a visual flowchart where each node is a calculation. It shows the calculation and the dependency downstream. You can click any endpoint in the financial model, revenue for a given product, and it shows you every calculation visually that feeds into it.

So what trace dependents does in Excel, this is that to the hundredth degree, in richness and in power, to quickly see what calculations are actually feeding a given output.

Julian: Those big blue arrows in Excel do not get you very far.

Jeff: Right. Now it’s a beautiful flowchart with little dots flowing between the boxes. It’s amazing. It delivers one of those aha moments when you look back at what you used to view as work and now view as toil.

Where operators feed the model

Julian: Forecasting is the scariest spot for me. Reporting and analysis, if you have all the data and the labels match, is just math. But modeling and forecasting are formulas creating numbers rather than typing in what someone’s going to pay you. Are you getting it right every single time?

Jeff: It’s all Python. There’s no LLM in it, it’s all deterministic, and we check the Python code. Who’s more likely to make a mistake, Python or a human with a fast, angry formula? That’s what we’re up against. I feel really good that the Python code is right, and that it’s doing what we want, because of the architecture we’ve put around it to check it and understand it. Python has long been a language for financial models, but the difference is that we didn’t need a team of engineers to build and maintain it - everyone on our team is writing Python with Claude.

Then there’s how we set the team up for what we call lifts, or initiatives. Team A wants to go do something, and in January it’s going to cause a 1% lift on a conversion rate. How do you put that in? So our models let an operator go in and say, I’m doing this initiative, I think it’ll do 1% conversion in January and ramp from there, tell me the impact. The model does that for them live. Then they can add it, and it goes into a queue for the finance person to review what the operator put in as an initiative. We talk about it, maybe have a conversation, and then it gets built into the model.

So across all the assumptions, there are opportunities to layer in additional lifts for given initiatives, so that our models tie to our operations.

Julian: It sounds like it’s been smooth. Nothing has broken that didn’t get caught?

Jeff: Not yet. To be fair, we proved read and write for all our models in Streamlit last week. Everything is mechanically sound. We’re spending this month doing all the audits and checks, and then we migrate next month. The goal is to delete our spreadsheets next month. That’ll be the moment. We haven’t done it yet. Right now we’re running Google Sheets and Python in parallel.

Julian: Did you ever feed the old models in as context for the Python that was replacing them?

Jeff: For sure, where there were models we felt good about the logic on. Where there were ones we’d been wanting to improve or re-architect, we took that opportunity instead. You can feed them in and it’s worked pretty well. But it gets you 80% of the way there. The long tail of getting to 100% confidence takes time.

The holy grail

Julian: Where do you want to get to?

Jeff: The near-term objective is that all of our recurring processes are 99% automated, and my team spends 100% of our time adding value. Solving problems, looking around the corner, highlighting risks and opportunities, catalyzing change and supporting the problem-solving with our leaders. All the recurring workflows, the model updates, the performance updates, the board decks, 99% automated.

Julian: Where were you on percentage automated a year ago? Six months ago? Now?

Jeff: Zero. Zero. 80%.

What I took away

Everyone should be sprinting at the semantic layer + unified data warehouse

I got genuinely excited when every CFO became obsessed with Claude, because it made the semantic layer + unified data warehouse so important, and at Cashboard we have spent years building one.

The reason Gusto could switch on Claude and have it work is that there was nothing left to assemble and no ambiguity about what anything meant. Every record from every system was already landing in one unified data warehouse, and every label was already tied to a single master definition. Everything that came after was still real work. But it was work they could start immediately, instead of after multiple years of heavy data engineering work.

If you’re at a mid-market company with no semantic layer and data warehouse, that’s the thing to sprint at. It’s the free lunch sitting right there. There are two ways to get it.

The Gusto path is to hire data engineers, wire up your integrations through something like Fivetran, stand up a Snowflake or BigQuery warehouse, and pipe everything in. Then write and maintain the scripts that match all your data labels together. That last part never ends, because there’s a new vendor or employee or customer or GL line every single day, and every one of them sends you back to engineering.

Or you can use Cashboard and have it in a couple of weeks. Every transaction and datapoint in a single unified data warehouse that’s always live. When a new label shows up, the humans get alerted, AI has a suggestion, and someone approves it with a click. No ticket to engineering.

Either way, that is the work. Everything else in this piece sits on top of it.

Faster FP&A compounds into company value

When I was a CFO, I sometimes found out three months later that we had a hole in the balance sheet. Three months of decisions made on a picture that was already wrong. Gusto’s leaders find out the day after close.

Every department leader gets granular detail on their own business immediately. Add a hundred more leaders and a thousand more employees and every one of them still gets their own snapshot, because of how it’s built. They see a bad trend the day it starts and can change something that day. They see a good one and double down while it’s still happening.

That’s hard to put in a business case, which is one of the perpetual frustrations of selling what I sell. But it compounds. Their competitors might grow 2x over a couple of years while they grow 10x, because of better decision making.

Gusto was at zero a year ago. There’s no better time than now to start.

About Jeff & Julian

Jeff Cobourn leads product and go-to-market finance at Gusto, where his team helps leaders make decisions to accelerate the business.

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.

Interviews with CFOs about AI is an interview series by Cashboard. We speak with finance leaders who use AI in their day-to-day work, and ask them really detailed questions about their setup.

If you’re a finance leader building with AI, we’d love to interview you! Email julian.rowlands@cashboard.co with a quick summary of what you’ve used AI to accomplish, and we’ll get a call booked.

Austin Hostetler recently used Claude to turn a Nordic bond term sheet into a working compliance model in about 15 minutes.

Then he used it to review the financial model going to Alpine Energy Services’ investment bankers and predict the questions they were likely to ask.

Austin is the Head of Finance at Alpine, a fast-growing hydraulic fracturing company that recently doubled in size, is preparing for additional fleet growth, and is now reporting to public bond investors.

The finance team is lean. Reporting and compliance requirements are not.

Austin has equipment leases, a Nordic bond with its own covenants and reporting requirements, a growing accounting operation, and an Excel model that needs to keep up with it all.

So he has started using Claude as a finance associate who remembers every loan document, reviews every model, and never gets tired of being asked a dumb question.

Usually, it works extremely well.

But once, Austin asked Claude to fix a three-statement model that was out of balance by $19,156. Claude solved it… by hardcoding $19,156 into the cell in question.

(My joke to Austin: wow, that’s the AGI moment. Every human CFO has done that too!)

And that’s the tension at the center of Austin’s AI setup: Claude can do in minutes what used to take a finance team hours, but only if someone who actually understands the work is watching the outputs.

With that, let’s dive in!

If you only read one thing: the top 5 highlights from my conversation with Austin

• A Claude Project can become the institutional memory for your debt documents. Austin loaded Alpine’s bond documents and equipment lease schedules into one Project. He can now ask about covenants, interest dates, reporting requirements, or individual lease terms without searching through hundreds of pages.

• Claude built Alpine’s debt compliance-reporting model in about 15 minutes. Austin gave the Excel plug-in the bond term sheet, sample reports, and access to Alpine’s financial model. It created a quarterly reporting tab with leverage, liquidity, and covenant-headroom calculations. Austin estimates the first draft would have taken him hours.

• AI is especially useful before high-stakes finance meetings. Before sending forecasts and financials to Alpine’s investment bankers, board members, and executive team, Austin had Claude review the model for errors and generate the questions that were likely to be asked. This helped Austin quickly run scenarios that drove Alpine’s decision-making around capital structure, capex decisions, and fleet timing.

• The QuickBooks connector is turning Claude into an accounting operator. Alpine is testing workflows where Claude reads billing spreadsheets, creates customers, builds invoices with multiple line items, and prepares month-end journal entries. Humans still approve every action before anything is written.

• Never trust a Claude-authored financial model just because it balances. When Austin asked Claude to fix a $19,156 difference between cash on the balance sheet and cash on the cash flow statement, Claude solved it by hardcoding in $19,156. The output looked perfect, but the logic was broken.

Running finance for a company that keeps adding fleets

Julian: Before we get into AI, give us some context on Alpine Energy and what the finance function is dealing with right now.

Austin: Alpine is growing quickly. We launched another fracking fleet recently, and we are already looking at multiple opportunities to build more. At least one of those could happen by January 1.

Each fleet means more equipment, more financing, more employees, more operational data, and more reporting.

We also recently completed a Nordic bond offering, so now we have quarterly reporting requirements, compliance certificates, interest-payment dates, and covenants that we need to stay on top of.

We are still running a lean finance and accounting team. I am hiring a finance associate now, and we will probably add accounting headcount as we grow. But the goal is to use technology to keep the team as efficient as possible.

Julian: You used Claude to help create the test for the new finance associate, right?

Austin: Yeah. Someone can tell you they are good at three-statement modeling, but you are taking their word for it.

Claude helped me create two tests. One is a simple LBO model. The other is a three-statement accounting model with intentional errors that the candidate needs to find.

We are also asking the candidate to screen-record the test so we can see how they work through it. But they aren’t allowed to use AI to solve it – I need proof that they understand financial modeling completely.

Alpine’s finance and data stack

Julian: What does Alpine’s finance tech stack look like?

Austin: QuickBooks Enterprise is our accounting system. Paycom is payroll. We use Cashboard for FP&A, analytics, reporting, and fleet-level financials.

I’m very involved in our three-statement model, forecasting, budgeting, and financing scenarios.

We recently moved our corporate cards and expense management to Ramp, which has been a huge upgrade from what we were using before.

Operationally, a lot of our field data lives in FieldPro. That includes pumping hours, inventory, consumables, maintenance data, and other KPIs.

We also track job updates in Slack. Each fleet has stage-by-stage updates, including maintenance issues and operating activity.

On the AI side, Claude is our main tool. It started with a couple of other people and me, and now we are trying to spread it across more of the company.

The finance associate who remembers every loan document

Julian: What was the first big win that you got from Claude?

Austin: Debt compliance. We have several equipment lease schedules with lenders. Each one has different terms, payment amounts, and reporting dates. Then we have the Nordic bond documents, which contain the covenants and reporting requirements for the bond.

Without Claude, it would take me so much time to create and deliver all the required reporting.

But Claude solved all of that. First, I put all of those documents into a Claude Project. Now it is almost like having a finance associate or legal person who remembers every word of every financing document we have.

I can ask when an interest payment is due, what reporting we need to provide, how a covenant is calculated, or what the terms are on a specific lease. I do not need to open five PDFs and start hitting Control-F. I also had it build a calendar with all the important dates across the documents.

Julian: I love using Claude to find things that are buried in a document. AI isn’t wise, but it’s amazing at ingesting information.

Austin: Exactly. You still need to verify important things, but it gets you to the right section much faster. It is also helpful because you can ask the dumb question you might be hesitant to ask someone else. That applies more broadly to AI. You can advance faster because you have somewhere to ask basic accounting, finance, legal, or modeling questions without worrying about looking stupid.

Building a quarterly compliance report in 15 minutes

Julian: You also used Claude to build the actual bond-reporting template.

Austin: I use the Claude plug-in inside Excel. My financial model has all of our historical financials, forecasts, and dozens of supporting tabs.

I dropped the bond term sheet into the Claude sidebar. I also gave it a few examples of quarterly reports from other companies that had completed similar offerings. Then I told it to use the reporting requirements and covenants in the term sheet to build a separate quarterly-reporting tab inside my model.

It created the structure, the net leverage calculation, the liquidity calculation, and the compliance lines. It also highlighted how much cushion we had against each covenant. That is now part of my rolling financial model.

It probably would have taken me hours to create the first version. Claude did it in about 15 minutes. I had to make some tweaks, but it got me most of the way there.

Julian: And now the reporting model updates live as actuals get updated?

Austin: Exactly. As the historicals and forecasts change, the bond-reporting tab updates. I have similar reporting tabs for the equipment leases. You still need to understand how the calculations work. I would never rely on it without checking the logic. But instead of giving an analyst a day to build the first draft, it just creates the first draft.

Reviewing the model before the bankers do

Julian: How else did you use Claude during the bond process?

Austin: I was constantly updating our financial model and sending it to the investment bankers.

Before I sent anything, I would have Claude review the entire model for errors and issues. I would also ask it to quiz me: Based on this forecast, what questions will the investment bank or potential investors ask?

That was useful because it prepared me for the conversation. It would flag a change in margins, a working-capital assumption, a capital-expenditure number, or something else an investor might question. It was checking the model and also helping me prepare to explain it.

Julian: I feel like Claude’s output is a little hypnotizing. The formatting looks perfect, everything looks clean, and your brain wants to conclude that it must be correct. But that stresses me out – for something going to investors or the board, I still need to understand and stand behind every number, and not being the person who wrote every formula feels scary.

Austin: I agree. It is a first-pass analyst and a reviewer. It can’t be the person signing the compliance certificate.

Letting Claude operate QuickBooks

Julian: What are you doing on the accounting side?

Austin: We are starting to use the QuickBooks connector directly through Claude.

There is a lot of accounting work that can be administrative. You need to create a customer, set up an invoice, add the line items, assign the right GL accounts, or prepare a journal entry from a spreadsheet. Those tasks are necessary, but they can take the accounting team hours.

We have invoices with a lot of line items. Our accounting team can give Claude the spreadsheet containing what needs to be billed. Claude can then prepare the customer and invoice inside QuickBooks.

The important part is that it asks for approval. Before it creates the customer, you review it. Before it creates the invoice, you review the line items and GL accounts. Then you approve the action. Something that might have taken a couple of hours can happen in seconds.

The same concept applies to month-end journal entries. Our team may have an Excel file with the backup for payroll entries, credit-card entries, or other recurring journal entries. They can give that file to Claude, have it prepare the entries in QuickBooks, review them, and then approve them.

To me, this is not optional. We need to automate more of this work. Remove the tedious administrative work so the accountants can close faster and focus on more important things.

The $19,156 solution

Julian: Where have you seen Claude go off the rails?

Austin: I had one example that was pretty funny.

I was working in a three-statement model. The model didn’t balance – it was off by $19,156. I asked Claude to fix it. It whirred away and then fixed it. Boom – everything tied perfectly.

It looked great until I clicked around and saw that Claude had “solved the issue” by hardcoding $19,156 into a cell. An analyst would probably get yelled at for doing that.

Julian: [Laughing] Who amongst us hasn’t hardcoded a cell to make your 3-statement model balance?

The disappointing part is that Claude only hard-coded one cell. A truly CFO-trained AI tool would hard-code the whole model before sending!

Austin: Right. That is when you know it has reached true CFO-level intelligence.

But it is a good example of why you need to understand the fundamentals.

If you do not know how a three-statement model is supposed to work, you might see that everything balances and assume it fixed the problem. It didn’t fix the problem… it hid it!

An assistant that knows everything about the company

Julian: So what’s the holy grail? What do you ultimately want AI doing for Alpine’s finance team?

Austin: There are probably three things.

The first is automating processes. As the company grows, we will add people, but I do not want to add staff accountants and analysts at the same rate as revenue and fleet growth. AI should take over more repetitive work so the finance and accounting teams can focus on higher-value things.

The second is speed. We are talking with lenders, expanding the bond, putting working-capital facilities in place, adding equipment leases, and modeling fleet growth. There are constantly new scenarios. Should we buy or rent a piece of equipment? What does the capital structure look like? What happens if the next fleet starts in October instead of January? We need to produce and update those analyses quickly.

The third thing is having an assistant that knows everything about the company. During our weekly cash flow meeting, I might want to know the receivable balance for a specific customer or how many days it's outstanding. Today, I may need to open QuickBooks, find the right report, click into the customer, and look it up. I want to ask Claude and get the answer in two seconds.

Julian: So not just the income statement. It needs the general ledger, balance sheet, historical models, operational data, debt documents, and all the context around how Alpine measures the business.

Austin: Exactly.

The operational data matters too. We track fleet-level financials in Cashboard. Once that data is connected to Claude, I want to ask: How much did we spend on fluid ends for Bravo Crew this month? Or show me the trend in maintenance spending by fleet. Or tell me what happened operationally on Alpha Crew yesterday based on the Slack updates.

That is where it gets really powerful. It is not just searching one system. It knows how the whole company fits together.

Julian: There are two sides to that workflow. You can use AI to write information into the systems faster: create invoices, record journal entries, reconcile transactions.

Then you can use AI to read the information back out: answer the AR question, explain the spending change, summarize fleet economics, automate the write, automate the read, and reduce the human job to review.

Austin: That is exactly it.

About Austin and Julian

Austin Hostetler is the Vice President and Head of Finance at Alpine Energy, where he oversees finance as the company expands its fleet operations and financing programs.

Julian Rowlands is the founder and CEO of Cashboard, the AI FP&A platform. He was previously CFO of Xendit, last valued at $3 billion, and Head of Finance at Spruce, which was acquired by Zillow in 2023. You can learn more about Cashboard at www.cashboard.co.

Interviews with CFOs about AI is an interview series by Cashboard. We speak with finance leaders who use AI in their day-to-day work and ask them really detailed questions about their setup.

If you are a finance leader building with AI, we would love to interview you. Email julian.rowlands@cashboard.co with a quick summary of what you have used AI to accomplish, and we’ll get a call booked.

Subscribe now

At one point, Ashkon Farmand and I realized we might be the only two CFOs alive who get excited about building primary keys on top of scattered financial data. That’s when I knew this was going to be a good interview.

Ashkon is a CPA who has spent most of his career trying not to be an accountant.

He taught himself SQL at KPMG using textbooks and YouTube. Then he got a Master’s in Analytics from UChicago while working full time in an analytical role, where he used SQL and Python to analyze beer and hot dog sales at Cubs games. After that came five years of buy-side M&A diligence at Deloitte, roughly 100 deals a year, turning messy customer data into EBITDA. Then he joined Sumeru Equity Partners and tried to drag its portfolio companies out of spreadsheet hell.

Two years ago, he took his first finance leadership role as VP of Finance at Payroll Integrations.

Since then, the company has grown from under $5M to double-digit millions of ARR. The finance team is still Ashkon plus external bookkeepers.

We connected through a LinkedIn post. Five minutes into our first call, it was obvious we had basically taken the same weird route into finance.

I did data systems consulting for hedge funds, went to U Chicago Booth for my MBA, made fun of Booth for being a CFO factory, and then immediately became a CFO. Ashkon and I also have both the SQL brain and the finance brain, which is extremely rare. He’s running his finance org exactly how I would.

If you only read one thing: the top 5 highlights from my conversation with Ashkon

• You can run finance at double-digit millions of ARR with one person. Ashkon outsources the debits and credits, buys modern software, and uses Claude to produce a ton of high-quality output.

• Vibe coding gets you to a shockingly good 80% in a few hours. Then the last 20% eats your life. The other problem is feature bloat: once you can build anything, suddenly your billing app also needs to push to HubSpot, post to Slack, reconcile Stripe, and make coffee. Ashkon built a working billing engine in a weekend, saw the maintenance burden that it was going to require, and promptly went out and bought Tabs.

• The scariest part of vibe coding is not the code. It’s letting the code touch anything important. Ashkon would not let his apps write directly to HubSpot or reach into AWS.

• MCPs make board prep feel like asking a smart analyst one more question. The night before a board meeting, Ashkon used the Rillet and Ramp MCPs to pull six months of spend on one vendor. The question came up the next day. He had the answer.

• Data mapping is the glue that holds finance together. Matching CRM records to usage data. Maintaining lookup tables. Untangling customer hierarchies after one customer buys another. This is the ugly work underneath billing, rev ops, and reporting. (It is also, conveniently, exactly what we’re building at Cashboard.)

Ashkon’s path: KPMG, beer and hot dog analytics, Deloitte M&A, private equity, Payroll Integrations

Julian: Thanks for joining us, Ashkon. You’ve spent your whole career becoming an accountant while trying very hard not to be one. How did that happen?

Ashkon: I started at KPMG in their advisory practice with a whole bunch of other accountants. I was trying to differentiate myself, and I got exposed to SQL. I was drawn to it because other people were afraid of it. I knew I could have a little job security and learn something interesting besides anti-money laundering compliance and really annoying regulatory projects that I thought brought no value. This was 10-plus years ago, so there was no coordinated way to learn. I was learning by textbook and YouTube videos.

I wanted to figure out how I could become a programmer slash accountant slash business analyst. I had no clue, but I knew I didn’t want to do debits and credits, audit, or tax. I already had a CPA, so an MBA didn’t make sense, and I didn’t want to be a software engineer, so computer science didn’t either. Right around then, schools started launching business analytics programs, and UChicago had just announced one for working professionals. I got to learn coding and the application of it, not just theoretical mathematics. I was like, this is great. I want to be an accountant who can code.

I took one class and realized, what the hell am I doing at KPMG doing compliance? So I went to work for a data analysis company in Chicago doing business analytics, analyzing concession stand sales at Cubs games, NFL games, concerts. I’m using SQL and Python to analyze beer and hot dog sales at sporting events. Amazing gig.

Eventually I realized the TAM of my skills, this hybrid CPA-plus-coder thing, was a lot bigger outside of food and beverage. So I went to Deloitte, after claiming I’d never work for a Big Four firm again, and spent five years doing M&A due diligence, specializing in private equity buyers, analyzing customer data during buy-side diligence. A hundred deals a year, basically two projects at a time. I could translate customer data into EBITDA and actually blend the accounting side and the data side.

Then I got the opportunity to do that same thing inside a mid-market private equity firm, Sumeru, helping portfolio companies beef up the tech stack for the finance function. Trying to teach older-school finance teams: don’t just hire another FP&A analyst who’s going to grind through Excel. Get a data warehouse, get BI, anything but broken Excel and Google Sheets that won’t load.

So after a couple of years of coaching people, I thought, let me just do the damn thing. I saw what CFOs were doing and thought, I know how I would do it. I’d never done it before. But I knew the data side, and finance is just data management. The controllership and compliance stuff is all pretty dry from there, and it can be automated if you have quality data. I knew what needs to be done at $100M ARR, so let me go start at $5M ARR and do it right from the get-go instead of doing a cleanup job. I joined Payroll Integrations when we were sub-$5M ARR. We’re now well into double-digit millions of ARR.

The team-of-one stack

Julian: And it’s still just you. That is insane to me.

I’m curious about systems, too. In my own CFO roles, I had accounting data, budgets and forecasts, payroll, an internal KPI database, and a sales CRM. What are you running all of this on?

Ashkon: It’s just me, plus external bookkeepers, because it’s cost-effective and they’re better at debits and credits than I am. I wanted to see how long I could stay a team of one, keep improving the tech stack, and get smarter about our data connectivity.

We upgraded out of QuickBooks into Rillet as our ERP earlier this year. We moved to JustWorks as a PEO, so I’m not running payroll anymore, which was annoying. Our data warehouse is in AWS, where I’m doing stuff in Python and SQL. We implemented Drivetrain for FP&A last year, and the way I use it has changed since MCPs and Claude Code blew up: I’m using it essentially as a data warehouse and for data mapping, whereas before I used it for modeling. We have Power BI, but between Drivetrain and Claude I don’t really use it as much. We’re implementing Tabs for billing, because our billing is chaotic and annoyingly complex. I vibe-coded some billing myself, and it worked, it’s decent, but I don’t want to maintain responsibility for all of our billing, so I needed pros to build a semi-customized solution. We’re on Ramp for spend. We’re in HubSpot, where I’m doing pseudo-rev-ops and piping data into Drivetrain for sales leadership reports.

And we just went live with Invoice Butler on AR. We’re high volume, low dollar amount, and I had HubSpot support tickets full of customers saying update my credit card, where’s your W-9, why is this charged this way. I can’t be doing that, and I’m not hiring an AR specialist. Those guys have been tremendous.

The easy AI wins: SQL, Python, and journal entries written straight into Rillet

Julian: Okay, so that’s your stack. What have you actually built with AI on top of that?

Ashkon: The easiest win, even from before Claude Code blew up, is that it helps me write SQL and Python better. But that’s because I had a baseline understanding from the old days of Stack Overflow and Google. And you almost don’t need to do that anymore, because Claude can just query the data directly.

Here’s one I like. We have a vendor that bypasses Ramp and pulls directly from our bank feed, so in Rillet it just shows up as, whatever, $10,000 withdrawn. No bill, no credit card. They’d email me an itemized PDF, and I didn’t want $10,000 sitting in G&A. I want $2,000 here, $2,000 there, allocated across R&D, G&A, and COGS. So I used OCR to get the PDF into Python, did the allocations, and wrote the journal entries directly into Rillet through the API. It was partly just to see if I could do it, but it saved me manual journal entries. Now I can upload the PDF directly into Claude and replicate the same thing.

The other big one is our usage data. I’m pulling about five million records out of AWS, putting them into a good format, and loading them into a shared S3 bucket to feed Tabs. That’s a Python script right now, and I’m converting it to a cron job soon so it runs nightly without me loading it up and clicking run. All of that is Claude-assisted, because I had no clue what a cron job was, and I don’t want to bug my engineers.

Prepping for a board meeting with the Rillet and Ramp MCPs

Julian: You use the Ramp MCP a lot. I’d love to hear an example of how that’s been helpful.

Ashkon: The best example: I had a board meeting coming up, and I knew they were probably going to ask about our Anthropic bill, because it’s gone up. So I said, hey Claude, I have a board meeting tomorrow. Pull all of my Anthropic expenses from Ramp and Rillet: averages, six-month trailing average, all that sort of stuff. And the board did ask the question! It was phenomenal to walk in prepared. That’s the Rillet MCP and the Ramp MCP working together.

Scheduled tasks are the thing I need to get better at. What I want is one that connects to my Gmail, my Slack, and my HubSpot, and every day pings me: here’s what you need to prioritize.

Julian: I built a Ramp expense-review skill that I really like. Every Friday, it checks the past week’s transactions, flags new vendors, looks back about 380 days for annual renewals, guesses billing cadences, and checks declined transactions.

Then it Slacks each person their own past and expected upcoming spend and says: if you don’t recognize something, please flag it. And please cancel anything you’re not using!

I also force every message to end with “sent using Claude,” because people should know that it’s a robot sending it.

It gives everyone spend visibility without me chasing them around. We’ve probably saved a couple thousand bucks from people canceling unused subscriptions.

(Note: I sent Ashkon my ramp skill & scheduled task after we hung up. Email me if you want it too.)

The vibe-coded billing engine and the customer-matching app

Julian: You mentioned doing a ton of vibe-coding — I’d love to hear more about that.

Ashkon: Our billing logic is complicated. Historically, it lived in a spreadsheet that’s 58 columns long, all if-statements and lookup tables, because we have parent-child customer hierarchies and a bunch of different channels. I tried to replicate it in Python when I first joined and didn’t want to maintain that either. So I vibe-coded a billing app.

It is not live-connected to AWS. I still export the usage data and upload it manually, which is one reason I’m replacing it with Tabs. But once the data is in, the app calculates each customer’s bill and pushes the invoice into Rillet through the API.

The app really works. I’m always cross-checking my work before using it just to be safe. Once a bill looks right, I just hit “push” in the app. The invoice appears in Rillet, and the app generates the supporting CSV automatically. Every customer wants to know why we charged them and what the underlying usage was, so I attach that CSV to the invoice.

I’m still running the app in parallel with Excel and reviewing everything before it goes out. It works. I’m also extremely excited to stop owning it — the maintenance burden would be way too crazy over time.

The other app I built is for mapping customer tags across systems so that I have a single unified tag for everyone. The customer names in HubSpot and in our usage database don’t always match. So I built an app that scores matches: these two names are a 100% match; lock it in and store that mapping forever; this one’s a 90% fuzzy match; flag it for manual review. The idea is that an entry-level person can review the flags instead of me going through thousands of names. But it’s all local, on my machine. I’d rather pay for a proper tool to do this for me, so I can collaborate with teammates instead of manually managing it all myself.

Where vibe coding breaks down

Julian: You’ve built some really cool software. When did you realize you shouldn’t keep owning it?

Ashkon: Security was the big one. I did not feel comfortable letting a vibe-coded app tap into our AWS directly, so I was writing a query, saving the file locally, and uploading it into my app. Same with HubSpot. I was hesitant to write data back to HubSpot directly without proper controls, because I don’t perfectly understand what I built, right? It’s not like I’m going through every script it created. I had decent controls and small sample sizes, but one of my company’s co-founders asked, are you sure you want to let your app loose on our HubSpot instance? And I was like, you’re right. I probably shouldn’t do that (laughs). So now the app exports a file that matches HubSpot’s import template, I review it manually in Excel, and I upload it myself.

The other thing is that vibe coding gets you a really damn good 80% or 85% within a couple of hours. Then you spend so, so much time on the remaining 20%.

And when you think you can build anything, the bloat is real. I want it to push to HubSpot. I want it to post to Slack. I want it to auto-log everything. Suddenly, the little app I built has become an internal software company that I apparently run.

For small, focused, one-off things, it’s great. For larger, important things, the build-versus-buy math stops working. I’ve built one billing app. Tabs has done it a million times. By the end of the weekend, my app was pretty great, and I still thought: it doesn’t make sense to spend the rest of my life on this.

Data mapping is the finance function

Julian: Before we wrap, I just have to say — you’re the first finance leader I’ve interviewed who tried to build his own data-mapping tool. I think that’s so cool. Data mapping in finance is such an insane technical problem.

I always handled mappings in Excel when I was a CFO and it was a nightmare. You can’t get down to vendor-level mapping because the data volume is insane, and there’s always a new one every day. Which means you can’t really understand your atomic units of spend and how they compare to budget. Same for customer mapping, employee mapping, etc.

We built Cashboard’s data mapping engine to solve that. It’s the crown jewel of our platform. I’m unhealthily obsessed with it.

You can create as many dimensions as you want, and stitch together infinite labels from as many source systems as you want. Then, when a new label shows up, the humans get alerted, and AI has a suggestion that they can approve with a click.

Mappings are just such a wild finance-specific data engineering problem, and — before I built my own platform to solve it — they were the bane of my existence as a CFO.

Ashkon: That’s right. I have three hierarchy layers of customers and a lookup table I’ve outgrown. But that’s the thing. What you’re building, data mapping and essentially lookup tables, is finance. That’s the finance function.

Julian: Some kids want to be astronauts. For some reason, I wound up spending my whole career at the intersection of data and finance, and now I’m apparently obsessed with it.

About Ashkon & Julian

Ashkon Farmand is the VP of Finance at Payroll Integrations, where he runs the finance function as a team of one.

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.

Interviews with CFOs about AI is an interview series by Cashboard. We speak with finance leaders who use AI in their day-to-day work, and ask them really detailed questions about their setup.

If you’re a finance leader building with AI, we’d love to interview you! Email julian.rowlands@cashboard.co with a quick summary of what you’ve used AI to accomplish, and we’ll get a call booked.

Sowmya Ranganathan is one of the most impressive finance leaders I’ve ever met.

She’s the former controller of OpenAI and Rippling, a CPA, and now she’s building the future of agentic accounting at her own startup Lumera.

I met Sowmya years ago when I was a Rippling customer and we asked our CSM for a demo of their NetSuite connector. And lo and behold: turns out Sowmya was the product manager building that feature, *as well as* their controller, and she ran the demo herself. I’ve been starstruck ever since.

Besides being brilliant and kind, Sowmya’s also the greatest stock picker I’ve ever met – except she’s done it via employee stock options instead of investing cash. Besides joining OpenAI and Rippling early, she also joined Square pre-IPO and helped them go public.

I asked Sowmya about:

• Scaling finance at OpenAI after they turned on paid ChatGPT subscriptions

• How her team used OpenAI’s products as part of that scaling

• The data infrastructure they had to build to keep pace as OpenAI’s ARR went from $28M in 2022 to $20B in 2025 (note: these numbers came from publicly available metrics)

• Whether the ‘finance engineer’ is a thing

• Building the future of agentic accounting at Lumera

If you only read one thing: my top 5 highlights from my conversation with Sowmya

• ChatGPT flattened the SQL learning curve almost overnight. OpenAI’s revenue ran entirely on SQL because the volume was far too big for Excel, and recruiters told Sowmya to pick a lane: SQL people or revenue people, not both. So she hired accountants who knew ASC 606 and let ChatGPT close the SQL gap.

• Let the problem pull you to AI, not the other way around. The OpenAI accounting team’s best use cases for AI came from identifying what was “breaking the team,” not from chasing a solution in search of a problem.

• Dashboards are easy and you can prompt one in minutes. The foundational work is upstream: capturing the data, capturing all the metadata, and keeping systems in sync. A clean ERP gives you clean reporting and a messy one does the opposite.

• Every IC is becoming a manager. Teams get smaller, and roles get broader. The job is shifting from doing the ten steps to building something that does the ten steps, then you handle the exceptions. If you have not considered yourself an architect or product manager in accounting, now is the time.

• Governance is what makes finance AI shippable. Anything an auditor has to bless needs access controls, version history, and change management. Without that, finance teams cannot comfortably put the automations they build into production.

Sowmya’s path: EY, Square, Rippling, OpenAI, Lumera

Julian: Thanks for joining us, Sowmya. You’ve had a wild career: EY, Square, controller roles at Rippling and OpenAI, and now founding Lumera. I’d love to hear more about that trajectory.

Sowmya: On the surface, it looks like a mostly traditional accounting path. I started out at EY, went to some tech companies, did accounting, became a controller, and did that again a couple of times. The more interesting thing is that I had a lot of career crisis moments in the middle of that.

At Square, for example, after we went public and did a couple of quarters, I was running close, and I thought, oh my God, is this the rest of my life? Am I just going to be living between quarters forever? I was so close to joining one of those coding bootcamps to change careers and become an engineer. But my husband, who is an engineer, talked me down from that ledge.

Rippling was really fun. I was doing a lot of work with the product teams and sometimes the go-to-market teams because the product we were building and selling was, in large part, for a finance audience. I found that work really interesting, and I thought that whatever I do next has to be something I love as a user, where the job can be more than just back-office close, and where I can actually push the company forward.

After about three and a half years at Rippling, I was ready for a break. The funny thing is that my last day at Rippling was the day ChatGPT came out. So naturally, I became a little obsessed. Most of my AI experiments were about what I could build for accounting use cases, or for myself as an accountant, using this tool. And this is just ChatGPT. This is before coding agents running in the cloud.

When I got an inbound from an OpenAI recruiter, I mostly just wanted to talk to the team and ask what they were doing, because I was so enamored. The finance org at the time was 10 people. I ended up joining the month we started monetizing with ChatGPT Plus, and my first month closing the books was the month we started making real money.

AI on the OpenAI finance team, early on

Julian: How was the OpenAI accounting team using ChatGPT in those early days?

Sowmya: It wasn’t the kind of AI mandate you hear about now. Today, it’s company-wide AI token leaderboards. Back then, no one really knew what it meant to use it for work. Engineers saw the light sooner than most other teams. On finance, we were initially just noodling with technical accounting and policy writing, since it seemed to know so much. It wasn’t really changing how we worked.

The big “aha” for me was that new team members could teach themselves SQL. Our revenue had to run entirely in SQL. These are 20-dollar transactions at huge volume, and there’s no way you’re running that in an Excel file. So I’d go to recruiting and ask them to find me revenue people who know SQL. They, in turn, would ask me to pick a lane: SQL people or revenue people. So we relented and hired an accountant who knows ASC 606. We realized then that ChatGPT could flatten the SQL learning curve. Then, very quickly, we turned it into an internal code-generation tool before people in the industry even had words for these things. We’d just say, here’s the gnarly thing I do in Excel, here are the source files I get, write me a Python script because Excel keeps crashing. It came from a very problem-driven place, and it was successful because you could clearly see the ROI. We didn’t go chasing a solution in search of a problem. Instead, we started by identifying what was breaking the team. Use cases proliferated from there.

How revenue actually flowed at OpenAI

Julian: Let’s talk systems. How did revenue actually flow at OpenAI?

Sowmya: Initially, everything was in Stripe. We had some syncs back to a data warehouse, but we’d write our queries in Stripe Sigma for the revenue data we needed. Then we had workbooks that turned those Stripe queries into NetSuite entries. NetSuite wouldn’t hold transaction-level entries; it would only provide summaries. Over time, we automated that end-to-end. Stripe data would land in the NetSuite Accounting Warehouse, which kept all the raw data. From there, you set up your aggregation, accounting rules, and posting rules in that system. Given how much data was flowing, we pretty much had to stand up an enterprise-scale subledger because of the complexity. With that subledger in place, you can go from a summary entry in your P&L all the way down to the raw transaction. If you want to trace which refund got applied to which payment, you can actually do that.

Julian: This hits home for me. My first CFO job was at Xendit, which is basically Stripe for Indonesia. I joined right after the Series A, and part of why they hired me was because I’d done data systems consulting for hedge funds before business school. Xendit was booking millions of transactions a month, and I had to get the cash balances, the customer liabilities, and COGS all booked to our balance sheet without breaking our accounting systems. I also needed to figure out per-channel gross margins. The scale of the problem needed both a SQL brain and a finance brain. We were basically building our own ledger. It took me ten months to figure out gross margins per channel, banging my head against the wall on the right SQL query and hard-coding things I knew were right today but would be wrong tomorrow. Looking back, I could have ripped through that in Codex in about five seconds. So when you describe a sub-ledger that traces a summary entry all the way to the raw transaction and scales to hundreds of millions a month, I get it.

Sowmya: Exactly. And one of the best things OpenAI had going for it was that the revenue team was already very SQL and data-savvy before ChatGPT happened. There were a couple of people I can think of who were just incredible. If we didn’t magically have those people in the seat, it would have been a disaster from day one.

The rise of the finance engineer

Julian: Funny enough, my own CFO path has an OpenAI connection. When I became Xendit’s CFO in 2018, I’d never been a CFO before, so I asked the founders if they could intro me to other YC-affiliated CFOs so I could learn from them. One of the people they introduced me to was Brad Lightcap, OpenAI’s CFO (now COO), and I remember walking through the Mission with him and asking him lots of questions about NetSuite. In retrospect, I should’ve asked him for a job! Later, through LinkedIn, I watched OpenAI hire a wave of people who sat right at the intersection of FP&A, data, and product and engineering. That’s the “finance engineer” role I keep hearing more about. Is that something you hired for?

Sowmya: Yeah, when the revenue team was three or four people, we started by hiring a finance data person before we ever scaled up the accounting team. This wasn’t quite a data engineer. Think of the role as a hybrid of data engineering, analytics, and a builder mentality, someone who could shadow another person, understand what they were doing, and then automate it. It was an amazing hire for the team. The finance engineer conversation right now is interesting because, in practice, we’ve always had somebody like this: the conduit between systems work, systems thinking, and operational processes. In earlier days, it might have been your Oracle analyst or business systems analyst. Then it became a fintech or business systems team that owned your NetSuite admin and configured customizations.

That role is transforming because the modern crop of systems isn’t so config-heavy. The latest systems are more plug-and-play, and customization now happens at the coding-agent layer: take an existing system and customize it to run my agentic workflow, or use context unique to my business to change how the system takes action. So the finance engineer still thinks the same way, as the conduit between systems thinking and what the team needs. Every few years, there’s a new rebrand. You definitely have more product- and engineering-focused folks now, but honestly, I’ve worked with people in this capacity for more than a decade, and they’ve always had a builder’s mentality. Thinking back to Square, we were on Oracle and had this odd payments recon work. We launched Square Capital and realized that ledger needs to work very differently from how credit card payments worked. We didn’t call it a product, but if you really think about what the team was doing, they were building an internal-facing product for the finance team.

Julian: Role branding matters more than people think. When I got to Xendit, we had a middleware team doing exactly this work, and nobody wanted to touch it. So I took a propaganda-first approach and rebranded it Transaction Intelligence, TXI for short. I basically pretended the old team had been dissolved and this was a shiny new one, even though it was the same people working on the same JIRA tickets. Suddenly, data engineers were excited to join. Branding matters!

Sowmya: Exactly.

What was being built, and what’s still hard

Julian: By the time you left OpenAI, what were people building, and what was still hard?

Sowmya: Toward the end of my time there, we were maximizing and templatizing the work and the prompts. The big shift to coding agents hadn’t fully happened yet, but the coding models have had step-function changes over the last six to eight months. If you talk to the team now, you’ll hear about the proliferation of apps and dashboards people are building on Codex. I can guarantee you Codex is top of mind. Sharing one-off Google Sheets, memos, and packets is fine, but when you can automate that end-to-end and make it a real, living, breathing thing, it changes the work people can do.

That said, the dashboard is almost the easy part. You can prompt and get one relatively quickly. The hard part is how you capture the data upstream, all the metadata, whether it talks to other systems, and how you keep it all in sync. That work really hasn’t gone away. No matter what company, industry, or tech stack you’re in, almost anyone who has done this in real life will tell you: if my ERP data is clean, I can get downstream reporting without a lot of headaches. But if my ERP is messed up, no AI is really going to help me, unless I’m using AI to clean it up… which is a great use case, by the way. A lot of the work we did at OpenAI was the foundational data and process work.

Where finance teams and AI are headed

Julian: Where do you think finance teams will be a year from now?

Sowmya: A year feels like a lifetime and I genuinely don’t know. But the trend I’m ready for as a CPA is that teams are going to be smaller, each role is going to be broader, and you have to think of your role as managing a bunch of work getting done. Even if you’re an IC, you’re basically a manager now. You’re not managing people; you’re managing the agents, processes, and workflows you’ve built as automations. It’s a very big mindset shift.

Previously, you could have a job where you knew the ten steps you needed to do to get something done, and that was the job. The future of the job is about making something else do those ten steps, and you’re only looking at exceptions or changing the process when it needs to change. So if you haven’t thought of yourself as an architect or a product manager in accounting before, now is the time. I think everybody is moving to that world.

Julian: And that’s the world Lumera is built for. I’d love to hear more about what you’re building.

Sowmya: What we do at Lumera is give teams a way to do this collaboratively and in a controlled manner. Instead of everybody spinning up their own cloud coding environments, with a bunch of skills that aren’t transferable across projects and no real access controls or change management, the platform handles a lot of the boring governance: the audit-ready stuff somebody needs to do so finance teams can comfortably communicate how they’re changing the code and how they’re building.

We’re tech-stack agnostic, so we connect to whatever tools you have, from ERP systems to G Suite to your payroll and AP systems. You bring whatever data you need, you pick your coding model, and you just start telling the AI what you want built. The difference from other site builders is that the coding agent doesn’t just build the site or the dashboard. It builds your full backend infrastructure. It can spin up agents and sub-agents, multiple of them, and do all of it in the background, so you, the user, can just focus on what you’re building and what your end outcome is.

Those outcomes can be inputs to your financials, like automating your close work, and not just the checklist, but every item in the checklist that used to be something you did manually. Then you automate downstream, like reconciling Salesforce and NetSuite, and keeping it in sync forever. The main thread I see is that anything an auditor needs to bless is happy living in a platform like Lumera, because it’s backed by the governance and controls you need. Every project has its own permissions. You give people viewer or editor access; you get version control and deployment history; you can figure out who did what and restore to an old version; and all changes to permissions are logged automatically for you.

Julian: So Lumera helps accounting teams get IPO-ready with a tenth of the staff, much faster, with all the controls in place?

Sowmya: That’s the idea.

About Sowmya & Julian

Sowmya Ranganathan is the founder of Lumera and the former controller of both OpenAI and Rippling. You’ll find her on LinkedIn and at lumerahq.com.

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.

Interviews with CFOs about AI is an interview series by Cashboard. We speak with finance leaders who use AI in their day-to-day work, and ask them really detailed questions about their setup.

If you’re a finance leader building with AI, we’d love to interview you! Email julian.rowlands@cashboard.co with a quick summary of what you’ve used AI to accomplish, and we’ll get a call booked.

Welcome to Episode 2 of Cashboard’s series of conversations with finance leaders about how they’re using AI in their day-to-day work. This time, we’re excited to welcome Ray Anderson, CFO of Claremedica, a multi-clinic, value-based healthcare operator.

Ray runs finance for a healthcare operator where the data is highly dispersed (lots of systems), high volume (lots of patients), and highly sensitive (lots of PHI). His data lives in Sage Intacct, an internal data warehouse, Power BI, Paycom, and a ton of Excel files. He’s also a Claude power user who has rebuilt how his team runs budget vs. actuals, financial forecasting, and writes SQL.

I’ve known Ray for 1.5 years. He’s smart, blunt, and really tech-savvy. I wanted to interview him because he’s gone deep down the AI rabbit hole, and very candid about what’s worked, what hallucinates, and what he’s had to do to get there.

Please enjoy my interview with Ray about how he’s using AI in Claremedica’s finance function.

If you only read one thing: Ray’s 5 takeaways for finance leaders

1. Claude is transformative. Pro or Teams gets you access to Claude Cowork and the Claude Excel plug-in, which is where Ray does most of his AI work.

2. No data scientists needed: Claude is exceptional at writing Python scripts that can run regressions. Ray’s team regressed 2+ years of historical KPI data against past financial outcomes and built a live forecasting model with a tighter standard deviation than anything else they’ve tried.

3. AI hallucinates most when mapping data fields. A vendor name with an extra space in the wrong spot can break a BvA. And consistency across runs is really hard – something Claude gets right one week might break the next.

4. Use Claude Projects to control drift across recurring workflows. Ray’s ‘Monthly Variance Analysis’ project carries the output template, guardrails, and last month’s manual fixes from session to session.

5. Claude’s ability to write SQL enabled Ray to reduce staff time spent on lower-level analytics work.

Thanks for joining us, Ray. Before we get to Claude, what’s the finance stack at Claremedica look like?

Thanks for having me, Julian. In terms of our non-AI stack, Sage Intacct is the GL; we have 7 EMR systems that feed into an internal data warehouse (Microsoft SQL Server); we use Paycom for payroll; and we use Power BI for data visualization.

And I fully live in Excel. I’m a little bit of an old school guy. On any given day, I’ve got six different Excel windows open, doing six different things.

On the AI side, we have a few products that are working really well for us.

Outside of finance, we use an AI copilot for clinicians called Navina, which automates HCC / condition capture from medical records. It takes half a second to accomplish things that used to require a small army of people. It’s really accurate and CMS-compliant. Lots of vaporware out there, but Navina really works. It’s been transformative for the business.

Within finance, we use Claude. We’re on the Teams plan. I mostly use Claude via their Excel plug-in and use their Cowork tool on desktop.

Where did Claude show up in the finance function?

We started by dipping our toes in: here’s a data export from the ledger; here’s a different file that’s our budget; compare the two, and write me an executive summary of a budget-versus-actuals variance analysis. And it did it. It was fast and mostly right.

That said, the horror stories are not unfounded. You can’t just trust it. So rapidly–in concert between finance and data analytics–we started shaping the universe of how Claude thinks. You can give it skills and personas. We’d say, “Hey, you are a healthcare actuary with 25 years of experience, your specialty is X, Y, and Z, take a look at this and give me a CFO-level one-to-two page response.” Once we started narrowing how Claude approaches answering queries, it quickly became much more effective.

Then I started using it like I would use an analyst. Claude is embedded in Excel via their plug-in, and because I live in Excel, I can have six windows open and have it doing six different things. Instead of Teams-ing or Slack-ing a colleague to run something down for me, it’s just operating in the background. The only limiting factor is how quickly I can dictate or type the requests.

Walk me through the KPI and forecasting work. I know you’re doing some really interesting work there.

We always talk about KPIs and leading indicators. We need real-time visibility into how the business is performing. But financials are a lagging indicator, while operating metrics are a leading indicator.

Our holy grail has always been to build a really tight understanding of how today’s operating metrics are likely to hit our financials in the near future.

Claude Cowork helped us achieve that holy grail.

So we pulled operating data from the past 2+ years and fed it into Claude. We said, “Here are the KPIs we track, and here’s the resulting financial picture. We think A correlates with and drives B. Go tell me why that’s wrong.”

Claude wrote and executed Python scripts that ran regression analysis from an actuarial perspective, and Claude came back with a gold mine. We ran this a couple of different times – the first pass back-tested okay, but didn’t correctly track to the future at first, so we ran it through a bunch of cycles. In the end, we came out with a really effective forecasting model.

Obviously, it’s a forecast, and there are unit cost deltas you’re never going to get quite right. But the standard deviation is far narrower than any other way we’ve done it.

What that’s done for the operational leadership team is give them real-time quantitative feedback. We can tell an operator, “Hey, you had a bad day yesterday, what happened? Because this thing spiked and that has an impact of $50,000 or $500,000 or $5,000,000.” It connected the dots in a way that I just don’t think was possible before. And it gives people more confidence that the things we’re measuring are the right things.

How do you actually run a budget vs. actuals through Claude in Excel without it lying to you?

It does hallucinate from time to time. So I’m not trying to portray myself as having perfectly figured this out. Over time, we’ve narrowed the guardrails. There has to be a log of all the changes that you made to the file. The formula list has to be its own tab. There has to be a reconciliation process.

The area where Claude makes the most errors is in data mapping, creating apples-to-apples ties between actuals, budgets, and pro formas. You’ll get a BvA that says you ran $200k favorable on a budget item, but I’ll know that’s not the case. Then I’ll have it go back to the source data and make sure it’s counting everything that has a snippet of a vendor name, and it would be missing one because the name had a space in the wrong spot. So now we save instructions like, anytime you’re looking at a vendor list, do the fuzzy match. Build a checksum. Show me that all the things zero out, the same way we used to when we were building sheets by hand.

I still don’t blindly trust it. But I directionally trust it now.

And how do you control for drift between the March BvA and the April BvA? How do you keep the output structure and the data mappings the same?

That’s a great question, and it’s a real problem if it’s not stored. Claude forgets. You open a new session, and it has no idea what you did before.

For us, that’s where Claude Projects came in. There’s a project called Monthly Variance Analysis. Inside it, we have all the guardrails. This is what the output will look like. Here are the tables to update in the background. Here’s where you go to get this data. Here are the formulas. Here are the things you need to track. And here’s the list of things that had to be manually fixed last time.

It’s a little bit of iteration. I’m sure it’s not the cleanest way to do it. It’s just how we’ve gotten it across the finish line. But it still takes a bunch of babysitting.

You mentioned analytics have benefited a ton as well. How has that changed?

This isn’t really a finance story, but you’ll appreciate it. Claude is really, really good at writing SQL code. This allowed us to reduce the staff time allocated to lower-level analytics. Now, the higher-level folks can just tell Claude what to do, and they get back perfectly written SQL. Their productivity has skyrocketed.

Our senior director said it best: “I can give this task to one of our new hires, and it takes them half a day, then I have to fix it. Or I can type a request to Claude, and I get it back in 32 seconds, and it’s right 99% of the time.”

What about PHI and PII? How do you draw that line?

The constraint we have is that the data must remain within our four walls. The data we’re storing in our database contains PHI and PII, and we don’t have a BII with Anthropic, so we never pull that data into Claude.

So when we’re feeding Claude data, it’s either coming from Sage Intacct as a GL export or from our internal data warehouse, scrubbed or de-identified. If it’s coming from somewhere else, it’s an export already in Excel that we can scrub before it goes in.

That’s the boundary right now. It’s also the question I get from every other healthcare finance person I talk to. Without live data feeds, you can’t put Claude on autopilot.

How do you think about trust in the outputs overall?

I still don’t blindly trust it. But I directionally trust it now.

Finance people are also just not great at making beautiful presentations. We copy and paste the spreadsheet. So you can have Claude interface between Excel and PowerPoint and have it build the deck, or pull the BvA forward into an existing monthly review presentation. That alone takes a lot of work off the team.

The bigger change, though, is that I don’t have to wait for an analyst to come back with a number. I just have to ask the next question.

About Ray & Julian

Ray Anderson is the CFO of Claremedica, a multi-clinic, value-based healthcare operator. He previously held senior leadership roles at Optum, UnitedHealth Group, and GE Capital.

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.

Interviews with CFOs about AI is an interview series by Cashboard. We speak with finance leaders who use AI in their day-to-day work, and ask them really detailed questions about their setup.

If you’re a finance leader building with AI, we’d love to interview you! Email julian.rowlands@cashboard.co with a quick summary of what you’ve used AI to accomplish, and we’ll get a call booked.

Cashboard is starting a series of interviews with finance leaders who are using AI in their day-to-day work, hosted by me (Julian Rowlands, Cashboard’s founder/CEO). The idea is to share highly practical AI applications that other finance leaders can learn from.

First up: Jesse Rubenfeld, founder and CEO of FinOptimal.

Jesse was previously Controller of D. E. Shaw Research and CFO of LimeWire. Before AI, he taught himself Python and used it to automate massive chunks of his accounting workload. Today, he runs FinOptimal, a tech-enabled accounting firm and software company.

Jesse’s the only accountant-engineer hybrid I know, and has been at the forefront of applying technology to finance for years. We’ve known each other for a long time, and FinOptimal runs bookkeeping for Cashboard, so I trust him tremendously.

Without further ado, please enjoy my interview with Jesse, which covers how he uses AI internally within FinOptimal’s finance function.

If you only read one thing: here are Jesse’s 4 takeaways for finance leaders

• Your data must be correct in order for AI to be useful

• The better your data (dimensional tags, etc), the more AI can help you

• You can automate a ton of bookkeeping with non-AI software. If you’re on QBO, Jesse’s firm FinOptimal can help you there.

• Find a way to feed all your data into tools like Claude (and ideally make that access permanent). It can do incredible analysis and the automations you can build on top are getting really powerful.

Thanks for joining us, Jesse. Before we talk about AI, it would be great to understand what your finance stack looks like.

So, QuickBooks is our system of record; we track time in Harvest; and payroll runs through a third party on the iSolved platform. Then I gravitate towards Google Sheets.

QuickBooks is updated constantly with all my accruals and journal entries. Our close process is almost fully automated. That’s not AI, but rather FinOptimal’s own software at work. We have a bunch of internal names for these workflows, including Wrangler, Payroller, Booker, Editor, and Allocator.

Basically, we use our own products (Wrangler and Payroller, specifically) to pull data from Harvest and iSolved into a Google Sheet. That GSheet auto-calculates every person’s fully loaded cost, and allocates it by customer, team, etc according to the hours they’ve tracked.

Then our Booker tool pushes the resulting journal entries into QBO on a schedule. We also have a tool called Editor that lets us bulk-modify QBO transactions via a spreadsheet.

The result of this is a QuickBooks dataset that basically self-closes in realtime. And it’s super detailed – I can even filter my P&L by customer and see my gross margin for each.

Where does AI fit into your processes?

Let’s start by talking about what we aren’t doing.

AI doesn’t auto-write anything to our books. Our automated booking workflows are deterministic.

I don’t want to introduce any probabilistic or generative inputs. I want absolute control over my books, and absolute certainty of what gets recorded. Automating the bookkeeping is a job for clear, controlled scripts and software-driven workflows.

We use AI in our internal finance function in a variety of different ways:

• Composing SQL queries for reporting and building workflows using natural language instead of painstaking trial and error (to reconcile month-end MRR with actual monthly accrual SaaS revenue, for example)

• Analyzing the financials with a focus on month-on-month fluctuations, basically variance detection and explanation

• Reconciliation of, say, Stripe balance transactions (as downloaded from Stripe directly) versus our books’ Stripe account (to figure out why our balance doesn’t equal theirs)

Basically, we’ve piped our QuickBooks (and other) data into a PostgreSQL database, and then connected that database to our Claude Cowork instance.

QuickBooks has an MCP offering through its partnership with Claude, but we actually use FinOptimal’s own MCP server (since we dog-food our own software internally). That gets me GL data as well as monthly close notes, supporting schedules, and more. The additional tooling means Claude can pull P&L lines, drill into transactions, and answer flux questions.

So it’s mostly used for instant queries. And I can do that at my desk via Claude Cowork, or from my phone via Claude Dispatch.

This is all downstream of having great data recorded in QBO. AI data analysis isn’t helpful unless the data is high-quality. And real-time close helps too, because it means AI can run any analysis on demand, anytime.

When I’m reviewing my data in Claude, sometimes I’ll realize I need to change my Chart of Accounts and reclassify transactions. For instance, we’d been counting Claude, ChatGPT, and API tokens as ‘Software Subscriptions’. The spend grew and we realized we needed a new “AI Usage” OpEx line.

I used Claude to pull a list of all relevant transactions. I populated those into a spreadsheet, fed that to our ‘Editor’ tool to reclass, reviewed manually, and pressed the submit button. Instant reclass for all historical transactions.

I haven’t built any scheduled tasks in Claude Cowork yet, but I’m starting to explore that.

Sometimes I would prefer to write SQL against my data in Postgres, rather than view in Claude. I use Claude to write the SQL query and then run it directly against the database. Our new Magic AI Report gives users the ability to formulate a SQL query by chatting with us directly in our app.

What’s the Holy Grail you’re building toward?

I’m building FinOptimal products that can help both ourselves and our customers.

The first product is called Closer. I’ve lived through the pain of getting comments on a draft close package.

That was the most soul-killing thing as an accountant. You’d get a comment, you’d know you missed something, and now you have to dig through the GL and find some needle in a haystack. AI can dig and give you the note right away, instead of having your CFO catch mistakes. That can make the accountant’s job a delight.

Closer basically takes the first pass at that monthly package. Identifies what looks off. Investigates. Either fixes it (with approval), or hands the human a high-quality note.

The second problem we’re solving is balance sheet debris. Old reconciliations and suspense balances. The kind of mess that quietly snowballs into a disaster. Balance sheet review is where I have the highest hopes for AI.

Will AI replace CFOs?

I don’t think so. It’s going to elevate the good ones. The rent-seeking charlatans will have to find something else to do. It’s a power tool. You can serve more clients better than you could before. I’m bullish on both software and services for the next two years, at least. In ten years, who knows, of course.

About Jesse & Julian

Jesse Rubenfeld is the founder and CEO of FinOptimal. You can connect with Jesse on LinkedIn here, and learn more about FinOptimal at finoptimal.com.

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 connect with Julian on LinkedIn here, and learn more about Cashboard at www.cashboard.co.

Interviews with CFOs about AI is an interview series by Cashboard. We speak with finance leaders who use AI in their day-to-day work, and ask them really detailed questions about their setup.

If you’re a finance leader building with AI, we’d love to interview you! Email julian.rowlands@cashboard.co with a quick summary of what you’ve used AI to accomplish, and we’ll get a call booked.