Skip to main content
Sequence

What a finance team of one can automate

Patrick Souris, Finance & Accounting, Fundamental

Fundamental

Patrick Souris is a certified public accountant with around 15 years in high-growth finance teams. He was Head of Corporate Accounting at Gusto, Controller at Fast and at Demostack, and most recently Controller at Descript. He now runs finance at Fundamental, the tabular AI company that came out of stealth in February 2026 with a $255 million Series A. He is a finance team of one, and four weeks into a 12-week course on building agents.

The first thing I built was a commission dashboard in Lovable, and I ran it alongside the old process for two months before I trusted it enough to rely on it.

At the time, we had 10 reps, no head of revenue operations, and the entire commission calculation sitting in a spreadsheet. Every commission tool I looked at cost somewhere between $15,000 and $25,000 a year, which felt like a lot of money to spend on what was ultimately arithmetic.

It took me about four hours to build the dashboard and around $100 in tokens. I wasn’t at the point where I could connect it directly to Salesforce, so I would download a report and upload the data myself.

“When I built it, I ran it in tandem for 2 months. Here’s how we did it before, here’s what the new tool is. And it was more accurate than just manually calculating it. So a check and another check for redundancy. And then once you have the confidence in that, I did it for 2 straight months and it’s doing it 100% without any errors, that’s just the confidence.”

Once it was running, each rep had their own dashboard where they could click into a deal and see exactly how their commission had been calculated, including the standard rate and any kicker for something like signing a three-year term. There was also a what-if box where they could enter a deal they had not closed yet and see what it would pay. Commission expense was calculated monthly, with payouts running quarterly.

I’d say it got me about 80% of what I would have gotten from the tools I decided not to buy.

AI is replacing the staff accounting layer

There is a category of accounting work where that 80% is already enough to be useful.

Think about a transfer between two accounts: the system can match the last four digits, recognize the transfer and treat it the same way it did the month before. When the transaction follows the same pattern every month, AI can handle it well.

It gets harder when the right accounting treatment depends on context. At my last company, our payroll provider was also a customer, which meant the same company could appear as both a payroll expense and a revenue share. One side sat in the payroll tools and the other in a contra revenue account, but the AI saw the same name attached to both and struggled to make sense of it.

That’s the kind of case that keeps me from treating the output as finished work.

“It can do like 80% of it, which used to have a staff accountant do it. You’re still gonna need someone to be driving. Like Tesla autopilot essentially. Yeah, I can do it, but you still gotta be attentive.”

What’s changing for me is the staff accountant layer rather than the review itself. I’m no longer offshoring as much of the repetitive work or hiring someone to do it. The system can do the first pass, and I can review the places where context or judgment is needed.

Check where the data goes in

A calculation can be perfectly accurate and still give you the wrong answer if the data going into it is wrong.

That is the bigger issue with something like commissions, because no amount of prompting is going to fix a Salesforce field that somebody entered incorrectly.

The commission tool could tell me when a contract value or date looked unusual, but it could not independently determine whether the underlying Salesforce record was correct. We handled that earlier in the process: the order form was matched against the record before the deal was marked Closed Won, and somebody on the revenue side verified the metadata against the actual order form.

The tool then gave us another layer of checking by looking for results that fell outside the normal pattern.

“He made $10,000 in commissions the last 3 months. And this month he made $100,000. So it would flag it. The trend has been linear like this, and all of a sudden he spikes because of X deal, you might want to check that deal.”

The same thing could happen with a deal that somehow had a start date in 2035. I use a similar approach for spend, so if team meals that normally sit within a certain range suddenly increase by $10,000 in a month, I want that surfaced immediately.

It’s much harder to catch the smaller version of the same mistake, though. A $1,000 error might still look normal enough to pass through, which is why I use these checks for the biggest exceptions and keep the actual controls closer to where the data enters the system.

Using AI for the first pass on revenue recognition

Revenue recognition is one place where I would not take myself out of the loop.

Our contracts combine usage-based pricing, platform fees, outcome-based pricing, milestones and minimum commitments, and a new order form can introduce a structure we have not dealt with before.

I have a project with our contracts in it, along with fake order forms that I write specifically to see where the model breaks. I can give it 10 things we are considering putting into a deal and ask how it would recognize the revenue, but I can also ask whether it would recommend structuring the contract that way in the first place.

Straight-line recognition it handles well. Milestones it can handle. Give it something like free credits that expire and do not roll over, and it can make an assumption that is wrong while sounding completely confident about it.

“I’ll be like, hey, you’re wrong, and it’ll challenge me that I was wrong, and it’ll go back and forth, and then I’ll finally have to prove it. This is what I did and why. And it’s like, oh, you’re right, I was wrong.”

I also give it source material rather than relying on whatever accounting knowledge is already in the model. I use a web crawler to pull public material on ASC 606, guidance from the big firms, postings and webinars, then use that material to build a rules engine specifically for a usage and consumption business. It is still a work in progress, and I would still put it at around 80% right.

That’s still valuable because it gets me through the first pass on a technical accounting question. Previously, I might have spent days reading before I got to the part of the question that actually required judgment.

“It’s almost like a thought partner instead of having to go to one of these technical accounting firms and spend $800 an hour to just talk back and forth.”

It can also affect how we structure the contract in the first place. If the model surfaces a revenue recognition problem with something the sales team wants to put into an order form, we can have that conversation before the contract is signed rather than figuring out the accounting treatment afterward.

Moving from prompts to recurring workflows

Our forecast now lives in Claude. It took 3 or 4 days of back and forth and probably 10 to 15 versions before I had one I believed, but it is now wired into the ERP. On the fifth of every month, it pulls in actuals, updates the financials and forecasts based on what has happened.

There’s also a dashboard for people who do not want to work inside the model itself, which shows ending cash, burn, burn breakdown, headcount and customer count, with the ability to drill down into what changed. Someone can ask why headcount increased by five people while costs increased by 30%, for example, and get back the explanation that we paid a $100,000 bonus.

That’s part of the reason I’m spending 12 weeks learning how to build agents properly instead of continuing to prompt models one task at a time.

If you have 1,000 transactions in a month, maybe 900 of them look like transactions you have already seen. Over time, the system should be able to learn those patterns, including the context around them. A restaurant expense from somebody on the sales team might need to be treated differently from the same expense submitted by somebody in another part of the company.

“If you get to where the AI is 90% confident that this entry is correct, then you have my permission to book that without me interjecting.”

I’m not there yet. I’m a finance team of one, so for now I’m still the person doing the spot checks. The goal is to get to a point where I only need to step in when the system encounters something it has not seen before or does not have enough confidence to handle on its own.

Get new entries by email

We’ll send you each new conversation when it’s published.