S4 | E17 | The Future of Finance Teams in an AI-Driven World with Deepak Bapat @ Tabs

Welcome to the Think Data podcast brought to you in partnership with Mydataworks. If you want to stay up to date with the latest breakthroughs and trends in the world of data and artificial intelligence, and if you're curious about some of the strategies that companies and founders use to launch data and AI products, then you're in the right place. Our aim is to bring together a diverse lineup of fantastic guests from the founders, through to accomplished leaders and product owners at some of the most fascinating data and AI companies worldwide. They will each offer you their own unique insight into what it takes to launch and scale a great data business. Thanks for tuning in, and I hope you enjoy the episode. Welcome to the Think Data podcast, and today we're getting into where AI actually fits in the finance stack. and why most teams are getting it really wrong. I'm going to be joined by Deepak Bapat. He is the CTO and co-founder of Tabs. They are an AI native platform that is automating contract to cash end-to-end. We're going to cover the difference between AI native and AI layered, what it really takes to build a zero error environment and what finance teams look like when AI starts running revenue workflows. Welcome to the show, Deepak. It's really, really good to have you on. I would be really interested to touch on kind of your background and for the kind of the audience that's not seen you or heard of Tabs before. Launched about three years ago, you've obviously come from that kind of real classic kind of software engineering background, ex-Latch, what spent six and a half years there. When was that kind of epiphany of kind of head of software engineering, growing tech company to founder. I'm really intrigued by that.

And so it's like building intelligence, isn't it?

Hmm.

It became a, the way people solved it in the past was a lot of manual work, classic SaaS, but still required some level of like janky engineering to plug a bunch of systems together. And we realized, well, we can always start with the base of the contract as the base of the customer relationship. And from that, we can build a real customer relationship. And LLMs kind of give us this superpower. And we learned that really early on. We kind of noticed that pattern where there was going to be this commoditization of reading documents and turning on structured data into structured data. And we just needed to make sure that we were almost ahead of the curve on the entire platform. So that's kind of how we started and how we've been building for the last three years.

And talk me through that kind of the early days, because you said you obviously you went into startup life. You know, you're building trading systems and you realize actually startup life with Yext was. Probably more relevant than obviously when you moved on from there. But what were those kind of first six, 12 months like in terms of that? You know, obviously with your co-founders trying to get an MVP to market. And also in chat GBT coming out and obviously version two and then the kind of whole world changed then.

Yeah. So I think those first six to 12 months were interesting. We actually didn't write, I didn't write any software for the first three to six months. And actually, the first product we built doesn't actually exist anymore. It was a hardware. It was a specific product feature that we built. But I think it was a lot of iteration. It was where do we start on the platform? How do we, like, there are a ton of wedges. And at the time, right, like, you know, you listen to people today and they talk about how vertical SaaS, you can't just build one wedge anymore because one wedge is easily reproducible by any one company. You must build more of a platform. So. We got a little lucky just being earlier on in that process. Like I'm more than happy to attribute just as much luck as to skill for that. But in taking advantage of that, I think what we did really early on is we just iterated very quickly. We found a bunch of design and development partners that wanted to work with us, had this need and this problem. And I mean, when you think about those early iterations, it was literally a view only. It was like... You can view your contract and the invoices. That was it. And then there was a question of, well, do we, in finance, there's a whole concept of an ERP or enterprise resource planning tool. NetSuite's a good example. Sage is a good example. Or your general ledger, which is QuickBooks. And all of these have invoicing products. And it's like, do we use the ERP native invoicing? And are we managing all of invoicing out of the ERP? Do we be building it ourselves? There was so much iteration that we were doing. And there's an old Paul Graham essay. where he talks about finding like the smallest atomic value of usefulness and leveraging that and iterating off of that atomic value of usefulness. And so what we found was being able to take a contract, turn it into a series of invoices, even if it's the simplest contract, was the atomic value of usefulness. And then we just every week we're shipping something new to our customers to try and figure out what to build. And I think we've, you know, it's only really been in the last six months, I would say, where we've really been able to almost roadmap more than a month out at a time,

which has been,

it's been an incredibly, like an incredibly evolutionary process in how we've built.

Yeah, it's really interesting. What do you put that kind of that rapid growth recently in terms of shipping those out? Do you put it down to just a, you know, LLMs and how, you know, AI has just progressed so much more, more quickly than we'd ever seen before?

In terms of, in terms of being able to ship today.

Yeah, exactly. You said obviously the last six months we've seen this kind of rapid, you know, increase where we were. Do you put that down to just how kind of advanced LLM is becoming?

I see what you're saying. So, yes, we have seen that happen. I guess the point I was making was more around the fact that we never planned more than a month out up until six months ago.

Oh, I see what you mean.

Now we plan a quarter out and. We generally know what the next six months after that quarter look like.

Yeah.

But for a long time, we were like, if it's more than four weeks out, we are just not going to agree, like agree that we are going to do it. And so. But what I will say is the pace at which we are able to ship every single month has increased so dramatically. And it's been such a cool experience to see how you can leverage all of the coding tools and yourself to almost X your own output. I definitely think that that's something that we are noticing and we are embracing. Yeah,

it's really interesting. I go back to, I think, a comment or a quote that I read about you. about You talk about kind of AI native versus kind of this AI layered approach. And obviously, when you look at kind of tabs, you said the first three months you weren't coding. It was actually just looking at this problem statement, trying to nail that. But specifically around tabs and that evolution of the product, what is that real difference between AI native products and then AI layered? And why is it so important for the domain, i.e. finance and tabs specifically?

Yeah, that's a great question. So specifically the difference. in my opinion, between a layer of AI that sits on top of an existing platform and an AI-native application is how you're thinking about building the primitives and the rails and how you're structuring your data internally. So one of the things that we have found is that, you know, at this point, right, like you can give SQL to one of these LMs, you can give no SQL information to one of these LMs. LMs are really good at is navigating relationships. So there's been a lot of research that has come out around how these LMs can actually navigate like graph databases. So earlier on, we knew that we were going to have to build with the idea that LMs were going to take over large portions of the workflow. And so what we ended up doing was we ended up building a real knowledge graph underlaying a lot of our uh a lot of our platform and our technology and we've we've leveraged obviously materialized views, we've leveraged graph databases, but that was one. The second thing I will say is I think, and getting to a place where I think we were a little bit contrarian earlier on, is this idea of when we started to build AI workflows and agents, we built them as ambient, LandChain uses the term ambient, but background agents more so than something that you are chatting with. So we never built a chat interface into our platform. To us, a chat interface was like something that you put on top of an archaic system of a record to make it a layer of AI on top of your data. But the real way to make something, in my opinion, AI native is to have the agents be the ones that primarily are actually manipulating the data. So for us, what that looks like is when a contract comes in, there are agents and AI workflows that run to process contracts. when emails come in. The same thing is happening when you send out an email. There is there are layers of of intelligence that are working in the background to figure out what the next step in this in this workflow or this process is. And it becomes almost like a choose your own adventure opportunity versus a world in which you've built a platform with very specific steps and rules. And you're just leveraging like a chat bot or some sort of pure LM to just choose between a series of. of structured workflows.

Yeah, it's interesting. It was like AI for AI's sake, isn't it? And just people were bolting this on to no real value add actually. And actually it's interesting how that kind of symbiotic kind of, you know, the structure and layered approach works better and also going back to governance. I think that's the one thing everyone talks about specifically in finance as well, you know?

I think this is a really good call out. I think that specifically when I think about, and the reason we never built a chatbot in Noreplap, form is, and I guess the bet was actually kind of, was pretty good. We have an MCP server. So if someone has Claude or Claude cowork or Claude code or cursor, they can use the MCP server and get all the data and they can chat through these other non tabs interfaces with the data, if that's what they want to do. But I think what we realized early on is, is, is finance specifically needs a level of determinism. Like there has to write two plus two just has to equal four. And so Again, there's a recent paper that came out, maybe it was in February, around how GPT 5.2 is actually quite bad at determinism. I think the title of the paper is like, GPT 5.2 can't count to five or something like that. And fundamentally in finance, two plus two must always equal four. And so there are functions and tools and specific workflows that must execute the same way every single time. If that's the case, adding a chat layer that allows you to manipulate data actually just... adds another layer of non-determinism to a workflow that someone expects to always turn out correct. So I'll give you an example. Our contract processing. So you take a contract, you turn it into a series of invoices, you turn it into a series of performance obligations for revenue recognition. Let's say for a given one of our customers, which we call our merchants, one of our merchants, we're at 97%. That last 3%, the question becomes, is... Is the merchant going to want to click a few buttons in the application to make sure that they get the right output they want?

Yeah.

Or are they going to want to talk to a chatbot hoping that that chatbot will understand what they're trying to say and manipulate the data inside of our system correctly? And our bet has always been they will still want to do the first thing.

Interesting.

At least for now, they will still want to do the first thing because we've all been in a situation. Bye. you know, even with how good the coding agents are, we've all been in situations where you ask the agents to do something, it does it wrong, you ask it to fix it, it does it wrong again. And at some point, you're like, all right, I might as well just, yeah, I might as well just do it myself, right? And like, that works when you have an IDE, it doesn't work if you're just using cloud code with no IDE. And so like, these are the sorts of things that we have made sure we have built our specific AI platform.

for our customer who requires a level of determinism and being able to click a button and say yes i agree yeah i really interesting and on that point what you know when you look at that product evolution of tabs and obviously as the cto and obviously being hands on yourself what's been the hardest part technically speaking to kind of get that end-to-end piece right you know putting the systems together you know taking the data from contracts what's the one what's the problem that's been keeping you up at night thinking god how are we going to solve this you

Yeah, I think the biggest problem is that as you go upmarket into the enterprise, right?

Yeah.

There was an interesting tweet. I don't know who it's attributed to, but it's this idea that as AI native companies go upmarket, there's an expectation from those upmarket customers that your system will mold to now whatever it is that they are doing. Whereas in actuality, they still need, like, you actually have best practices because you have the insights, you have the data, you've seen it a thousand times. They should be molding process just as much to you as you are to them. And I actually think that this is one of the biggest challenges, which is when you say, hey, we are AI, people still expect I can do anything I want and I can do it the way I want to do it. And the answer is actually no. Our system has enough data at this point. And. the tools inside the system are built for best practice to get you the outcomes that you want. It is about being able to measure outcome. I mean, people talk about outcome-based pricing and whatnot, but it is about being able to measure and explain outcomes in the application itself for someone that I actually feel is the hardest problem to try and solve. It's like, how do you explain to some, because previous to this in SaaS, The expectation was almost like I am getting a process. The metrics that you would look at is like, how many times is someone clicking on something? How many times, you know, how many invoices am I generating in the platform? That shows you success. Whereas actually the success that I want to drive is, how are we minimizing revenue leakage while minimizing human capital, right? Like that, that. function, that optimization function is a much harder thing to articulate in platform. And that's what I am actually spending my time trying to solve. Surprisingly, it's more of a product problem than it is an actual technical problem.

Yeah. And you've also got the additional challenge of finance teams. I know you talked about going up market, but if you look at finance teams, just generally, you've got to see the finance teams that are very... technologically advanced they're very efficient well run but obviously your product can make them even more efficient but equally you've got those ones that are very reliant on alps they've got fragmented system setups they've got different infrastructures different databases how what steps do you take to ensure that when you're integrating tabs and you're not ultimately breaking what they've already got is it is that almost again goes back to your point about the product more the education piece and it's you know without a good data environment or good setup it's Oh, to be... plugging AI in is not going to make it any better.

Yes. Like I think I think the way I think about it is like, OK, if we took each of these agents to be labor, let's let's let's make let's take the thought experiment that an agent is just additional labor for for your team. Plugging an agent into a bad data hygiene situation. is not like if you plugged a human in, they would sit there scratching their head saying, what should I do next? Right. And and and at the end of the day, what we care about is getting look at the end, like what we care about is getting as much context into our system as possible for the agent to do its job as well as possible. And so what that oftentimes means is getting data cleanliness in a really good spot. There are companies that we work with where they don't even know where all their contracts are. If you don't know where all your contracts are, how are you supposed to give us your contracts to calibrate? That's like the first step in the entire implementation process. And so it's as basic and as simple as get all of your contracts into one spot. Figure out how you are going to get your contracts into tabs for us to do our job. And like sometimes we have to start that early. So, yes, there is absolutely a data piece because what we are not going to do and what really no. company is going to let us do is just have full visibility into their entire software stack to just figure out where the contracts are like it's just not going to happen yeah i think it's super super valid i know you

talked about kind of whether ai the agents are going to be like an additional resource or you know there to complement what the team is already doing but there's a lot of talk around let's be honest ai agents replacing folk and displacement And. What's your honest opinion around the makeup of a finance team over the next couple of years? If you brought products like Tabs in, are we looking at driving more efficiencies, freeing folk up to do better quality work? Or is there going to be a wholesale shift where the job levels just increase and actually those kind of data heavy, you know, kind of manual heavy work could be replaced?

Yeah, I think it's a great question. Look, the honest answer in finance specifically. specifically our domain, is that we already have a shortage of accountants. In the US, I'm sure it's the same in parts of Europe. There are not enough of top CPAs graduating every single year to make up for the ones that are retiring. And so the way I see it playing out is our job is to make sure that you can, my biggest thing is you can scale your finance team sub-linearly. while your growth remains above the linear line. That is what I believe will always be possible. It's possible today. There's two basically, how do I describe this? Two scenarios that I see playing out in a couple of years. There are companies that already have reasonably sized finance teams. And our job is to be able to drop into that team and be able to allow them to continue to run, handle attrition. So as people leave the company, right? They don't have to bring someone new on. And as they grow, they don't have to bring new people on. The second one is I do believe there's going to be a point where tabs is part of a larger, I'd call it back office suite of agent AI native or agent capable tools. So you can think HRIS, you've got the ripplings, the gustos, etc. In AP and spend, you've got ramp, Navon, Brax, etc. that are all going to be kind of talking to each other. There's going to be like a layer of agent to agent communication amongst these tools. There will be a single human orchestrator that sits on top of it, and you will be able to scale to $100 million in ARR with a single human operator orchestrating a series of agents that are all communicating with each other across various companies' tools.

Yeah, I've been hearing a bit more about that, that kind of interoperability between at different AI agents and... That's exciting. I think, you know, for people coming into this space, they should see, let's be honest, more companies are still hiring more finance focused, just ultimately the way the makeup of those teams will just be leaner and more efficient, but it's not necessarily going to stop companies hiring accountants. That's kind of ultimately.

That's exactly right. And I think in every tech, in every change in technology, I don't think you've actually seen, like, I think that everyone out on our team who uses AI, pretty AI pilled organization, who's using AI for... the majority of their tasks, it's not like they're, they're packing up their stuff and going home at 3pm. Like, there's just more to do. We can just do more with more. And so that's how I think about where this this sort of trend and trajectory is going to go.

Yeah, I love it. And final question for you, what's next? You know, I know, obviously sounds like there's some product things you're focusing your attentions on, but obviously, growing business, you know, there's a lot of companies pouring into not necessarily your space but yeah AI agent is one of the hottest tickets in town right now. So what can we expect to see from you guys over the coming months?

Yeah. When I think about what we are trying to solve for. It is a contract in your CRM goes to closed one and your finance team doesn't need to touch it. And they are, cash is hitting their bank account and they're able to pass a revenue audit from a CPA without having to, you know, do all the back and forth and the what's called revenue cleanup at the end of your year when you go into your audit. Those are the two outcomes that I'm looking to drive. And my expectation is that for the majority of like... our mid-market companies, they will have achieved, let's say Pareto rule, 80, 20%. Like they've achieved 80% of that outcome by the, like my goal is within the near future, by the end of this year, within the next year, et cetera, to be able to get to that point. And from there, we will continue to build, we will continue to expand horizontally, new verticals, et cetera. But that is really what I'm focused on. Build an underlying knowledge graph, build... the road, which is the platform, and then build the cars, which are the agents, such that you can get from this closed 1.A to either of these two destinations autonomously.

Yeah. I've got no doubt it will happen. I think you've been so laser focused in a niche, which is obviously benefits from this AI agent piece and tabs is really, I love the fact you've gone so deep into a use case within that finance piece. um and just nailing it there's a there's a most of the founders have been on here the successful ones are the one that solve a problem in a narrow port in a narrow vertical right it's actually let's just be really good at that and on the car point let's get from a to b as quickly and more as efficiently as possible and it's uh yeah excited watch you guys uh watch you guys grow and i'm sure there'll be uh some really interesting kind of listeners for this one so yeah thanks deepak for coming on this afternoon it's been a really interesting alex thank you so much i I really appreciate you having me on. Awesome. Thanks very much.