Revenue Recognition for SaaS Contracts under ASC 606

What is the role of a solution engineer?

Steve Keifer:
So for those in the audience that maybe you’re not familiar with solution engineering, can you tell us a little bit about what that means? What’s the scope of responsibility for your team? What’s your day to day like?

Dan Kullback:
So depending on the company, it may be called solution engineer, sales engineer, solution consultant. But really the role of a solution engineer, especially here at Ordway, is for prospective customers understand their needs. In this case, specific to a business process, billing and revenue automation. Do they have process issues? Do they have controlled deficiencies, gaps? Do they need to scale? And then really take and align our solution to ultimately a process that will provide ROI for them that will make sense to invest in Ordway. First you’ve got to understand ultimately the challenges of that business and then you’ve got to prove it out to them through demonstration, through sandbox accounts, through proof of concepts as well to show that, hey, this is what our product does. This is how it can help your business and really developing that ROI story behind the pre-sale process.

Tell us about your background.

Steve Keifer:
I know we were chasing you for about a year trying to get you to come to Ordway. You had a really compelling background before then. Maybe share with our audience a little bit about your kind of journey to becoming a CPA. What did you study in school? What did you do before you were in Ordway?

Dan Kullback:
Yeah, so went to school at University of Minnesota, go Gophers, got my CPA, joined PwC in their Chicago office right out of school. Found out about this little job called sales engineering, sales consulting, and it was really a cross-section of my interests and my background. So accounting and having that in my bones through getting my CPA, but also, you know, not only just dissecting processes and… finding out and learning about businesses, but going from just picking and auditing and finding what was wrong with being able to present to them how to correct a process or how to really help out a business. Working with people, working with different companies ultimately led me to, through my process or through my time with NetSuite, spent about four years there. Then as you said, Ordway was knocking on my door. was in the middle of the pandemic and had my first child. So maybe took a little longer than an order we would have liked. But after I ripped apart the software and the process and saw what it ultimately could do, the rest, as they say, is history.

What is a simple example of how SaaS companies recognize revenue under GAAP accounting?

Steve Keifer:
Good, well, it was worth the wait. Well, let’s switch gears a little bit. And I wanted to talk to you about revenue recognition. And this is an important topic. And I think it’s well understood by all the large publicly traded companies and certainly by the large private companies as well. But we work with a lot of smaller startups and early-stage SaaS and cloud companies. And a lot of times, they don’t even necessarily have a finance department yet. It’s the founder and the CEO and their dog trying to do it. trying to figure this stuff out. I know when I dug into it, you get quickly intimidated with all these terms like performance obligations and standalone selling prices and contract modifications. But in a lot of cases, the way you end up recognizing the revenue is not terribly complex. Maybe we just start with a simple example to help the audience wrap their head around it. I know we’ll oversimplify here and come back to the complexity in a minute. But let’s just say you had a typical SaaS contract. $1,000 a month, maybe they sign an annual agreement, pay all 12 months in advance. How would you go about doing revenue recognition on that?

Dan Kullback:
Yeah, so huge caveat, right? We’re not going to tell anybody how to do their accounting. Make sure you work with your auditors to get to a process that you define appropriate. But if we’re really getting simple, what you traditionally see out there, and the answer is always it depends, but if it’s simply just pure software signing up, paying 12 months upfront, the biggest thing you have to understand is recognizing over the service period. So even if they pay fully upfront, If it’s a 12-month contract, you’re going to have to typically what we see is delineate, or excuse me, break that up into 12 chunks and recognize it every month, 1 12 over the contract terms. There’s a gazillion different it depends kind of clauses that we can get into in other situations. But really, fundamentally, you’ve got to spread it over the terms at which you’re delivering it from a true SAS model.

What is the history behind the recently introduced ASC 606 revenue recognition standard?

Steve Keifer:
So hold that thought on the complexity and the it depends stuff, because we’re going to come back to that in a minute. But I wanted to give the audience just a little bit more context before we go into that. So all this falls onto the umbrella of this ASC 606 standard for a US GAAP and IFRS 15 for the rest of the world. I remember I was in an adjacent accounting software vendor, FinTech vendor, you know, six, seven, eight years ago when this stuff first came out. And I remember just the look of fear in our customers’ eyes when they were talking about 606 and what a big change it was gonna be. And, you know, perhaps over dramatizing it by talking about it as the biggest accounting change ever and new gap. Maybe you could rewind the tape a little bit and just kind of give us some context for why the FASB switched from 605 to 606 and… what some of the changes they were looking for customers to do in their reporting.

Dan Kullback:
Yeah, I think a few, they gave a few reasons, right? They worked on it with IASB, so kind of convergence with international standards. It says it’s a more robust framework, right? So, more robust disclosures, more robust criteria, they were trying to make it so there’s comparability across industry, really they just had. You know, they’re saying they had the stakeholder in mind to be able to have more information, to be able to read into that on the 10 K read into that and disclosures and, you know, kind of, I think the biggest thing is really improving comparability, right? It would be one of the biggest ones.

What are some of the advantages of using a revenue recognition software application instead of tracking revenue in a spreadsheet?

Steve Keifer:
Got it, got it. Now, a lot of early-stage SaaS companies, they start out recognizing revenue in an Excel spreadsheet, and that makes sense if you’re bootstrapping or you’re in the seed round, probably going out and buying revenue software is not at the top of your list, trying to focus and go to market and getting customers and revenues. Probably a little more important, but as you start to grow and scale, this becomes a lot more important to get right. What are some of the risks? that companies might face if they don’t move off spreadsheets at the right time but a more formal kind of software application. What’s at stake?

Dan Kullback:
Yeah, I mean from personal experience in my audit days, when I would get handed a spreadsheet for support, you go, oh crap. If you’re thinking about doing something manually, one fat-fingered number within one cell can corrupt it. One misplaced or corrupted formula can destroy the whole thing. And then you compound that to revenue, right? And with auditors, the risk of fraud is always very high in revenue. So it’s very scrutinized and very tested. Now you’re talking about doing that all manually and you’re going to have to. You’ll see a lot of testing behind it then, right? And then is one error and it’s going to compound into so many more tests. And the next thing you know, they’re ripping apart everything. The audit fees are going up. You might have a significant deficiency, right? So this is all the doom and gloom stuff was very real. If you can’t have or if you don’t have any IT controls or systems to be able to automate some of the stuff, even the most mundane can become the ugly monster that then you’re restating your financials or you’re missing out on that significant financing because the auditors found something that misstated revenue, whatever it may be. Right, so fundamentally these are doom and gloom scenarios, but Especially when it comes to revenue, that stuff’s very scrutinized and if you can find a way to systematize it, you’re probably just safer and it’s more effective and efficient for everybody.

What are some of the complexities from the five-step process for recognizing revenue under ASC 606?

Steve Keifer:
Yeah, I know that makes sense. And I hadn’t thought about it that way, but yeah, you’re going out and trying to raise venture debt or another round and you’ve got a tier one fund ready to put money into you, but you failed the audit. You could be kicking the whole thing back six months or longer, so makes sense. Now you teased us a minute ago with some of the complexity. I kind of forced you to give that simple example, but indulge us if you would now and how this can get. really complex and maybe those in the audience that are not yet convinced that they need software to do this hopefully will be by the time you’re through.

Dan Kullback:
Yeah, I mean, the procedures, you know, 606 was broken down into five steps. So identify the contract is typically pretty easy, you know, in the case we were talking about software over 12 months paid upfront. Step two is identifying performance obligations. So what that means is, hey, yes, it may be software that you’re selling, but included in that was implementation discounted 100%. So you’ve got these other components that now they’re saying, well, you wouldn’t have had that initial contractor sold that deal without those conditions. Those are conditions now for revenue recognition. So, you’ve got the transaction price, which is step three, but step four, you’ve got to break that out, allocate it, and then step five, recognize it as you’re delivering the service. So, you know, 12 months for the software we talked about, 12 months for maintenance. but implementation only goes four months. Well, you’ve got to figure out how much the standalone selling price, the fair value for each of those are. Pull it out, the equal weight out, or the weighted average amount, or whatever that may be out of the total contract, 12K. Apply it to each, and then have it on its own recognition schedule and criteria. So at face value, it’s very simple, but you’ve got three services bundled in one that they’re saying you now have to account for.

What did you learn from evaluating Ordway’s revenue recognition software before joining?

Steve Keifer:
Got it. Well, at least, well, I shouldn’t say I don’t got it. But I trust that you do and the others that need to understand this at that level of depth. Well, you certainly have an amazing amount of depth and experience on this. And you kind of referenced before kicking the tires on Ordway and when you were interviewing with us. But maybe you could share just a little more. For someone like yourself to come and represent a product and sell it, I imagine you’ve really got to believe in it. What was it that? convince you to make the move over to Ordway when you think about in terms of the product and our revenue recognition software capabilities.

Dan Kullback:
Yeah, yeah. It was really spending tons and tons of cycles with different prospects specifically focused in billing and revenue to understand a lot of the… the common pitfalls, not only between past softwares of use, but just competitors in the field out there. And one of the biggest things that Ordway is, is it is a platform and billing and revenue were built together. So where that, you may hear, hey, it’s the same platform. Hey, it may be this module was built in 2015 and this one was five years later and they don’t always talk together. So knowing the pitfalls, I really did stress test the system before agreeing to come over. It’s just a lot of things in the weeds that I was able to poke and prod at, and it was really truly one fluid product. Where 606 says, yeah, you got to decouple billing and revenue, you still have to have one uniform platform and contract solution to be able to that when you make a change, for example. Right? you’re changing the contract and billing module, that’s got to seamlessly flow into revenue. It’s not always the case with solutions out there, especially if they were built piecemeal, right? Or you acquired a different product to handle a certain part of it. So, Ordway is truly one solution to be able to handle that. And yeah, I beat it up a little bit before I did come over. You’re absolutely right. And that’s just from running through all these deal cycles. and testing out these pitfalls. And by the time I was done, I was very comfortable with what Ordway has to offer, which to your point is why I’m here.

Steve Keifer:
Good stuff. Yeah, I know. I think you’re dead on about the integration, not just between billing and revenue recognition, but that’s a huge issue. It seems like in every technology product where you’ve got data models from two different companies trying to sync up and never perfectly align. Well, thanks so much for taking time to spend with us and educate the audience a little bit about revenue recognition. I know I always learn a lot every time I talk to you, and I picked up a few things here. Hopefully the audience did as well. And thanks to all of you for tuning in and hopefully we will see you again on a future episode of the Ordway podcast where we talk about capitalism’s favorite business model, recurring revenue.