On-Demand: What You Should Know About Capitalizing Software Development Costs

We'll also leave some time for Q&A both in between sections and at the end.
Moderator: So I think we've come to our first polling question, and we'll now launch our first polling question. Which topic are you most interested in? A, capitalization of internal-use software development cost. B, capitalization of developmental cost for softwares to be sold. C accounting post initial capitalization or d, all of the above.

Please remember that in order to receive your CPE certificate you must remain logged on for at least 50 minutes and respond to at least three polling questions.
Richard Cleaveland: So Jaime while we wait for the internal polling results my guess is as I mentioned with the reliance on software for a lot of internal business processes, a lot of people are going to be interested in this concept of internal-use software and capitalizing those costs.
Jaime Gilmore: That's right Rich, I hadn't seen that and I think the lines are becoming more blurred over time with the way we deliver software how we use it. It's become really pervasive in almost everything that we touch. So I do think that this is a great opportunity today to refresh everyone's knowledge to respect to the rules and help them decipher some of the nuances for the application thereof.
Richard Cleaveland: Yeah and I think from the software vendors side too what we've seen is a lot of those vendors moving from a perpetual or term license model where they're selling software to customers to more to a software as a service, or a fast model, and they're business models.
Jaime Gilmore: That's exactly what I'm saying about I would say 10% of the distribution are, 10% of my clients are still distributing software on those perpetual models. But majority of them are moving to the hosted, or the fast model that you mentioned.
Moderator: Okay I will now close the poll and share the results.
Richard Cleaveland: So it looks like we got a lot of people interested in internal-use software as we thought and then all of the above. So it's good, we've got a little bit of all these topics in these slides and why don't we jump right in to the overview of development costs.
Jaime Gilmore: Okay so before we dive into the accounting rules around capitalization and software development, cost let's spend just a few minutes and discuss the topic at a high level to provide us with a nice starting point. Software development costs maybe capitalized, that it's recorded as an asset to be expensed over a future period, if they relate to internal-use software and software to be sold leased or otherwise marketed.

The guidance governing the capitalization both for internal-use software is ASC 350-40 and the guidance that addresses the rules around capitalization of software to be sold can be found in ASC 985-20. The rule around capitalization and subsequent amortization differ based upon on how the software was used.

So where do you start? Well you maybe subject to internal-use software capitalization rules if you purchasing or developing software or purchasing the right to use software that's hosted by a vendor, often referred to as software in the clouds. Such software will be used to support internal operation.

Vendors of software also face challenges with identifying the correct capitalization rules to apply. Vendors selling software need to evaluate their arrangement to determine if they apply the guidance related software to be sold or internal software rules if their hosted solutions are really service contract.

Fred can you highlight for us some of the key characteristics of costs that maybe incurred when developing software for internal use?

Fred Kosnac: Sure so for internally used software the software has both of the following characteristics. First is that the software is acquired or developed solely to meet the entities internal needs and second is that there's no substantive plan to market the software externally. So activities such as the cost sharing agreements and routine market feasibility studies are not considered a substantive plan. We'll get into the substantive plan a little bit more on the next slide as we talk about external software.

Often an entities past practices can shed some light on whether a software is for internal use or is subject to a plan to be marketed externally. An example of this would be a company that both uses and sells its own software products. A history of both using and selling softwares creates a rebuttable presumption that any software developed by that entity is intended for the sale lease or other marketing.
Jaime Gilmore: Great Fred. Do you also some insights to help us identify when it maybe appropriate to apply the rules for software to be sold and marketed?
Fred Kosnac: Absolutely. So the characteristics we have under the development process of software to be sold, leased or marketed, an entity drafts a substantive plan to market the software externally. Now this substantive plan could include hiring a sales team, setting up licensing agreement with distributors, or identifying promotional and billing activities.

At this point it's important to note that in order to be considered a substantive plan the implementation of the plan should be reasonably possibly. So if all you have are some preliminary meetings some general R&D this would not constitute as substantive plan, it needs to be more focused on that to meet the definition.
Richard Cleaveland: So Fred if I'm company and I'm developing this piece of software for my internal use, and I think oh this would be great potentially to sell it one day, you'd actually have to have a lot more than that. You need to have like a time, plan in place and really do some work around developing that a channel before you've considered selling software externally.
Fred Kosnac: Yeah that's correct. Without that focus plan that really kind of leaves out where you're targeting, and you know when plan to go to market things like that. It's really hard to have to say that you have that substantive plan in place.
Jaime Gilmore: So it seems to me that, in a world without hosting or software being delivered under the SaaS model the rules for capitalization would be much simpler to apply but that's not the world that we're living in. So Rich could you take us through some of the insights and perspective of a customer in applying these rules in a hosted environment?
Richard Cleaveland: Sure and I think you know especially with the movement of software out of the server within our physical office location and to the cloud, the analysis of what's considered a purchase of software by a customer versus a service contract becomes important a little bit more complex. So you know software delivered by a vendor through the cloud either provides access to that software for the customer, or it's really owned by the customer but just hosted by that vendor as a convenience.

So the guidance of the literature puts out some guidance as to how you might make this determination as to whether or not it's a service or a purchase of software. Specifically there's to criteria that if they're met it's considered to be the purchase of software. One, the customer has to have the contractual right to take possession of the software at any time during the hosting period without significant penalty.

The meaning in the agreement the customer has got the right anytime to move that software out of that vendor hosted environment to their own environment or to some other third party. Secondly it's feasible it must be feasible for the customer to run this software on its own hardware or at that other third party.

So they also kind of give a little bit more color on what they mean by without significant penalty. The customer can take possession of it without significant penalty if it can take it without incurring a significant cost and if it doesn't cause a decrease in the functionality or diminution of the utility to the value of the software.
Jaime Gilmore: I think one good example of where a customer may not be able to take possession of the software without that decreased utility is with respect to virus scanning software for example. If the customer is able to take that software and migrate it to their own that are at the core of softwares basic purpose.

I think that's an example where you may physically be able to make the move right? But suffers some diminution of value or utility in the process.
Richard Cleaveland: I think that's a good example and it just points out that there's a lot of judgment involved in determining whether or not you can easily take that software and still operate it as you intended to have it operate within the vendor's environment. So Jaime I just walked through kind of from a customer's perspective, how about from the vendor's perspective?
Jaime Gilmore: I think we have a bit more on the customer's perspective because we don't want to overlook one of the newest ASCs in this topic area.
Richard Cleaveland: I think you're right, ASC 2018-15 which just recently came out. So we talked a little bit about the hosting arrangements and when it's a service contract typically those historically have been scoped out of internal-use software development rules, and you'd account for it expense as you're paying those subscription payments.

However often with those types of arrangements the customer is required to make significant upfront investment and implementation of that software. Usually implementation it's to build connectors maybe between the hosted solution, and their own software that helps data move between the two software packages a little bit more easily or just simply tailors it a little better for the customers use.

So the ASC that came out 2018-15 said those implementation costs although they might relate to a service contract would still be scoped into software development. Internally used software development cost rules and would be evaluated under those rules to determine if they can be capitalized.

So that new pronouncement is effective for public entities with annual periods beginning after December 15th 2019. For all other entities for annual periods beginning after December 15, 2020. Earlier application or adoption of that pronouncement is permitted. So now I think would be the right time for us to move to the next area.

So we talked about the customer perspective Jaime and the guidance though for vendors is similar in determining whether or not they're providing a service or selling software also.
Jaime Gilmore: That's right Rich. Much of the same consideration that you just covered, also come into play from the vendor's perspective. For instance vendors must perform the same analysis as customers with respect to their hosted arrangement. The two criteria you just covered regarding a customer's contractual rights, to take possession of the software and the feasibility of them to do so would be key factors in the vendor's determination of which set of rules to apply.

If both criteria are met the vendors should apply the capitalization rules for software to be sold. If the two criteria are not met then the vendor providing a service and the vendor should apply the internal-use software guidance to the treatment of the software development cost.

Now we have here for you some examples of internal-use software. It's a starting point in your considerations around this topic. So from the customer's perspective goes back off the system. The ERPs, your general ledgers packages, your billing modules, your CRM, customer relationship software packages are generally into the internal-use guidance.

From the vendor's perspective, software being used to provide a service like we mentioned earlier under the SaaS model, that would also be into the internal-use guidance. Vendors should also consider, software vendor using to provide a service where software is not at the forefront of that service, but just an outsourced business function. The software that they maybe using to facilitate that provisioning should also be subject to tune the internal-use software capitalization rules.
So before we move on to our next topic, let's take our second polling question.
Moderator: Okay we are now sharing our second polling question. Do you utilize a time tracking system to capture the number of hours your employees spend on software development projects? A, yes, B, no, C, unsure, D, we don't internally develop the software. Please remember that in order to receive your CPE certificate you must remain logged on for at least 50 minutes and respond to at least three polling questions.
Jaime Gilmore: So I think one of the question, which is a bit of a housekeeping question came in regarding the references to the particular codification sections. So at the back of this slide deck you'll find that we've included a reference slide for you. So you'll have that for your takeaway so no need to worry about missing those references. They're all packaged up for you right here.
Richard Cleaveland: I think another question we have Jaime, it's an interesting one also that it says if the developer owns the cloud-based software, but the customer's making significant changes to meet their needs, and I think that gets into that implementation, how do you deal with those costs, either the making significant changes to it?
Jaime Gilmore: So again from the customer's perspective the company that's making those modification I think they need to apply the analysis. How are they using the software? Will they will using it despite making these modifications to support internal operations or is it going to be integrated into perhaps some other component of software that will deployed and sold to the market?

So I don't know that making significant modifications changes the rules that apply. I think what is timely is the new ASU?
Richard Cleaveland: Yeah I think that's right. If it is a cloud-based, and you've already gone through that analysis, and determined that it's a service contract and general you'd expense those payments under a service contract as you incur them you'd still be able to adopt that new ASU and look at those modifications that you're making, there's the implementation cost and evaluate whether some of those would be able to be capitalized and under the rules for internal-use software.
Moderator: Okay we're now going to close the polls and share the results.
Richard Cleaveland: So a little bit of mix of responses here between yes, no and we don't internally develop software, a lot of the we don't internally develop software maybe you know purchases of a fast solution. I think again those rules are really looking at whether you own that software or whether it's a service contract will be key in the analysis.
Jaime Gilmore: Okay so Fred indulging upon your previous summary of some of the key characteristics of cost incurred when developing software for internal use, can you now walk us through the application of the related capitalization rule?
Fred Kosnac: Sure. So ASC 350 specificities three stages in the developed of the internally used software. So the first. So the first stage is the preliminary product stage, this is where the software does exploratory research, so they'll determine the desired functionality, they'll determine if the technology exists to achieve the performance goals.

The cost during that stage are expensed as incurred because at this point you haven't done anything substantial for a specific software. Second stage here is the application development stage. So this is the stage where most of the true development takes place, including development task design, coding, hardware installation and testing. This is the stage at which it will generally be capitalized.

Third stage here post implementation is after the product has already been rolled out and is being used for its intended purposes. Theses cost again would be expensed as incurred and typically the cost here includes things such as training, and maintenance cost.

So as mentioned in the previous slide the application development stage is where the capitalization of course takes place. The common types of cost capitalized during this stage include the external cost of materials and services incurred directly related to the software such as third party developer and payroll related cost are employees who are directly involved in developing the software.

So an important note here again is that training cost incurred during this stage should not be capitalized but expensed. In order to begin capitalizing cost during this stage management must first authorize and commit to funding the project and the company must have completed the preliminary project stage.

Additionally, project completion should be reasonably expected. So with that Rich do you think you have any example you could walk us through of the internal-use software?
Richard Cleaveland: Yeah so I think we'll start, I'll read through a company XYZ develops a CRM software to manage its customer base. The software is intended for use by the sales department so that they can track customer behaviors. Billings and collections are maintained in an emailing mailing list. Given the intended use of the software it's not expected to be marketed or offered to customers, it's determined that it meets the company's internal needs and therefore the CRM is classified as internal-use software.

So management has identified the following categories of cost in developing the software. First surveys of its sales force determined features that would beneficial to a new CRM system. Meetings between the IT department and management to lay out a development plan, labor cost related to the design of various module within the CRM system, outsourcing fees to a third party firm to help with coding and data integrity.

Staff training sessions to teach the employees how to use the software, and then labor costs to fix bugs after the software has been launched. So in our analysis and looking at the guidance the first two categories of cost the surveys to determine the features that will be shown and then meetings to develop, create a development plan those are preliminary project stage costs and should be expenses incurred.

The second two labor cost related to designing the modules and using outsource resources to help with that development those would be application development stage phase costs and would be capitalized. Then the last two training people to work and use the software and then fixing bugs after it's been launched those would be post implementation costs and would be expensed incurred.

For any of the costs that qualify within that application stage for a capitalization those would be capitalized and then the company the entity would begin amortizing those would determine useful life when the software is ready for its intended use.
Jaime Gilmore: Okay Thanks Rich. So just spend a bit of time on internal-use software and the application of the guidance there, let's pivot and turn our attention now to the application of the guidance governing the capitalization of software to be sold or marketed.

So cost incurred to develop software sold by companies where the customer owns the software and maintains the software on their computer or their server regardless of whether the customer owns such software for a specific period of time i.e. a term life or in perpetuity.

The cost for such development should be capitalized behind the rules of ASC 985-20. Inversely if a vendor is provisioning software under that SaaS model, then the application of the rules of ASC 350-40 that Fred and Rich just discussed would govern. So when does capitalization begin and end? Capitalizing cost begins only after reaching technological feasibility when the software is to be sold.

This is a bit different than the rules that govern internal-use software. The capitalization period end when the software is available for general release. Similar to the rules for internal-use software not all costs can be capitalized even if they're incurred during the capitalization period. So some of the costs that are eligible for capitalization includes development labor, this can be internal personnel, payroll cost as well as third party cost, for software development or software that maybe purchased and integrated into the software that's being developed.

Some costs that are not eligible for capitalization regardless of when incurred include overhead, administrative time and expense, training and maintenance. So those bug fixes, that Rich mentioned previously. Those are a maintenance type activity and any cost related to that would be expensed as incurred.

However, work generally doesn't stop on a software product once it's made available for general release. Companies are constantly thinking about what to do next? How can we improve the product? So ask yourself am I adding additional functionality, if you are the cost associated with that work to expand upon a functionality or add new features are eligible for capitalization.
Richard Cleaveland: Jaime you know if I'll interrupt there's one question that we have, I think was asked back for internal-use, but was similar to what you were just covering there with bug fixes and whether other enhancement, significant enhancements that are made post to the implementations of internal-use software would you have to expense those or if it has functionality could you capitalize those costs as well?
Jaime Gilmore: The same rules apply generally apply. So if you're adding significant functionality whether it's for your own use or external reapply those rules with respect to the planning and post implementation they maybe eligible for capitalization as well.
Richard Cleaveland: Great.
Jaime Gilmore: Okay so with respect to the capitalization periods let's take a moment to discuss our starting point, technological feasibility. So the guidance state that technological feasibility is achieved when an entity has completed all planning, designing and testing activities that are necessary to establish that the product can be produced to meet design specifications including functions features and technical performance requirements.

There's generally two approaches that are employed to make such determination. The first thing a detailed product design and the second thing a working model. So we've highlighted here for you the steps within the detailed product design that need to be completed in order to reach that technological feasibility. So Rich in your experience over the years have you seen a trend toward one of these approaches over the other?
Richard Cleaveland: I think the working model definitely is going to come later in the process than a product design. It's after the working model would be after you've got almost a beta version of this and you know it's operated, it's doing all the main things that you look to develop. I think early on when this guidance was originally written a lot of the development tools that exist today did not exist.

A lot of times when programmers were making stuff at that time they didn't know whether it was going to work for its intended purpose or not until they got a working model developed. Now you fast forward and we've got there's better development tools, there's platforms on which people are building software. In a lot of cases that takes the uncertainty as to whether to not the product is going to work as they intended much early in the process.

So it's seen more people going to that product design at this point. But it doesn't mitigate the need for having detailed documentation around how it's going to work.
Jaime Gilmore: I think that need for the detailed documentation is even more of an issue now in the agile type work environment where things are moving at a very quick pace. There isn't a starting at one point, and you in a seamless straight line work towards the end product. I think having that documentation around multiple modules in the development of modules really helps it achieve the goals and results in the appropriate application of the rules.
Richard Cleaveland: I think that's right.
Jaime Gilmore: So we said at the end point too the capitalization period for a software to be sold and marketed is at the point where the software is eligible for general release. This is generally when the software is available to be downloaded by the consumer B or is available for subscriptions or distribution.

So just think of that when evaluating your timeline. So we have an example here that Fred's going to walk us through to highlight the application, some of the considerations around applying the guidance here on software to be sold.
Fred Kosnac: Thanks, Jaime. So in our example here we have a company that develops a propriety software, which we're naming program X. That provides business the ability to gather big data and create detailed analytics in real time. The company license is the software on a perpetual basis and the customer maintains the software on their own computers and servers.

So here we have a list of or our timeline of the development of the software which I'll run through February 17 a company has preliminary meetings to come up with the concepts for the new software and market analysis was obtained to determine their potential customers. April, through September the work has started on developing the structure of the new software consisting of labor cost, or consulting.

September of that year first working version of the software is completed however there's still some significant development issues that need to be worked through before the program works as intended. In October the development issues have been resolved by the team, the company now has a working data of program X which meets the specification of the original project design.

November 17 through January of 18th the development team was to finalize the various modules of the software and the end of January the company begins training its tech support team to service the new software and performs further tests in an effort to detect bugs. February of 18th the company completes the project and signs up its first customers to annual subscriptions.

In April the company releases its software attached to program X which fixes some lighted bugs that existed at the time of the launch. Lastly October through November of 18 the company develops and completes the significant features that give the customers the added ability to run predictive analytics on various scenarios.

So after taking in the timeline of the events and you know all the facts and circumstances in the example, we would say that in evaluating these costs the company should capitalize the development cost that were incurred from November 2017 through 2018 January of 2018, excuse me. All the costs before that period were incurred prior to the company achieving technological feasibility.

So again that's that key milestone you want to look for. Capitalization of these cost would cease upon the date in February of 18 when the software is deemed ready for general release to its customers. This would likely also be the data that the company would begin amortizing the capitalized costs over the determined useful life. This is something in the next section that Rich will be covering a little in more detail.

The costs related to training the tech support team would also be expenses. Then as far as the costs that were happening after the completion of a general release of the software most of these would be expensed for the software patch and there's no added functionality it's really just bug phases nothing significant there.

However, the development costs for the addition of a significant feature does add functionality in this case and therefore it would be capitalized.
Jaime Gilmore: That's a lot of dates and activities to consider in the application of the rules here. So it seems like this would be an exercise that really involves multiple departments not just the finance group working through the accounting in a vacuum. So what are some of the other departments that should get involved in this process or that the finance group should get involved?
Fred Kosnac: Absolutely that's a great point to bring out Jaime. So really I mean this shouldn't be something that the accounting team is working in a vacuum on. When they're going through this analysis it should really be kind of a joint effort between them and the either the project manger or whoever is heading up the development team of that software so that they can work in concert there and really come up with the specific timelines of when the different milestones are hit. So when technological feasibility happens and when the software is ready for general release, so everybody is on the same page when it comes to the period that the costs should be capitalized and then when that software should start being amortized.
Jaime Gilmore: Yeah. I think it's helpful for the finance group to have you know a little insight into the development the software development team plan. So that all the proper procedures and processes can be put in place. Thanks Fred. So we've now arrived at our third polling question.
Moderator: Okay now I have launched the polling question. What is the average period over which you are amortizing capitalized software development cost? Is it A, one to three years., B, three to five years. C, greater than five years. Or D, you're unsure. Please remember that in order to receive your CPE certificate you must remain logged on for at least 50 minutes and respond to at least three polling questions.
Richard Cleaveland: So we've got a question about a company that's developing custom software for their customers. So they're not selling any product, they're developing at the requirements of a customer to meet the customers specifications. The question is should those costs be capitalized also? The answer would be no those should be expensed as cost of sales for the development services that are being provided to those customers in that situation.
Jaime Gilmore: Conversely that customer could be capitalizing the expenses that they're incurring by outsourcing this development to this third party.
Richard Cleaveland: That's exactly right. Whether it's interest for their internal use or then they're going to use that to sell to someone else. Good point.
Jaime Gilmore: I think we're going to go to the poll and share the results.
Richard Cleaveland: Okay so it looks like most people answered three to five years and there's also some with one to three years. I think Rich and Jaime would say that that's pretty on par with what we've seen with a lot of our clients.
Jaime Gilmore: I think so, I think the expectation is that the capitalization period and amortization period rather for software nowadays is on the shorter side of things. So this is falling right in line with what we've seen and practiced.
Richard Cleaveland: So I guess is that segue to the next section. Now that we've talked about capitalizing the cost and what gets included, we'll turn our attention now to how do you account for this cost once they've been capitalized, and you've put the software in the service. Where you've had it available for its intended use.

So for internal-use software amortization of the capitalized cost begins when the software is ready for its intended use and that's generally after all testing has been performed. This may or may not be before the software actually has been placed in the service, although I would expect that those dates are pretty close together.

The cost generally should be amortized on a straight line basis unless there's some other systematic irrational basis that's more representative. I think typically what we'd seen in practice is a straight line amortization of these costs.

So based on several factors and there's judgment involved. But typically you'd look at what the planned obsolescence would be around software such as this or how fast things have changed in the market place and other economic factors and what the intention is for your use of it and when you plan to replace the software going forward.

So you know given the history of rapid changes within technology as we mentioned we tend to see a relatively short useful life and you know one to three or three to five years sounds pretty reasonable in that respect.
Jaime Gilmore: On a personal note I mean I think we find in our personal day to day interactions with technology operating systems as an example, they become quite antiquated very quickly. So I think you know approaching that even from you know personal standpoint it gives you an indication of what an appropriate useful life might be.
Richard Cleaveland: Yeah I think even after setting the estimated useful lives and the amortizing you still have to be concerned with potential impairment of that software, the software costs. The literature puts forth about five different factors that you should think about and factors that if these circumstances occur that you should really consider whether or not assets is impaired. First of which is whether or not it's expected to perform as intended.

So you might put the software in place intending to support a certain business process and then find out several months later that you're going to go a different direction or use something different, it's just you need to impair the asset.

Whether or not the software is expected to change significantly, that same scenarios you might decide to change it and make it a different, have it perform differently than the initial software package you put in place. Cost to developer or modify the software if those vastly exceed the expected amount.

So what the literature means by that is if you started with a development team, building a piece of software and then determine that you had to rework a lot of that or get some other team or outsource developers to rebuild it, you can't capitalize both sets of costs. You've got to only capitalize only to what was expected for the development.

Then finally obviously if the software is not being used any longer for its intended purpose or at all then you would need to consider whether or not to impair it. Basically that would require some judgment, looking at the net book value of the asset and writing that off to the P&L.
Jaime Gilmore: Thanks Rich so next we'll turn to amortization of software to be sold. So a little bit different than internal-use software there isn't, the guidance doesn't provide for the subjective selection of a method which to employ to amortize these capitalized costs.

The guidance says that the annual amortization shall be the greater of the amounts computed using one of these two methodologies, rather. The first methodology being the application of the ration of the current gross revenues for the products to the totally anticipated future gross revenues for that product to the capitalized cost. The second being the straight line method which you mentioned earlier Rich.

So I think in practice we find that most use the straight line method because it results in a larger initial expense when applied isn't that correct?
Richard Cleaveland: I think that's right. I mean if you think about like developing a new software product in the earlier years of that development revenue relative to the forecasted future revenue is going to be quite low, which is going to result in that ratio being in many cases less than what it would be on a straight line basis.
Jaime Gilmore: I think from a comparability perspective though you know this isn't at the discretion of management, which to choose. I think the straight line method by default generally eliminates some of the volatility that might come into play with the application of the ratio of current gross revenues to future gross revenues.

The application of that methodology also is highly dependent on management estimates regarding future revenues. So again anytime there's the injection of judgment into something, it opens it up for future rework or it changes in estimates. So we said that amortization starts when the product is available for general release.

So to walk you through and provide an illustrative example of the application of the two different methodologies. So here, assume that company ABC developed program X to be licensed to customers. The total cost capitalized from the time of reaching technological feasibility, through March 1st the day in which the software is ready for general release to customers was approximately $150,000.

The company estimated a useful life of three years and expects to generate a total of approximately $2 million in revenue over that same period. So we have two tables here, under method one this is the ratio of current gross revenues to future gross revenues. You can see that in the first 10 months of sale in our example the company's expected to generate 15% of total expected revenues to the product and 15% of that capitalized cost of 150,000 yields an amortization expense of 22,500 for the initial period.

When you compare that to the application of the straight line method you can see that the straight method yields an annual amortization for that initial period of approximately 42,000. So this in case the guidance would say you need to apply the straight amortization method to amortize the cost into the P&L.

So similar to internal-use software the guidance requires an impairment assessment to be performed the capitalized cost for software to be sold. This test is called a net realizable value test. Specifically the guidance states that this test should be performed at each balance sheet date, taking the unamortized capitalized cost of a product and comparing that to the net realizable value of that product.

So what is the net realized value? The guidance says that, it's the estimated future gross revenues from that particular product reduced by the estimated future cost of completing the performance obligations related to such product. What are those future performance obligations? It's generally the maintenance in customer support. So supporting the product for a period of time.

So taking the unamortized cost and comparing that to the net realizable value is this net realizable value test. If the unamortized cost exceeds the net realizable value you have an impairment situation and the assets needs to be written down. Now again once that asset has been written down and not subject to re-measurement to subsequently restored.

So I think that concludes our discussion around the capitalization and amortization of software to be sold and we have now arrived at our next polling question.

Moderator: Do you anticipated the adoption of ASU 2018-15 will have an impact on your financial statement? A, yes. B, no. C, no change. D, not sure.
Richard Cleaveland: Jaime while we're waiting for this polling results, one question that came in is where would the amortization expense be recorded in the P&L? Is it would go to cost of sales or would it go to?
Jaime Gilmore: So I think this depends on the software that we're talking about whether it's for internal use or a software to be sold and marketed. So for internal-use software this is going to find its way into SG&A, for software to be sold or marketed it will find its way into the cost.
Richard Cleaveland: Yeah and I think also if it's internal use and you're using it for some sort of R&D process unrelated to it you might allocate it to there also.
Jaime Gilmore: That's a great point yeah.
Richard Cleaveland: I guess the point it has to do with that the functional use is and how that best matches up to the-
Jaime Gilmore: To what you're disclosing in your P&L?
Richard Cleaveland: Right.
Jaime Gilmore: Right.
Moderator: Okay we're going to now close the poll and share the results.
Jaime Gilmore: Okay, so I think this is, it is a relatively new ASU, so you know respondents the majority of respondents are not sure of the impact just yet. So this at least puts it on the radar, and it gives you sometime to read the pronouncement and digest the impact of it, like we said it really does just allow companies now to capitalize some of those implementations costs in a cloud scenario that previously had to be expensed.

So I think just ASU is more closely aligning the governing guidance with the business world that we're living in. Okay, so we've come up, we've covered some of the rules, around the capitalization amortization, we wanted to spend just a few minutes with you speaking about some of the other record keeping and financial reporting considerations around software development cost.

So Fred we talked a bit about how companies, or the need for companies to track internal payroll costs. How do you think companies do this? Capture the data necessarily to apply the rule?
Fred Kosnac: Sure well I've seen a couple of different ways. I've seen companies that have implemented software or purchased software that specifically tracks projects, I can't remember the name of one right at the moment. They'll have it where it's, they have it kind of split up by project by days and by employees, just to ensure that the development cost are tracked properly.

There are some other companies where maybe that's really not a feasible option, they don't see it to be very cost effective. I've also seen companies track, in an excel spreadsheet and the key there is just to make sure that it's detailed enough that you can still kind of see that breakout of the different projects instead of just doing you know like a lump sum saying okay 80% of all of my employees work on development at some point. You want to have some more detail in there and then to supplement that usually is a good idea to have some sort of accounting write-up to kind of prove your position on that.
Jaime Gilmore: I think you know prior to training at EisnerAmper I started my career in industry for a software company. We did, has a luxury and I'll call it a luxury of implementing a time and attendance system with pre-loaded tasks that the developers would code their time to. This is setting up that system is if we refer back that cross functional effort for finance to understand what the steps are in the development process and then creating a tool that can be used thereafter to help with the accounting.
Richard Cleaveland: I think it's a great idea. Just as we mentioned just making sure that you can track those costs effectively because it's important. I think also a roadmap and having a good clear roadmap of the functionality that's being developed around the different modules and so that way you can document kind of how that functionality is changing and whether it's internal use or whether it's to be sold or marketed is important as well.
Jaime Gilmore: I think the challenge really comes in with the internal personnel. Because when you're outsourcing a portion or all of the development functions then you can clearly identify in your documentation, which vendors are providing, some are providing perhaps planning services, while others are providing that development activity, that core development activity.

So that's a little bit easier to contend with, it's really finding the right tool to capture your internal personnel hours.
Richard Cleaveland: Absolutely.
Fred Kosnac: Also, for all companies but in particular those that are public and subject to having internal controls over these process to ensure that the costs are being captured completely accurately and their valid cost is extremely important.
Jaime Gilmore: That's true, it's having a well designed internal controlled environment really goes a long way to just reporting and accuracy. So putting in the effort upfront really sets a stage to make the accounting you know down the road.
Fred Kosnac: In talking about the financial statements we talked a little bit about where in the P&L the expense, the amortization should be reflected. But we really have some changes to kind of where those costs end up in the financial statements in general isn't that right?
Jaime Gilmore: That's right. So if you think about some of the costs we discussed that are eligible to be capitalized, primarily it's personnel costs the development chain. So in normal order payroll costs generally reside in your P&L as an operating expense. What the rules here do is they're moving some of those costs to your balance sheet and reporting them as an asset. This has implications to EBIDA calculations, right Rich?
Richard Cleaveland: That's correct, it's going to change that calculation and often we see increased scrutiny around those numbers just given the fact that it's you know changed the classifications. Again record keeping, having a good basis for why you're capitalizing is critical.
Jaime Gilmore: Okay so I think that concludes our presentation for today. We can just take a few questions now in our last couple of minutes. Just for references I know I said it earlier but I'll advance the slide here. So this next slide in everyone's deck you have the references to the applicable sections of the constitution should you need to go back and take a read through to help you work through your analysis. So give us a moment just as we take a look at some of the questions that have come in.
Fred Kosnac: So one of the questions that I see here is just a follow up as related to tracking the time you know for projects in a detailed spreadsheet. I was looking to see what kind of detail would be considered sufficient and how someone would verify this information. I think a lot of that goes back to again just kind of stressing the importance of having those conversations with your development team and your project manager to make sure that you're hitting whatever milestones you're hitting.

If it's external that you're hitting technological feasibility. If it's internal making sure seeing where the application development stages of and making sure that you have all that documented, because at the end of the day there could be some judgment that's involved here as far as you know if you're looking at something we were applying a percentage of an employees time you know you want to make sure that that estimate is reasonable and that's usually something that the accounting team used to do in conjunction with the development team.
Jaime Gilmore: I think you know speaking from past experience as well, well alternatively to having that time and attendance system, if we could have also just had conversations with the lead developer and understand what role each member of his department played in the development process.

While others were our core developer and spent 100% of their time. So getting an understanding of what role each member of the software development played will help in categorizing the time whether you're tracking it in that time and attendance system or simply in a spreadsheet.
Richard Cleaveland: We have another question here relating back to implementation fees and whether or not the customer can capitalize those and amortize them over a subscription period when it's a fast model. That relates back again to the new ASU 2018-15. So to all of those implementations fees you'd have to take a look at and you'd have to evaluate whether or not they qualify for capitalization under the internal-use rules.

So if you've got planning fees in there where you're designing what type of features are going to be implemented maybe those fall within that planning phase. If there's training cost also to train the employees to use that that package those would be post implementation and expense.

But any of the true development work that's being done to implement it that would qualify for capitalization. So the current treatment would be to expense all those costs and then this ASU would allow you to be able to capitalize some of those development costs moving forward. I think we've gotten an awful lot of questions in here-
Jaime Gilmore: We do.
Richard Cleaveland: ... During the session which is good. You know we don't have enough time to address all of these with two minutes left here. So I think what we'll do is we'll take a lot of these questions offline and see if we can contact the people submitting those questions directly and see if we can help answer some of their questions.
Jaime Gilmore: Okay. Well thank you all for joining us today to revisit a topic that's very pertinent in today's day and age with respect to the capitalization rules for software developments costs, okay.
Moderator: We hope you enjoyed today's webinar, please look out for a follow up email with a link to the survey and presentation. If you have additional questions about today's topics that you would like addressed, please feel free email our speakers directly. For those who meet the criteria you will receive a CPE certificate from eisneramperu@eisneramper.com within 14 business days of confirmed course attendance. Thank you for joining our webinar today.

^{Transcribed by Rev.com}