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.
This was an interesting read, thanks for sharing!