Switch back to main site : Click Here
.jpg)
Noah: Welcome back listeners. Today we are continuing our new series, Growth Mode On, sponsored
by our good friends at GrowthMatch.com. Growth Match helps tech companies grow their audience, supercharge their sales, and activate thought leadership in their industry. They are turning entrepreneurs into thought leaders one video at a time, and by utilizing fractional growth teams. You can learn more by checking out their website at GrowthMatch.com.
Well today I have a special guest on the CodeStory Podcast, Jesse Rubenfeld, the founder of FinOptimal, prior CFO of LimeWire and controller at DeShaw. He has extensive experience in financial operations and automating them. Jesse, thank you for being on the show today.
Jesse: Thanks so much for having me, Noah.
Noah: Absolutely. Before we jump into FinOptimal and all things there, tell me and my audience a little bit more about you.
Jesse: Thank you. I'd love to. I started my career at LimeWire doing everything you do when you're an entry level accountant, data entry, copying and pasting, entering bills, even filing some paper back in the early 2000s. As a coding enthusiast, I started trying to automate as much of that as I could. First, I learned Perl from some of the people around me. There was a lot of developers there. Eventually I learned Python, and those skills allowed me to speed up the accounting function I was charged with many fold. Over time, I started looking for ways to export that skill beyond my full time employer and start to do that for private clients that were on QBO. That's where FinOptimal started.
Noah: Perl then to Python. What did you do to learn those languages? Did you just grab a book and go? Did you go through some sort of micro course? Tell me a little bit about that.
Jesse: It's funny. If we'd had the internet in 1998 the way we do today, I probably would have been a developer right out of school. I would sit in the computer lab trying to... I remember I took an intro C class and had to make a program simulate the knight's move on the chess board. How's the knight move? I was sitting in there in the lab at one or two in the morning banging my head against the wall. This is pre-stack overflow. I'm like, I should not be spending my college time this way. I resolved then, okay, I'm not being a developer. Years later at Limewire, when I was trying to automate stuff, there were other developers around that I'd say, how do you get the bank balance? In those days, there weren't APIs for banks. You just had to write a robot that would go onto the website and pull the thing. Someone had to teach me, hey, put a cron job in place and then use this pearl, that functionality to scrape the HTML and process it this way. Here's how you save an Excel file or a CSV file. It was begging, borrowing, and stealing the time from developers wherever I could get it until my boss would be like, okay, those people have a job. Leave them alone. Then I'd go bother somebody else. If we had stack overflow back then, everything would be different. Eventually for Python, it was a lot more self-taught, but I always depended on, and FinOptimal in fact is set up this way, a very open culture where I could just walk around, ask other people what they were doing, tell them what I was doing, hopefully work in environments as I generally did where people weren't threatened by that. Hey, yeah, here's how I do this. Here's how I might try what you're trying to do. It's very collaborative and generous, much like the open source community on which so much important Python code is based.
Noah: I'm really glad I asked that question because nowadays you jump into the internet, you learn a language, and also you connect to any sort of API out there, right? But you were having to do some nitty gritty stuff, scraping websites, building robots, and beg, borrow, and steal developers time. That's a really cool story and a great foundation for how you set out to do this thing.
So when we're talking about FinOptimal, let's start to center around that. My first question is this, why should startup founders care about accounting? As a startup founder myself, I know that day one, that's not the first thing that comes to my head, especially being the product guy. So why should startup founders care about accounting?
Jesse: In short, accounting, accrual accounting is the language of business, and you need to
speak it to talk about your business with investors, employees, and customers. For SaaS companies, let's take deferred revenue. You get paid upfront for a year's worth of software.
It's not revenue in that first month, only a twelfth of it is. They prepaid 12 months. If you don't book it correctly to reflect that deferral, your ARR and your MRR numbers won't be right. Any tech founder that's reporting ARR and MRR knows how much their stakeholders care about those numbers. So take that concept and apply it to all your processes as a tech founder. Think about payroll, think about contractors and other expenses, bank and credit card charges. There's a lot of leverage you can get out of your financial data when you keep it clean and organized in a way that makes sense for your business.
Noah: That makes a ton of sense. So then what is finance automation? Give me a definition there and why does it matter? How can it transform someone's business?
Jesse: Simply put, finance automation is using software to automate back office finance and accounting tasks. So think charging customers, paying bills, calculating and booking accounting entries and then reporting on that data. The scope of the automation varies based on company size and industry. We're hyper-focused. FinOptimal is focused on the accounting automation, which is a subset of finance automation. I want to distinguish here between the work of automating the organization of accounting work versus the execution of accounting work. Organization means task management, document collection, time tracking. Distinguish that from the execution of the accounting, which means calculation, data entry, recording of journal entries, which for FinOptimal's clients happens exclusively in QuickBooks Online. There's automation and automation assisted. Automation assisted is, let's take the example of you have a CRM and you win a deal, you go in and mark the deal closed won in your CRM. Then the accountant downloads a report, calculates some stuff and queues up entries, filling up, like they fill in a template and then they do an upload. That's automation assisted. The accountant is still doing a lot of the heavy lifting there of getting that stuff into QuickBooks the way it needs to look. Full automation is when the deal's marked as closed won, there's something that sees that status change, invoices the customer automatically and it calculates the entries automatically, recording everything in the correct period. Think back to the third revenue example I gave at the beginning. The benefit of this automation, there's a couple of key benefits. The first is visualization. See your key financial metrics when you need them. I mentioned before MRR, ARR, but also gross revenue retention, which is another way of inversely expressing churn. Investors and other stakeholders want to see that. See the results of your experiments, your business experiments in financial terms. When you try something new, you want that feedback to flow through to your financial system quickly and that will give you more faith in the burn rate, the runway and these you express and toss around that are fairly difficult to calculate without a strong system of doing so. The other benefit beyond visualization is optimization. You didn't start your business to worry about accounting. If you're doing things manually or with traditional accountants, your cost is going to increase as you grow. It's going to be mostly linear and with automation, it's going to be sub-linear. You're going to reduce errors. Your accounting system is going to scale with you from the standpoints of both cost and ops and you're going to save a ton of time, which of course is the most valuable thing to all of us.
Noah: With my next question, I could probably extract from what you're saying in the automation piece, but I want to ask this kind of openly and give full space for your answer. It's around the intersection of engineering and accounting. Why does that matter and how are you blending that at FinOptimal? Again, with the automation talk and the optimization around the systems, I can get where you're going to go, but I want to hear what you have to say there.
Jesse: I sat through implementations before I was really an expert in this stuff, general ledger
implementations in larger organization environments where there's consultants that are technical people that come in to implement your accounting system. Then there's a group of accountants that are talking to each other. They have a two or three week engagement to try to figure out what to have the software company build. What I learned is that accountants often don't know what to ask for and engineers don't know enough accounting to know what to offer. You wind up with these somewhat Frankenstein integrations that have the wrong fields or fields that are using different functions than what you really need.
Noah: That sounds all too familiar.
Jesse: Most of software is about mapping. It's not about ridiculous AI algorithms, which are great. Have someone on your team that can stitch that together. So much of what FinOptimal does and what we see other people doing is about moving files to the right place at the right time. It's about having enough fields to do exactly things that are not technically daunting. It's just about spec’ing it out correctly and being able to very nimbly adapt.
When the engineers build something and then they realize they got close but missed the mark a little bit, wow, the accountants are not using this field or wow, they're still entering it twice into this other place. I don't understand. Being able to process that very practical feedback and then tweak the product to adapt and really help the accountant, that's the engineer-accounting gap that we're trying to close. That's why having done all the work, filed the paper, entered the data, copy and pasted all that stuff at the beginning of my career, under the guidance of great accountants that taught me how to think about the role of the accountant as the eyes and ears of the business, to treat the business's money like it was my own money. Being able to take that mentality and the understanding of how to do a strong financial close to trying to build a product helps me focus. We're trying to build a culture where our team focuses. The accountants that know code focus on building something that's really going to get the job done rather than just automate something. We're trying to revolutionize an industry that's been stagnant for many, many years. That requires the intersection of these two disciplines. It's not enough to be an accountant talking to a coder or an MIT grad who hires some smart ex-controllers or CFOs. We're really trying to build a culture of people who either know both coming in or are coders interested in accounting or accountants that are willing to learn to code.
Noah: Makes so much sense. When you're building things in engineering, when you're connecting systems, APIs have come a long way from the time when you were having to scrape sites. They've grown a lot. They've become easier to use. A lot of them still aren't perfect. They still have gaps and probably don't expose everything that needs to be exposed. Tell me from your perspective, what are some of the limitations you see in these native APIs?
Jesse: Unfortunately, a lot of times the QBO integration, the QuickBook Online integration that third-party developers build is an afterthought. It's a marketing tool or it's a minimally viable integration that will get the accounting done at the coarsest level, but it won't really facilitate the kind of accounting we're talking about. It's very, very frustrating. A lot of payroll providers, for example, will book payroll entries at the summary level. Here's your total gross pay, your total taxes, and fees. Three lines for what is every software company's biggest expense, their payroll. That's very common. Maybe they'll book it by department. I'm not going to name any names here of payroll companies. We figure out how to work with all of them in a way that really books these things correctly. Typically, we'll have our clients just turn off the QBO integration and we build our own. Having an accountant design the QBO integration, ideally as an engineer, but if not, then certainly with engineers, right? You'll figure out you need to book the payroll by person so that you can see the spend by department, by city, by manager, whatever it is that matters to that business. Compare that with a summary of the native API and you understand, wow, if I want to see profitability by client, I need to know how much each of these people are costing me. I know how they're spending their time, but I can't figure out how much this client is costing me because the payroll data is booked at the summary level. I have some other more peccadilloes that I can talk about on a tech-focused podcast, but where accounting is concerned, that's really the most common thing. They're just bereft of the features you really need. You can't get the granularity of detail and you wind up having to integrate directly with that third party's API to get the stuff out of their software service, to munch the data, to book it correctly, which is to say at the level of granularity and dimensionality that the client needs into QuickBooks.
Noah: Okay. Then that's actually an interesting segue. I think you sort of answered this, but there's probably a little bit more meat there with the native APIs and the apps that tout that they're QuickBooks integrated, right? Is it the same sort of flaws that you're seeing in those applications that you have to pull data out from them in order to make it actually work? Is that the main flaw there or are there others?
Jesse: That's a great way to sum it up. I think I'll try to be specific again with a tech-focused crowd here, and there's going to be a lot of coders, of course, in your audience. A big problem is completeness, right? The APIs, a lot of these companies are still not API-first software companies, and you can't get all the data that you need from the API. Sometimes we have to have clients or our own team download payroll reports, right? Save them to a Dropbox folder, which then our magic sort of processes, but there's not an API call that will get you that. So that's the first big flaw is a lot of data is available with the API, but not all of the data. So you wind up sometimes having to just throw out the API altogether and be like, we can't use the API to get the accounting data. We have to have a person manually download this thing. Why are they making this thing available in the UI of the web and not also from the API? Right? So that's certainly my biggest peccadillo.For services that, there's other services that we use data from, like Harvest or Time Tracker data or Shopify or all sorts of project management tools. They're all really, really good. Their APIs by and large are very, very strong. And by and large, they're very complete. A lot of them are very complete. It's just that the accounting section of the API is not complete. If you're going to pull from Shopify, for example, the order data, you can get all the
order data you want. Each JSON blob is hundreds of lines for each order. So those APIs are very, very strong. It's just that when you need accounting data, it's so specific. It's not that I fault these companies. It's so specific. You could book things a hundred different ways. You ask 10 accountants, how should I book this consumer packaged goods revenue? You'll get a hundred answers. And so it's hard for a software company to build it. You really need a very accounting-minded engineer to come up with a use case that's going to support all those different use cases. You kind of have to build the most granular integration so that accountants can come along and season to taste and be like, all right, I don't want every paycheck. I just want something by department. All right. I don't want every department. I want the whole payroll booked as a summary. They can water it down however you want, but you want your API to support the most granular integration that an accountant might want. The only thing other than that would be change data capture. There's still a big problem with deletions. We're trying to cache data locally, so we're not hammering your API every time we need to do something with a large quantity of it. Create and update endpoints are really good. Give me everything that's been updated since this timestamp, created or updated. You can get a whole bunch of data, but if something gets deleted, which is often supported in the web UI, there's no endpoint that says, hey, tell me what has been deleted so I can roll forward my cache and catch up with you. And I'm not using cache data that has stuff that's already been deleted. So change data capture would be my only...QuickBooks is great about that. They have an amazing change data capture endpoint. I wish every software service did.
Noah: You mentioned earlier dimensionality and combining that with that lowest level of information so that accountants can season to taste. That really connects the dots for me. You have to be able to serve everyone. It sounds like not every accountant needs the same thing, which is probably why things like OLAP cubes and different tools like that where you can slice and dice how you need to became popular for a while. You probably are still used to that, I'm not sure. But whether you can slice and dice and roll up however you want to.
Jesse: Totally. I think a lot of it... And again, none of that slicing and dicing is mind-boggling. You're never going to have an engineer or an accountant that's like, oh, that's really difficult. I don't know if we have the compute for that. I don't know if GCP can handle it. This gets back to having that API that's got everything at the most granular level so that you can season. Generally speaking, more detail is better. But for example, if you're selling stuff on Shopify, you don't want every order in QBO. You're just littering your QBO instance with tons of data that's not relevant. You don't want every customer in their address that ever bought something for 10.99 from your website. You want to book daily summary entries or monthly summary entries. But you do want to break that up by product. You want to book taxes separately. It's an art. It's an art and a science. And the dimensionality is about... You do need dimensions. QBO has class. They have another one that barely anyone uses called department. These are just multipurpose fields that QuickBooks makes available. There are times when even that's not enough fields. And we have ways of packing additional information into those QBO entries so that our analysis can support dimensions beyond just the ones that QuickBooks makes available. But a lot of people are talking about dimensionality just because you often need more fields than whatever software product you're using is working. The flip side is people get carried away and they have so many fields. They're like, oh, wow, I can have so many fields. And then they come up with, they overuse it and then it's not well organized and you wind up having to enter the same data into multiple fields. So it really takes a lot of forethought to stitch together a strong accounting system based on QuickBooks online, but that's what we're experts at.
Noah: Okay. So then this will be interesting. How can finance automation eliminate 80% of manual steps in your accounting and bookkeeping? We've talked a lot about automation. We've talked a lot about engineering and tooling, but how can, you know, specifically automation eliminate this much of the accounting and bookkeeping processes? Great question. Double data entry, gone. You know, calculations, automated reporting, continuous. Right. That's my summary. It normally consists of hundreds and hundreds of keystrokes, mouse clicks, uploads, downloads, spreadsheet wrangling. You know, that's how, that's how I came up, right? Once a month, we've got to calculate the nav and we've got to like deliver this and we've got to report budgets to actuals. And so there's like, I think of it like a slot machine in Vegas, where there's an accountant who gets in front of that machine and pulls a giant crank and then a bunch of stuff comes out and then they've got to carry the coins over to this bucket, right? And it's a real, it's a real rigamarole. Most of that stuff, especially the copy paste, especially the uploading and download can and should be automated. And I really think that it's 80% is probably an underestimate, right? If I look at my own career and the time I managed to save in my own job as a full-time accountant, I think it's closer to 90, 95%. I probably would not have wanted my boss to know at the time, but I do think it made me a better accountant. I was able to spend time thinking about things, right? That most accountants probably didn't have the luxury of having time to think about. And, you know, I guess I want our customers to know that, you know, we're accountants, coders, and most importantly, thought partners. Okay. Those three things together, not one of them by themselves, but all three of accountants, coders, and thought partners, right? Help us achieve that level of automation, right? That thoughtfulness, that time to think through what you're doing, to rethink it, to iterate is key to making the automation work. It's not just taking a software product, throwing your data at it and being like, all right, I'm automated. It requires a thought partner that knows how to code and is an accountant.
Noah: So that, I think that lays the foundation for my last question. At least you've seeded the answer in my mind. You have a traditional accounting firm, right, that you've worked for before. How is what you're doing at FinOptimal different and better, right? And I hear you saying it's the strategic thought partner, the automation, the consistency of information, but I want to hear how you coin that. I will summarize by saying that it's flat fee. The optimization is on us, right? If an accountant is charging you hourly, there's no incentive to get up that automation curve. And I think that there's a lot of accounting firms that have lost some good people that have said, hey, let's incorporate this software tool into our workflow for our clients. And the partner will say something like, we do that, we're going to bill a lot fewer hours and our model is predicated on the hourly, the billable hour. And eventually, that forward thinking software using person is like, all right, I'm tech savvy. I'm not getting anywhere here. I'm going to go work for a tech startup or I'm going to go work for an accounting firm that's more forward thinking. It's about the change from the billable hour to the flat fee. It's about the change of the relationship from the partner to the customer to the relationship between your brand and the customer. We're working with startups in all industries. We're hyper familiar with the modern tech stack. We're always tech focused. At best, accounting firms are accountants and thought partners, but even that's harder to find. You get a lot of people who are just cranking out tax returns. The real gold standard that you want is someone who's going to do all three of those things, be an accountant, be able to write code and be a thought partner. And there's just not that many companies out there yet, surprisingly in this day and age that can do that, but FinOptimal can. If you feel like you're spending too much on your accounting, if you're not getting fast responses from your accountant, or if you're just interested in getting a free benchmarking consultation, please book an intro call with us on finoptimal.com and we can let you know how you stack up from a people, process and technology perspective and give you tangible steps to make a difference.
Noah: Well, Jesse, really appreciate you being on the show today. I've learned a lot about FinOptimal and how you guys are optimizing the process for accounting through automation, through your engineering know-how and through your strategic partnership with businesses. I really appreciate you being on the show today.
Jesse: Thank you. It's been a pleasure. This was a fun conversation.
Noah: I love the point Jesse made about APIs needing to return the lowest level of data to support dimensionality and allow accountants to season to taste how they roll up their data. FinOptimal is supporting the accounting world through strategic partnership, automation and consistency and would make a fantastic partner for your business.
As a reminder, you can learn more about GrowthMatch and their fractional growth teams and packages by going to growthmatch.com slash code story. And thanks again for listening.
.png)
.png)
