Cursor for Finance Teams

0:00 All right, cool. Let's Let's get going. Um Really appreciate everyone jumping on today. Um super excited to do this. We've been um talking about these sessions for non-technical folks for some time. And so, it's always great to kind of show people what we've been working on here internally uh and kind of using Cursor at Cursor uh for finance and accounting teams.

0:25 Um I'm Will. I lead the revenue accounting and order to cash operations team here. Uh I am originally from Australia, live in Seattle now, but I'm down in San Francisco this week uh in our office uh to run this. Before here, I was at Fivetran where we built kind of the revenue accounting function for public company readiness. Before that, I spent time about 5 and 1/2 years at Stripe. Um Originally joining to kind of operationalize uh the 606 ASC 606 implementation. I led revenue and

0:57 billing auto revenue accounting, cost accounting, and billing uh operations there as Stripe kind of grew from 700 to to 8,000 people. Um and also worked on the first version of Stripe's RevRec product. Um which was really really exciting. Um before that though, um worked in public accounting um mostly focused on tech companies in Australia, Canada, and the Bay Area. Um so, I think what's really interesting about this is that I come from this from the practitioner side like as an

1:25 accountant and we're using these tools now um uh as non-technical people. And uh it's been pretty incredible to see what we've been able to do here internally over the last uh 6 months. I joined Cursor uh in November 2025. So, it hasn't been very long and it feels like we've lived an entire life already here. It's been very very busy, but we've been building a lot of really cool stuff. It's been super exciting. Uh I wish that a lot of these tools were

1:52 available uh years ago when I was working at some of my other other jobs. Um the Today is not a product demo. So, if you if you don't know what Cursor is or you're not familiar with what Cursor is, I would say go and check out some of the other workshops. We have Cursor 101 and a few other sessions that are fantastic.

2:11 So, the workshop links are really really helpful. Um the assumption is that people understand at least like how Cursor works or how these tools work in general. Um and I'm not going to do much demoing of our product core product. What it's mostly it's focused on is a is a framework for thinking about how finance teams can use Cursor and then we'll run through a couple of live examples. So, we will do a little bit of a live stuff and all of the things that we're going to talk through based on

2:37 things that we've actually done internally, things that we've investigated internally, things that we've built internally. Obviously using kind of demo mock data. I can't show you everything that we do here. So, we'll we'll show you as much as we can. Um cool. So, talked through this already.

2:56 Um A quick grounding on of what Cursor is. So, it's it's I think of it as an intelligent workspace. Maybe that's not how like a an engineer might explain it, but that's kind of like how I think about it. A part editor, part AI agent that can kind of read your files, connect to your systems and do all the work alongside you. Um three things that matter for finance and accounting is kind of context. So, it can see your entire workspace. So, data files, SQL scripts, GL account mappings.

3:25 Um it's not a blank chatbot. Um connections. Through MCTs, it can kind of talk to all of your systems live, data warehouse, ERP, Slack, Notion, etc. So, you don't have to copy and paste across different chats or conversations or tools. Uh previously when I was not using Cursor, I find myself like doing something in ChatGPT and then going to another tool and like moving across all of these. And and so, Cursor is able to kind of consolidate all of into one place. And then iteration. So, every

3:54 conversation has memory. Um so, you build on each step and then I think that's what actually makes it really, really powerful. You actually um uh can kind of iterate as you go and it can understand through kind of the context window and the iteration process, which I find to be really helpful. You can kind of start small and kind of build over time.

4:16 The the way that I've kind of come to think of it a lot about this is is that like there are kind of two distinct modes of getting value from AI in finance. The first one is is mode one, which is AI as your analyst. So, you can kind of like describe what you need, you get a deliverable back, an investigation, a reconciliation, a memo, journal entries, things like that. You kind of use it once and then you you move on.

4:40 Um think of like every ad hoc analysis that you've done, um every SQL query to answer a question, every pivot table to investigate a variance. Like that's kind of mode one. The AI makes you really, really fast um at the mechanical parts of of doing that. And so, kind of your throughput your throughput is is significantly increased.

5:01 Um mode two is kind of AI as your builder. So, you build something that lives on. It might be a tool, it might be something that your team interacts with, it might be something that runs on a schedule, it might be an investigation some month-end thing that you do. Um it has a workflow, um it has an audit trail, and it's something that kind of like persists beyond, you know, an individual agent chat.

5:23 I think that like mode two surprises people um because accountants don't necessarily think of themselves as as tool builders. Um but when the AI is kind of writing the code, you don't need to be an engineer, you need to know the business requirements. You need to be that subject matter expert and nobody's going to know that better than the person who kind of does the work. Um I think what's been really, really interesting here is that um, we've built, you know, as people started

5:52 to understand more about how to build and how to leverage these tools internally, we've kind of seen like a proliferation of um, of little small tools um, being built by the people who are like the core uh, owners of the workflows. Um, one random story quickly was uh, someone on our collections team built a little tool to basically auto-populate all of our uh, business information for ACH vendor forms, right? Like that's something that was done very manually before. Um, the person who was doing

6:23 that was, you know, working in cursor and had built this process and now it's like a queue system that kind of populates those forms and then someone reviews it and like that's something that was very manual before uh, and quite cumbersome and time-consuming uh, and is now just uh, you know, a couple of a couple of clicks uh, through some automations, which has been really, really cool. Um, a good example though of just someone who like knew that process end to end and knew exactly like how it

6:46 should work and and was able to automate that. Um, the question that we kind of get asked a lot and and we've talked to some finance teams about is is like when do you use each of these? Like when does mode one make sense? When does mode two make sense? And so I like to think of it as like mode one is when the task is unique or unpredictable or a one-off. So if somebody asks a question, you have to do an investigation, um, you've got some anomaly that you want to kind of uh, dive into.

7:12 And mode two is when you catch yourself kind of like having those same conversations again. Or it's like something that's a repeatable process or something that you know is going to occur again and again and again. Those are the types of things that you consider kind of like building into a tool. So we're going to go through a couple of um, live examples. And we'll do two examples of mode one. Uh, one more of like a fast investigation and the other one more of an analytical deep dive. And

7:38 then the second uh, the third example is a mode two example and it's kind of like a build that we that we've done internally here. I'm just going to stop there for a second. Are there any questions so far? >> Two questions from Tom that I thought were great. So Tom was asking first, how are you ensuring version control when you're using data for financial close?

8:02 >> Uh very well. Yeah. So we um we have spent a lot of time on data governance um with our kind of like finance engineering team and our uh finance data team. And so um we we basically run like reconciliation. We take snapshots of things like that and we do like diffs uh as we go. Um I think that we've still got some work to go on on like how this is going to kind of persist long term.

8:32 >> Great. And then another question from Tom was around data management. How do we determine like who owns the data between maybe our our data and analytics team, accounting, engineering, etc.? >> Yeah. Um we're still working to be perfectly transparent. We're still working on that. We've been a very small like function across uh go-to-market uh systems, finance systems, and and data. Um the way that I've historically thought about this though is that you have

9:01 people who like data producers and data consumers. And so like we are a data consumer um and and most of the teams uh that we work with are the data producers. And so having really clear understanding of the kind of like we call it like the contract, the data contract around completeness and accuracy, and timeliness. Um and that is something that you really need to work closely with those partner teams on um and and get to uh a framework and an understanding.

9:30 >> [snorts] >> Cool. >> And maybe one more question before we jump into your your examples cuz I know those are going to be great. Um, how do you think about the like buy versus build um working more towards model mode two in your examples when you're thinking about financial tools and platforms?

9:53 >> Yeah, um Yeah, I mean people have been talking about SaaS apocalypse, right? And like I I I kind of like don't quite buy into that um uh that statement um we like I I some of one of the things I'll show you later is is is uh we automated our contract provisioning queue. It's kind of like an order management process that was very very manual when I got here and that's fully automated now. Um it's not an enterprise piece of software, but it was a true pain point that was preventing us from scaling

10:25 effectively. And so the buy or the build decision at that point was very very straightforward. It was like we know that we are not going to scale as fast as we need to scale um without having some form of automation at this point. And so the it was very clear that we needed to build something. The buying process was going to take um much longer um you know, it would require system integrations and um uh uh you know, vendor onboarding and like all this stuff and we just didn't really

10:51 have the time. So I think that like time is a is an interesting kind of factor to [snorts] consider when you think about buy or build. Um I would also think about scale like time and scale and complexity. Um the other thing that's that's interesting I guess is that when it comes to buy or build is that we um didn't have a lot of internal resourcing when I got here in November to even help us on it on much of this stuff. And so um if there were more complex things that

11:23 we wanted to to uh build, we just probably wouldn't have been able to do that and we would have solved it with a tool. There are all there are also tools that are kind of clearly you know, in that space that do it, you know, very well that are not going to you know, it we're not going to be able to replicate that. >> [snorts] >> Or it's not worth it. Yeah, risk appetite. It totally makes sense.

11:44 Um I think I saw another question quickly that I just wanted to answer. It was, do you position this AI as something that can do the rev rec and accounting close, essentially build up the functionality in AI, or do you position this more to assist accountants in verifying their GL and accounting? I think to to date, it's mostly been the second piece. Um we're not telling Cursor to go off and like do rev rec for like some of our large contracts or anything like that. I think that we are trying to be very thoughtful

12:12 about um uh deterministic um you know, rules and things like that and inputs and outputs that are clearly understandable. Um and so when we are building tools, like in the contract um provisioning um process that we'll walk through in a little bit, there are very clear inputs and outputs for the process, the business process. Um and there is still a lot of complexity around um rev rec and things that there is you know, there is significant judgment involved in some of

12:43 those in facts and circumstances are not always consistent across deals and things like that. So, I wouldn't I wouldn't tell Cursor or any AI tool, just like I wouldn't tell like a junior, you know, intern to go off and like do the rev rec for this specific deal. Yeah. All right, I'm going to keep moving along here. We'll jump over into a couple of these examples. Um One of the earliest examples um leveraging Cursor internally was this and I actually I posted about this on on my LinkedIn cuz it was it was

13:18 pretty exciting at the time. It was basically a uh a question that came in from um someone in the finance team about a issue they we seeing with uh a team that had a self-serve team that had 10 invoices that were stacking up and they were all unpaid. And basically our product or our system shouldn't allow that functionality to or shouldn't actually allow that to occur. Once you have one unpaid invoice, you're supposed to be basically blocked from from using the product. And so

13:45 we were concerned about that obviously and we wanted to kind of run a quick investigation on that. So we did that entirely in person. So what I'm going to do is jump over to cursor now. We'll pull up a new agent. So this is what cursor looks like when you first kind of open it up.

14:01 We've got a couple of side bar this side bar on this side. There we've got kind of like our file file view code view. We've got a browser window here and this is kind of like your your repo um as well and then we've got the side bar here which is all of our conversations and history.

14:20 So we'll close that down. And so what I'm going to do is run through this now. I'm just going to show you like the example of the Slack thread. So this was kind of the Slack thread that came in about this customer um uh this issue that we're seeing. So I'm what I and this is exactly how I actually work through this. I'm going to take this um exact thread Slack thread drop it into cursor. And I'm not going to do anything else.

15:01 I'm just going to leave that and I'm going to hit go. And so cursor is connected to our GitHub repo so it understands our entire code base across our product and so it's also connected to our data bricks instance through MCPs and connected up to a lot lot other tools Slack and notion etc. And so, it's actually able to uh understand and reason across all of those tools you know, instantaneously essentially. And so, what I've done is I've copied that Slack thread into the chat window or the agent window here and Cursor's

15:37 actually going off to basically reason, understand the the the the the question, reason through what I'm asking, and then trying to basically like troubleshoot the the issue. And you can see it's kind of put ahead its own little to-do list here. It's now going off and running through each of these steps and kind of pulling running through its own analysis here like as it goes. And so, I'm just going to let this run for a second.

16:07 I think that what's really cool about this is that like you don't necessarily have to know anything about your code base. You don't have to know any files are, you don't have to know anything about what's happening here. The tool is actually going off and and trying to understand all of that live.

16:23 So, it's going off to try to search for the code base to understand what section of the code base the functions lived in that actually control this product functionality. Excuse me. And it's actually kind of talking to yourself so you can kind of see it's like actually run this earlier as a test so it's actually even looking back at like previous versions of of like the conversation that existed before.

16:58 And now it's starting to actually populate the investigation output here. So, what Cursor has gone off and done is it's now pulled the um issue within the code base. So, this is the actual um lines from the code uh this specific function that has allowed this to happen and it's now actually drafted an example uh sorry a Slack message of like what the problem is. So, it's found the problem. It's identified why this is happening. It's then gone and looked at that specific customer and validated the the logic against this

17:34 customer. And then it's produced a summary for me of all the other teams that are also impacted by this specific issue, the number of invoices that are open, um the total exposure. And then it's actually just jumped out the top 10 customers um uh by open uh invoice value um and kind of like what what's actually going on with each of those. And then it's even proposed a fix for me. So, it's actually come through and suggested, "Oh, this is actually how we would do this uh

18:05 uh correction in the system." Um if I was an engineer, I could actually go and actually create this PR directly from this conversation and push that into production um for review. And so, the entire process can be essentially like shrunk down to one person doing the investigation, looking through the analysis, understanding the output, and then proposing the fix all live um through one single conversation.

18:37 I'm going to also show here um Let's just jump in here. We often get asked a lot of times, "How do you validate findings and things like that?" The way that I typically do this is by if this had found these specific customers, I would probably go and look at Stripe, our payment processing system, and validate that the behavior that I'm seeing in the output here is actually what's happening in the Stripe tool. So, it's just like a quick way to go and

19:28 validate. I wouldn't go and look at every single one of these. I might look at like two or three of them just to make sure that it's understanding what what's going on here correctly. And that that makes sense, the output makes sense. And then here I've just asked it to go and validate, just a validation, and we'll see how that goes. And then we'll basically propose a linear bug report for engineering team.

19:49 And so again, like all of this is happening entirely within a single chat window with Coda going off and kind of pulling all the contacts and everything together on its own. Typically, [snorts] this sort of investigation might take you a day. It might take you a couple of days, and it probably would have involved having to talk to the engineering team, triage in Slack, go and get someone from data analytics to maybe run some investigation, do some scoping. Um

20:20 And then it might it it's it it might then get put on a backlog, or it might get kind of stuck in a Slack channel somewhere. And so, we've been able to kind of do all of that in the space of, you know, 5 to 10 minutes. It's gone and done some additional validation on these accounts. So, it's actually validating the the treatment of these invoices with the function that I identified in the code base to validate that that behavior is matching the issue that was found.

20:55 Um It's also run some additional checks. And then it's kind of proposed the the bug report here. So, this is actually what we might file to the team, the engineering team, and then and can go and um fix that issue in production. Any questions on on that example? I don't know if anything popped up that was interesting.

21:23 How do you give access cursor access to your Git code base? Yeah, I mean, it's a part of the kind of initial product setup. So, once you actually get cursor running, you need to um have a Git uh login um with your company's organization and kind of have that all connected up in that way. Um it's usually something that's set up um and asked for when you first kind of log into cursor.

21:47 Um yes, so there's another question here. For this example, can you also look at your ERP system and see the AR balance? Yes, you could. Um you could definitely do that. Um depending on what system you're using, um NetSuite, if it's NetSuite, I don't know if NetSuite's MC I don't know how well built out NetSuite's MCPs are at this point, but if you have your NetSuite data piped into your uh data warehouse somewhere, you could then further go and do this by basically asking, you know, your data warehouse

22:14 MCP to kind of talk to cursor and ask that question. You could definitely do that. Um churned or inactive? Yeah, you could definitely do that. Um I know there's another question there. It's like, can you see if the Acme has churned or is inactive? You could definitely do that, too. Um you could uh anything basically any piece of data that you can get out of your um Stripe data like your Stripe data tables or using the Stripe MCP, you can go and understand it understand that uh and validate that further.

22:50 So, there's an interesting question there from Tom that said, what if the code base is very long and deep and a detailed monolith with multiple upstream services that goes into the billing engine? How effective is it for cursor to know? So, I I I I hope I answer this question I I I hope I answer this question correctly. Uh I'm not an engineer. I'm not techni- I don't know if I'm technolo- But like, as an example, our billing infrastructure internally, um there are multiple services that that

23:15 finally get down to the table that we use for booking revenue, right? Like there might be like five or six upstream tables and a couple of jobs that run between that. We've been having some challenges with some um data discrepancies in our in our rev rec table. And we're actually able to trace back the uh reconciliation issues all the way back to the furthest upstream table using Cursor. So it can actually go and look at um what tables are feeding what, what are the jobs running

23:43 um to basically produce those outputs, uh were there snapshots, were there actual PRs that got pushed and and made changes to the way those tables are created, and it can actually go and trace back through the entire history of that. We actually did an investigation of that yesterday. So yes, you can do that.

24:02 Can I ground this prompt with appropriate guardrails, rules, and skills? 100%. Um I have not been the biggest user of um skills. Uh I probably should be. Um but you can definitely do that. Um we've actually built a uh a couple of skills internally. The finance team has built what we call um finance assistant. And so this is actually all of our definitions. So you can have this out out here. So it basically has predefined um uh predefined definitions um of like all of

24:38 these different terms that we use internally. And then all the tables of where the the the the canonical source of truth is for each sort of definition. So you can have all of that built out as well. It's been super helpful, actually. >> [snorts] >> This is This is an a good example, I guess, of a situation where if you don't give Cursor the right context, it is totally possible for these LLMs to to go to the wrong place or or quote unquote hallucinate. And so, having a skill file or having some sort of reference file

25:06 that will point it to the correct place every single time it is really important. So, we we use this quite a lot. >> One tip I would give around skills and actually figuring out like how to create some of these primitives is a great time is like right after you've finished a task. So, we actually have a built-in skill called create skill. Um so, like right at the end of a session, let's say you you generated this report like Will just did, you could say like, "Hey Cursor, {slash} create skill to kind of

25:39 codify what we've just done." And now it's very easy for you to reuse and re-go through that workflow um directly. >> So, here is an example of that um create skill flow. Um I saw someone else ask a question, which I think is interesting. Um just around like at Cursor, we use um Stripe for all of our self-service customers uh for billing and invoicing and collections and things like that. And then all of our enterprise or sales-led customers are um

26:08 uh billed through a separate system um and we deal with ACHs and wires and things like that. I don't have to tell Cursor that every time I interact with it. Like if I post a a uh a team ID um for a self-service customer, it understands that and it doesn't I don't have to tell it that. So, it can kind of like also start to um understand um the consistent, I guess, like shape of questions or the shape of requests that you get, which is really helpful.

26:34 Um cool. Um uh Jake asked an interesting interesting question. I I I don't know if Zoe you have a good answer for that or not. Um about how Composer Yeah, Composer 2.5 for finance applications versus more like traditional coding tasks. >> Yeah, that's a great question. Um so I I think you're spot-on there in terms of thinking about like what are the strengths and weaknesses of different models, what was their their purpose. Composer is still at the end of the day designed for engineering tasks.

27:13 So maybe where I would see it shine specifically in financial use cases is like maybe around more of those like data and analytical tasks versus like if you have to write some sort of prose or something like that, like a general-purpose model might be a better fit there. >> Yeah. I think that's actually a huge benefit of Composer is kind of the auto mode and and being able to determine the correct or the determine the best model for the request that is

27:44 that is happening at that specific time. So um if you are doing a pure coding thing, it might suggest that Composer 2.5 is the best for that specific situation. If you are writing an accounting memo, maybe, you know, 4.7 makes sense, but if you run it on auto mode, it's really really good at determining the right um the right model for the right task. Um the next example I want to run through is something um I know we've um just checking time quickly as well. I'm

28:14 going to run through this one actually pretty quickly cuz I really want to get to the the the sec the the last example, which is kind of like something we built internally and kind of run you through that. Um so we process about $200 million a month of self-service customer invoice volume through Stripe um and we are on an IC Plus pricing. So um for those who don't know what IC Plus pricing is, it's essentially interchange plus where Stripe will pass through the

28:36 underlying cost um from the card networks or the issuing banks um to you with a markup on top. You get visibility into uh all your underlying costs, which is something you wouldn't uh typically get access to um when you are just on sticker rates of 2.9 and 30 or something like that. Um this also means though that you actually have control over uh a little bit more control I guess over your cost and you can actually influence um uh how your costs are going to be uh incurred. Um so what we did about 3

29:06 months ago was I worked uh in Cursor to essentially understand and analyze all of our processing costs for a month and then started to basically deep dive into each bucket of cost to understand if there were cost efficiencies that we could be um uh obtaining. And so I'm going to show you a little bit about how I did that. I think this is a little bit more of like a typical finance kind of um investigation, but this is like a deep very very detailed uh investigation

29:37 analysis. Um so I'm going to show you quickly the prompt. Um this is the prompt that we ended up using. Um this is a lot more structured than what I did when I when I was playing through this, but this is kind of like if I could um if I could redo this, this is how I would have written it. Um but basically I'm providing context around like the persona for the specific request. I'm going to give the data um tables and all the different pieces of information. Um

30:11 for this example, I'm going to provide these files because I don't want to use production data. Um but if you have your financial warehouse uh hooked up to Cursor as well, it can go and query all of that activity on its own. You don't actually need to provide that detail. And then I've provided some some specific categories that I want Cursor to investigate. So L2, L3 data quality um certain types of transactions in the US uh are eligible for cheaper um interchange or scheme fees based on

30:42 certain pieces of uh metadata that you pass to the the card net the payment processor. So are we doing that correctly or not? There are certain other types of categories here that you can optimize to get better processing costs. So this is the prompt. I'm going to copy this directly into a new agent workflow. I'm going to drop the files in here as well.

31:04 So the files that I'm sharing are things like history of our oaths. This is all just like demo data. Lots of volume of information here. All of our balance transaction information for the month of March. And then our cost data here as well. So this is kind of like by transaction, what was the card, what was the card type, country, all the interchange fees and things like this. This is all information you can get from Stripe's data pipeline.

31:35 I'm going to drop all that into here. And here we go. This is a pretty detailed analysis. So this is probably going to take a minute or two while this runs. Um but when when I have done this in previous companies, this type of analysis is something that um took multiple days and and required meeting with many different teams to kind of understand one um how our product was actually functioning in terms of information that wasn't wasn't being sent. Um working with our analytics team to

32:11 actually help build the queries and build out basically the um the sensitivity analysis and the understanding of of how our processing costs were being incurred. And then you know, if we were able to change if we were able to move you know, certain types of transactions from L2 to L3 and get a better rate, like how would that impact our overall costs? And so Cursor is actually going to run through that analysis right now based on the prompt that I've shared and build that

32:38 into build that entire thing out. So, I'm going to let this run for a second. Uh and I might just switch over and see if there's any additional uh questions that have popped up so far. How can you This use case, how do you verify that these results are reliable? Yeah, how do you check this? Yeah, um so in this specific instance, what we actually did after this was I went back and I um validated all of So, So, the first part is actually getting the data. So, all the

33:09 data is coming directly from Stripe. So, I'm not um producing anything that isn't um coming directly from the the provider. Um and then I am actually uh cross-referencing and validating this information um with Cursor and then also with Stripe as I go.

33:25 And then what we actually did at the end of this was we built this report and we actually shipped it to Stripe and we asked them to go and confirm what we'd found and then have them come back to us with suggestions on what to do. So, um after we met with the Stripe team, they actually they actually said this was the most detailed cost optimization analysis they'd ever seen and they couldn't believe that it was actually produced by um a tool. Um And so that was that was quite interesting and we did actually find

33:54 some things that we should have been doing uh better and and optimizing better to save us um across uh a couple of those categories that we we talked about there. So, in this case, so you you talk about validation and things like that. Like in in a situation where you're working with maybe an engineering team and it's you know, it's Cursor's helped you identify a specific, you know, bug in code and then a proposed fix. Like I would never go and create a PR and like push that into production. I would send that to

34:21 the engineering team and be like, "Hey, we saw this problem. We've done this investigation. Um we believe we validated it by looking at, you know, Stripe or other sources of information to confirm that um the issue that's being identified is actually happening. Can you please go and like do some final validation on this and confirm what's happening?

34:44 And as you can see here, Cursor is kind of like running through this analysis. Um It's going to take a little bit of time cuz it's quite a lot of data. Uh cloud agents. Yeah, um I have I have been spending a lot of time with automations and not necessarily cloud agents. I Zoe, what how do you kind of think about cloud agents?

35:08 >> Yeah. So, I think you're getting to probably the key use case that I'd recommend for this group. The benefit of a cloud agent essentially is that you the work is being done not on your local machine. So, you don't have to have your computer physically opened for the agent to run.

35:26 So, whether you want to you know, be sitting there and and working on something or maybe you want the agent to be building something while you're in a meeting or at lunch. That would be great use case for cloud agents. But automation specifically are really useful because they're kicked off based off of event triggers. So, let's say every morning at 9:00 a.m. you need a certain process to run or every time you get a message on Slack, you want some

35:50 sort of response to be sent. That's a great opportunity to leverage an automation. What are What are some of the automations you're using, Will? >> Um one of the ones that we just built recently was um So, we have we use a tool called Console and Console um uh is a essentially like a a ticketing system an AI-driven ticketing system that was originally brought in by our IT team.

36:16 But it's got it relies on having a very detailed knowledge base. And so, we built the knowledge base using using Cursor actually. We had Cursor go back through the Slack MCP and create basically scrape 6 months of history from our Slack channels to understand like what were the questions that were being asked and how were we responding to that and were they resolved appropriately. And so we built the knowledge base from that initial investigation and now we've built an

36:41 automation that runs every 28 days to go and look back at the previous 28 days of messages in the channel to then confirm whether we have new pieces of thing new pieces of questions or new new data that we want to add to our knowledge base. So it's essentially like auditing our knowledge base consistently every every couple of weeks.

37:02 So I would like that's something that like you'd ask someone to do and they would just never do it, right? Like they would you'd ask a person to do that exercise and they just wouldn't get around to it. It would be too hard. It would be too time-consuming or it would like fall to the bottom of the priority list. And now we have a an automation that just runs every 4 weeks and it drops us a Slack message and says, "Here's all the things that I found um based on the last 4 weeks of of conversations from your

37:26 Slack channel. Here's the suggestions that I'd make to your knowledge base. Um do you want to approve these or not?" Yeah. Um this is still running. What I'm going to do is it's it's also building a canvas um which is another really cool uh feature of cursor. But while this is finishing, I want to switch over quickly to the mode two example, which is actually a build example. I know we only have a few minutes left and I want to get through this.

37:54 I'm going to root it here. Um so when I joined here in in November, um our product provisioning process for our enterprise customers was um entirely manual um meaning that every time a a sales uh a sales led deal was closed one in our system, someone would run a report um from that at the end of each day, look at all the closed one opportunities uh in an Excel spreadsheet, take that data, put it into another spreadsheet by manually moving it across. Um Then then they would go and download all

38:36 the order forms and validate that the order forms matched what was in Salesforce. And then they would take that information, send it to someone in a Slack channel, and say, "Hey, these contracts are ready to be provisioned." And um this was taking probably an hour, 1 to 3 hours of somebody's time every single day. Um And it was something that it just wasn't going to scale at all. Um and we've essentially had a 10x growth in that process since I started over the last 6 months. And so, we knew that that was

39:07 just not going to be something that we could scale uh manually. So, what would happen is you'd basically get a to reload this page quickly. Um you get an order form that came in like this. You would Someone would take it. They would punch it into the spreadsheet. And they might make a manual error. They might put something in incorrectly. And they would fill out all these fields. They would then go and look in um Salesforce and validate that that information was correct or not correct.

39:37 If there were errors, they'd then have to go and investigate that with somebody on the deal desk team. And then they might, you know, ping someone in Slack and go, "Hey, there's this discrepancy here. What's happening?" Um then you would go into our provisioning tool and actually punch all this information in manually and then hit "Provision team."

39:54 Um hugely time-consuming. What we ended up doing was building a completely automated flow um that runs on a cron job uh every 15 minutes. And what it does is it basically extracts um contracts as they closed one and then pre-populates them into this um uh uh portal or I'm going to call it like a an app that we all have access to and this is a published app within environment and it's actually gated behind after permissions as well so it's only available to the accounting team.

40:31 And so it runs every 15 minutes. It actually ingests new contracts and as it ingests a new contract it actually extracts the PDF from Salesforce and scans it with an LLM and then performs a validation of the Salesforce quote and opportunity data against the PDF objects to determine whether they matches or whether it doesn't match. So this is kind of like a typical order management process occurring here in an automation or workflow that we've kind of built

41:01 ourselves. From here you can see that the system has identified that there was a discrepancy in the number of seats that we were going to provision which is also resulted in a discrepancy in the value of the contract. And so from here what we can actually do is flag this discrepancy to the deal desk team trigger a submission to it for a ticket to go out to them to correct that but at the end of the day the signed order form is the source of truth so we're going to

41:29 go ahead and provision that anyway. So this is essentially allowing us to simplify that process and we can hit provision directly from here and that will automate the entire provisioning process downstream. >> [snorts] >> And then deal desk can actually go in and correct that data in Salesforce and all of that gets logged through a slack workflow as well. This takes about two minutes maybe per deal. You get the view of the order form signed order form

41:58 here on one side you get your reconciliation for systems and you get your queue here on the left hand side. All of this is updating automatically it's doing an extraction it's all tracked and in an audit log so we actually have records of everybody that has touched this, what's been extracted, who's provisioned what. So, you can share all this information out with your auditors or share it with anybody else. Um and then uh yeah, it's the whole the whole

42:25 thing's kind of just running on it on its own cadence. Um if we had not built this process internally, we would probably we're doing 7 or 800 deals a month now. We were doing 100 when I started. This would be someone's full-time job just doing this validation. Um and so, we've been able to scale this process without having to add a single person or a single system through this automation that we built ourselves. Um this type of stuff is totally possible

42:57 um by accounting and finance folks um as long as you've got kind of like the right system structure and set up. Um uh but yeah, huge huge time saver. Um I know we are technically out time, kind of ran a little bit long. I would love to yeah, give everyone a a few minutes to to drop questions into the chat, ask anything that we haven't covered. Um I know there's a lot to kind of absorb.

43:38 Um We have a question here. Assuming there are commissions involved with this deal, once the reconciliation is complete, can the PO be synced to automate the commission payment? Um I'm sure that's possible. Um we haven't hooked up this to any of the other um pieces of accounting at the moment. Um but that would likely be the case. We um are still kind of investigating what commission software we want to use. So, um as we go through that process though of selecting a vendor and things like that,

44:11 you know, having MCPs, having, you know, published APIs are things that we are 100% going to require from from whatever vendor that we go to work with. Cool. It looks like Yeah. Who or what team at Custer's typically driving these automations and workflows? Um I assume I assume the question from Colin there is about who is actually like doing the work to build this. Um we are doing it uh on our own.

44:53 We we've built every everything that we've built internally has been built by us. Um we have not had any any any sort of like engineering folks involved in any of the builds. Um the engineering team that we worked with predominantly at the start was our security engineering team to make sure that we were set up correctly um and that we weren't going to uh you know, break anything. So, we you know, setting up our octa permissions, setting up our GitHub structure, making sure that we had the right um

45:19 uh data brick credentials and uh credentials into uh Salesforce and and other tools. Um but it's been us um mostly. Um yeah. Can you talk about how you built this from scratch? Uh Iris, um do you mind if I go through the process in mode one eventually? Yeah, I think that's a really good example a really good question there that like the two the two kind of um processes that we talked through or the two kind of um flows, I'm going to just flick through it a little bit, but it's kind of like

45:51 they kind of feed each other. You can kind of do an investigation, um understand a problem, and then maybe that turns into a further uh analysis that then turns into some sort of automation that you build. Um we struggle a lot with um fraud and abuse given that we, you know, are are an inference uh provider uh and we have uh built a number of um tools internally to monitor fraud uh and kick off certain certain sort uh types of investigations. And then on top of that, we now have

46:22 like a fraud dashboard. So, we have these investigations and automations running to kind of identify fraudulent activity and then we have a dashboard that we look at every day to kind of like see how that how what the output of those looks like and what we should be investigating and what we maybe shouldn't be investigating.

46:38 How you How do I build this presentation? I built it in Coda. The entire thing was built in Coda. All these little demos and everything um was all built in Coda. Um Yeah, this This is actually This is actually a almost identical representation of the the queue system that we use internally, like our actual queue system, and I had it replicate that in Coda using demo data. So, this is This is actually exactly how it looks, exactly like this. Um The the the the structure on the side is

47:09 a little bit different, but this entire kind of like panel view and validation view and all this kind of stuff is exactly how it works for us. Uh do you members of your team or another Coda team allocate time to leverage Coda for financial market analysis? Um We don't. Uh I'm not sure if you have any thoughts on that. From John, there's a question from John there. >> Yes, this was around >> Yeah. >> At least for I'm not on the financial uh team. I'm on on our go-to-market

47:45 team, so I'm mostly working with our enterprise customers, uh which includes many team many financial teams at some of our customers. Um so, I wouldn't say I specifically have time sectioned out for financial analysis like that, um, but I do think we try to carve out time to actually use Cursor and to leverage it for our own work. Um, that's what helps us be very empathetic to our customers and kind of understand the different use cases and challenges that you guys run into. >> Yeah.

48:15 There's a There's a point there from Avi that it would be helpful to show how to build this in Cursor from scratch with an example. Totally Totally hear you on that. I think that building something like this like you could spend you like it would take a full hour session to probably do that one example. And that might be something that we do at a later date, kind of walk through building a full tool from start to finish. Um, I think the purpose today was try to try to give a little bit more of like the context

48:42 around the framework for thinking about how to leverage these tools, um, in finance. But I totally hear you on that. Makes sense. Um, yeah, have Cursors starting things, kind of workflows across an entire company, weekly internal sessions led by power users. Yeah, um, I would I think that what we've seen has has been a lot of organic growth from the individual {slash} team side that then kind of like um, leaks over into the enterprise space. Um, if you are already using um,

49:22 AI tools, uh, I would definitely suggest like understanding who are kind of like the the the admins of those tools internally and letting know that you want to get access to a tool like Cursor and trialing that out yourself. Um, I think that one of the biggest benefits of obviously working here is that we've had pretty uh, a pretty high degree of flexibility and autonomy to leverage these tools and build for ourselves. So, like I think that we've been very lucky. Uh, I In previous companies that I've worked

49:52 at, that has not been the case, and so I think that we've been able to do a lot because of the fact that we're at Cursor and not somewhere else. So, I totally empathize though with the you know, other companies, maybe a little bit larger, maybe more structured, maybe more mature, going to have stricter, you know, security policies or IT policies or tools, you know, policies around vendor and securities and stuff like that.

50:21 Is the finance team building out their own GitHub repo and using PRs for controls for approvals? Um Yeah, we have a pretty common structure, like a mono repo. So, the entire company has a mono repo. We have a separate section within the mono repo for our accounting apps. And we've built a number of automations within the GitHub PR process as well as leveraging our own BugBot product to to uh run basically like AI review processes over all of our PRs.

50:56 So, if they are low risk, they go through without needing any additional approval as long as kind of BugBot has given it the blessing. If it's medium or high risk, it still requires an engineer approval. And so, we do have a bunch of approvals and workflows and things like that for our PO for our PRs. Um Do you see Cursor primarily being an internal workflow tool for finance versus a customer-facing tool for finance?

51:24 Um Maybe you could maybe Keenan Brown, you can share a little bit more context on what you mean by a customer-facing tool for finance. I'll wait for a follow-up there. Yeah, so with this this specific tool, there's a question there from Jake about how much technical context do you give Cursor throughout the build of this kind of tool? Are you letting it make all decisions and just focusing on functionality, business logic, etc. Um Woah.

51:53 We had worked with our security engineering team here to basically like this was the first thing that we built, the first tool that we built internally and now we have a whole suite of of tools. And it was essentially an exercise first off of explaining to security engineering what we wanted to build and how it was going to function and then they helped us kind of pick the right tools based on Coda's tech stack and how we operate internally. We have other functions

52:19 across the company that are also building their own tools and we're trying to standardize how tools get built. But once you get that framework or that foundation in place, we then kind of have free free reign to kind of go and build on top of that. So get the basics of the foundations in place and consistent across the org and then um you can kind of go from there.

52:43 Um How do you deploy this agent so other team members within your team can interact with the agent? Uh if you're referring to this um what I'm showing on my screen right now, this is not an agent. This is actually a fully built um application that lives um uh and is deployed um within uh uh kind of environment here at Coda. So anyone within the accounting octa group can access this.

53:13 Cool. Um I know we've kind of run a little bit over time. Um Thanks for all the great questions everyone. Uh really appreciate those jumping on. Um We would love to run more of these sessions. So if there is any feedback, we'd love to hear it. Um I think some people made some great points about showing like a full demo end to end of a build. Um we could definitely do that. I think that'd be really cool. Um and there's a couple of other people on my team who

53:40 would be really excited to do that as well. >> Awesome. >> Yeah. >> Thanks everyone for joining. Uh we'll get out the recording and any of the um other resources that that you guys asked for um in the in the notes afterwards. >> Cool. Thank you so much everyone. Really appreciate it. >> Bye. >> Bye.