Software costs and revenue recognition in the age of AI

0:02Hello, and welcome to PwC's Accounting Podcast.

0:11Today we're covering some of the latest accounting hot topics for software and SaaS or software as a service companies, including how AI is creating new considerations for revenue recognition as well as software development costs.

0:41I'm Pat Durbin, a Deputy Chief Accountant in PwC's National Office and host for today's episode. Today, we're covering some of the latest accounting hot topics for software and SaaS, or software as a service companies, including how AI is creating new considerations for revenue recognition as well as software development costs. We'll walk through some of the latest questions we're seeing, how the existing accounting guidance applies, and the key considerations companies should have on their radar. To help me work through all of this, I'm joined by Angela Ferguson and Mike Coleman, both partners in PwC's national office.

1:20Angela and Mike have extensive experience helping companies navigate revenue recognition and software accounting matters. Angela, Mike, thanks for joining me. Happy to be here. Good to be here. So revenue recognition has always been a hot topic for software and other technology companies. And now with this AI wave impacting almost every business, this seems like a great time to discuss some of the latest accounting hot topics and trends in the sector. Maybe before we dive in, we should just level set on some key concepts. Maybe I'll start with you, Angela. We'll be talking a lot about software that a company might develop and license, as well as software that might develop and then deliver through a software as a service or a SaaS arrangement.

2:03Can you just remind our listeners how the accounting guidance distinguishes between those two models for the delivery of the software functionality? Yeah, that is a good place to start because the accounting guidance, as you said, does have a different model for a license of software versus software that's being provided purely as a service to customers. So the accounting guidance has two key questions that you have to evaluate. The first is, does the customer have the right to take possession of the software without incurring a significant penalty? The second question is, is it feasible for the customer to run that software on their own infrastructure or by using a third-party vendor to host the software for them.

2:54If you answer yes to both of those questions, then the arrangement includes a license. If you answer no to either of those questions, so either they don't have the right or they wouldn't be able to feasibly run the software, then the arrangement is accounted for solely as a service. And that's even if the contract itself refers to there being a license. for accounting purposes, we're just going to view it as a service. So why does this matter? On the revenue side, it matters because there's a different timing of revenue recognition for a license versus a service. For a license to software, if it's distinct, revenue is recognized at a point in time, which is typically at the beginning of the license period.

3:43And licenses are usually distinct in this space. Well, often, yeah. I mean, there's a question there. But if it is distinct, whatever revenue is allocated to the license and the arrangement, you're effectively recognizing that up front all at once. In contrast, a service, revenue is recognized over time as that service is provided. There are also some other implications, you know, downstream when you're applying the model, and there's things around a certain royalty arrangements and the exception for royalty payments that'll depend on this. But those are the main differences is that point in time versus overtime.

4:20So key question to start, do I have a license or not? Exactly. And essentially the same analysis Angela just walked through applies on the cost side for the purchaser. Does that entity have the right to take possession of the software without significant penalty? And is it feasible that they can run it or have somebody else run it with them? If yes, the arrangement includes a software license and a service of hosting that software license. And if no, the arrangement has no software license. It's purely a service. The impact to the purchaser is whether the software license exists and then the presentation of those costs.

4:57So if a software license exists, you have a software asset that needs to be recognized, you amortize that software license over its useful life, and the cash flow is investing. If there is no software license, then there's no asset to be recorded and all the costs would be not amortization, just the regular operating cost and the cash flow activity to operate. So it's interesting that we have kind of this same delineation point, but maybe just to highlight as we go through the rest of the conversation, we're going to be talking about kind of both sides of the equation. A lot of times we'll focus maybe either just on the revenue side or sometimes we'll focus just on the cost side.

5:33We're going to try to hit both parts here because they're both kind of relevant, both being impacted by some of the new flavors of things we're seeing in the AI realm, but then we'll try to sort of keep things straight for everybody as we go through, but we are going to cover both sides. So now that we've established you have to make this distinction of whether you have a license or not, we sort of explained the concepts, but do we get a lot of questions, like what are some of the nuances that we sort of deal with in this space? Well, that basic guidance I walked through has really been around for a while.

6:06It actually predates even the current revenue guidance in ASC 606. So things like what is a significant penalty? I mean, those judgments have generally been around for a while, so they're pretty well understood. We don't necessarily get a lot of questions on that topic. However, there have been a couple of types of arrangements that have come up more recently where the question of is this a license or a service has been relevant or come up, been debated a bit. The first one I would mention is what I'll call bring your own cloud. And what I mean by that is a company that typically provides SaaS that they host themselves or use a cloud service provider to host it for them when they're providing it to a customer might have an arrangement where a customer would like the software or application to be in the customer's own controlled account with a cloud service provider.

7:08So in that case, the arrangement has really changed as far as what the company is providing because they're having to provide their software or application in the customer's controlled account. So in that case, it's likely that there is actually a license to the software in that arrangement that needs to be evaluated. The other one that has come up is tied up with the whole issue of whether an arrangement has an embedded lease, which has also been a hot topic, right? But in some cases, you could have equipment that is hosting software. And if it turns out that that equipment is actually being leased to a customer, then it's likely that any software that's on that equipment is also being transferred to the customer.

7:58And that could be a surprise if you didn't anticipate that there was going to be a lease in that arrangement. To the customer lessee, I guess, in that context. Exactly. Yeah. So lots of interesting nuances as this space evolves. And when you think about the embedded lease point, the cloud, bring your own cloud, you really have to get into sort of the specifics of these arrangements and really how the software is being delivered, but you also can't just sort of presume that it's the same in all arrangements or the same across the organization. You really have to look at how the company is contracting.

8:31Absolutely. I think my cloud would be raining. Okay, so we've got sort of that background, sort of the nuances of how to think about whether we have a license or not. What are some of just the, say, generally hot topics in revenue for these software and SaaS companies? So we have to start with AI, right? Because that's obviously the hot topic for really companies across all industries. But specific to SaaS and software companies, we're seeing them beginning to incorporate AI-enabled features into their offerings, and then assessing how they're going to price these offerings or these features and monetize these new AI services.

9:16So one way this might occur is that there's a SaaS arrangement that a company incorporates some AI-enabled features into that arrangement and prices it on a per-use basis or maybe calling it per token, and that's how they charge for this new feature. So from a RevRec perspective, there are a couple things you need to think through. The first question would be, are these AI-enabled features a distinct service that's a separate performance obligation from what I'll call the base SaaS offering? And this is really going to depend on how the AI features are being integrated into the SaaS. But if these are sort of optional, incremental features that provide additive functionality, it's likely that they would be a distinct service being provided in addition to the base SAS.

10:15So then the second question would be, what is the revenue recognition pattern for those AI services? And again, this will depend on what you believe the performance obligation is related to those AI services. One possibility is that you're providing access to AI services, and that might be more of a time-based or straight-line type recognition pattern. Alternatively, you may say the promise is really the output of using that AI feature. And in that case, revenue might be recognized as the services are provided or used by the customer. That may be a little bit of a spoiler here, but I think we're going to come back to this concept a few times.

11:03And it's not like many of the things we're going to talk about today, not really a new gap concept. We're applying it in the AI context. Right. this whole point of is your promise in a SAS arrangement to provide access to the SAS or to deliver some sort of usage, quantitative usage of an application for a period of time, the nature of your performance obligation. That's a fundamental question. We're now taking it and applying it in the AI context, but it's not really a new question in the SAS context. Agree. So maybe just to kind of highlight the distinction we're trying to make here in terms of the nature of the promise, do you have some examples we could think through?

11:46Sure. Maybe I'll kind of give an example on like the two ends of the spectrum, right? So in the first example, the customer gets unlimited access to AI features for some period of time, so some contract period. And to keep it simple, maybe it's for a fixed fee. So you have a fixed fee for unlimited access. Well, in that case, you're likely going to conclude your promise is providing access, and you would recognize that fixed fee on a straight line basis over that period of time. It may be a little more complicated if there's also a variable fee, perhaps based on some sort of usage metric. And in that case, you'd have to evaluate whether the variable consideration allocation exception applies.

12:30I have to say that slowly because it's a mouthful, which might allow you to allocate that variable fee to certain portions of the contract. And if you don't meet the exception, then you would have to estimate the variable consideration. But again, that's similar to what we have to deal with in SAS today. The other end of the spectrum, so another example is where a customer purchases a package of tokens. So they pre-purchase this package of tokens that they then use up as the customer uses the AI features on the platform and say that they have to purchase more tokens if they run out of that package of tokens.

13:13And there's really no time limit on when they have to use those. So as long as they continue to be a SaaS customer, the right to use those tokens would continue to roll over, if you will. So in that case, you would likely conclude that your promise is providing the tokens or the output that comes from using the token, and therefore you would be recognizing revenue as those tokens are utilized. And sometimes people think of this as kind of like a consumption or usage-based recognition as opposed to the other example I provided. So that kind of gives you the two extremes. I think what we find is that some arrangements...

13:54Oh, we're that simple. I know. A lot of arrangements are going to be somewhere in the middle. So there will be probably many variations of how these arrangements are structured, how they are priced. And like you already said, Pat, it's similar to how we've had to evaluate SaaS arrangements that are also structured in various ways and may have different ways of fees being charged and how they're monetized. So are there any other revenue-related questions? And I think some of what Angel just talked to is going to have a cost consequence too. But maybe before we dive into that, Mike, anything else on the revenue side?

14:27Yeah, there are a couple of things. Sometimes the vendor will receive rights to the customer's data as part of the AI service, often in training the data models. So the question there is whether that data, those data rights, are non-cash consideration in the arrangement. And so what the vendor would want to do is understand, well, what are the rights? Do they extend beyond the purpose of training that customer's data? And does the vendor control the rights? That's the key determination. So if they get an asset that they control that's distinct, then it might very well be non-cash consideration.

15:04There are also some principal versus agent considerations, especially when using a third-party provider for some of the AI services. And so the question is, is the vendor using a third party's AI in its offering? Are they separately arranging to build and integrate the offering? Generally, it's an integrated offering, but you'd want to make sure that whatever the vendor's doing, and they're using a third party for any of that component of the service, do they do that principal versus agent assessment? So principal versus agent, everybody's favorite topic. We sometimes call it gross net or PVA.

15:44And I know we continue to see a lot of questions in this space generally, especially in the software sector. But let's maybe dive in a little deeper. So what are we seeing specific to this context? Sure. The issue typically comes up when that software company or SaaS company is selling through a marketplace or reseller or distributor. So from the SaaS or software company's perspective, the question really is whether the intermediary that reseller is their customer or the end user. The SaaS or software vendor won't ever be the agent. They are selling software or providing services. The question is, who are they providing those services to?

16:27The principal agent assessment is done from the perspective of the reseller. So is the reseller gaining control of the service or software and reselling it, or are they just arranging for the sale and acting as a sales agent? So the impact on the vendor's conclusion, if the vendor is the principal to the customer and they are using the reseller as an agent, they would record revenue as what the customer, the end customer pays with a commission. That's the reseller's keep, so to speak. But if the reseller is a customer, then the amount the reseller pays them would be their revenue. So that would be sort of the net version versus the gross version in the first scenario.

17:13That's right. And then the answer is going to depend upon the company's facts and circumstances. Does the reseller integrate the SaaS into their own offering? Are they really taking control of that SAS or software and therefore the company, that reseller is the company's customer? You also want to know whether the reseller is primarily responsible for providing the SAS or the software. Particularly in the SAS space, it's not common where the reseller is responsible for providing the SAS or taking possession of the SAS. normally that comes from the SAS provider not always the case but the more common circumstances the reseller really isn't controlling the SAS it sounds like some of those considerations are probably similar would be linked up with some of the things we were talking about earlier in terms of just figuring out what is the nature of my promise as a software company like am I transferring the SaaS to like in the bring your own cloud scenario, how is that really being delivered?

18:19And again, I think it gets pretty technical in terms of how the arrangement actually works. Right. And there's a lot of variations in how much the reseller is actually involved, right? They may have very little involvement just arranging the sale between the two parties or much more involvement up to the point where they're actually integrating that SaaS into their own offering. So you really have to understand what's happening in each party's role. And I think when just to put it in context, when we say reseller, we could be even talking about some of the large cloud service providers, their kind of platforms that they operate on, you know, they have marketplaces, they have the operating platform on which they deliver the cloud, that could be sort of the quote unquote reseller in this context.

19:04Right. So I think those are some good examples, Mike. And I think we've established that, you know, SaaS, software as a service, is not really a new concept at this point. I do think you maybe still see how this industry has evolved. Maybe I'll call it like vestiges of the old, you know, on-prem software delivered, you know, through a license model. But, you know, they're very different delivery model that has a very real distinction. from an accounting perspective. And so I think we'd expect to see, you know, those distinctions manifested in practice. And that's sometimes inconvenient for companies because they'd like to just sort of have one model for everything.

19:46But, you know, unfortunately, you really have to get in and look at it. So maybe just switch gears a little bit, Angela, and come back to this sort of, you know, AI ecosystem a little bit more broadly. And particularly in a case where we've got an arrangement or a set of arrangements maybe where a company may have both customer and vendor relationships with a counterparty. How do we need to be thinking about those situations? Yeah, we're seeing this more and more often. For example, where a company is negotiating to sell its product or offering to a customer, and at the same time, they're agreeing to buy the customer's offering or commits to a certain amount of spend with that customer.

20:35And the key guidance here that will likely apply is consideration payable to a customer. So at the same time you're selling to your counterparty, you're also paying them for something. So under that guidance, you need to evaluate whether you're paying for a distinct good or service in exchange for the payment you're making. If not, then that payment is a reduction of revenue. So in many cases, I'd say the company is buying a distinct good or service from their customer, but it really will be important to have a process in place and some controls in place to do this evaluation because some of the things you'll need to assess are, you know, what specifically is the company buying or committing to purchase from their customer, does that arrangement have commercial substance?

21:28For example, does the company actually plan to purchase something they will use and benefit from? You also need to consider from the distinct evaluation whether the goods or services you're purchasing are related to what you are selling to the customer. So again, you need to establish that what you're buying is distinct from what you're selling. So in some cases, that will be obvious, like the two things will be unrelated and not really used together. So it just happens that the counterparty is both a customer and a vendor. But it could get much more judgmental if those two things are related.

22:08For example, if you're buying a component from your customer and then using that in the production of what you're selling back to the customer, You would want to have a robust analysis of whether what you're buying is distinct from what you're selling. And that's definitely going to be very facts and circumstances as far as what conclusion you get to there. And then lastly, even if you are buying something that's distinct, you also need to assess whether you are paying more than fair value for what you're buying. Because if you are paying more than fair value, the excess amount would still be a reduction of revenue, because that would be considered a discount on what you're selling.

22:51So lots of layers there. I think that last point, though, is particularly important, because it's not necessarily sort of an all or nothing conclusion, right? You really need to figure out even if you have a distinct good or service, if you've paid more than fair value, you may have part of it that gets allocated to cost, part of it that's still treated as a reduction of revenue. Yeah, that's right. And I've seen where sometimes these are structured as the company is just committing to spend a certain amount with their customer. And that could be, say, I'm committing to spend$10 million on a take or pay basis.

23:27But when the company does the evaluation, they say, well, I really think I'm only going to buy$8 million worth of stuff from my customer. So that extra$2 million is just a discount on the things I'm selling to my customer. So the$2 million would be a reduction of revenue. And that's really effectively an estimate that you'd have to continue to evaluate and update through the end of the contract. So maybe that concept of a minimum commitment or take or pay is sort of a nice segue back to sort of another angle of how we need to be thinking about some revenue questions in the SaaS space. we're starting to see sort of combinations of committed usage or minimums, which, you know, sort of raises that question of is it really just an access to the platform or is it an amount of usage and some judgments there?

24:25What are we thinking about in that context? Well, I think it's really common in this space to see a master agreement where there's a minimum spend commitment, but not necessarily specific goods and services that the customer is going to buy. So there's maybe a list of things with pricing that the customer can use that minimum commitment on. And I'd say a common misconception is that this is some sort of stand ready obligation. Now that I have this minimum commitment, I'm just standing ready to sell things. But typically that's not going to be the case because revenue recognition is going to depend on what the customer ultimately purchases and what's ultimately delivered or transferred to the customer.

25:15So, for example, if they could draw down on this minimum commitment by buying different products and services, revenue would be recognized as those products are delivered or as those services are provided. So that sounds pretty straightforward. I'd say these arrangements can get more complicated if the pricing is not at SSP and then also not at a consistent discount off SSP. So if you have very inconsistent discounting on the goods and services that the customer is buying, because then it may not be appropriate to just use sort of the stated contract price when the customer actually makes the purchases and there may need to be some allocation there.

26:05So that's when those types of arrangements really can get complex. And we could probably have another whole conversation on SSP or standalone selling price in this context, right? Because it's, I'm sure, challenging, especially as companies try to figure out how they really want to go to market commercially when you're talking about things that don't have a directly measurable cost, right? Yeah, that's right. Save that for another day. And another issue that comes up in this space is what gets disclosed in the remaining performance obligations disclosure or the RPO disclosure? And so the key question there is, well, is there a contract?

26:41So sometimes a commitment to spend by itself may not be that, but is there a contract? What is the contract customer actually committed to buy or purchase? A good one is there are termination rights. So before they make those purchases, is there a way where the customer can terminate and not have to make the purchase? And then are all the terms and considerations known? So those are things that come up to figure out what exactly do we put in that RPO disclosure. Yeah, I'm glad you brought that up because the RPO, remaining performance obligation, or sort of that's now accountant vernacular for what some people might have thought of as like backlog, is starting to get a lot more attention, certainly from the analyst community, but you're starting to see even more sort of just casual commentary in like the financial press about RPO.

27:28So I think companies really making sure they have a consistent approach to evaluating that, determining what gets included is really important. We have started to see the SEC taking an interest in some of their comment letters in terms of how companies are developing those disclosures. What are the key judgments they're making so that they feel like the reader has enough information to understand what's going into the RPO disclosure? So that's a good one. So that's been quite a bit on the revenue side. And as I alluded to earlier, we are going to get to the cost side of what all this AI activity means.

28:12And probably when you think about it, there's a lot of cost out there in the system, right? We've all heard a lot about the massive amounts of capital that's being deployed into the AI system. Well, that is going to create costs somewhere for somebody. So there's a lot of money at stake here. And we're starting, I think, to see companies really focused on, okay, what do I do with all these costs now? Yeah, the most common question we get is, can I capitalize my AI costs? And the answer we typically can, we typically give is, well, depends on how your AI is being used. So let's take AI to develop software.

28:52So there's no specific, here's the accounting standard for AI development costs. The existing accounting standards for software capitalization would govern the cost, any and all costs that you would incur in developing those software. So there's nothing specific related to AI. And the cost of developed software, again, there are two standards. It's the internal use software standard, and that would include software developed for internal use, including SAS, and that's accounted for under ASC 350. And then software that's externally marketed, where you give the customer the right to take possession of that software, that's accounted for under ASC 985.

29:40Yeah, so we're back to that same division of the gap. If it's SAS model, it's internal use, we have one framework. If it's going to be licensed or delivered in a license, it's deemed to be externally marketed, we have a different model for that. That's right. And as a reminder, the FASB has a new standard on internal use software costs. ASU 2025-06. It takes effect in 2028 for calendar year companies, but it can be adopted now. Essentially, it clarifies the capitalization threshold for internal use software. It adds this notion of is there significant development uncertainty, but it doesn't change the nature of the cost that can be capitalized, so that isn't changing.

30:25And so for internal use software, which is where the AI discussion tends to happen more often, mostly because in the external software world, you reach the capitalization threshold very late in the process. So there's not a lot of opportunity to capitalize, whereas you tend to reach it earlier in the internal use software development guidance in that development process. So when it's internal use, the real question is, is the software or is the AI that's being used to create the software, is that a direct cost that can be capitalized? Because the internal use software standard is very specific.

31:08Direct cost of a service to use to develop the software can be capitalized, whereas overhead and general costs have to be expensed. So the question is whether those AI costs, are they direct costs of developing the software or are they overhead? And the other thing to keep in mind is when you have AI costs in the development process, if they are not capitalized, either because you haven't hit the capitalization point or there's some other type of expense, it's just not direct enough, I'll say, is what is the expense classification of those costs? I think most folks think AI expense, well, if it's expense, it has to be R &D.

31:57And what we would say is it's not automatically R &D. You really have to look to see as to what you're using those AI costs for. So if I were using AI to develop a marketing campaign, it wouldn't be R &D necessarily. Or if I was using AI to right size or make my back office more efficient, that might not be R &D either. So it's not automatically R &D. I guess it could be cost of sales, too, if you're using it as part of your revenue generating activities. That's right. Yeah, and just maybe, and we'll come back to the question of, like, the cost of developing AI software. We were just talking about using AI tools to develop software.

32:40So there's like different facets to this question, and we have to think through it a little bit differently. So this is very specifically to I'm incurring costs for the use of AI that I may use to help me develop my own software, which might be different than if I'm actually just trying to develop AI software. So we were talking about the new FASB guidance. You talked about it being recently issued, technically not taking effect until 2028, but I think we have started to see some companies adopt this standard already. Any early observations? We've seen or we're about 100 public companies that have adopted early.

33:22Most of them adopted in 2026, a few in 2025. The vast majority have adopted prospectively and have disclosed that there's an immaterial impact upon their adoption. Only a few have adopted retrospectively. And the companies span the range of industries, so it's not really focused on any one industry. Yeah, so just probably putting that in context, the likely reason there was an immaterial effect is they weren't capitalizing before and they concluded under this new standard they likely weren't going to capitalize many costs. That's right. And it's easy to early adopt in that case. Yes, very easy.

34:01Are there any new issues that sort of get triggered by this standard that are going to come up maybe for the companies that haven't adopted? Interestingly enough, the question that we get is how much documentation or process would a company need in implementing the new guidance, in particular around that notion of the probable to complete threshold. And again, the new guidance is going to introduce this notion of a novel, unique, or unproven technology and whether there is a development risk for that. And so if you identify there being a development risk, then you would need to have some type of evidence and documentation that that risk has been solved.

34:48And so, again, the question is how much documentation you need about identifying the risk and when it's solved. And, you know, that really depends on the company's facts and circumstances, the type of development process that they have. But again, we tell companies you really want to have some specificity about the type of risk you think is there that may cause the uncertainty. And then what is that testing plan and how would you test it to make sure that that uncertainty is resolved? And it might not be a single policy for the whole company, right? If they have different types of software that they're developing, they should do it at that project level.

35:29That's right. Absolutely. And I guess I thought it was important to talk a little bit about this software cost standard, the software cost capitalization. We have done a whole separate podcast on this topic, so we'll link that in the show notes if you want to go a little bit deeper in that space because there are some additional nuances there. But maybe we can just sort of try to bring this to a close, and maybe I'll just ask both of you for some maybe key takeaways in this space, and maybe I'll start with you, Mike. Yeah, I would say both from a revenue and cost perspective, there's no specific gap for AI.

36:07So the key is trying to figure out what relevant gap that exists will apply to AI and how you're using it. So that's going to be either I'm recognizing revenue for some sort of a software arrangement or on the cost side, I'm developing software tools, either AI tools or using AI to develop a tool. And I look to the software cost guidance. Right. Yeah, I mean, I would echo that. There's not going to be, I don't think, ever really like specific AI guidance, right? It's all about. Until the AI writes its own. Yes, that's true. That's right. So I want to be about, you know, what are you using the AI for?

36:48And then sort of applying the existing guidance that we have. I'd also say even though, you know, us accountants, we're probably never going to really understand the AI technology. there is some base understanding that you need to have of both how the company is using AI and then how it's being deployed or provided to customers in order to understand the transaction enough to apply the appropriate accounting model. No, I think that's great. I think it's really important for the accountants to kind of dig in as much as they can, again, recognizing we're not computer scientists, but to really understand how the technology is working and being delivered.

37:27Because it's not going to be a one-size-fits-all answer here. No, and it'll extend beyond software. So as companies get service subscriptions for AI, they'll use it to do other things outside of developing software. Yeah. Now, that's really good insights, really great perspectives, and I really appreciate you guys both coming in today. Thank you. Yeah, no problem. No problem. This podcast is brought to you by PwC, All Rights Reserved. PwC refers to the U.S. member firm or one of its subsidiaries or affiliates, and they sometimes refer to the PwC network. Each member firm is a separate legal entity.

38:06Please see www.pwc.com slash structure for further details. This podcast is for general information purposes only and should not be used as a substitute for consultation with professional advisors, including accountants and lawyers.