Latest / PwC's accounting podcast / FASB's new software cost guidance

Transcript

FASB's new software cost guidance · PwC's accounting podcast

0:00
SPEAKER_00: Thought Leadership from PWC's National Office.
0:07
SPEAKER_04: Hello and welcome to PWC's Accounting Podcast.
0:10
SPEAKER_04: I'm Heather Horn.
0:12
SPEAKER_04: In today's episode, we're discussing the FASBE's new internal use software standard that was issued in September.
0:19
SPEAKER_04: This new standard is applicable to any type of company that uses software for internal purposes, which is most companies these days.
0:29
SPEAKER_04: For today's episode, I'm joined by Pat Durbin, a deputy chief accountant in PWC's National Office, and Mike Coleman, a partner in the national office.
0:37
SPEAKER_04: Both of them have years of experience consulting with clients on this topic.
0:41
SPEAKER_04: In addition, Mike was a member of a practitioner's working group during the FASB's development of the new standard.
0:47
SPEAKER_04: So he definitely has some unique insights into how they landed on this new model.
0:52
SPEAKER_04: So, Pat, Mike, welcome back to the podcast.
0:55
SPEAKER_04: As always, so nice to have you on.
0:57
SPEAKER_04: And uh it's definitely a good timing to have a discussion about this guidance.
1:02
SPEAKER_04: So just taking a step back, Mike, can we set the stage for the new standard, uh, which makes some targeted improvements to the internal use software guidance?
1:11
SPEAKER_04: And how did we get there and uh why internal use software?
1:15
SPEAKER_02: Okay, so um the reason the FASB took on the software cost project was a misalignment between the accounting guidance and the way software is actually developed.
1:28
SPEAKER_02: As the FASBI was working on the software cost project, they realized the accounting guidance for externally licensed software was actually pretty responsive to the way companies develop software.
1:40
SPEAKER_02: It was meeting its objective.
1:42
SPEAKER_02: So they decided to leave that guidance alone.
1:44
SPEAKER_02: You know, why why change it if it was working?
1:47
SPEAKER_02: Uh they found that the misalignment issue was really with internal use software, but not all types of internal use software.
1:55
SPEAKER_02: The existing internal use standard was difficult to apply to software that's delivered via the cloud as a service.
2:02
SPEAKER_02: So the focus was making improvements to the internal use software guidance only.
2:07
SPEAKER_04: So, Mike, maybe before we get into the actual models and explain some of the differences between what we mean by internal use and externally licensed, just to take a step back for people who've been following this project, from your perspective, big picture where we started, where we ended, are we close?
2:24
SPEAKER_04: Are we far apart in terms of how this project progressed and where it landed?
2:30
SPEAKER_02: Yeah, so what I would the way I would describe it is when they started, it was let's try to have one standard for software and make life life easier that way.
2:41
SPEAKER_02: And so when they attempted to do that, their the results of the accounting guidance didn't really align with what everybody wanted.
2:52
SPEAKER_02: So it wound up being a much lighter touch than I think people had expected.
2:59
SPEAKER_02: So they didn't touch the external standard, they didn't do expansive disclosure requirements, they really just made targeted improvements in basically two areas only.
3:10
SPEAKER_02: Now that sounds simple, and we'll get into it.
3:15
SPEAKER_02: And it's a little more nuanced than that, especially as we deal with AI, and we'll talk about that too.
3:21
SPEAKER_02: But from where we started to where we ended was much less changes, more flexibility.
3:27
SPEAKER_02: And I think people were surprised it wasn't as expansive.
3:31
SPEAKER_01: Yeah, I mean, I think if you go back to the original genesis of this project, there was an expectation that maybe we would come up with a model that would result in capitalizing lots of software development costs because I think there's a perception that there's a massive amount of intellectual property in software that isn't on anybody's balance sheet.
3:50
SPEAKER_01: And a lot of companies are leveraging those intangible assets to generate revenue.
3:56
SPEAKER_01: I think, as Mike mentioned, as they got into it, as they explored it, I think they realized one, some practical challenges with doing that, and there didn't seem to be a great desire, either from the investors, frankly, for those costs to be on the balance sheet, and certainly not from preparers wanting to have to go through the process of capitalizing all these and then obviously assessing those for impairment at some point.
4:20
SPEAKER_04: So then, all in all, you guys would say where we landed from a preparer's point of view, definitely some things to learn.
4:27
SPEAKER_04: But actually, people are pretty happy about these proposed changes to the model.
4:32
SPEAKER_03: Okay.
4:32
SPEAKER_04: I'm getting lots of nods.
4:34
SPEAKER_04: So okay.
4:34
SPEAKER_04: All right.
4:35
SPEAKER_04: So with that, I think it's always helpful to have some of that background.
4:38
SPEAKER_04: So then with that said, Mike, just to make sure we're starting in the right place, I think it's good to remind people the difference between internal um use and externally licensed software.
4:50
SPEAKER_02: Sure.
4:50
SPEAKER_02: So when an entity plans to transfer the software code to a customer, and assuming the software's sole purpose isn't to be used with the service, there's always one caveat there.
5:02
SPEAKER_02: So in that scenario, think of like your banking app, right?
5:05
SPEAKER_02: That's an app you're going to use with the service.
5:07
SPEAKER_02: So assuming an entity is transferring the software code to the customer, it's not like that software to get to a service.
5:14
SPEAKER_02: That's externally licensed software.
5:16
SPEAKER_02: So it's just use it, think of it as simple as that.
5:19
SPEAKER_02: The software vendor transferred the software to the customer for its use.
5:24
SPEAKER_02: Think of classic off-the-shelf productivity type software that we've been using on our PCs all that time.
5:30
SPEAKER_02: So that type of software.
5:32
SPEAKER_02: It's like the company selling its product.
5:34
SPEAKER_02: Okay.
5:35
SPEAKER_02: Software for intended, that's intended for internal use.
5:40
SPEAKER_02: So think of an enterprise resource planning or ERP system.
5:44
SPEAKER_02: Companies either build them themselves or they purchase them from big ERP vendors.
5:50
SPEAKER_02: After it's built or purchased, that entity is going to use it, not sell it.
5:55
SPEAKER_02: And that's internal use.
5:57
SPEAKER_02: So it's more like an asset that they're going to use for some long period of time.
6:01
SPEAKER_04: So, Mike, if I take a step back and I think back to the days of like floppy disks or other types of disks, it's a little easier to see a separation in the types of software.
6:14
SPEAKER_04: But now, if I think that so much software is in the cloud, and even if you're licensing software, you might just have a license to use something in the cloud versus internal use.
6:24
SPEAKER_04: I think it can, at least to me, seems like it can get a lot murkier.
6:28
SPEAKER_04: So, how do we think about that difference?
6:31
SPEAKER_02: Yeah, so the the way I would think about that, again, the external license is I'm transferring, whether it's on media in your sloppy disk, in your floppy disk or sent via email or some type of uh data service.
6:51
SPEAKER_02: That's the I'm moving the code to you.
6:55
SPEAKER_02: That's the externally licensed.
6:57
SPEAKER_02: As far as the cloud, the cloud phenomenon is the vendor is going to maintain that software on their servers or hire someone to maintain it on their servers.
7:09
SPEAKER_02: And what they're doing is they're providing access to you.
7:12
SPEAKER_02: And the accounting distinction is when I deliver something to you, that's a sale, like a product, an externally licensed.
7:21
SPEAKER_02: When I make a promise that you're going to use my assets or I'm going to give you the functionality, that is a service for accounting purposes.
7:30
SPEAKER_02: And then my software, the vendor software, which is going to enable to deliver the service, then becomes an internal use asset to deliver the service.
7:41
SPEAKER_02: So that distinction of the code transferring via some type of electronic download or possession versus you accessing has a big difference in accounting, because one is an asset used to provide a service, and the other is the transfer of the asset.
7:58
SPEAKER_01: But I think your observation that most software that we used to get via floppy disks is now accessed in many cases online via the cloud is exactly kind of the impetus for why this project matters, because it's ultimately the same development activities that are generating that software, whether you actually deliver it and let somebody download it and run it on their servers locally, or you host it in the cloud.
8:26
SPEAKER_01: Most of the development activity is similar.
8:29
SPEAKER_01: So I think there was a view that why do we have these two very different software cost capitalization models for something that's essentially the same type of activity?
8:38
SPEAKER_02: Yeah.
8:39
SPEAKER_02: So just envision that vendor that's selling software, it's developing, just as Pat said, that software in the same exact way.
8:48
SPEAKER_02: In one case, the software is going to be transferred to the customer.
8:52
SPEAKER_02: In the other, it's going to be access.
8:54
SPEAKER_02: Why should that have a different accounting answer for the development activity that is taking place?
9:00
SPEAKER_02: And that's where the FASB is focused, trying to solve that issue.
9:05
SPEAKER_02: Make sure that the delivery mechanism for that development didn't change the cost answer.
9:11
SPEAKER_01: If we think back to those first couple of examples, right?
9:14
SPEAKER_01: The sort of kind of off-the-shelf productivity applications externally licensed versus the back office ERP system, that was sort of the, I'll say the original dividing line between the two models that we had out there.
9:27
SPEAKER_01: And you could imagine that the development process probably looks a lot different if you're trying to develop something that you're going to sell and commercialize and you're constantly thinking about how I can make this better, what are the additional features, what are the functions that I can add to it, versus, hey, I have a very defined set of problems I need to solve in my business to run my business, you know, HR, payroll, accounting, finance.
9:51
SPEAKER_01: I'm just going to go build a system to do those things.
9:55
SPEAKER_01: It's a much more finite, sort of linear process.
9:58
SPEAKER_01: And so that was the original cut between sort of, hey, external use, really hard, might not really be feasible.
10:05
SPEAKER_01: We're going to wait a long time to capitalize versus internal use.
10:09
SPEAKER_01: It's kind of like, well, I'm just going to go buy the thing or build the thing.
10:12
SPEAKER_01: Once I decide to do it, I'm going to start capitalizing.
10:15
SPEAKER_01: So you had that very distinct difference.
10:18
SPEAKER_01: But now as we're doing the same thing, both for kind of internal use and externally licensed, it was time to refresh the model.
10:27
SPEAKER_04: Although, as we started to say, not as big a change as maybe we thought at one point when we look at the models.
10:34
SPEAKER_01: Probably depends on how people were thinking about applying this internal use model to this software.
10:40
SPEAKER_01: And there's a subtlety there that if you had any plan to sort of externally license it, so if you sold the software and made let people take it and run it on their servers, then all of those development costs would be subject to the externally licensed model rather than the internal use, even though maybe you were using it for internal use.
11:01
SPEAKER_01: But if you were going to use it exclusively as a SaaS application, then you'd have a very different model potentially.
11:07
SPEAKER_01: So that's where I think some of the tension was.
11:10
SPEAKER_01: So in theory, this project should alleviate tension.
11:14
SPEAKER_04: All right.
11:14
SPEAKER_04: So then with that said, now that we have a lot of this background and we understand the scope, and hopefully our listeners can understand which start to think through which type of software they're they're thinking about.
11:25
SPEAKER_04: Let's get into the standard.
11:27
SPEAKER_04: So, Pat, then what would you summarize as the key changes?
11:31
SPEAKER_01: So I think the the one maybe point we haven't really talked about that's important before we get into like what the standard does is we've talked about kind of the way software is developed or um the way it used to be developed, maybe to the way it is now.
11:46
SPEAKER_01: And there used to be this concept of sort of more linear development, meaning you'd have um computer scientists go sit or sit in a room, think about an algorithm, decide, okay, that's the algorithm we want to build.
12:00
SPEAKER_01: We're gonna go now write the code, um, you know, we're gonna get that into some sort of testing, we're gonna iterate a little bit, but largely we're just kind of following a sequential process.
12:10
SPEAKER_01: The way software development activity happens sort of currently in the modern era is what's referred to as agile development.
12:18
SPEAKER_01: So you're running through a series of kind of trial and error sprints, you know, constantly iterating, constantly trying to find new features and functionality.
12:28
SPEAKER_01: So that's really a little bit of the business dynamic that's in play in terms of why we needed to think differently about the model.
12:36
SPEAKER_01: So importantly, if you think about that linear model, the old model used to talk about these very defined development stages.
12:45
SPEAKER_01: You know, so you had the like a planning stage, and then you had an application development stage, and then you had a post-implementation stage.
12:52
SPEAKER_01: The new standard eliminates references to all those stages and really just now focuses you on whether or not you actually are going to build the software tool or the application, and whether at the point in time you're making the evaluation, is it actually probable that I'm going to finish what I started.
13:14
SPEAKER_04: So, Pat, before we move on, I have to uh point out one thing.
13:18
SPEAKER_04: I had to almost laugh when you said in the modern era, because my guess is in 1970, when they had mainframes and all their cards, they probably thought that was the modern era.
13:28
SPEAKER_04: So I'm not sure if we're like post-modern years.
13:30
SPEAKER_01: September 2025.
13:32
SPEAKER_04: Exactly.
13:33
SPEAKER_04: So, anyways, it's kind of funny to think about what they probably thought 50 years ago.
13:37
SPEAKER_01: Will be the old days in three months.
13:38
SPEAKER_04: Yeah, exactly.
13:39
SPEAKER_04: 50 years ago.
13:40
SPEAKER_04: So, okay, so let's go back to the model because when you described it, it sounds like, oh, we could end the podcast.
13:46
SPEAKER_04: This is so straightforward.
13:47
SPEAKER_04: However, I'm sure it's not quite that easy.
13:49
SPEAKER_04: So, what are some of the things you need to think about then?
13:51
SPEAKER_01: Yeah, so as I mentioned, there's essentially two criteria.
13:54
SPEAKER_01: One is that basically somebody in the organization with the appropriate authority has committed to the project and has presumably budgetary approval to actually fund the development.
14:04
SPEAKER_01: That seems fairly tangible, fairly straightforward.
14:07
SPEAKER_01: The second criteria is the one that really I think is going to require a little bit more thought.
14:13
SPEAKER_01: And that's this question of is it probable that the project will be completed and the software will be used to perform the function intended?
14:22
SPEAKER_01: Now, the concept of probable should be familiar to most of our accountants.
14:26
SPEAKER_01: Um, it's the standard accounting definition of probable, means the thing that we're thinking about is likely to occur.
14:34
SPEAKER_01: We usually think of that as like a 75% likelihood.
14:38
SPEAKER_01: What's interesting though is the standard sort of qualifies that probable assessment by indicating that if there's significant development uncertainty, you can't conclude that it's probable you'll complete the project.
14:53
SPEAKER_01: So until you get over that hump of concluding there's no longer significant development uncertainty, you won't capitalize the cost.
15:01
SPEAKER_01: You'll just continue to expense them as incurred.
15:04
SPEAKER_01: So then you say, okay, what's a significant development uncertainty?
15:08
SPEAKER_01: Or does a standard give me a steer there?
15:11
SPEAKER_01: Well, it has some words in it.
15:13
SPEAKER_01: It describes a significant development uncertainty uncertainty as existing when the software has technological innovations or novel, unique, or unproven functions, or features.
15:28
SPEAKER_01: And I'm sort of over-emphasizing the word or there, I think to just illustrate that that's a lot of different things, and you only need, presumably, one of them to conclude that there's significant development uncertainty.
15:42
SPEAKER_01: Or the other characteristic of a significant development uncertainty is that the significant performance requirements of the software have not been identified or continue to be substantially revised.
15:55
SPEAKER_01: So if you just step back and think about all of those things for a minute, it sounds like there's a pretty broad pathway there to conclude that significant development uncertainty will continue to exist for quite some period of time during the development activities.
16:14
SPEAKER_04: Yeah, I mean it's interesting.
16:16
SPEAKER_04: We mentioned AI earlier, but really it almost sounds like anytime you're trying to innovate, you're gonna have some questions of whether these you meet these criteria.
16:26
SPEAKER_04: So if I just step back, then in trying to apply this model, really trying to understand whether or not I have this significant development uncertainty is sounds like kind of the key.
16:37
SPEAKER_04: And Mike, I don't know if you have some pieces of it.
16:39
SPEAKER_02: Yeah, no, it's it's absolutely the key.
16:41
SPEAKER_02: I mean, you know, the existing standard has those two criteria management committing, the funding, and it's probable.
16:48
SPEAKER_02: But that significant development uncertainty qualifier is really the key.
16:54
SPEAKER_02: Now, it it's it's important to note that if that uncertainty is identified, the standard's clear, it can't be probable until that uncertainty is resolved through coding and testing.
17:07
SPEAKER_02: Right?
17:08
SPEAKER_02: So this isn't one of those things where you make the judgment that I found it and then can make the judgment that it's not there anymore.
17:13
SPEAKER_02: You actually have to prove it's not there anymore through coding and testing.
17:17
SPEAKER_02: So you have to have progressed your development at some stage further in order to say the uncertainty you identified is no longer there.
17:27
SPEAKER_02: And you know what that's going to do, it's probably going to expand the circumstances where a company would conclude it's not probable that there's going to be some uh significant development uncertainty.
17:39
SPEAKER_04: Aaron Powell So, Mike, before we go on to talk about how this works in practice, when the standard was under development, why was this kind of glommed onto as being an area of focus?
17:51
SPEAKER_04: Aaron Ross Powell Sure.
17:52
SPEAKER_02: So again, if we go back to what they were trying to solve for, that circumstance where a vendor licenses software and delivers that via uh transfer of the code and has that same development process and delivers it via the cloud.
18:10
SPEAKER_02: And it's looking at, well, I've got two different methodologies on how to when it's probable or when I start capitalizing.
18:18
SPEAKER_02: And so they were using these words specifically to align the point in time for capitalization close to the external standard.
18:29
SPEAKER_02: So the external standard has a notion of when you reach technological feasibility is when you capitalize.
18:38
SPEAKER_02: And you reach technological feasibility when you don't have development uncertainty, right?
18:44
SPEAKER_02: So it's very similar words.
18:46
SPEAKER_02: So they didn't want to use technological feasibility and bring that into internal use because there's a lot of companies that have internal use that aren't familiar with technological feasibility.
18:56
SPEAKER_02: So they instead said, if your development has significant development uncertainty, very similar to the external use standard, then you would say it's not probable until I've tested and coded and have resolved those uncertainties, right?
19:13
SPEAKER_02: And again, the two indicators they give that is novel, unique, and have new features or functions, that would be a company saying, All right, I'm doing something, you know, however we define novel, unique, groundbreaking.
19:30
SPEAKER_02: Um you can lean on that.
19:33
SPEAKER_02: And we would expect companies like in an AI world, which is very new technology, to lean on that.
19:39
SPEAKER_02: And then you have others, the that second condition, which is the requirements of the software are changing or subject to change.
19:50
SPEAKER_02: That really gets targeted at the agile development process, because the agile development process is constantly doing sprints, re-figuring out what you want to code, what features you want to plan for.
20:05
SPEAKER_02: So it's sort of this very fast plan code, plan code, change the requirements to get to the end.
20:11
SPEAKER_02: And so if you have a significant amount of requirements changes, which typically happens in Agile, then it's another thing to lean on to say I've got significant development uncertainty until I get through most of those requirements, which typically happens later in the in the game.
20:28
SPEAKER_02: So it's really trying to close that gap and get that hosted software delivery similar to the external use standard.
20:38
SPEAKER_04: All right.
20:39
SPEAKER_04: So, Mike, I think that's helpful.
20:40
SPEAKER_04: And I think especially helpful to understand the similarities to the external software development.
20:48
SPEAKER_04: But if we then try to figure out in practice how this is going to work, Pat, are there some examples that you can provide that if I'm trying to identify if I have significant development uncertainty, what does that look like?
21:01
SPEAKER_01: Yeah, so I think maybe it's helpful just to go back to some of the examples we started with earlier and sort of this contrast of like the back office ERP system, very defined set of requirements, sort of very finite development or set of development activities.
21:18
SPEAKER_01: You could imagine that if I was evaluating a project like that for capitalization, I could probably get over the hump of significant development uncertainty relatively early in the process.
21:31
SPEAKER_01: If you contrast that to let's say it's a commercial-facing platform, um, you know, I've I've um got a business where I'm trying to enable my users to connect peer to peer, perhaps display some advertising, um, possibly even process payments.
21:50
SPEAKER_01: Maybe I'm looking to add some new AI enabled features, sort of constantly taking stock of like where do I think demand is.
22:00
SPEAKER_01: What's going to increase engagement, thinking about all the possible ways I could do that, all of the different possible scenarios that I might try to be contemplating.
22:11
SPEAKER_01: That's a much less well-defined outcome.
22:15
SPEAKER_01: And I'm sort of constantly, as Mike was alluding to, iterating trial and error, trying out new features.
22:21
SPEAKER_01: I might not have very much experience at all, say, particularly in the AI application development space, since that's such a nascent space.
22:29
SPEAKER_01: So I might conclude: look, there's significant development uncertainty here, probably almost close to the point of when I think I'm done.
22:38
SPEAKER_01: Right.
22:38
SPEAKER_01: So those like those are almost like the bookends of how to think about significant development uncertainty.
22:43
SPEAKER_01: Ultimately, you're going to have to come back and think about in your business, like what does it mean to me, and try to put some sort of framework around it so you can operationalize the standard.
22:53
SPEAKER_01: But that's sort of just conceptually how I'd think about it.
22:56
SPEAKER_04: So, Pat, maybe before you go on, using your two bookends, in particular, you know, this I'll call it simpler example of the ERP and it's operating HR and accounting.
23:08
SPEAKER_04: Maybe for that particular company, they haven't put in a new ERP for, let's say, 10 years or could be even longer.
23:16
SPEAKER_04: But nonetheless, we're saying, well, but the functionality and features and otherwise, maybe if they don't have a lot of experience, but there's still a lot of proven experience out there versus the other bookend, or how do you, again, if I'm the company that hasn't really done even a relatively simple system, how do I think about that?
23:35
SPEAKER_01: Yeah, I mean, I think it's fair.
23:37
SPEAKER_01: I think when I was thinking of the entity-specific evaluation, a little bit more in the context of probably this is my product.
23:44
SPEAKER_01: I'm the only one that has this product, I'm developing my thing.
23:47
SPEAKER_01: Like the ERP example, I don't think very many companies are actually building their own ERPs anymore, right?
23:54
SPEAKER_01: They're at least purchasing the engine from one of the main ERP suppliers.
23:59
SPEAKER_01: They might be doing some of their own interface.
24:00
SPEAKER_01: Custom and stuff, you know, custom reporting.
24:03
SPEAKER_01: But even those from a pure like technological standpoint, they're well-traveled ground, I guess I would say.
24:12
SPEAKER_01: So I think even though you might not have done it, you're probably hiring a consultant that's done it.
24:16
SPEAKER_01: So it's just like it's more accessible, more attainable, more known and defined, I think is the distinction.
24:24
SPEAKER_02: Yeah, and I I think in in those cases, once management has decided, hey, we're gonna do this platform, there's not many wholesale changes to the platform.
24:35
SPEAKER_02: Now it's building that base platform that you have, as opposed to thinking of a lot of new features and functionality along the way, as Pat was describing.
24:46
SPEAKER_02: What do all my customers want, the breadth of all those features and functionality, what may not work, what what will work.
24:53
SPEAKER_02: In the ERP space for the for the companies that install it themselves, they make those decisions earlier on versus later on.
25:02
SPEAKER_02: And so that helps with when do you have the significant development uncertainty?
25:06
SPEAKER_04: All right, that's very helpful context to both of you.
25:08
SPEAKER_04: So then, Pat, let me go back to your other bookend.
25:12
SPEAKER_04: So we're seeing, hey, I have in mind I'm gonna have all these new features, maybe AI or or otherwise, and it is unproven.
25:20
SPEAKER_04: How then, and Mike touched on this briefly, but how am I gonna know when there's some resolution?
25:27
SPEAKER_04: Like it's gotta be some way down the path before that happens.
25:31
SPEAKER_01: Yeah, and I think that's probably the biggest operational challenge that the standard presents is on the one hand, it seems like it gives you a lot of avenues to conclude there is significant development uncertainty.
25:43
SPEAKER_01: It will ultimately be very specific to the project, to the application.
25:47
SPEAKER_01: When that is resolved, I think you could imagine a scenario where it could be, I would say, very late in the development cycle.
25:55
SPEAKER_01: So the window between when you start capitalizing and when you have a product that's available for release is probably pretty short.
26:02
SPEAKER_01: Um, but it's you know going to be down to how you decide to design your process, to define your requirements, and then as Mike alluded to, you do have to resolve it through coding and testing, which again probably happens when things are pretty well developed.
26:17
SPEAKER_02: Yeah, our suspicion is companies that are used to developing in the external space have dealt with the concept of development uncertainty as they get to tech feasibility, and it's defined in the standard as a working model, right?
26:35
SPEAKER_02: So they're used to that.
26:38
SPEAKER_02: The this guidance didn't bring in the words working model, it didn't say once you hit working model, you're there.
26:45
SPEAKER_02: But if I'm a company that has historically done the external development model, and now I'm developing software that's delivered via the cloud, which is under internal use, I'd quickly be able to say, well, my process defines uncertainty that gets resolved in external when I hit working model.
27:06
SPEAKER_02: I'm going to follow the same process.
27:09
SPEAKER_02: So I'm likely close to working model for software that's going to be delivered via the cloud.
27:15
SPEAKER_02: Like so I think companies are going to, again, not define it there, but in their process equate well, the uncertainty is resolved at the same time for both.
27:27
SPEAKER_02: So that's the stage, and we're going to align them as both.
27:30
SPEAKER_02: And again, that's what the point of the standard was trying to get to.
27:34
SPEAKER_04: So just taking a step back and thinking about this from a preparer's perspective or the auditor who has to audit what the preparer is doing.
27:43
SPEAKER_04: If I'm relatively early stage and the company says, okay, I there is significant development uncertainty, here's why.
27:51
SPEAKER_04: And we would expect that to be documented.
27:54
SPEAKER_04: They'd want that documentation.
27:56
SPEAKER_04: Then would you anticipate at that point in time you would be identifying what needs to happen for the significant development uncertainty to be quote, lifted, or is that sort of as it evolves, you will know if you've resolved this development uncertainty?
28:14
SPEAKER_02: Yeah.
28:15
SPEAKER_02: So I I think there's going to be two things that a company will document.
28:19
SPEAKER_02: The first is going to be, hey, we're going off and going to create, and I'll I'll use AI as an example.
28:27
SPEAKER_02: But we're going to do our first attempt into the AI world, and we're going to see where it goes.
28:34
SPEAKER_02: And I can see companies saying this is very unique, very novel.
28:38
SPEAKER_02: This is a big change to how we typically do our software.
28:44
SPEAKER_02: So we're going to say we're developing something that's very unique and novel right now.
28:50
SPEAKER_02: And I don't know that there's going to be a lot of disagreement with that, knowing what these companies do.
28:58
SPEAKER_02: Then there's going to be, all right, I'm not developing AI stuff.
29:02
SPEAKER_02: I'm developing my suite of products at to the next level.
29:07
SPEAKER_02: Okay.
29:07
SPEAKER_02: When I do that, the company says, all right, here's what I want to do.
29:11
SPEAKER_02: I want to make version, whatever I'm going to make, or I'm going to make a new application in the suite that I offer.
29:18
SPEAKER_02: And I think I want to achieve certain requirements for the software, but I really don't know which requirements I'm going to do.
29:28
SPEAKER_02: Yeah, because you have to do some research or work first.
29:30
SPEAKER_02: Yeah, and when the development happens, this is this is a process where we have a hundred ideas and hopefully get to 10.
29:37
SPEAKER_02: Like that type of thought process where we're going to think about a whole bunch of different features and functions, and we sort of know the area that we want to go, but it's going to take a lot to refine that through customer discussions, figuring out what works, what doesn't work.
29:54
SPEAKER_02: And as those requirements are subject to change, that's one of the definitions in the standard that says significant development uncertainty is.
30:02
SPEAKER_02: When your requirements are subject to continual change, you have to wait until through coding and testing, they're no longer subject to change.
30:10
SPEAKER_02: So it allows for that agile development to progress, where you get to a point that says, okay, my requirements aren't going to change anymore.
30:18
SPEAKER_02: I know what this software looks like.
30:20
SPEAKER_02: And that typically happens at the end.
30:22
SPEAKER_02: So I think companies will just document that here.
30:24
SPEAKER_02: We're going to develop this next thing.
30:28
SPEAKER_02: We're going to go through our stage, initial stage of development, where we're doing a whole bunch of different sprints for a whole bunch of different requirements and features, and we don't know where it is yet.
30:40
SPEAKER_02: And then they'll document here's the point where we think we've now narrowed it enough where there's not much more change.
30:46
SPEAKER_02: And that's how they'll document those two.
30:49
SPEAKER_04: All right.
30:49
SPEAKER_04: That's a very helpful perspective.
30:51
SPEAKER_04: So we spent a lot of time talking about this timing of when you're going to start capitalization.
30:56
SPEAKER_04: Any other things we should be focused on in the new standard?
31:00
SPEAKER_02: Um So those were the two changes.
31:03
SPEAKER_02: So the focus is the thing that didn't change, right?
31:06
SPEAKER_02: So the costs that are eligible for capitalization haven't changed.
31:10
SPEAKER_02: So that's the cost to obtain software from third parties, direct materials and services consumed in the development, so payroll, including stock comp, cost of employees that are on the project, all of that direct cost are still the costs that are eligible.
31:26
SPEAKER_02: So that hasn't changed.
31:28
SPEAKER_02: And the costs that are specifically not allowed to be capitalized haven't changed either, which would be GNA, overhead, data conversion, and personnel training.
31:39
SPEAKER_02: The new standard doesn't define a software project.
31:43
SPEAKER_02: So that's like the unit of account as to what the development is.
31:48
SPEAKER_02: And the board intentionally said we're leaving that up to companies to know what their software, what their project is to do their unit of account.
31:56
SPEAKER_02: They do that now.
31:57
SPEAKER_02: And so that wasn't a change.
31:59
SPEAKER_02: So that is still a judgment that'll be made.
32:01
SPEAKER_02: And then the last thing is the current guidance talks about cost to implement a cloud solution.
32:10
SPEAKER_02: So if you're deciding I'm not going to license software, take it and put it on my servers, instead, I'm going to sign on to a cloud-hosted service like a Says, software as a service, the cost to implement those follow the standard as if you were putting it on your software.
32:30
SPEAKER_02: Now, in that case, if you're going to the company vendor and saying, I want a finished Says product, and you're going to use that product, there's likely not a lot of development uncertainty in your implementation of the existing as opposed to creating the new thing that needs to be implemented.
32:52
SPEAKER_02: So we don't think there's going to be a wholesale change in the level of capitalization for the implementation costs for Says, which was covered after this.
33:00
SPEAKER_02: Trevor Burrus, Jr.
33:01
SPEAKER_01: Yeah, maybe just a quick point of clarification on that last topic, because it's sort of like a consequential amendment.
33:06
SPEAKER_01: Like our whole discussion has been for the company who's developing the software, whether it's externally licensed, internal use.
33:14
SPEAKER_01: This sort of is the one little piece of guidance that flips it around a little bit, but it's kind of like if you think of one of the internal use options, is I might just go buy an off-the-shelf ERP system and I would capitalize that off-the-shelf software that I bought.
33:31
SPEAKER_01: This is the guidance that says, well, hey, if you procure that same software as a purchaser through a cloud application, you don't really have an asset that you buy, but there might be some other costs that go along with getting that solution implemented.
33:47
SPEAKER_01: So that was there was guidance that existed for internal use software, or it leveraged the internal use software guidance.
33:54
SPEAKER_01: So this is just sort of a consequential clarification.
33:58
SPEAKER_01: So again, doesn't change really anything.
34:00
SPEAKER_04: All right.
34:01
SPEAKER_04: That's helpful clarification.
34:03
SPEAKER_04: So all of this said then about the new standard, what's the timeline then for companies to adopt this?
34:09
SPEAKER_04: And do we have any sense if we think people will adopt early?
34:13
SPEAKER_02: Okay, so it's a month or so old.
34:17
SPEAKER_02: Um so it's not mandatory until 2028 for calendar and companies, but you can adopt it early.
34:24
SPEAKER_02: You know, given that the new guidance is better aligned with the way companies develop, there may be some benefits for adopting it early, but we haven't heard that that's a trend that people are going to do.
34:38
SPEAKER_02: And companies will still have to take their process and make sure it matches the words and make sure they're all aligned to apply the standard correctly.
34:46
SPEAKER_02: But I would mention any company that's thinking of adopting early, if they adopt mid-year, um this you know, you're required to, in your financial statements, to make it affected as if you adopted at the beginning of the year.
35:02
SPEAKER_02: So a standard issued in September, if companies like, ooh, let's adopt it, it's like, well, you have to adopt it back as of 1-1 this year.
35:10
SPEAKER_02: So you may not have time to do all of that, and maybe 1-1.
35:15
SPEAKER_02: Oh, 26 might be the better way to go.
35:18
SPEAKER_02: But companies will make that that decision.
35:21
SPEAKER_02: There are um three transition approaches.
35:25
SPEAKER_02: So full retrospective for all periods.
35:28
SPEAKER_02: Then there's prospective.
35:29
SPEAKER_02: So as a date of adoption for all the new costs, you apply the new standard as you go.
35:33
SPEAKER_02: And then there's a modified approach, which basically says you're going to do it prospective, except for projects that are in process now.
35:44
SPEAKER_02: If they wouldn't have met the capitalization standard, you would then remove the capital, any capitalized amounts related to those projects, not completed projects that are already been capitalized, but the in-process projects and and take that asset off through retained earnings.
36:04
SPEAKER_02: That's the modified approach.
36:06
SPEAKER_04: So then maybe just one point of clarification, because we uh Mike, you made the point that if you early adopt during an interim period, you have to go back to the beginning of the fiscal year.
36:17
SPEAKER_04: But we also said if it's prospective, that on the date of adoption, you would only uh consider go forward costs incurred.
36:25
SPEAKER_04: But I guess just one clarification there that if you take the prospective approach and it's in an interim period, that date of adoption would be the first day of the fiscal year.
36:37
SPEAKER_02: Yes, that's right.
36:38
SPEAKER_04: All right, so something for companies to think about then.
36:40
SPEAKER_04: Yes.
36:41
SPEAKER_04: And then um, Mike or Pat, anything uh that we're hearing in terms of early adopters or approach companies may decide to take, I could see benefits at least of the latter two.
36:53
SPEAKER_02: The first one seems more difficult, but um we haven't heard anything that would be a trend.
36:59
SPEAKER_02: Um we have heard some companies wanting to do retrospective because you know they want to alleviate the having to track and having to have their balance sheet have amortization.
37:13
SPEAKER_02: We've heard some companies wanting to do perspective one-one, not having to look back at all and just take it um go forward.
37:20
SPEAKER_02: So it's been a mixed bag and there hasn't been any trends, and it's really all about what position the company is, how much they capitalize to begin with.
37:30
SPEAKER_02: So it's really going to be company specific.
37:32
SPEAKER_02: We haven't really seen a trend.
37:34
SPEAKER_04: All right.
37:34
SPEAKER_04: Well, it sounds like a follow-up podcast once we start to see some companies adopt, and I'm sure there'll be more questions to bring up.
37:41
SPEAKER_04: So, Pat, let me go back to you for a moment because I I think there's a a related topic here that we've touched on briefly, but I maybe just to get a bit more specific.
37:52
SPEAKER_04: So we've talked a bit about AI and specifically AI software development.
37:58
SPEAKER_04: But again, I feel like that's every time you open the newspaper or open your app with the newspaper, uh, you know, there's some new company that's announced they're doing something with AI.
38:08
SPEAKER_04: And so just to specifically address that, what does it really mean if someone is saying they're doing AI software development?
38:18
SPEAKER_01: So is AI a thing?
38:19
SPEAKER_01: I haven't really heard that.
38:22
SPEAKER_02: Pat actually got me with that question.
38:25
SPEAKER_02: What what does AI mean?
38:26
SPEAKER_01: Yeah.
38:27
SPEAKER_01: No, it's it's a good it's a good question, and we've we've gotten it a lot, actually.
38:31
SPEAKER_01: And I guess the short answer is while AI is a very new technology, um, certainly a massive amount of uh money and resources being devoted to developing tools uh under this umbrella concept of artificial intelligence, at least from an accounting perspective, we think of it as software.
38:54
SPEAKER_01: And so the question is what are you actually doing with this AI development and putting it in the context of the software cost capitalization framework that we've just talked about?
39:07
SPEAKER_01: So sometimes it's not just software.
39:10
SPEAKER_01: There might be some other elements of an AI activity that aren't pure software.
39:15
SPEAKER_01: One example is a lot of uh data is necessary oftentimes to train some of the models and the algorithms.
39:24
SPEAKER_01: So purchasing data from another party is that party's intellectual property.
39:30
SPEAKER_01: So you've now purchased intellectual property, that's an intangible asset.
39:34
SPEAKER_01: We would evaluate that as the purchase of an intangible asset.
39:38
SPEAKER_01: Sometimes those intangible assets would be capitalized, oftentimes they would be.
39:43
SPEAKER_01: Sometimes, if they have a very limited specific purpose, there's no alternative use for that data other than the one thing you bought it for to train your AI, you might expense it.
39:54
SPEAKER_01: But you know, that's one flavor of it.
39:57
SPEAKER_01: You'll have some other costs that you incur as part of the AI development project, but it's just like the other costs we've talked about in the context of other software development.
40:06
SPEAKER_01: Some of it will be the actual coding and design and development of algorithms, some of it will be other general overhead costs that the organization normally um incurs.
40:17
SPEAKER_01: So the again, the short version is there's no separate special model for AI costs.
40:22
SPEAKER_01: It just goes back to this framework we've been talking about.
40:25
SPEAKER_01: Now, you can imagine, I think, as we also alluded to, that given the novel, unique, unproven nature of some of this technology, you might be concluding for quite some time that those costs should not be capitalized because there is significant development uncertainty.
40:42
SPEAKER_04: Aaron Powell So then with all of that said, once I'm in this development, and again put aside the cost of if I'm buying data, which I know you saw is a separate consideration, but what are some of the components of the development then I would normally think about?
40:57
SPEAKER_02: Aaron Powell Yeah.
40:58
SPEAKER_02: So oftentimes when we hear, ooh, I'm doing AI development, people quickly say, Oh, you're gonna develop a generative AI large language model.
41:10
SPEAKER_02: And most companies are not developing a generative AI large language model.
41:16
SPEAKER_02: And that's because they are so expensive, so resource intensive, and very difficult to do.
41:24
SPEAKER_02: What most companies are doing is entering an arrangement with the companies that have the generative AI large language model.
41:34
SPEAKER_02: And this gets back to the scenario of a company may say, Oh, I've entered into a license for one of those large language models.
41:42
SPEAKER_02: And I'm using air quotes on a podcast.
41:44
SPEAKER_02: I don't know why, but I always do.
41:47
SPEAKER_02: But the concept of licensing that large language model is probably not accurate.
41:53
SPEAKER_02: It's probably more like a service because you're not taking the code and running it on your servers.
41:59
SPEAKER_02: The server farms are too massive, too um cost-consuming.
42:03
SPEAKER_02: So companies that are developing their AI typically have a service arrangement with one of the companies that have the large language model.
42:12
SPEAKER_02: And then that service arrangement, one is not an intangible asset, it's a service, and it happens so early in the development phase, that's likely just an operating cost to be able to use that large language model.
42:29
SPEAKER_02: We talked about the data.
42:30
SPEAKER_02: The data is going to then likely be purchased.
42:33
SPEAKER_02: You could use your own data, but that doesn't have a cost because that's an internally developed intangible, different podcasts.
42:39
SPEAKER_02: But um so that doesn't have a cost.
42:42
SPEAKER_02: So you can purchase data.
42:44
SPEAKER_02: That's its own intangible asset.
42:45
SPEAKER_02: We do get questions about what's the amortization period for the data, because people think, oh, it must be short because it's going to be a good idea.
42:54
SPEAKER_02: Yeah, data's changing or whatever.
43:00
SPEAKER_02: Um, it all depends on what your contract for the data is, how how long is your license rights for that, and then how much are you going to be using the data?
43:10
SPEAKER_02: What we've seen is companies purchase data with the intention to use that data over years to develop multiple AI software applications.
43:20
SPEAKER_02: So it's very likely that you could have the data have a longer life than the individual software that's being trained.
43:28
SPEAKER_02: Right.
43:28
SPEAKER_02: So it's just a very own analysis.
43:31
SPEAKER_02: How long am I going to use that data?
43:34
SPEAKER_02: Um and then as Pat said, once you have those two components, the other components are prompt engineering, regular software coding, which is you follow the regular software approach to that stuff.
43:46
SPEAKER_01: I mean, I guess the one point, maybe just to um layer on, you could still have the distinction of am I doing this for internal use to build my own application hosted through a SaaS?
44:00
SPEAKER_01: uh platform or am I doing it in some sort of an externally licensed model?
44:03
SPEAKER_01: But I think as we alluded to earlier, those models, even though they have different words, they get you to a pretty similar outcome.
44:11
SPEAKER_01: So maybe a distinction without a difference.
44:13
SPEAKER_01: Under the existing model, a little bit more work to do because you have to somehow figure out a way to translate what you're doing into these um project stages, which again feels like an out-of-date concept, especially for this.
44:27
SPEAKER_01: So but that's a lot there.
44:30
SPEAKER_04: Definitely a lot to think about here.
44:31
SPEAKER_04: And I do think this question, um, I know you guys both smiled at me when I said a follow-up podcast, but I do think it's going to be very interesting to see as companies start to adopt the approaches they're taking and then from a practical perspective, what questions are coming up as people actually try to operationalize this.
44:49
SPEAKER_04: So I do think we'll have a follow-up podcast.
44:52
SPEAKER_04: But in the meantime, uh just any final words of wisdom from you as companies start to think about adoption of the standard?
45:00
SPEAKER_04: And maybe Mike, I'll start with you.
45:02
SPEAKER_02: Yeah, I I think you know my expectation is there's a new model with new words, the thought as it aligns um more closely with the external use.
45:17
SPEAKER_02: But my expectation is other than the software developer that's developing software for SaaS or cloud, most companies aren't going to have a very significant change.
45:32
SPEAKER_02: Right.
45:33
SPEAKER_02: Certainly companies that you know are the internal use only, not only companies.
45:39
SPEAKER_02: I don't want to say it that way, but I think of a bank that has a lot of software that they use internally I I don't see this really having that much play.
45:49
SPEAKER_02: I think if there's a change, the change would likely be in that software developer that's developing software to be sent over the cloud.
45:57
SPEAKER_02: And if the change is it'll be less capitalization.
46:01
SPEAKER_04: So it sounds like then really trying to understand what this even means for your company before you worry about timing of adoption or how you're going to adopt or anything else is is probably a good first step then.
46:13
SPEAKER_01: Yes.
46:14
SPEAKER_04: So then Pat, how about from your perspective?
46:16
SPEAKER_01: Yeah I was just going to say Mike was sort of talking about the reporting outcomes which I agree with.
46:20
SPEAKER_01: I don't think there's going to be a massive change there.
46:23
SPEAKER_01: I think what you alluded to really is where some of the work is is making sure you align your processes, your controls, your documentation to uh marry up to the new uh guidance, but you do have some time and you also have the ability to think about what do you think makes the most sense?
46:41
SPEAKER_01: Do you have a bunch of costs on your balance sheet that you kind of wish weren't there because you know you've you're forced to capitalize them under the old model.
46:50
SPEAKER_01: Does anybody you know care that much?
46:52
SPEAKER_01: Would you rather just get them all off the balance sheet.
46:55
SPEAKER_01: So some of those considerations I guess um more practical than theoretical.
47:01
SPEAKER_02: Yeah and I and I would add while there is a long runway for it, we have to disclose the impact of standards issued and not yet adopted.
47:10
SPEAKER_02: So it's there's still some work as Pat said to make sure we figure out how this is going to impact the business because if you don't adopt it early and you wait, there is some disclosure requirements to say how it will impact yeah it's a great reminder.
47:24
SPEAKER_04: So for companies calendar year on companies that's coming up soon that they're going to need to include some of those disclosures.
47:31
SPEAKER_04: So uh I think that's definitely important.
47:33
SPEAKER_04: And then Pat, you know, remind your comments reminded me we've seen other standards as well where it's like well it might not really make a change but the terminology is a lot different and so you you don't want to wait until the last minute because then it could be a scramble versus having an orderly amount of time.
47:50
SPEAKER_04: So all right well gentlemen this great topic is very interesting to talk to you both.
47:55
SPEAKER_04: So thanks so much for joining me today.
47:56
SPEAKER_02: Thanks Heather to be here.
47:58
SPEAKER_04: That's our show for today tune in next week for more fresh episodes so that you never miss any of our audio content follow the PWC Accounting Podcast wherever you listen to your podcasts.
48:11
SPEAKER_04: And to stay up to date on all our latest accounting and reporting news sign up for our newsletter at viewpoint.pwc.com from Thought Leadership at PWC I'm Heather Horn.
48:38
SPEAKER_00: member firm or one of its subsidiaries or affiliates and they sometimes refer to the PWC network.
48:44
SPEAKER_00: Each member firm is a separate legal entity please see www.pwc.com slash structure for further details.
48:53
SPEAKER_00: 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.