EP4 Software Performance Obligations

Discussion around the types of software performance obligations (POBs) and what differentiates them.

Transcript

EP04 Software Performance Obligations

Published: April 13, 2023 

Welcome to the RevRec Gals Podcast, where two consultants with over 30 years combined experience share stories about the implementation and challenges of revenue recognition accounting.

I'm Susan. And I'm Natasha. And we are the RevRec Gals.

<Natasha> Welcome to today's episode of RevRec Gals. Today, we're going to be talking all about performance obligations, sort of focusing on the software, tech world side of things with software, term-based license, SaaS. I'm super excited to jump into this. 

 Susan, why don't you start us off with what you've seen as some of the misconceptions or confusion on this particular topic?

 <Susan> I think the biggest confusion comes in anything that's over time. Perpetual software is pretty understandable. You're giving a license; the customer doesn't have to pay for it again. They have the right to use it in perpetuity. It may not work in their operating system in the future, but that doesn't mean they don't have the option. The biggest misconceptions I see are, people see time-based and think, oh, I can just recognize revenue ratably over time, and I don't have to think about anything upfront. I don't have to worry about professional services or support or separate performance obligations. And I think that really goes into what we wanted to talk about today of the time-based software versus SaaS. What's the difference, and how do you account for it differently?

 <Natasha> Yeah, I think you’re spot on is that over time piece. And I think it's sort of holding on to old concepts because under ASC 605, often there was no difference in the accounting treatment because term-based licenses didn't have VSOE for that upfront component, and so, the performance obligations are combined and recognized over time. Under the new guidance, under ASC 606, that's not necessarily the case. People have this tendency to feel like it's an over time performance obligation, it's an over time deliverable, so we're going to recognize it over time. And often people can also be very confused on term-based or time-based versus SaaS. What's the difference? Because often from an end user perspective, it could be very similar, but I think that's where you get into the legal side. What are you actually receiving as a customer? What are you actually getting a right to as a customer? What's the architecture, the technical aspects of how this is being delivered to the customer? Are they being delivered a cloud-based offering where you have a right to access something such as a SaaS offering? Or are you actually getting a software license where you have the right to download and this upfront software functionality that is being delivered to you in a technically different way than SaaS, but with a time-based component, which is very different than the perpetual where you can use it forever?

 <Susan> I see the difference between perpetual and time-based is instead of the customer paying multi thousands or hundreds of thousands of dollars upfront for the software and then paying for the support component or updates and upgrades component, in a way you're allowing the customer to pay for it over time because you're breaking that price into an annual fee or multi-year fee, but yet it's still the same type of thing where you've sold them a license and then you're providing support and/or updates and upgrades.

 <Natasha> That's a great call out because really the perpetual and the term-based licenses are the same thing. The difference being they have a limited time frame to use that same software functionality even. It's a limited time frame. It's almost like saying, I don't want to say payment plan, but they're essentially saying, hey, we don't want to buy the perpetual [license] upfront and pay for the whole thing. We're just going to pay for it a year at a time or two or three years at a time.

 <Susan> Which is also nice given that technology changes, so the customer is not tied into this software that five years down the line, they want to go with your newer product. They can just commit to a limited amount of time.

 <Natasha> What I see also is sometimes there's confusion in the language around these. These are three different things from an accounting perspective. And I actually think it's kind of funny how we as accountants end up really understanding the nuance between these things, more so than other members of an organization, because we have to get the accounting right. Often, there are other members of an organization that don't really care whether it's perpetual or term-based or SaaS, and some companies will offer all three of a very similar product. They offer all three of these things. Getting clear on, do you call it a cloud-based subscription in your contract, or are you calling it a term-based software license, or a perpetual software license? I've seen startups that are selling a cloud-based SaaS product, but their contract template says software order form. I know what they're providing, ultimately, is cloud, but man, the paperwork is confusing.

 <Susan> That's very true. I mean, we've talked a lot about the contract, and there are times where I'll had to say, okay, what do you mean by this term, because I think it means something different to you than it does to me.

 <Natasha> Yes, exactly. And that's where really you can't take a contract at face value, and you can't necessarily take someone describing their products to you at face value, because I sent some questions to someone in charge of sales at a startup, and they wrote back that they had term-based licenses, and all of a sudden I'm like, oh, your accounting is going to completely change. And then when I dug into it, no, they just have cloud subscriptions, but in their mind, they're term-based or time-limited, because it's true, a cloud-based subscription has a time limit to it, but that doesn't mean it's a term-based license. Getting into the nuances is really important, and sometimes it even takes talking to the technical team to really discern, are we actually selling a software license? Are they downloading it? Do they have a right to the code, or are they accessing something in the cloud?

 <Susan> That's interesting you talk about the cloud, because when you talk about the cloud, it sounds to me you're talking really about the SaaS, which stands for Software as a Service. So, software as a service being you've got the software out there, they're accessing it, you're going to be providing additional features, additional functionality, updates, upgrades over time as they become available. That's always a key thing. And the customer has a right to those automatically just by their right to access the software. One of the questions I have for you is, what if the customer is holding that software on their own site versus on a data site that's owned by the vendor? Is it still considered SaaS?

 <Natasha> So I think what I'm hearing is, you, Susan, are selling me some sort of software functionality that I will have access to. And I think what you're asking is, am I accessing this on Susan's servers? And I log in to a website and Susan is hosting it, and if Susan's servers go down, I no longer have access? Or has Susan provided me the code, which I have then stored on my own servers, and if Susan's servers go down, I still have access to my platform? Is that what you're saying?

 <Susan> Yeah, so the nuance to that is, you may have the software on your servers, but I'm responsible for updating and upgrading them, and maintaining them.

 <Natasha> Oh, that's a good nuance.

 <Susan> I've seen clients where their end customer has very strict requirements on who can access software and what can come in and out of their network. They may be a government entity or network or health care, something like that. And so, it's sort of this hybrid where they want to host it, but you're still responsible for it.

 <Natasha> Typically, what I've seen, as always, right, every instance is different and has its own nuances. Typically, what I've seen is if a company has the right and ability to download that software and to continue to access it on their environment, it's considered a software license, whether it's time-based or perpetual, and even if it's hosted by a third party. So maybe they're not even hosting it. Maybe it's hosted by someone else completely. But ultimately, they have the right to host it themselves. They have the right to download that functionality. It's their software to use. Whether it's ever updated, upgraded, or maintained, they could continue using that software as it is today. And they maintain that right over time. And so, I think as long as they have the access to that functionality on day one, where Susan Incorporated could go up in flames tomorrow, and you could still use that software, to me, that's a software license that's been transferred at a point in time.

 <Susan> So alternatively, I've seen where the location of the software is really more of a technicality. The vendor is responsible for that software, and the end user only has the right to it during the term that they've signed up for.

 <Natasha> So like a term-based license?

 <Susan> No, it's really more of a SaaS model, where they have the right to the maintenance, the updates, upgrades. The only right that they have to the software is under breach. If the company goes under, then they have the right as part of the breach of contract.

 <Natasha> That makes perfect sense. That's interesting. I haven't come across that, but I can definitely see how you would get there, where it's truly a SaaS offering. Devils in the details there with looking through that legal language, talking to the technical teams. What's actually being delivered? What do they actually have access to? And really looking. Sometimes it's obvious or clear, but other times it's not clear. Another version of this I've seen on a related topic is hybrid licenses, where maybe you have a little bit of both. And where you might have an app that you download to your phone, or an app that you download onto your computer. But ultimately, bulk of the functionality exists in the cloud. And in those cases, you're really talking about a cloud-based offering. And these apps that are downloaded are really just ways to interact with that offering. Or maybe certain information can be available offline if you're not online all the time. And so, I think it's interesting because I've heard people use this concept of hybrid in their selling practices. But it can be very different than what we think of it as hybrid from an accounting perspective. And so that's, I mean, just to add to the confusion of is it software, is it cloud or SaaS? Maybe it's both.

 <Susan> So when you've seen that they have an app that they have to download it in order to access the software, do you have two different performance obligations, one for the app and one for the service? Or is it really just a mechanism for accessing the service?

 <Natasha> I mean, because there is specific accounting guidance out there that goes through some of these examples. And of course, it depends because it always depends. But I think you could have either. And it's really a matter of evaluating. Do you have two separate performance obligations, two separate instances where you really have a downloaded software version of a product that you can use on its own? And if you never access the cloud version, you would be fine. And then, you also have a cloud instance. And maybe they talk to each other, but both of them have all the functionality and could be used independently. Or is it really a mechanism, and it's more of an interface that feeds into that cloud-based offering, in which case, is it really distinct? Does it really meet the criteria of a distinct and separate performance obligation? And of course, there's all the instances in between those two extremes, right? Both are possible, and it certainly adds to the confusion.

 <Susan> I did have a client who had a software that would sit on the desk of the employees of the customer and access the SaaS offering. But that app that was on each person's laptop had a little bit of additional functionality that was specific to being available on the laptop and accessing. I think it managed the phone. And so, they did assess it to be a separate performance obligation, but it was immaterial in the context of the contract.

 <Natasha> Oh, yeah, that's a great point, too. Maybe it meets the criteria of being distinct, but it's perfunctory and immaterial. It's not really value added enough to be really a separate performance obligation.

 <Susan> Let's talk a little more about time-based licenses. So, we know that when we sell a time-based license, if it's a one-year, two-year, three-year, we would figure out how much of that would go to the license performance obligation and how much would go to the services or updates and upgrades. What happens upon renewal? So, say the customer bought two years of time-based license and you come up upon renewal, do you do that calculation all over again? Or is it just now a service offering?

 <Natasha> With a term-based license, and often is the case with the perpetual licenses too, is there always sold with this idea of continuous updates and upgrades, maintenance, maybe some support? And most companies just plain don't sell it without that component. And so, with a term-based license, you have this access to the software that's delivered upfront, that functionality, just like with a perpetual software, there's a time limit to it, but it's all delivered upfront. And then you have this ongoing support and updates and upgrades that is over time. And so, when you first deliver it, you have, in most cases, there are some exceptions where you would not do this, but in many cases, you'd have this upfront revenue recognition and this over time revenue recognition. Now we come up to renewal, do we still do that? And at least from what I've seen, the case is yes, because when that renewal happens, you are getting an additional right to that functionality. Now it's already been delivered, right? You already have it. But it's not until you actually sign that contract that you have the legal right to continue to use it past a certain date. Where I think people sometimes might get tripped up conceptually here is if you have a January 1 to  December 31 term-based license for a customer, and you're trying to get them to renew December 15th so you can get that license revenue this year. You can't because that actual right only exists next year. And so, you actually have to delay that upfront component, even though you're still going to separate it. You have to delay that upfront component until your current term-based license ends. I think that's a little bit counterintuitive for people. They think once you sign it, you have the right. But the guidance maybe anticipated people doing that, and so you really do have to push out that revenue recognition to the end. It's like the latter of when you actually have the right and then the end of that previous contract. And then you still have that overtime component too.

 <Susan> Let's talk about SaaS licenses. SaaS seems pretty straightforward. You're providing this cloud service over time, the customer has the right to access, and as updates and upgrades are provided, they have the right to access those. Is there any difference if you have multiple customers using the same software versus each customer having its own instance of the SaaS offering?

 <Natasha> So I've seen different offerings where there's dedicated servers or dedicated infrastructure to a particular customer. Again, that's maybe a requirement for a specific type of entity, whether it's banking or healthcare or government. But ultimately, the offering is the same in that they're both cloud-based offerings or both you're accessing a platform versus downloading a software or getting rights to a software. And so, maybe it's priced differently, maybe it's sold a little bit differently, maybe you pay a premium, and so that would certainly feed into how you allocate and your SSP, but it's ultimately the same nature of the product. That being said, I would imagine, I'm curious if you've seen, have you seen where this dedicated infrastructure has actually made someone flip-flop from SaaS into perpetual term-based?

 <Susan> It comes down to the contract once again, and it comes down to what rights does the customer have at the end of the term. So, do they have the right to then, after X number of years, own the software, or does it revert back and they just have no access any longer, except to the data that they've perhaps accumulated in the system? And going back to your language of the contract, it can be time-based, but if they have that right to the software at the end, are you really giving them a perpetual license? 

 Talking more about SaaS, what about, there are a lot of times where you have professional services that go along with the SaaS. You have the installation, you have the administrative setup, and things like that. How do you deal with these as a performance obligation?

 <Natasha> You know, it's funny, I just had a client that I was working with on this, and I think it's really, there can be a lot of confusion for people because there's a lot of guidance out there, and there's a lot of people trying to structure their contracts in a way that their industry peers are doing it, and sometimes the language can get confusing So typically for a SaaS-based offering, you have some sort of subscription over a period of time, but sometimes there might be this upfront component or this upfront fee, and it can take different forms. It could be phrased as a setup fee or an activation fee. It could be sizable, or it could be not very big compared to the overall amount in the contract. What they mean by setup or activation or even implementation could mean that someone on the backend, an engineer, copies an instance of their offering, and they send someone [the] login [details], and it took them all of 15 minutes. In other instances, they could mean an implementation process that means configuring a sandbox and testing and training, and it could take six to eight weeks. From the provider's perspective, it might cost them six to ten thousand in labor in order to implement that software. And so, I think this is where we're really getting clear on what are you actually providing here really makes a big difference, and you really have to dig in. What is setup? What do you mean by that? What is implementation? What do you mean by that? And sometimes it could even be implied. Maybe they don't even have it in the contract, but there's this implied service that comes up just to get people onboarded, whether it's a separate line in the contract or not, and that ultimately could sort of meet the criteria of a performance obligation. Have you seen confusion around that too, or what have you found?

 <Susan> I have seen confusion around that. I've also seen where there are professional services that are requested [separately]. One of the things that you have to think about when you're talking about that installation and administrative stuff is, can the customer even use the software if you don't do it? Is it a requirement in order to use the software? I've seen where there's professional services that occurs after the service has begun, where it's really a true professional services request. So, it may be bringing on another server, or it may be enabling another router to work with the software. And it's a one-time charge, and it's non-recurring, and the software is usable with or without this addition. It becomes more usable if you do it. And so, there are times where you can actually take that professional service as a truly separate performance obligation that may have its own method of delivery. It was interesting because I just dug into this. I'm so glad we're talking about it. When you dig into it, if someone else can provide the service, if someone else can provide those implementation services, somebody else who could be hired, maybe you could do it internally, maybe you still can't access the functionality without it or use it the way you intend to use it without it, but there are lots of people out there that can do this [service] for you. That's a pretty good indicator that you're probably moving to an area where you have a distinct performance obligation. 

 What was interesting in this scenario is that this particular company does not open it up so that other people could provide the service, so they don't provide access to third parties or the company, but the nature of the services are really more configuration than they are customization in the core software, because on the other side of this, we've talked about the functionality, and then we talked about the separate distinct, very clearly separate performance obligation. But then there's this idea of customization that is really like, we're developing software and functionality specifically for you, that is part of our core functionality of the solution that we're offering you. And that's where you get into this idea that it's not distinct. So, what was interesting to me is that when you dig into it, it's really more about the nature rather than can someone technically do it. Well, no, because we don't open it up. Okay, well, then what does it actually look like? If you open it up and other people can do it, then it's a little more obvious. It's clear. If you're not opening it up, then it's like, okay, let's dig into this little more. Let's talk about what is this person doing? How are they doing it? Et cetera. You know, it really can get sticky.

 Going back to your point before, it's about truly understanding the products that are getting sold. Let's talk about something that everyone's got. Let's talk about the software that comes on your everyday items like a laptop or an iPhone or things like that. You have multiple softwares. You've got your operating system, which that little chunk of hardware is not going to do anything but fill your garbage can unless you have an operating system on it. You then have what I would call your discretionary software. Which mail application do you want to use? Using Apple Mail or Outlook or Google Mail or Hotmail or whatever option you have. What are some of the things you've seen that need to be considered when you are looking at performance obligations related to things like an iPhone?

 <Natasha> I just looked at the 10-K for Apple, and I was a little surprised because in my mind, I was expecting to see two performance obligations. And they actually had three, and I just hadn't thought about it ever, but it totally made sense. So, when you think about an iPhone, I know there are probably people out there who can use these differently, but to me, an iPhone without the operating software is a really expensive paperweight. You literally cannot use it as it's intended to be used without the operating software. Now, I'm sure there's some really cool engineer that could probably figure out how to do it themselves, but ultimately, 99.999% of iPhone purchasers are intending to use it with the operating software and literally cannot use it as a phone without it. And that's really, does the phone turn on? Can you turn the volume up and down? Can you make a phone call? Can you text someone? What is core to the solution or the product being sold? What I expected to see on the 10-K was the updates and upgrades because my husband always makes fun of me whenever he looks at my phone. I'm like way behind on the updates, and no wonder it's slow and glitchy. And ultimately, I can use the phone as a phone with what's delivered upfront with the phone itself. But the updates and upgrades make it run a little bit smoother, makes all the apps that I downloaded work a lot better. The part that surprised me, so those two I was expecting, this upfront component with the hardware and the software combined as a single performance obligation, because ultimately, the operating software is not useful without the associated hardware to run it on, because you're not going to go buy Apple operating software and put it on an Android phone. It's not like you can go out into the world and be like, I'm going to pick my phone, I'm going to pick my operating software, and I'm going to merge them together. That's just not the case. And so, these are a single combined performance obligation upfront. Then there's this overtime component, the updates and upgrades. And then the part that I didn't think about is exactly what you mentioned, that sort of discretionary apps or software functionality. And when you buy an iPhone, it comes with Apple Mail, it comes with Apple Maps, it comes with Siri. And ultimately, you may choose to turn Siri off, because you don't like the idea of Siri listening to you all the time. You may choose to download Google Maps, because you prefer Google Maps or Waze over Apple Maps, and you could never use Apple Maps, but you're still getting the benefit of that phone. You're still realizing the entire benefit of that upfront performance obligation separately than those other software or applications. And so, I kind of had this aha moment, like of course those are separate performance obligations, because they are essentially committing to deliver those for the life of you using that phone, regardless of whether they're paying for it separately, regardless of whether you actually use it, they have committed to making that available when you buy that phone.

 <Susan> It's interesting to think back to the difference between 605 and 606, because under 605 you had the residual method, where you had to have a value for your updates and upgrades based on standalone selling price. So, if you think of an iPhone, they don't sell support, so there was no way to value that, and their revenue was actually ratable over time for something that you and I would think of as a piece of hardware. And if you start to think about that, there are so many things that now have software embedded in them. I mean, think of your car.

 <Natasha> Yes.

 <Susan> All the electronics on there. You know, at what point then do you end up having like a car recognized over time because you can't value the software?

 <Natasha> Oh my gosh, I love that you brought that up because I remember being an auditor on a... It was like a relatively small startup, and I had come from a tech client on revenue recognition. So, for my office where I was, I was one of the few people that really understood revenue recognition for technology companies. And then I went to this small startup that was a medical device company. And nowhere in the paperwork did it say their software. And I was sitting there scratching my head like, guys, there’s software, like the software that makes this medical device work is the primary component. If you look at it, it looks like a piece of hardware that looks a little bit like a dental office chair with some sort of metal hat-looking thing, like a hairdryer. There's nothing medically happening when you sit down in this chair if you don't then turn on the operating system and the software that makes it work the magic. It was funny because in the work papers, they're like, oh, it's just a piece of hardware. It's like a car.

 <Susan> It's more like a computer.

 <Natasha> Yeah, it's more like a computer. It's just a fancy chair associated with this computer. The lines are certainly blurred, and I think that's a great point on how the guidance, the 606 guidance really does a much better job of reflecting that.

 <Susan> Thanks for listening to this episode of the RevRec Gals podcast. Join us biweekly as we explore the practical application of ASC 606. We would love to hear from you. Please leave a review, comments, or topic suggestions on your favorite streaming service, or check out our website at revrecgals.com. 

 The examples discussed are based on specific company dynamics. Check in with your auditors before making changes to your current processes. 

 Specializing in revenue recognition may result in employment for life. Please consult your friends and family before pursuing this career.