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.