Democratized, self-served performance data is what every company *says* they want.

The dream: let anyone in your business ask Claude a question and get good answers. Claude is already connected to your company’s systems (accounting, CRM, database, etc) – should be easy, right?

But when internal leaders actually run these queries, things will start to go wrong – and fast.

That’s because the people asking those questions *aren’t familiar with the shape or structure of the data that they’re querying*, which means they’ll inevitably ask questions that Claude can’t help but misinterpret.

And when Claude misinterprets a question, it’ll give a very confident and very wrong answer.

Fast forward to: chaos, recriminations, a great gnashing of teeth.

A semantic layer solves this problem. It’s like a seeing eye dog for people who aren’t close to the data. It’s how you make sure those people get good answers to the questions they *meant* to ask, even if they phrased things in a way that doesn’t match the underlying data structure.

So do you need a semantic layer?

Yes *if* if you want every department head making fast decisions off their own numbers. (But this requires CEO buy-in and a company-wide mandate – easier said than done!)

No if you’re happy with finance staying the middleman, or if you can’t get that company-wide mandate across the finish line.

Step 1 in answering this question: decide what kind of business you want to run.

This is a culture decision before it’s a software decision

The first question to ask: do you want every business unit leader to be responsible for knowing exactly what’s going on in their part of the business?

That means knowing how many new customers they brought in last month, what they’re spending against their budget, and what their team’s salaries actually add up to.

(I think you should definitely want this!)

If the answer is no – because you’re small, for example – stick with finance pulling and sending the performance numbers.

If the answer is yes, you have two ways to get there.

The first way – the classic, brutal way – is that finance is regularly pulling performance data, filtering it for each org, and sending it out with commentary. Every leader gets their numbers, and every number goes through finance first.

The second way – the way that Gusto does it – is to have org leaders self-serve their own numbers *in addition to* finance’s reporting.

They do this by using AI (ex: Claude) to query a semantic layer, which sits on top of a unified data warehouse configured with bespoke data access permissions tailored to each leader. The semantic layer makes sure queries are always correctly interpreted by the AI.

Now, let’s go deeper on what a semantic layer is.

A semantic layer is a seeing eye dog

A semantic layer helps someone who’s far from the data, and doesn’t know how it’s structured, get answers to the right questions.

Without one, people who don’t know how the data they’re querying is structured will ask unknowingly dumb questions.

Maybe they’re new, maybe they’ve never been allowed near that system, maybe they just don’t live in it every day. The questions make total sense in a vacuum.

But because they’re blind to the data structures they’re querying, Claude will answer wrong. Or more specifically: Claude will give the right answer *to the wrong question*, instead of translating their query into the question *they meant to ask*.

Finance people mostly don’t run into this, at least not when querying financial data or key performance datasets. That’s because they work in the general ledger, the CRM and payroll every day, so they know how the data is stored and naturally ask questions in a way that matches it.

The problem shows up when *everyone else* starts asking, and if you want the business to move fast, everyone else is exactly who you need asking these questions.

A semantic layer is the data unlock that allows individual business units to be self-sufficient and make fast + correct decisions.

Fast business units are how a company compounds

Letting business units make their own decisions and move quickly is how a company compounds growth. You end up with a bunch of little CEOs, each running their own corner of the business, and none of them waiting on anybody to find out how they’re doing.

Napoleon figured this out and used it to conquer most of Europe.

(Forgive me a quick nerd-fest here – I wrote my college thesis on military history, and I’ve been waiting fifteen years for it to be useful at work. My time has come!)

Most armies of his day considered about 10 miles a day when traveling. But Napoleon’s army routinely covered 15 to 20. He did it by splitting his troops into corps, independent mini armies with their own infantry, cavalry and artillery, that marched on separate roads and spread out across the map but stayed within a day’s march of each other so they could back each other up.

They lived off the land, and no longer needed to wait on the supply wagons, while his opponents were still tied to fixed supply lines and moving at the speed of their slowest cart.

In a company, data is the supply line. If every question has to go back to finance, you’re the army waiting on the supply wagons before you can move.

Then there’s the opposite story: Louis XIV.

Starting in 1661, Louis’ finance minister Jean-Baptiste Colbert gave him a full account of the country’s revenue, spending and assets twice a year, written up in little gold-embossed books small enough to carry in his coat pocket. It was the first time a sovereign ruler had access to his country’s complete financial records. But when Colbert died in 1683, Louis stopped looking at them.

At the end of his 72 year reign – spent almost entirely at war with other European powers – France was nearly destitute. He didn’t know the numbers.

(Jacob Soll tells the whole Louis XIV story in The Reckoning, his phenomenal history of accounting, which I can’t recommend enough if you’re the kind of person who enjoys this newsletter.)

Be like Napoleon, and not like Louis XIV. Democratize your data access so that your company can compound faster.

Example: How a semantic layer solves business problems in realtime

Take a VP of marketing at a software company who’s setting next year’s budget.

He’s got roughly $4 million in ad spend. A small slice goes to brand marketing. The other $3 million or so goes to demand generation, mostly Google and LinkedIn ads.

His targets for next year are:

• 2,000 marketing qualified leads

• $12 million of marketing sourced pipeline handed to sales, and

• $6 million of total spend across salaries, vendors and ad campaigns

Ideally he has an equation built from past years that calculates this many dollars on this platform produces this much pipeline, and knows that x pipeline should turn into y revenue.

The goal is to get similar results at a bigger budget, and that’s where it gets hard, because spend levels change what works. If you double your Google spend, do you get twice the revenue or 10% more?

The only way to find out is to spend, watch the results, and move money between channels as data comes in.

Google worked well last year, so he puts 90% of the ad spend there and 10% into LinkedIn.

Hypothetical outcome 1 (bad):

• Three months in he realizes Google isn’t working anymore (the equation broke) and LinkedIn is.

• He moves the money, but by then he’s spent roughly $675,000 on Google ads that weren’t working, and he has nine months left to hit a full-year target.

• Spoiler: he’s going to come up short.

Hypothetical outcome 2 (bad):

• Google is working, so he stays the course.

• But something about product market fit has changed and those deals aren’t converting to revenue as quickly as they used to.

• He can’t see that revenue is converting slowly, so he never changes strategy.

• He hits his lead and pipeline targets, but far fewer of those deals close and pay out this year than planned.

• Outcome: the company misses its revenue number.

Hypothetical outcome 3 (good!):

• Two weeks in he sees more coming out of LinkedIn than Google, so he starts shifting spend over and doubles down when it keeps working.

• Instead of $675,000, he’s capped his Google losses at $100,000, and the rest of the year’s budget goes to the channel that’s actually producing.

• Outcome: He hits his 2,000 leads and his $12 million of pipeline.

The difference between those three outcomes: how fast he sees the data.

But he can’t do this by default because his data lives in five different places, and he doesn’t know how the data is structured.

To solve this, the company needs two things.

The first is a unified data warehouse that combines all the data from all of those systems in one place.

You can also set up role-specific access permissions in the data warehouse. For example, the marketing leader could be granted full visibility into the ads and Salesforce data, and marketing-specific filtered visibility into accounting, payroll and budget.

(Data leaders consistently tell us Snowflake works best for both data storage & access permissioning purposes)

The second is a semantic layer that translates the fields in that warehouse into the way a business leader like him actually thinks about them. Gusto uses Cube.

The semantic layer sits on top of the warehouse and is connected to his Claude, which respects his permissions. When he asks Claude something about data he doesn’t know, like accounting, the semantic layer translates the question properly, because the data team already solved that problem, and he gets the answer to the question he meant to ask instead of the question he actually asked.

Without it, he’ll get confident answers to the wrong questions.

But with the semantic layer in place, he can save his year.

Decide what kind of company you want to be first

So, should you have a semantic layer? It all goes back to the question from the top of this piece. Do you want every department head responsible for knowing what’s going on in their part of the business, and able to check it themselves?

If the answer is no, keep finance as the middleman. It’s slower, but it works fine when only a handful of people need the numbers.

If the answer is yes, you should set up a unified data warehouse, permissions so each leader only sees their own slice, and a semantic layer so Claude answers the question they meant to ask. That’s how you get a company full of little CEOs who catch their own problems in realtime, instead of a quarter too late.

There’s great software out there for semantic layers (again, Gusto recommends Cube.dev).

But you’ll have to build the definitions yourself. Someone on your data team has to sit down and decide what revenue, an active customer and a marketing qualified lead actually mean, write those definitions down in the semantic layer, and take ongoing ownership of them. Gusto’s data team spent about a year doing exactly that.

It’s slow, unglamorous work, but it’s the difference between an army waiting on the supply wagons and one that’s already twenty miles down the road.

Julian Rowlands is the founder and CEO of Cashboard, the AI FP&A platform. 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.

Austin Johnsen is the VP and Head of Corp Dev at Zapier as a team of one. Every time he asked to hire someone, leadership asked him the same question: “Have you run out of things to automate?”

So he kept automating.

He gets a 50-page diligence report on a target in about two hours, for $500 to $1,000 in tokens. A consulting firm would charge him $50,000 to $100,000 and take a month.

He also has his AI agents challenge each other’s diligence findings. OpenAI’s Codex picks apart the first-pass report, pushing the other agents to recheck claims against the source documents. Reading the logs, Austin jokes, Claude and Codex seem to hate each other.

Going in, I expected Austin to have automated the process of buying a company. There’s some of that, but his biggest unlock happens earlier in the process. He built his own live, indexed database of conversations happening across Zapier, and he uses it to figure out where the company has gaps that an acquisition could fill.

Before Zapier, Austin built out the corp dev team at Twitch inside Amazon, and before that he was at Twitter when it bought Periscope. This is our first episode outside FP&A and accounting so it was interesting seeing how sharp Corp Dev leaders are using AI. Moving forward, I’d love to do more of these with other finance functions, like treasury and finance ops. If that’s you — call me!

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

1. Austin’s biggest unlock is a live context layer he built himself and calls Hive. It indexes a ton of activity happening across Zapier, so he can see where the company has gaps and which acquisitions would fill them.

2. He makes multiple models argue with each other. Claude drafts, Codex tears the work apart, and when they can’t agree he pulls in more models through Vercel’s AI gateway to reach a consensus.

3. A diligence report that used to cost $50K–$100K now costs $500–$1,000. It used to be from a consulting firm and took a month but now just needs tokens and takes about two hours. It’s roughly 90% as good.

4. AI hasn’t made deal cycles any shorter. Legal and negotiation still take four to six weeks. The new problem is that AI makes it too easy to ask the target too many questions.

5. Nothing goes out without his review. Hard guardrails in code block sending and deleting, every claim has to cite a source, and he still edits heavily (and sometimes rewrites from scratch).

Austin’s stack at a glance

• Main interface: Claude Code.

• Second opinions: Codex, connected through OpenAI’s command-line tool so Claude can send it work without leaving Claude Code.

• More models: Vercel’s AI gateway, which connects to roughly 200 models, including Gemini and DeepSeek.

• Connectors: the Zapier SDK. It reaches nearly every tool Zapier connects to, even ones without a native MCP connector.

• Context layer: Hive, a self-built local full-text index Austin built with Claude Code. It pulls from Gmail, Google Calendar, Google Drive, Slack, Airtable, Granola, Todoist, Gong, and more.

• Deal pipeline: Airtable.

Austin’s path: New Orleans, banking, private equity, Beijing, Twitter, Twitch, Zapier

Julian: Tell me about yourself. How’d you get to where you are now?

Austin: I run corp dev at Zapier and have been here three-plus years, but I’ve been doing corp dev for a long time. I grew up in New Orleans, went to Penn for college, and was at Wharton for undergrad. I went into investment banking, then private equity. The PE fund I worked at was explicitly non-tech. We literally said we would buy any company other than a tech company, but tech was always what I was interested in.

So I went back to business school to switch into tech. I did two years at HBS, then a one-year fellowship in China with the World Wildlife Fund. HBS sponsors you to go work for a nonprofit for a year. WWF was one of the first nonprofits allowed into China, back in the ‘80s, basically because of the panda logo (seriously). Because they were there so early, their offices were technically inside the Forbidden City compound. During lunch I could wander around the Forbidden City by myself.

Then I came out to San Francisco, did another year of banking, and finally got out of banking and jumped to Twitter, where I did finance and then corp dev for about three years. Then I went to Twitch, within Amazon, and built out the corp dev team there over five-plus years. A couple of other stops, including Patreon, and then Zapier. So four or five years of banking and private equity, and corp dev for 10-plus.

Julian: Any acquisitions you want to highlight?

Austin: The one that got me over to Twitch was Periscope. It was Twitter’s live streaming app. In 2015 or so, everyone at South by Southwest was live streaming on Periscope or this other app, Meerkat. This was before you could live stream on Twitter or Instagram or anything else. My boss found it, and we went after it and bought it.

I was one of the first 500 or so users. It was me and a bunch of random celebrities. Through that I learned a lot about live streaming and got to know people at Twitch, which had just been bought by Amazon. People who’d been doing Amazon retail or AWS didn’t know much about game live streaming, and Twitch was thinking about building in-house corp dev. So playing around with Periscope and random celebs is how I ended up spending five years playing games.

Before AI, the job was 20 two-pagers a week

Julian: What was your job like before you started using AI?

Austin: The big thing, in investment banking and corp dev, is how much manual work was involved. When I was a banker, I worked for a guy who had a reputation for working more than the overworked investment bankers. He was very sink or swim. He’d give me work and assume I’d figure it out.

Every company he looked at or wanted to talk to, he wanted what he called a two-pager on it. You had to pull their financials, spread their filings, type in all their revenue numbers, calculate EBITDA, work out ownership percentages. The tools back then weren’t good enough to trust, so I did it all by hand, 10 or 20 a week. Nowadays you’d type a ticker into a service like Capital IQ or FactSet and it would fill out the report.

There are endless manual things like that we used to have to do, and I would never do them now. But I look back and think, I learned how to read filings so fast and get to exactly what I need. Now you don’t get any of that learning.

“Have you run out of things to automate?”

Julian: Tell me about what you’ve built with AI.

Austin: At Zapier, I’m a team of one. Everywhere before Zapier, I had a team, and when I joined I expected to build one out. But Zapier is a no-code automation platform. We connect close to 10,000 tools. If you’re not an engineer and you Google how to connect Google to Salesforce to Excel, Zapier is the top result.

Every time I pitched our CEO or CFO on hiring someone, the response was always, “Have you run out of things to automate?”

So I started thinking about what I’d actually hire someone for. I track my pipeline in Airtable. I’d type in a company name, then go find its website, a description, its fundraising history. It was a giant pain. Half the time it wasn’t done, or I’d wait weeks or months and then do a cleanup pass. That’s exactly the kind of thing you’d give an analyst or associate.

I couldn’t hire anyone, so I automated it with Zapier. These were simple, deterministic zaps from before AI. Here’s a company, go to its Crunchbase page, pull the domain and the fundraising history, because those are always in the same spot.

The one I could never get working was LinkedIn. I also track who I’m meeting with, so if I’m meeting Julian, I want Julian’s LinkedIn in Airtable. But there are enough Julian Rowlands out there that it would never pull the right profile. That was one of the first places I used AI. Once GPT-3 got search, an AI step inside a zap could use context clues, like your company, to find the right profile. I didn’t need to write 50 rules for finding the right person. The AI could figure it out. Mixing deterministic steps with AI steps exploded from there.

Corp dev is too small for anyone to build tools for, so Austin builds his own

Julian: Can you walk me through the lifecycle of a deal and the AI pieces in each stage?

Austin: At this point I have AI everywhere, and it’s expanded a lot over the past year. By the end of last year, using just ChatGPT or Claude chat with the built-in connectors, I was starting to feel like I’d finally run out of things to automate. I was getting ready to tell my CEO, all right, I can’t automate anything else, I need help. Now, with Claude Code, and more and more with Codex, any idea I have, I describe it and ask it to build it.

That matters more in corp dev than in the rest of the finance org. Corp dev is such a small, niche function that there aren’t many tools being built for us. Any time a startup pitches me on building for corp dev, I tell them the TAM’s not big enough. Go find a better space. Finance and accounting have tons of tools. In corp dev, I was always making do. My CRM is really designed for sales, and I’d force it to work for my use cases. Now I can build custom stuff that actually works.

Hive: Austin built a live index of everything happening at Zapier

Austin: Deals start with strategy, with deciding what we should be exploring. One of my biggest challenges has always been staying on top of what everyone in the company is doing. I have one-on-ones with product leads, engineering leads, and go-to-market leads. But Zapier has about 800 people, and priorities are always shifting.

So I built a full context layer. I call it Hive. Claude built it, it runs locally, and it uses the Zapier SDK to connect to every tool I use. It’s constantly ingesting data across Slack, Google Drive, and email. Now I can ask, what’s going on with this project? Have priorities shifted? Who should I go talk to? It’s effectively a thought partner who knows everything going on at Zapier, and it’s been game-changing for strategy and prioritization.

Julian: How did you build it? It sounds like you vibe coded your own app in the middle of all this.

Austin: I’m not an engineer. I sort of pretend to be one with Claude. Claude Code is the pane of glass I operate everything on, but I’ve asked it to build a lot of scaffolding and code underneath that makes it run better.

Hive came out of a laziness problem. I was working on a deal memo, and I kept having to say, what about this? Did you miss this? Look at this too. When I finished, I asked how many follow-up searches it had needed. It was 160 additional calls to other sources. I asked, how do I make it so you know this up front? It said, well, we could build X, Y, and Z. I don’t know what any of that means. So I said, tell me why I’d want this, give me feedback, and if you sell me on it, go.

Julian: So it’s a database on your hard drive with a table for every system that has relevant information. Is it storing summaries, or every Slack message?

Austin: It’s a full-text index now. I was running into problems where it was summarizing things badly. So it’s a 10-gigabyte-plus file that lives locally. I back it up, and I had Claude figure out a way to back up just the index and the vectors, which is only about 500 megabytes, so it syncs properly. If it ever died, it would redownload all the data.

It indexes my work and personal Gmail, Google Calendar, Google Drive, Slack, Airtable, Granola, and Todoist, where I keep my to-do list. I have a little menu bar app that tells me if it’s falling behind. It’s a green button in the corner of my screen that turns orange or red.

It’s indexed most of what I look at, so pulling up my contacts is fast. But it also knows, oh, Austin’s talking to this company and he’s never talked to it before, let’s see if anyone in engineering has played around with it. Then it’ll tell me, Bob in engineering said something about them in a Slack channel you’re not in. Go ping him for his opinion.

If there’s no MCP connector, there’s probably a zap

Austin: Here’s my plug for Zapier. The Zapier SDK is publicly available, and it lets you hit everything Zapier connects to. If there’s not a native connector in Claude Code or Codex, it’s probably connected to Zapier.

So Hive has access to our Gong and basically every tool at Zapier. Before a meeting, I can ask: Is this company a Zapier user? How much do they use it? What do they pay? Has anyone in engineering ever talked to them?

Make the models fight

Julian: Is Hive the only way Claude Code and Codex connect to each other?

Austin: About six months ago, one of our very AI-pilled marketers kept telling me to use ChatGPT more. I kept saying no, Claude’s better, I’m not switching. She said, you don’t have to switch. ChatGPT has a CLI now. Connect it to Claude Code and you can hit ChatGPT directly from inside Claude Code.

That ended up being one of the big unlocks. Every model comes at things slightly differently, and their answers never perfectly overlap. Now Claude gives an answer, and I can ask Codex for a second opinion without leaving Claude Code. Claude sends it to Codex, gets feedback, responds, and they have a whole conversation without me copying and pasting anything.

The even crazier version is Vercel’s AI gateway, which connects to about 200 models. We have around 150 of them approved for use at Zapier. If Claude and Codex can’t resolve something, I’ll tell it to pull in three other frontier models. It’ll come back with, I had Gemini, Muse, and DeepSeek weigh in, and here’s the consensus. It’s crazy expensive, but it gets better answers.

Julian: Better answers are worth money.

Austin: Yeah, diligence is where we spend crazy amounts on tokens. I have a diligence workflow where Claude, running on Fable, does the first pass on a data room. A bunch of subagents give each other feedback and go check the work again. Then Codex comes in, tears their report apart, and sends them back out.

I’m anthropomorphizing a bit, but it’s very funny watching the logs, because Codex and Claude Code seem to hate each other. Codex will say, I can’t believe Claude said that, it’s not supported at all in the documents. Claude will say, what are you talking about, yes it is, look at these docs. Then Codex will say, well, maybe one of those is right, but the others aren’t. They’re being catty and fighting with each other.

One thing I’ve learned is that the models get lazy. If you expect them to hit every file in a folder, they’ll read five and say, I think I got the gist, I don’t need to read the other ten. So Claude wrote code for me that forces it to ingest every single file, write notes as it goes so it doesn’t fill up its context window, and build an index.

Across a very large data room, that takes 90 minutes to two hours. The output is a 50-page diligence report. It costs maybe $500 to $1,000 in tokens. A consulting firm would charge me $50,000 to $100,000 for a similar report and take a month. Maybe theirs is 99% of the way there and mine is 90%. But theirs costs multiples more, and mine takes two hours.

Julian: Are you just ripping through tokens?

Austin: Yes. I spend a crazy amount. I tell our CFO this all the time. The alternative is hiring someone, and that person is going to cost $200,000-plus a year. I spend a lot on tokens, but way less than $200,000 a year.

And in corp dev, I’m looking at acquisitions where we might spend tens or hundreds of millions of dollars. Worrying about $500 in tokens on a $500 million deal doesn’t seem like prioritizing the right thing. It’s a rounding error.

From 30 minutes to 30 seconds on every banker teaser

Julian: I like to ask for hard numbers in these conversations. How much time did a single opportunity take you before AI, and how long does it take now?

Austin: There are two versions. The first is a random inbound. I get a steady stream of anonymized teasers from bankers. I used to spend 20 or 30 minutes on each one, reading the teaser, looking up the company, looking at the website, pulling up information on the people.

I’ve fully turned that into an AI workflow. It reads the teaser, adds the company to the pipeline, and stages a draft email with next steps. So 30 minutes turned into 30 seconds of reviewing the next-step email, and I agree with its next steps about 90% of the time.

One of those workflows is basically a deanonymizer. Before AI, you could sort of figure out who a teaser was about, but it was a pain. Now, if the teaser has enough detail to actually be useful, the AI is going to figure out which company it is. It narrows it down very quickly.

The second version is actual M&A deals, and this is the interesting part. I don’t think AI compresses the timeline. It lets me go deeper and cover more. But diligence increasingly feels like it was never the bottleneck. Negotiations, legal docs, and drafting still take the same amount of time. If a deal took four or six weeks before, it still takes four or six weeks. I’ll mainly blame the lawyers.

The big thing we’ve had to work on is that AI lets us do *too much* diligence. We were asking too many questions about things that don’t move the needle or aren’t material to whether we do the deal. So we’ve put guardrails in place. Do we really need to ask this question? Does it change anything, or are we just creating work for the target because AI makes it easy?

Claude drafts almost everything. Austin sends all of it himself.

Julian: You mentioned writing a deal memo. Are you writing deal memos by hand?

Austin: It’s a mix. More and more, I’m having Claude draft them. But there’s a ridiculous amount of infrastructure around that to make it good. It wouldn’t do well if you dropped some files in a chat and said write me a deal memo.

Through Hive, it has access to every deal memo I’ve written at Zapier, so it has lots of templates and examples. It has everything indexed about the target. And it has a ton of rules on how to write like Austin.

I try to have Claude draft basically everything I send, including emails and Slacks. Then I edit, sometimes very heavily. The system keeps both versions, its draft and mine, tracks the diff, and generates rules about how Austin writes.

Julian: What safeguards do you use? It sounds like there have been times it said it read everything and didn’t.

Austin: Despite all the layers of prompts and code, I’m still asking, did you actually read everything? I know that was your instruction. I still can’t trust the first draft. For deal memos, basically every time, it does a draft, then reviews it to make sure it checked everything. It goes through multiple iterations before I look at it.

I also have two hard guardrails that are code-based. I guess Claude wrote the code, so maybe it could get around them. First, it can only draft. It can never send anything for me. I’ve blocked it from sending emails, Slacks, things like that. I’m sending more and more of its first drafts as is, but there’s enough weirdness in its responses that I don’t know if I’ll ever let it auto-send.

Second, it can’t delete anything. Even if I approve it, it can only move things to the trash. At some point it said, oh, sorry, I deleted that and I can’t get it back. Luckily it wasn’t anything big.

It also has to cite its sources. Whenever it cites numbers, an argument, or something someone else said, it has to link inline or add footnotes so I can go back and check.

Julian: I’m the same way. Sometimes I’ll rewrite something from scratch on my own just to make sure it’s going through my brain. I’ve caught a lot of things that looked really good at the aggregate level, and then when I zoomed in, they didn’t make sense.

What I took away

Single source of truth comes first, even in corp dev.

Corp dev is as much a strategy job as a dealmaking one. You sit inside the business, talk to the CEO a lot, look at internal projects, and keep an eye out for companies that could fill the gaps. To do that well, Austin first had to build his own single source of truth.

A single source of truth is the first step in everything, and Austin’s is just a different one than for FP&A professionals. His goal is to understand the whole company super deeply, including the conversations, the projects, and the really qualitative work. So he saves and indexes conversations happening in a lot of Slack channels, plus his email, calendar, Drive, and meeting notes. It’s bonkers.

Austin can justify $500 in tokens on a single analysis because he’s buying companies for hundreds of millions of dollars. For a single FP&A report, I think that’s probably too much, and I don’t think you should have to spend it. The cost comes from pulling in so much unstructured data from so many different places. You also don’t need what Austin built for something like budgeting. Budgeting is collaborative, and other people have to submit their projections, like who they’re going to hire next year.

You don’t have to wait on a missing MCP.

Right now everyone is in a kind of arms race to connect their systems to AI, and everyone has that one system that doesn’t give you good data over MCP (Model Context Protocol, the standard way AI tools plug into other software). Some accounting systems have good MCPs you can pull transaction data from. Others don’t.

Austin’s point was that you’re not stuck. Through the Zapier SDK, he pulls from tools that don’t have a native connector at all. I need to dig into this more for finance systems, but you don’t need to wait for a vendor to fix its MCP before you can get at that one other system. Quickbooks, for instance, doesn’t allow you to pull transaction level data via their MCP. Maybe you could get around that with the Zapier SDK.

The smartest people are still doing their own thinking.

Austin is the first non-engineer I’ve talked to who’s running multiple AI platforms at the same time, and he still doesn’t let any of them send anything.

That’s further validation of something I keep seeing. The smartest people I know are still running their checks. They’re not letting AI just send stuff or write stuff. They review everything, and they often rewrite it by hand. The people I come away from these calls respecting the most are not abdicating their thinking to the machines.

About Austin & Julian

Austin Johnsen is the VP and Head of Corp Dev at Zapier. He previously built the corp dev team at Twitch (Amazon) and worked in finance and corp dev at Twitter, where he helped acquire Periscope.

Julian Rowlands is the founder and CEO of Cashboard, the AI FP&A platform. 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.

Last episode I said I’d seen the future. Jeff Cobourn’s team at Gusto delivers budget versus actuals one day after close, and rebuilds their forecasts three days after close. They’re operating at a level of speed and productivity that’s unprecedented in FP&A.

They got there by moving their revenue models out of Google Sheets and into Python, running an agent that grades other agents’ work, and keeping their finance code in GitHub.

But almost none of it would work without Gusto’s data team. So I asked Jeff to introduce me to someone who helped make it possible. That person is Julia King, who joined Gusto two years ago as their Chief Data Officer.

She walked me through their exact setup including the six-month move off Redshift onto Snowflake, and the work of getting finance to agree on what a word like “active customer” means.

I also played devil’s advocate by arguing with her about whether a semantic layer is actually necessary. Isn’t it enough just connect all your systems to Claude via MCP? Why do you need a unified data warehouse + semantic layer, when Claude can already get that data?

She had a great answer about how an MCP server can hand Claude your data but it can’t tell Claude what your words mean (and your words change all the time). I was convinced! Her detailed answer is in the full interview below.

If you only read one thing

• Hallucinations are solved. Unknowingly stupid prompts are not. Claude isn’t making things up anymore. But it might interpret your question differently than you intended it, and it’ll give a correct answer with complete confidence to a totally different question than you meant to ask. When Julia’s team digs into why, the math is almost always right and the question just got understood differently than the person asking it meant it.

• The further someone sits from the data, the more dangerous that gets. You know your accounting data, what the fields are, what’s tagged as what, so when you ask a question you get the right answer. Hand that same access to a marketing lead who doesn’t know that department, class, and business unit are three different things, and they’ll ask about business units, get the departments answer, and never know the difference.

• The hardest part is agreeing on what a word means. Before Gusto’s data team could build anything, they had to sit down with finance and settle whether an “active customer” is somebody who pays or somebody who logs in.

• A semantic layer is how you make that answer stick. It’s a written-down set of definitions — what each table and column means, where it comes from, how each metric is calculated — sitting between the person asking and the raw data. You define “active customer” once, and every question after that uses your definition instead of one Claude improvised.

• Dashboards are alive and well. People will tell you a Claude-generated HTML file does the job now. It doesn’t. You want something persistent, always live, measuring the same thing every single time, sitting somewhere other people can see it. That allows you to catch the errors in real time, and benefit from many eyes on the same page.

• Your accounting data is a free audit of every other pipeline. Gusto pipes the books into the warehouse partly for finance and partly as a check. The close is the one number finance knows is true, so if the warehouse ties to it, the dozen other systems feeding it are probably working too.

“The data team was great. The state of data wasn’t.”

Julian: Let’s start with your background.

Julia: I’ve been in data a very long time. I got into it by accident after college, moved to the Bay Area in 2000 for the dot-com boom and then the very quick crash. I liked being able to look at the numbers and understand the business, and how much impact that could have. So I stayed in data engineering, analytics, and some data science. Mostly with startups.

What attracted me to Gusto was a couple of things. I love the mission, and I like working for companies where what gets built has a clear benefit to the customer. We know how many small businesses fail. Managing cash flow, managing paychecks, understanding what you need to do to hire your next employee — all of that is very challenging for somebody whose actual job is running a food truck. If we can build solutions so they don’t have to worry about it, that gets me excited.

Then on the data side, when I was interviewing it was pretty clear some of the platform investments weren’t up to date. The data team was really great. The state of data at the company wasn’t where it should be. A business with product-market fit, growing at a healthy rate, and still a foundation to rebuild — that’s an unusual combination, and for somebody like me it was exciting.

And I liked everybody I talked to. That’s the third thing. You have to like who you work with.

Six months to get off Redshift

Julian: So Snowflake was already in place when you got there?

Julia: No. That was one of our first big projects. We were on Redshift, which is behind the times, as we all know. The migration took about six months. I laughed, because I just said that’s what it was going to take and my team said that was crazy. They did it. They’re amazing. October 31st was our date, so November 1st we were officially on Snowflake.

But we didn’t want to wait for a platform replacement before starting to build more intelligent solutions. So in parallel we were redesigning how a lot of this data looks.

One of the big projects we talked about when I was joining was a customer 360 view. A lot of companies have built one. Gusto hadn’t, and it’s harder for a company like ours. We’re not a retail business where you buy a SKU and the price is obvious, maybe with a shipping discount. Our products are complex. What do you even consider a product? How much do you charge for it? Subscription services with complicated calculations get harder to store in a way that lets you build intelligence on top of them.

Julian: And you had to agree with finance on what things meant.

Julia: Yes. We worked really closely with the finance team to agree on what an active customer is for a SaaS business. Is it somebody who pays? Somebody who actually logs in and uses the product? How do you want to look at it, and what makes sense? We did a lot of work with that team validating it.

Once we had that, the question became what else they need to see the whole business, not just the customer. Is it a sales-driven motion or self-service? How do we onboard and manage that customer? That’s what gives finance and accounting the ability to look at the P&L in different slices.

Julian: Besides completing your single source of truth, how else do you benefit from having accounting data in Snowflake.

Julia: At the end of the day, that’s the source of truth for how much money we made, because that’s how we close the books. So if our numbers match across different cuts and slices, or if there are differences and we understand what they are (and there always are differences) then we have much higher confidence that our pipelines are working as expected.

It’s killing two birds with one stone. We’re bringing in data the finance team needs to see how the business is doing, and it also lets us make sure we’re not losing anything when we ingest from all these other sources.

Julian: What else did Snowflake unlock?

Julia: We had some Salesforce and we had NetSuite in Redshift. It just wasn’t connected in a way that we could self-serve. You had to build a dashboard with a very complex SQL query to even try to attach it together.

With Snowflake we could bring in more data more easily. Salesforce has a data share with Snowflake, so we pay them extra money and get the data in an easier way, and more frequently than once a day. Up to five-minute latency. For finance that probably doesn’t matter. For some of our other solutions it does.

Our people data (e.g, employees, salaries) also lives in Snowflake, in a separate project. It’s very locked down, most of us can’t see it. But we can data-share between the projects and aggregate in a way that doesn’t reveal anybody’s personal information. If teams need that alongside financial KPIs, it’s a lot easier for us to put it together now.

Mapping is a guardrail problem

Julian: How did you solve data mapping across all these source systems?

Julia: We did a lot of profiling of the data coming from the source systems, and we work very closely with the teams that own them. Salesforce is the big obvious one because it changes a lot. So we make sure those teams understand which objects matter most and will have downstream effects.

We put a lot of guardrails in place so that if things get added or dropped, we get alerted. And ideally they let us know ahead of time, which they do. They’ll say, hey, we’re making these big changes, we’re cleaning up, this might have an impact. We’ve been cleaning up Salesforce quite a bit.

With AI especially, we’re building more and more skills that monitor and alert us that something is changing. We haven’t figured out how to make AI intelligent enough to fix it for us yet. You still really do need a human in the loop there. But at least it identifies that something changed.

So the first pass is the mapping itself. What does this thing mean? Do we understand how the data looks? Does it pass our checks when we compare a calculation across different sources? Once we had that standard view, the question became what observability looks like on top of it. A field we rely on is suddenly coming in with less data — that’s a problem, go look at it. ETL (extract, transform, load) failures are more obvious. If it fails, of course we go look.

Julian: And centralizing helps with that.

Julia: One of the benefits of centralizing is that the more people looking at the same dataset, the more likely somebody notices when all of our checks have missed something.

At an aggregate level a metric might look fine. Cut it by five different attributes and suddenly it doesn’t make sense. You might only be missing one or two percent, which is a lot more noticeable in a subset than in the total.

So this is why I vote for: if we need a dashboard, let’s all look at the same dashboard. If you use our self-service tool to generate your own answer — great, but please do it through that. And if something doesn’t look right, let us know. We have feedback capabilities. Don’t just walk away from it, because it’s quite possible something did happen to that number. Our automated checks can’t catch everything; there are way too many metrics.

If people build their own versions of it, you’re in trouble.

Julian: How locked down is the layer underneath?

Julia: Very. We built an AI copilot for our dimensional models that takes in our naming conventions and requirements, checks for duplications, designs the dimensional view, and requires documentation to go with it. Human prompted, AI generated, then reviewed by a data engineering team before it goes to production.

The good news is our finance team uses this too. They can build new models without waiting on data engineering, and then we review and make sure it makes sense and there are no mistakes. So the cycle of cleaning and adding datasets is a lot faster.

Why the semantic layer doesn’t go away

Julian: What’s the semantic layer tool, and what was it like to set up?

Julia: We use Cube.dev. It’s open source, and they have hosted options too. We’d already been using it for our customer-facing reports, and we were early on as big proponents of the semantic layer, so when we wanted to prototype the AI piece we said let’s try it.

This was a year ago, before a lot of companies had published how they built it. So we were poking at it — does it write a query we like, that we approve of? It worked great.

Then we said, well, it works, but maybe there’s something better out there. We don’t know. It’s lightweight, we can put the documentation we need in it, it’s really easy to develop against, and we have skills running on top of it that look for duplication and make sure it stays clean.

Some people on the team are trying to push us toward Cortex in Snowflake. I’m not sold. I also like that Cube is platform agnostic — if we have datasets that live outside Snowflake, we can still send the query into those systems. We don’t need multiple semantic layers.

Julian: A lot of CFOs tell me they just connect everything to Claude, set up some shared projects, work through it a few times, and it gets it right enough going forward. And every decent system is going to have a good MCP in the next 24 months. How would you answer that?

Julia: Your business changes all the time. The vocabulary you use to describe your business changes all the time. Different systems and different people call things different ways.

So you can have the best MCP server on the planet, and somebody is going to call it in a slightly different way, and there’s no guardrail making sure the AI understands what it’s actually trying to do, uses the right terminology, sends the right request, and generates the right query.

We’ve seen it so many times already. You send a prompt, you get an answer, and it’s “incorrect” — and I use big quotes on that. Then you look through the trace, and it interpreted your question in a very specific way. That isn’t incorrect. The interpretation was.

So how do you guide it? How do you make sure it asks follow-up questions when something is unclear? You need additional context for that, and you need the semantic layer to provide the definitions. Because AI is really good at saying, wait, I’m confused, there are three different versions of this, let me make sure you’re asking about the right thing.

I just haven’t seen MCP endpoints do that, and I don’t know if they ever will. Salesforce has an MCP published. Awesome. But how our instance of Salesforce is implemented versus somebody else’s, and how we talk to it versus how they talk to it, is going to be different. I don’t think that internal semantic layer knowledge base necessarily goes away.

Although I also didn’t think Claude could write a SQL query two years ago. So here we are. It’s all changing really fast.

If you’re starting from zero

Julian: If a finance team has none of this in place and wants to get to where Jeff’s team is, what are the steps?

Julia: The definitions are the hardest thing to figure out and align on. Getting that alignment early and making sure it’s documented is very important, because then building the datasets to attach to those definitions can go fast. You can feed a lot of that intelligence into AI and generate the tables.

Then setting up a semantic layer, whether you do it yourself or buy a third-party solution that has it integrated. We have an engineering team and a really strong data function, so going third party didn’t seem right for us. But if you’re a small company and that isn’t a talent you have internally, I’d look at solutions that provide the semantic layer and the visualization layer, and potentially some of the ETL capabilities.

None of that will work if you don’t have clear definitions of what these metrics are supposed to be.

Julian: Why does the visualization layer matter?

Julia: Because that’s what unlocks self-service. Take your example from earlier — a CFO builds a Claude artifact and it kind of works. That artifact lives in an isolated place where you don’t actually know where the data came from or how it was generated. The lineage, knowing how this metric was calculated, is critical. Otherwise you don’t know what you’re looking at.

Artifacts are great to prototype and move quickly. But in reality you want to build something you can just refresh and rerun. That’s what Jeff’s team has done a lot of work on — migrating their initial prototypes into more integrated solutions so they’re not regenerating a standalone thing every time they want to answer the same question.

I’m not a fan of Tableau, and I’ve become much less of a fan of Looker. There are newer solutions out there; Omni is a lot more agentic and can interrogate your data. We use Streamlit within Snowflake for that layer.

What I took away

Hallucinations are solved. Dumb prompts aren’t.

The failure isn’t fabrication anymore. It’s that you type something that means one thing in your head, the query hits a raw data structure with janky column labels, it guesses at a join or two, and you get a confident answer from Claude that’s answering a totally different question than the one you meant to ask.

“What’s our revenue per active customer?” is a totally reasonable question. Except active customer might be defined three different ways depending on who’s asking, and the definition might have changed last quarter. Did you mean active customers in the last week? Active customers in the last month who are on a paid plan? Just plain registered users?

At Gusto, Julia’s team had to sit down with finance and settle whether an active customer pays or logs in. That conversation happened once, between two teams, and produced one answer.

The further you are from the data, the more danger you’re in

If you’re the finance leader, direct MCPs work great. You know what’s in the GL, you know what’s in the CRM, you know what payroll looks like, so you ask questions that match the shape of the data without thinking about it. Direct MCP connections and a few projects will get you a long way.

Now picture somebody in marketing asking questions without that context. They are going to think they’re getting the answer to the question they asked, and they’re going to get the answer to a different one, and they have no way of knowing. So you’re incurring some steady rate of confidently wrong answers, and you won’t find out about most of them.

One group owns the definitions, or everybody triple-checks

So the choice is this. Do you want one group — finance and data — owning the definitions so everyone else can move fast? Or do you want everyone in marketing and ops and sales triple-checking every answer they get? Or worse still – not checking at all?

At scale it’s obviously the first one. That’s what a semantic layer buys you: you define what each table and column represents, where it comes from, and what it means, and then it’s enforced every time Claude asks. Claude doesn’t go invent its own version of active customer. It just knows, because someone told it.

Julia’s advice to anyone without a data team like hers was to buy something that brings the semantic layer, the visualization layer, and some of the ETL together (which is the thing we build at Cashboard). Her more important point was that none of it works without the definitions, and nobody can hand you those.

The live dashboards matter

Even with all of that, things break. Julia’s team can’t catch everything because there are too many metrics.

I think about this like crime on the subway. The New York City subway is remarkably safe despite the headlines, and not because there aren’t crazy people on it. It’s safe because there are so many people on it that when something goes wrong, it gets noticed fast.

Live dashboards do the same job. A number that’s subtly off will eventually cross enough eyeballs that somebody stops and says wait, that’s not right. That only works if everyone’s looking at the same dashboard.

About Julia & Julian

Julia King is the Chief Data Officer at Gusto, where her team rebuilt the company’s data platform and the semantic layer the rest of the company now queries.

Julian Rowlands is the founder and CEO of Cashboard, the AI FP&A platform. 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.

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.