EP5 Other Performance Obligations

Join us for a discussion about non-software performance obligations including services, hardware, and contractual requirements that do not impact revenue. 

Transcript

EP05 Other Performance Obligations

Published: April 27, 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.

<Susan> Welcome to this episode of RevRecGals. Today, we're going to talk some more about performance obligations. Natasha, let's talk about maintenance, because there is two pieces to that. There's the support, and there are the updates and upgrades. So how do you see those as being recognized in relation to performance obligations?

 <Natasha> I'm so glad you asked that, because I think that sometimes there's a lot of confusion around that. Certainly, when I was actually meeting with a new client the other day, and they kept referring to maintenance, and really when I think of maintenance, there's two pieces. There's support, which is really the technical support, chat, phone calls, when you need that extra help with the platform, which is also relevant for SaaS companies, for example. And then there's the updates and upgrades, which I think of as really specific to software transactions, whether it be a perpetual software transaction or a term-based license. And so there's really two pieces of it. And typically, they're over time. And often, they're ratably [recognized] over time, where it's provided evenly over a specific contract term or product life. But I have seen instances where the updates and upgrades might have a different pattern of performance than the support. So, when I think of the maintenance as the updates and upgrades versus the support, typically, they're both stand ready performance obligations recognized ratably over time. Often, we can combine those if they have the same pattern of transfer.

 <Susan> One thing I also wanted to note was these two pieces of maintenance are delivered by two separate groups. So, you have technical support, and then you have usually the engineers who are updating and upgrading. So that's also a differentiator that makes them technically two separate performance obligations.

 <Natasha> Yeah, that's a really good point, too. And even when you talk to the technical teams, there's this idea of bug fixes versus new versions or features. The difference between the bug fix updates versus the actual upgrades that upgrade you to a different instance or version or add features, those could be even different teams. 

 As you know, there could be times where they might actually have different terms or different periods that they're being provided over. Did you want to speak to maybe a couple examples of where you've seen that?

 <Susan> So one example is a company I actually worked for where they would sell their product to resellers. The minute the product goes out the door, the customer has the right to updates and upgrades. But they don't really have a need for support until they install the product. What I've seen happen is in order to try to create an instance where the terms are similar, they may add an implied period to the updates and upgrades, so they start as of the day of shipment. And then the support will start either at a set time after delivery, like if you haven't shown that you've installed this product within three months, we're gonna start your support, or we'll start it on the day that you install. So, you end up with slightly different timeframes, but you also end up with this implied period, which you have to incorporate into your performance obligation and the value of it.

 <Natasha> Yeah, that's a good point, because if you have this implied upgrade and update period, where you're getting all the benefits of those updates and upgrades, maybe they've signed a contract for 12 months, and they have 12 months of support, 12 months of updates and upgrades, but really, they have an upfront three-month implied period. And from a value and SSP perspective, that's really a 15-month term, rather than a 12-month term. Now that you're saying that I do recall a client where I had, in most instances, their hardware would ship right away and arrive at the customer pretty quickly. And it was right around the license start date, support start date, and it all happened so closely that, you know, they would track the differences in timing for materiality, but it was never really an issue. However, they did have certain countries that when they shipped, they had to ship internationally. They didn't have local distribution centers. And clearing customs and the shipping took so long that they ended up with that same instance where they had an implied update and upgrade period, but they wouldn't actually start their licenses or their support until the product had actually arrived, which was not the case for the rest of their geography. So, I think this is also something that can be different not only on a business model basis, but also specific geographies might be different or have different nuances.

 <Susan> Yeah, based on type of customer and location of customer. It may also be the type of product. Some products may be treated differently. There can also be implied services even when there's no maintenance contract sold. So, I have seen some startups where, for the first three months, they allow the customer to call in and get assistance with any installation or questions they may have. So, even though they haven't sold support separately, there is an implied support and then there is an implied performance obligation that needs to be accounted for.

 <Natasha> That's such a good point because I've seen where that gets so gray. At what point does that become a performance obligation or not? Because in some instances, you might have a startup that, they're eager to bring on customers, they're eager for their customers to be successful, they want them to have high stickiness, and their sales organization and account managers, they're compensated on renewal rates and people sticking around and paying their invoices and being happy. And so, account managers might be providing some of that white glove service that may go above and beyond and almost border on something that looks like support. And so, it sort of becomes at what point is what they're doing an implied support, or is this just, hey, we're trying to keep our customers happy, good customer service. And I think it's interesting to see that discussion at play because I've seen conversations where there's almost a perspective where, hey, this is just good business practice to keep our customers happy. You know, this is a strategic decision. It's not actually an enforceable right of the customers. But then there's other instances where this implied service does really truly represent support or some other separate performance obligation.

 <Susan> I have seen in contracts where they will have a paragraph about meeting monthly or quarterly to go over project plans or to review stuff. And you bring up a good point, is that a performance obligation within the contract or is that a customer relationship transaction and activity? And so, you really have to dive into what's the meat of that meeting? Is it really driving a project in project management or is it customer relationship and just keeping that going?

 <Natasha> Yes, and I think there's even in the guidance that they even talk about things that are de minimis or perfunctory in the context of the contract. Some of those meetings or reports are, it's just good business practice. When you look at the contract as a whole, it barely is a blip on the radar. In other contracts, it does sort of rise to that level of like, hey, they're paying for extra project management or support or whatever the case may be. It is really a subjective area, and there's no one answer. 

 So, the other area where I think this can get tricky is there is a scenario or a few scenarios, specifically, you see it a lot in the security industry where your support, your updates and upgrades specifically have to be combined with the software itself. And this is actually something that was quite common under the old guidance, under 605, software was always combined with the updates and upgrades because you never had VSOE (vendor-specific objective evidence). That went away with 606, for the most part, for many companies, but there is sort of this exception for some companies. You see it a lot with security businesses where essentially the software that's delivered on day one is useless without those updates and upgrades. And so, there are these instances where the updates and upgrades are not actually a distinct separate performance obligation from the upfront software piece, and you have to combine them.

 <Susan> It sounds like you effectively have a SaaS software offering along with your hardware.

 <Natasha> Correct. And you might see this in, there's different hardware pieces that are sometimes sold with different software solutions. I've had two different security clients with hardware pieces where the software is installed onto the hardware. And in those instances, those updates and upgrades are then combined together. It's just sort of a nuance that I think is important to note because every once in a while, you'll see that. And then it really comes down to evaluating how often those updates and upgrades are pushed out, how many customers are downloading them, can they operate the software without the updates and upgrades, or is it really not very effective without those updates and upgrades? And so, I think that's where things require a little more investigation and review than maybe your more standard software transaction where those things are really separate.

 <Susan> Yeah, again, like we talked about, getting to know the business and what is it, not just what's the language that they're using, but what is the meat and the essence behind what the offering is.

 <Natasha> Yeah, I had two different clients that had this scenario, and it really was getting into the nitty gritty, and that's where you start to get into conversations with the software engineers, with the technical support, with your downloading reports on who's downloaded their updates, who's downloaded their upgrades, what instance are people on, and you really get into the nitty gritty, which can be kind of fun, as long as my head's not spinning too fast.

 <Susan> Yeah, that's the thing with being a consultant, you have to get up to speed really fast on these products and offerings.

 <Natasha> Yes, and everyone always calls everything something a little bit different or throws around their jargon, not realizing that it's a jargon, and I have to slow them down sometimes. Can you remind me what that product is again? So, but yes, the fun part of being a revenue account is getting into the business.

 <Susan> Yeah, and just as kind of a sidebar to anybody getting into revenue and/or consulting is understanding the jargon makes a big difference because somebody may say billings and to a revenue person, that may mean something different. I've had a client where they say billings, I think of invoicing. When they say billings, they're talking about sales comp. Or revenue, the revenue, I'm thinking 606. They're thinking sales numbers and bookings. So just clarifying, especially when you're getting into these performance obligations, what really are we talking about? Getting past the language and the jargon into what is it we're talking about.

 <Natasha> And it's funny because that almost brings us full circle because what I was saying at the beginning is that I had a SaaS company that was signing what they call maintenance contracts. And I said, maintenance contracts makes me think you're selling software which would include updates and upgrades. But I think what you're selling is software as a service (SaaS), which would include support. But the definition or the nature of a software as a service or a platform is that the updates and upgrades are just included as part of access to the platform because it's being hosted by the vendor. And so, one of the first things that we're working on is, let's clean up the language in your order form. I know you're selling a SaaS product, but let's make sure the language matches that, because the language they were using made it look like they were selling software. So, it definitely can be confusing.

 <Susan> That's especially true on bigger deals, because I've seen ones where they have software and updates and upgrades, and they're allowed to switch between products, and they have the right to future products and just all kinds of things. And are you really selling them all those different components and pieces or are you giving them basically a right to access all of your products, including updates, upgrades, and everything else?

 <Natasha> Shall we talk hardware?

 <Susan> Yeah, let's talk hardware.

 <Natasha> I know you've had more recent experience around hardware clients or clients that sell hardware, both as individuals and bundles. Can you tell me a little bit about some of your more recent experience with that? 

 <Susan> Sure. So one of the things I see is when you're selling hardware, you have a bill of materials. So, you've got the base hardware, you may have modules that get added on, and how do you decide which of these are separate performance obligations? I think part of that goes to what are the selling practices and what is, how are you pricing it? So, if you're pricing, say, a piece of hardware that includes two modules, that could very well be its own performance obligation. And then as they buy additional modules, each of those additional modules would be its own performance obligation. And that's sort of just the hardware. So, you have to look at what are the selling practices. If they don't, and it's basically a build your own scenario where you pick the base and you pick all the different modules and then the pricing is based on all of those different ones, then it could be that you have to look at each of those pieces as a separate performance obligation.

 <Natasha> That's such a great point. And one of the analogies that I always use when talking about separate performance obligations, because what the guidance requires is that it's not only capable of being distinct, but that it's actually distinct within the context of a contract. And so, the example I use is you can go buy two by fours and a kitchen sink and all the things you need to remodel a kitchen at Home Depot. But when you hire a contractor to remodel your kitchen, you're not purchasing those things individually such that if he showed up and said, here's all the materials, now can you pay me half of the price? You'd be like, no, I'm only paying you, I'm paying you for the remodeled kitchen. And so, a two by four is certainly capable of being distinct, but is it distinct in this particular contract? I'm not buying two by fours, I'm not buying a kitchen sink, I'm paying for a solution, which is a remodeled kitchen. And I think what you're saying is very much reflects that, it's this idea that what are the selling practices, how is it being used? You really have to take a step back to say, what are they really buying here? Sure, these individual pieces are capable of being distinct, but are they distinct in this contract for this company in this business model?

 <Susan> That was a really good example. I like the kitchen remodel.

 <Natasha> You'd be a little bit miffed if the contractor just dropped off all the material, right? No, no, no, I could have gone to Home Depot myself. It's the assembly that's the issue.

 <Susan> But let’s also talk about something that's tangible to people and you've brought up before, is it like an iPad? It's a piece of hardware that has software on it, and then it has apps that are installed, and then it has updates and upgrades. So, from a revenue perspective, there are multiple pieces there. There's the hardware and the perpetual software that's installed in it, then there's the updates and upgrades, and then there are the apps. 

 And from a hardware perspective, you may sell hardware bundles. I've seen clients that sell the hardware and the services combined. So, you're buying your hardware, but then you're also getting a discount because you're pre-buying one or two years of maintenance. And so, you're having to allocate between that hardware and the maintenance. Even though it's a single price, even on your price list, it's really multiple performance obligations.

 <Natasha> Maybe there's an implied warranty or implied services. Sometimes it'll be spelled out in the contract, and then other times it's not and it's implied, it's business practice, expectation, et cetera.

 <Susan> It's interesting you bring up implied warranty because that is when you have to look for. Typically software has a 90-day warranty and hardware may have anywhere from one to five years of [language that says] if it's broken, we'll repair it or replace it. But if that warranty includes additional [benefits], like the right to updates and upgrades, the right to technical support, do you really have an additional performance obligation there and not just a warranty reserve?

 <Natasha> Yeah, that's a good point. And that's where, when I review a contract, that's where I think I mentioned in our contracts when this is the thing that I think is the biggest risk area, because what could be hiding as potential performance obligations in a contract is not straightforward, and it's not clear where those will show up. They could kind of show up anywhere. And to your point, they could show up in a section called warranty. They could show up in a section called support. Maybe it's not standard support, it's some sort of upgraded support that is above and beyond. So, I think that's a great point that these performance obligations might go under a different name.

 <Susan> They do sneak in there.

 <Natasha> Yes.

 <Susan> So let's move on to professional services. So, you work a lot in the SaaS area, and I know there can be upfront setup fees, there may be implementation services, there may be other professional services. When do you consider them a separate performance obligation versus part of the SaaS offering?

 <Natasha> Great question. I would say that my first and foremost approach is always, is it material? And just hope that it's not. A lot of my clients that are SaaS customers, they might have very straightforward, simple implementation. Maybe customers can do it themselves, and what they really do is just set up the instance for a client, send them the access, the subscription starts, and they're basically up and running. And any implementation services could be very much optional and sold separately. And then often in those cases, most SaaS companies don't want to be in the business of selling services, and so they offer it to make their customers happy and successful, but it's not something they're pushing on their customers in any way as far as trying to generate or grow their revenue. They're more interested in pushing the SaaS side of things. And so usually it's a material for those clients, and those are my favorite ones, because no matter what you do, it doesn't matter too much. 

 But where I have seen this get really sticky is in some companies, they'll charge something called a setup fee. And the guidance is pretty particular about these setup fees or activation fees. And when you think of, I think joining a gym is a great example. They might charge you some exorbitant fee upfront, where it's $500 to join, right? And then $100 a month after that. And really to join, all they're doing is setting you up in the system. There's nothing that you're getting of benefit upfront. And so, it's not, they have this fee that's upfront, but it’s really associated with the rest of the contract and doesn't represent a performance obligation. 

 And so, I recently had a client where they had an upfront fee. And sometimes what that does, which is really annoying, is it calls into question whether there's a material right in the contract, which can get really sticky. But usually, it's just an upfront fee that needs to be amortized over, hopefully, just the life of the contract, but potentially renewals too. So that's where you actually have a setup fee, but there is no performance obligation. 

 On the flip side, there could be a setup fee with actual services that represent a separate POB. And then my favorite, if we can have favorites, is when you have the upfront services, the implementation services, and no fee. Because again, with a lot of these SaaS companies, they don't want to necessarily push their services. The services are there to make their customers successful. If they can get their customers to pay something recurring, they would rather bake that price into the recurring line on the contract than a one-time upfront implementation fee. So, they might give it away for free. It might be called out on the contract, it might not be called out on the contract, but the reality is, is the only way for those clients to really get up and going on their subscription is with some sort of implementation. And that's where things get definitely subjective, because what I see is there is one way where they create a new instance, they send you access, it's a 15-minute exercise, it happens the same day or within a couple days, depending on a company's operations. That's one extreme example where it's very clear that there isn't a separate performance obligation. It's just sort of a perfunctory activity to get people going. Then there's the, it's gonna take eight weeks of services, you could hire someone from an outside firm, we work with these partners, we can provide it. You could do it on your own with our training material, and it's very clearly a separate performance obligation that's distinct. And then there's something in between. And I think that's where it can get a little gray, get a little subjective.

 <Susan> Well, do the services have a standalone value to the customer? Like you said, can the customer do this, or a third party do this, or are they hiring you to do it? And that lends itself to, this potentially is a standalone service because they have other options.

 <Natasha> What you said is spot on, that if someone else can provide the service, it's clear that this is a distinct service that someone could benefit from, from other readily available sources. And so that makes it, it's a good check in that box that this is a distinct performance obligation. Now, maybe you're a startup and no one knows how to implement your software or your SaaS offering. You know, if you're Atlassian or Salesforce or any other bigger company, people start service companies, they get to know your software or your platform, and they'll start their own service company because they become an expert in your product. If you're a brand-new startup, that marketplace doesn't exist of people who are experts at using your platform. And so there might not be those examples, but technically there could be, and hopefully maybe there will be. And so that's where I think it gets gray. And that's where you really think about, is it a customization of software? Are you developing and customizing your offering for a particular customer? Are you getting into that core of what you're providing? Are you configuring? And I think that's also where you can get to that single performance obligation versus multiple performance obligations and separate distinct services. Because if what you're doing is really just part of the SaaS offering or software offering, it could be a single performance obligation. But if you're really just configuring and getting them set up, and even if no one else currently can technically provide those services, in theory they could, that's where it gets gray. And it requires a lot of judgment. 

 And there's examples in the various guidebooks, but again, this is where you get to nerd out with the engineers. You get to talk to the people on the services side. You get to understand, you know, what's their strategy around it. Oh, you have plans in the next six months to partner with service companies to do this? Okay, that's good to know. Why can't they do it themselves? Do they not have access? Could they have access? So, you ask these questions to sort of pull the thread and see what you find. This is why I say at the beginning, I just hope that they're small and immaterial and you don't have to do anything. Ideally, they have access right at the start and no big deal. Yeah, and the services are just simple, straightforward training and it's easy. And oh, by the way, it's less than 1% of our revenue. And I'm like, great, let's move on.

 <Susan> I've also seen customers that for the first 30 or 60 days, they'll make professional services available to help the customer install on their own. But relative to the value of the contract, the value of those services is so small because maybe it's $2,000 a day, so you're talking $6,000, that it's immaterial in the context of the contract. So, it's just not even recognized as a separate performance obligation. It's more noted in the contract review.

 <Natasha> I think you hit on something so important there. You alluded to this idea that they're there to help the customer implement. And the reality is all these companies want is for their customers to be happy, to be successful, and to use their product, love it, and want to use it more. And the way to do that is to provide them with a little extra help if they need it. And so rarely are you going to run into one of these companies where if their customers want a little extra help with their implementation, you're not going to say like, sorry. No, they want them to come back. They want them to buy more. They want them to sign an expansion deal. They want them to renew. So, they will do that. And I think to your point, sometimes that's just extra a little bit of customer success manager or an account manager, or it's perfunctory in the context of the contract. It's immaterial. And so, that's, I think, where it gets really subjective. Most companies are going to help their customers out if they need it. And at what point does it become a separate distinct performance obligation? The answer is, and I hate to say this, it depends.

 <Susan> In the example I gave, not every customer uses that service. So then, if you take the percentage of the customers who use it, the value becomes even smaller.

 <Natasha> Then it shows that it's not really needed, it's just being a good partner.

 <Susan> And also, if they have a support contract, sometimes they'll consider that part of support.

 <Natasha> Yes. Where does implementation services begin or end, and where does support start? 

 Susan, I know, particularly with software companies is where I've seen it the most, where you have this idea of future features that customers either want, or companies might talk about. Often, these future features might be vague, or there's no timelines around it, so there's not much to do from an accounting perspective. But sometimes these future features are a lot more specific, and they may rise to a level where we actually have to account for it. Can you maybe tell me a little bit about a time where you've seen that?

 <Susan> I've seen that a few times, actually with both software and hardware companies. If it's actually a physical piece that they're adding on, like you're going to get another hard drive or you're going to get something like that, it is actually a commitment within the contract. It's basically a specified update and upgrade. Normally we have unspecified updates and upgrades that will be delivered when and if available, on an unknown schedule. They may or may not have any. But in this case, the customer specifically said, I'm buying this with the expectation I'm going to get that feature in the future.

 <Natasha> This is why identifying the performance obligations is so important. It's easy to skip this step or to undervalue it because I think people just want to get to the point where they're recognizing revenue. And that makes sense. But I actually think identifying the performance obligations is really a meaty part of the process, and it shouldn't be discounted.

 <Susan> Let's just wrap up this session talking about some of the things you might find in a contract that are not performance obligations. I know I've seen things like a business recovery plan, insurance requirements. What have you seen that may look like a performance obligation, but really is typically not treated as one?

 <Natasha> This one's interesting because I mentioned before, this is something that I always think can sneak in there, right? Performance obligations can sneak in there. And so, as a consultant going from client to client, I always have fresh eyes when I look at these contracts. This is where I ask a lot of questions also. And so business recovery plan, insurance requirements, absolutely audit requirements, retaining records, cooperation with auditors. Those have definitely been in there. I think we already sort of mentioned the idea of meetings or progress reports. Again, that's a little subjective. 

 Sometimes support or uptime service level agreements, SLAs. So, most companies have what they consider to be their standard support that maybe it comes with their standard support offering or their standard SaaS offering, and maybe they have a standard warranty, standard SLA of what kind of service they are going to provide. Often what I see is variations to that. They have their standard one-pager of how they describe it, and they attach it to every contract. And some customers will want to adjust that wording. And as soon as I see that wording adjusted, I think, oh, there's definitely a performance obligation hiding here. But sometimes, it's just if you talk to the company, they already do that for all their customers. The customer just wanted the wording to be more specific, and it doesn't actually represent anything new or anything more being provided to that particular customer. It's just that they wanted it specified in writing. So, I think that's another area where it's easy to get carried away and think, oh my gosh, they've added something here. They owe them more. And it's like, well, actually they give all their customers that. 

 What about you? Have you seen any other things?

 <Susan> It's basically anything that's more operational. So, if it's something you would do in the course of running your business, it typically is not a performance obligation. It's not specific to this contract. If it's anything that you have to do significantly differently, then it may be a separate performance obligation.

 <Natasha> Typically, these are just good business practices. It's how people do business. And audits, insurance, disaster recovery, these are all just part of doing business. Those are clauses in a contract. And I do think this is an area where the more contracts that you review, the more you start to see the same things over and over again, and you feel comfortable. This is just thrown in there for the sake of it. No one actually expects this to have unique value, distinct value to the customer.

 <Susan> This concludes our discussion on performance obligations. If there are areas you would like us to dive in deeper or topics we missed, drop us an email at revrecgals.gmail.com. You can also find us on LinkedIn or at revrecgals.com. Thanks for listening.

 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.