In general, the software industry is viewed as having several sectors, including packaged applications (shrink-wrapped software); operating systems for individual and networked computers; administration tools for networks; enterprise software for large-scale data handling; and customized software to meet specific company and industry requirements. The software industry is unique, and its special characteristics should be understood by the accountant practicing in this field. Only with a clear understanding of the industry can the accountant properly apply the software industry’s specialized accounting practices.
Through this post I discuss about capitalization and amortization of software cost.
Broad Applicability of FASB Statement No. 86
Financial Accounting Standards Board (FASB) Statement No. 86, Accounting for the Costs of Computer Software to Be Sold, Leased, or Otherwise Marketed, applies to the costs of both internally developed and produced software and purchased software to be sold, leased, or otherwise marketed. Section 6.5 discusses AICPA Statement of Position 98-1, Accounting for the Costs of Computer Software Developed or Obtained for Internal Use, which is applicable if the software is developed or obtained only for internal purposes.
Software Products
Statement No. 86’s accounting applies to costs of computer software products to be sold, leased, or otherwise marketed. The software products may be marketed separately or as firmware (as part of a product or process), even if the software is contained in a product having a software component that cannot function or be marketed separately from the overall product. Examples are software included in calculators and products of robotic technologies.
It is sometimes difficult to determine whether Statement No. 86 applies in some situations in which software is used to derive revenue. In particular, it can be difficult to determine whether the applicable document is Statement No. 86 or SOP 91-1. The appendix to SOP 98-1 contains numerous informative illustrations in which software would and would not be considered internal-use software. The “would nots” would be software covered by Statement No. 86. A reasonable benchmark is that software covered by Statement No. 86 is software for which customers acquire or receive the right to use. This can occur either by the customer acquiring the software directly or acquiring the product that contains the software (e.g., computer game cartridge).
Software products covered by Statement No. 86 include enhancements to covered products. Enhancements are defined as:
A software product is most easily defined by describing its necessary qualities. As a product, it is complete and has exchange value. As software, it is a set of programs that interact with each other. A program is further defined as a series of instructions or statements that cause a computer to do work.
As the capacity of semiconductor devices expands, it is becoming more common to see software being developed solely to be embedded in a semiconductor device or in hardware as firmware. If software is to be marketed only as firmware or as part of a broader product, all research and development activities related to the broader product must be completed prior to capitalizing any of the related firmware development costs. Paragraph 5 of Statement No. 86 states:
The FASB staff’s view was that the cost of purchased computer software with no alternative future use should be expensed if technological feasibility of the broader product to be marketed has not yet been established. Accordingly, those wishing to capitalize the cost of internally developed or purchased software to be included in a broader product should, to the extent possible, delay internal software development work or the purchase of software until after technological feasibility of the broader product has been established.
Computer Software Research and Development Costs
Costs incurred prior to establishing technological feasibility of a software product are research and development costs and should be charged to expense in accordance with FASB Statement No. 2, Accounting for Research and Development Costs. These costs include costs of planning, designing, coding, and testing that is necessary to establish that the product can be produced to meet its design specifications, including functions, features, and technical performance requirements.
The FASB used the following definition of development in defining activities that should be considered software research and development.
The next paragraph of Statement No. 2 notes:
Determination of Technological Feasibility in General
The criteria for determination of technological feasibility and commencement of capitalization of software development costs may vary, depending on whether the development process includes or does not include the preparation of a detail program design. The basis for determination of technological feasibility in either case is discussed in the following sections:
The determination of technological feasibility must be made for an entire software product. If a product includes more than one module and the modules are not marketable separately, the determination of technological feasibility must be made for the entire product, including all the modules, and not on a module-by-module basis. If the criteria for capitalization are met, including technological feasibility and net realizable value, software development costs must be capitalized. A company may not elect to use an accounting policy in which it applies more stringent criteria than those set forth in Statement No. 86. For example, a software company may not elect to use the working model criteria for commencement of capitalization if it meets the detail program design criteria. However, it should be noted that in practice, many software companies do not capitalize costs after technological feasibility because such costs are determined to be immaterial.
Determination of Technological Feasibility If a Detail Program Design Is Used
If the software development process includes the preparation of a detail program design, technological feasibility is determined and capitalization of software development costs begins when the criteria specified in paragraph 4 of Statement No. 86 are met:
A product design is defined in Statement No. 86 as follows:
Statement No. 86 defines a detail program design as follows:
The precise form of the documentation can vary widely from company to company, partly depending on the development process, the individuals involved, the maturity of the company’s technology, and other factors. If new products are involved, it is generally expected that there will be more documentation than, for example, for enhancements to establish products. An important step in meeting these criteria is ensuring that the information in the product design and the detail program design are consistent and that the technical features and functions described in the detail program design will meet the product specification in the product design.
Technological Feasibility If a Detail Program Design Is Not Prepared
If the development process does not include preparation of a detail program design meeting the previously described criteria, then capitalization of software development costs should begin when the criteria specified in paragraph 4 of Statement No. 86 are met.
A working model is described in Statement No. 86 as follows:
The term working model has sometimes been used to refer to a prototype with the important portions of a product written in pseudocode. Because Statement No. 86 requires that a working model be written in the same computer language as the product to be marketed, such prototypes are not working models for purposes of applying Statement No. 86.
The working model should be compared with the product design for consistency and completeness before capitalization commences. If the working model is the basis for technological feasibility, the amount capitalized will generally be significantly less than under the detail program design approach. Most significantly, under the working model approach, much of the coding activities in creating the software product will be charged to research and development.
Projects That Do Not Precisely Employ Either a Detail Program Design or a Working Model Approach
Sometimes software companies do not use a software development process that clearly follows a detail program design approach or a working model approach. For example: a software company may not prepare a detail program design prior to starting work on constructing a working model, but a detail program design may emerge as a byproduct of the working model development. In such cases, the criteria of a detail program design are met, and capitalization should commence when the detail program design has been completed, rather than waiting to start capitalization until the working model is completed.
Once technological feasibility is established and capitalization commenced, there may be refinements to the detail program design that evolve during the development process—for example, as better ideas are discovered and minor development issues arise and are resolved.
Costs of refining the detail program design and related activities not specifically contemplated in the original detail program design should be capitalized. If, however, there are substantial changes to the original detail program design that indicate that the original logic or concept of the technical features of the product was not feasible, consideration should be given to whether technological feasibility had, in fact, existed. If it is ascertained that technological feasibility was not yet established, capitalized costs should be charged to research and development.
Additionally, subsequent costs incurred up to the point that the detail program design was consistent with the technical features that will be used in developing the final product also would be charged to research and development expense.
Determination of Market Feasibility
The term market feasibility is not used in Statement No. 86. However, it is sometimes used in practice when considering whether a new software product or an enhancement of an existing product will be accepted in the marketplace so as to generate sufficient revenues to enable the capitalized software costs to pass the net realizable value test of Statement No. 86.
Statement No. 86 requires the use of a net realizable value test (discussed in more detail later in this post), as of each balance sheet date for all software products for which costs have been capitalized, including new products and enhancements of existing products for which sales have not yet occurred. The notion of market feasibility points out that in order to capitalize software development costs for a product or a product enhancement, in addition to determination of technological feasibility, the software company must also be able to demonstrate that the net realizable value test will be met for the costs of the product or enhancement that will be capitalized.
Aggregating the Direct Labor Component
Software development is a labor-intensive activity. Accordingly, most software companies base the accumulation of software development costs on hours incurred. Some companies have sophisticated project cost systems that are administered with timereporting procedures by which employees submit time sheets or time cards with hours charged to individual projects. Separate job codes may be set up for a project after the criteria for capitalization have been met. Sometimes one job code is used to accumulate all the hours on a project, and hours charged to the project after the criteria for capitalization are met are isolated for computation of amounts to be capitalized.
Personnel whose hours are normally capitalized usually include programmers, systems analysts, project managers, and, in some cases, administrative personnel involved in the software development process. Most hours incurred will be directly chargeable; however, there may be some supervisory and management time that is appropriate to include in capitalized amounts. In many software companies, executive personnel are technically oriented and actively involved in the development process.
In some cases it is appropriate to include a portion of their hours in software development cost accumulation on a direct charge basis, and sometimes as an overhead factor. For example: in a large software company, there may be an executive who is the company technical director, who is active in software development, managing the projects on a fulltime basis. In such a company, all other executive personnel may be performing general management or other management functions, but not be directly involved in the development process. In smaller companies, all executives, including the chief executive officer, may participate in software development activities.
Although costs have been accumulated for software capitalization in diverse ways, most often software development costs are developed using direct labor as the basis. The software company tabulates the number of hours a particular employee has incurred in working on a capitalizable project, then multiplies the hours by the employee’s compensation rate. Software developers frequently work more than the standard number of hours because of the time pressures involved in bringing a new product or enhancement to the marketplace.
Example:
Assume that a senior programmer is paid $62,400 per year, or $30 per hour based on a work year of 2,080 hours. The programmer is entitled to 120 hours of vacation and 80 hours of holiday time, so that in a standard work year the programmer would work a net of 1,880 hours.
Assume, further, that the programmer actually works 2,400 hours during the year instead of 1,880 hours. The result is that essentially there are 2,600 hour attributable to the programmer’s salary of $62,400—the 2,400 hours worked, the 120 hours of vacation time, and the 80 hours of holiday time. The author would base the amount to be capitalized on $24 per hour ($62,400 divided by 2,600). An extreme illustration shows why this is necessary.
Assume that all 2,400 hours of the programmer’s work time was spent on capitalized projects, and the company’s accountants by rote priced out the time at the programmer’s standard rate of $30 per hour. The company would have capitalized a total of $72,000 (2,400 multiplied by $30), when it paid only $62,400. The error would be further compounded by inclusion of a vacation and holiday factor in the fringe rate included in an overhead factor. Obviously, there must be appropriate systems to capture the information and to monitor activities to determine if or when standard rates need to be adjusted.
Overhead Rates
Overhead rates should be computed using the general approach used in inventory costing or for computing the overhead cost of self-constructed assets.
I have found it effective to develop an overhead rate to apply to capitalized direct labor, which includes the following three factors:
Fringe costs include :
Using the example of the senior programmer discussed in the preceding section, and assuming standard hours (1,880 hours) worked.
Other Direct Costs
The preceding two sections discussed accumulation of direct costs based on labor hours and computation of an overhead rate. In addition, capitalized costs should include other direct costs that are generally not appropriate for inclusion in an overhead rate.
Examples are costs of outside consultants, purchased software to be included in the software product being developed, travel expenses, materials and supplies, and other direct costs. As shown above, costs of computer usage in development activities should be capitalized as part of overhead. Sometimes these costs can be determined by multiplying the number of hours of computer usage by the average hourly cost of operating the company’s computer facility.
Computer hardware depreciation should be included in capitalized costs to the extent that the computers were used in development activities. This depreciation is often included in the hourly cost of computer usage of the company’s computer facility. There may also be computers outside a central computer facility that are used, sometimes exclusively, in the development process, for which appropriate amounts of depreciation and other costs should be included in capitalized amounts. The specific procedures for accumulating these costs should be based on the company’s internal operations and accounting systems.
Outside consultants may be engaged to perform software development activities at a software company’s site. In such cases, it is appropriate to add to the consultant’s fee an overhead factor for the consultant’s use of the company’s facilities. If this is done, however, in computing the company’s facilities overhead rate, a factor for the use of facilities by outside consultants should be reflected in the determination of the facilities overhead rate to be used for employees. This can be accomplished by adding a factor for fees paid to consultants using the facilities to the net salaries in the denominator of the computation of the facilities overhead rate. The amount added should generally not be the entire amount of the consulting fees, because such fees are usually higher than net salaries paid to employees on an hourly basis. If outside consultants are engaged to work on software development projects, depending on the circumstances, it may be appropriate to include a management and supervision overhead factor if company executives supervised and participated in the consultant’s work.
As for all costs, capitalization of other direct costs should not occur until technological feasibility of the product has been determined. For example: purchased software to be included as part of a product under development (which, therefore, has no alternative future use) which is acquired before technological feasibility of the entire product is determined, should be charged to research and development expense.
Product Enhancements
Product enhancements are defined in Statement No. 86 as follows:
Bug fixes are included in maintenance costs under Statement No. 86, and should be accounted for as period costs and not capitalizable enhancements. This distinction is sometimes confused in practice. How to account for product enhancements was one of the first significant issues on implementation of Statement No. 86.
In Emerging Issues Task Force (EITF) Issue 85-35, Transition and Implementation Issues for FASB Statement No. 86, the EITF considered the question of how Statement No. 86 should be applied to product enhancements.
In the Issue, the EITF was not asked to reach a consensus but the FASB staff provided information on how to apply Statement No. 86 to product enhancements. The FASB staff indicated that if an original product is no longer to be marketed, the net book value of the original product should be allocated to the cost of the enhancement (perhaps more appropriately called the enhanced product). The costs of the enhanced product, including costs “allocated up” from the original product are amortized over the life of the enhancement, and all costs are included in net realizable value testing of the enhancement.
If the software company develops an enhanced product and continues to market the original product, then a portion of the net book value of the original product should be “allocated up” to the enhancement, based on a systematic and rational allocation method. It has been suggested that lines of code could be used in some way to develop a calculation of the allocation. Relative projected revenues could also be used.
Various other bases have been used in practice. In certain circumstances, it may be appropriate to allocate to an enhanced product the value of a third-party development license. For example: this may be appropriate if the original product is the basis of the proprietary technology and will continue to have greater integrity and longevity than the enhancement, and if the technology in the original product may be transferred into other enhancements in the future.
Some software companies continually enhance their products to extend their life and to maintain their marketability in light of competition in the marketplace. In such cases it is impractical to “allocate up” the net book value of the product into the costs of the enhanced product and start a new amortization life every time an enhancement is completed. In these circumstances, the author recommends an “allocation down” approach, in which the cost of enhancements is added to the cost of the original product. This approach should not be used, however, if the enhancement is major and results in the release of a product that is marketed as a new product.
Amortization Capitalized Of Software Cost
Statement No. 86 requires amortization of capitalized software costs for both internally developed and purchased software. Amortization should commence when capitalization ceases upon the availability of the product for general market release. Amortization should begin when a product is available for general market release, even if the software company decides to delay market release because of its competitive situation or other factors.
Amortization must be computed on a product-by-product basis using the greater of straight-line amortization or revenue-based amortization. Because amortization is computed on a product-by-product basis, within a particular period some products may be amortized by using straight-line amortization and others by revenue-based amortization. Straight-line amortization may be used for a particular product in one period, and revenue-based amortization in another, depending on the level of revenue realized in each period.
Straight-Line Amortization Method
Straight-line amortization should be computed by dividing the net book value of a product at the beginning of a period by the product’s remaining useful life at the beginning of the period. Statement No. 86 does not provide any guidance on lives to be used for straight-line amortization. Based on industry practice and SEC views, however, lives in the range of three to seven years are the norm. The SEC has, in fact, indicated that it may challenge lives longer than five years for personal computer-based software and longer than seven years for other software.
If the estimate of useful life of a software product changes from the life originally used in computing further amortization, the new estimated useful life should be used in computing future amortization (a change in estimate). However, the convention of using the most current estimate of useful life should not be employed to unduly extend the amortization period of a software product.
Revenue-Based Amortization
The computation of revenue-based amortization is based on the percentage of currentperiod gross revenues for the product to the total of current period and estimated future gross revenues for the product. Estimated future gross revenue streams should be based on management’s most realistic prediction of future revenues for the software product. Each year, actual revenues should be compared with revenues projected in the past, and present predictions should be compared with revenue levels and trends in the past few years to determine whether they are reasonable.
Statement No. 86 does not specify how many years into the future the revenue stream should be projected in computing revenue-based amortization. I believe that it is appropriate to use projected revenues only for the remaining useful life used for straight-line amortization, even if the software company believes the revenue stream will continue further. The projected gross revenue stream for revenue-based amortization should be consistent with the projected revenue stream used in the net realizable value test.
Because in practice many revenue projections for the net realizable value test and amortization take the shape of a bell curve, amortization is typically determined on a straight-line basis, rather than a revenue basis. Projected revenue curves tend to grow from the initial year leading to the straight-line minimum in initial periods, and straight-line and revenue-based amortization are generally similar in later periods.
Amortization of Enhanced Products
If a software company has developed an enhanced product, and the net book value of the original product has been fully “allocated up” to the enhancement, the estimated life of the enhancement is used to compute straight-line amortization of the net book value “allocated up”, as well as the capitalized cost of the enhancement.
If only a portion of the net book value of an original product was “allocated up”, straight-line amortization of the portion of the net book value left with the original product continues to be based on the estimated life of the original product. Straightline amortization of the portion of the original product’s net book value that was “allocated up” to the enhancement and the capitalized cost of the enhancement is computed based on the life of the enhancement.
If a company’s software products are continually enhanced, and the company follows the convention of adding the cost of the enhancement to the cost of the original products, the company may continue to use the life of the original product to compute straight-line amortization of both the net book value of the original product and the enhancements. If the enhancements continually extend the useful life of the product, and the costs of the enhancements are sufficiently significant that amortizating them over the life of the original product would distort amortization expense, the author recommends an alternative convention seen in practice. Using this convention, straightline amortization of the original product continues to be computed over the original product’s estimated useful life, and straight-line amortization of the enhancements is computed using the same life as that used for the original product, but starting with the year in which the enhancements were completed. In such situations, the software company might be justified in “allocating up” all net book value each year and starting the original estimated useful life over again each year. By using this “vintage account” approach, the software company does not have to go through the “allocation up” approach each year, and is, furthermore, probably amortizing its capitalized software somewhat more quickly than if it had selected the “allocation up” approach.
Clearly, though, the company must carefully reassess the useful life of the product each period to ensure that the amortization is not being unduly extended.
Reporting Amortization in Interim Periods
Some companies allocate amortization to interim periods in a practical way, by computing the estimated total amortization for the year and recognizing the total amount on a straight-line basis throughout the year. However, if revenue levels vary substantially from quarter to quarter and amortization amounts are significant, it may be necessary to allocate more precisely the annual estimated amortization to quarters, based on the amount of revenues for each quarter in relation to estimated annual revenues.
Through this post I discuss about capitalization and amortization of software cost.
This discussion assumes that the reader has some familiarity with computers, computer hardware, and computer software, and provides the information necessary to allow the accountant to actively participate in discussions affecting the accounting treatment of events occurring in the subject business.
Broad Applicability of FASB Statement No. 86
Financial Accounting Standards Board (FASB) Statement No. 86, Accounting for the Costs of Computer Software to Be Sold, Leased, or Otherwise Marketed, applies to the costs of both internally developed and produced software and purchased software to be sold, leased, or otherwise marketed. Section 6.5 discusses AICPA Statement of Position 98-1, Accounting for the Costs of Computer Software Developed or Obtained for Internal Use, which is applicable if the software is developed or obtained only for internal purposes.
Software Products
Statement No. 86’s accounting applies to costs of computer software products to be sold, leased, or otherwise marketed. The software products may be marketed separately or as firmware (as part of a product or process), even if the software is contained in a product having a software component that cannot function or be marketed separately from the overall product. Examples are software included in calculators and products of robotic technologies.
It is sometimes difficult to determine whether Statement No. 86 applies in some situations in which software is used to derive revenue. In particular, it can be difficult to determine whether the applicable document is Statement No. 86 or SOP 91-1. The appendix to SOP 98-1 contains numerous informative illustrations in which software would and would not be considered internal-use software. The “would nots” would be software covered by Statement No. 86. A reasonable benchmark is that software covered by Statement No. 86 is software for which customers acquire or receive the right to use. This can occur either by the customer acquiring the software directly or acquiring the product that contains the software (e.g., computer game cartridge).
Software products covered by Statement No. 86 include enhancements to covered products. Enhancements are defined as:
. . . . improvements to an existing product that are intended to extend the life or improve significantly the marketability of the original product. Enhancements normally require a product design and may require a redesign of all or part of the existing product [FASB Statement No. 86, paragraph 52].An issue of FASB Highlights of Financial Reporting Issues published in February 1986 contained unofficial FASB staff guidance on the application of FASB Statement No. 86 in a question-and-response format. In that publication, the response to question 1 provides the following additional descriptive notions about software products contemplated by Statement No. 86.
A software product is most easily defined by describing its necessary qualities. As a product, it is complete and has exchange value. As software, it is a set of programs that interact with each other. A program is further defined as a series of instructions or statements that cause a computer to do work.
As the capacity of semiconductor devices expands, it is becoming more common to see software being developed solely to be embedded in a semiconductor device or in hardware as firmware. If software is to be marketed only as firmware or as part of a broader product, all research and development activities related to the broader product must be completed prior to capitalizing any of the related firmware development costs. Paragraph 5 of Statement No. 86 states:
Software production costs for computer software that is to be used as an integral part of a product or process shall not be capitalized until both ; (a) technological feasibility has been established for the software; and (b) all research and development activities for the other components of the product or process have been completed.Thus, in certain situations, software development costs incurred after technological feasibility of the software has been achieved will, nevertheless, still have to be expensed as incurred. This would occur if the R&D activities have not yet been completed on the other components of the product (e.g., hardware configuration). This accounting can also result if a software product is purchased for inclusion in a broader product. Question 13 in the February 1986 FASB Highlights of Financial Reporting Issues, which included the views of the FASB staff on an array of Statement No. 86 implementation questions, asked: “What factors, if any, may determine whether the cost of purchased software that will be integrated into another software or hardware product will be capitalized?”
The FASB staff’s view was that the cost of purchased computer software with no alternative future use should be expensed if technological feasibility of the broader product to be marketed has not yet been established. Accordingly, those wishing to capitalize the cost of internally developed or purchased software to be included in a broader product should, to the extent possible, delay internal software development work or the purchase of software until after technological feasibility of the broader product has been established.
Computer Software Research and Development Costs
Costs incurred prior to establishing technological feasibility of a software product are research and development costs and should be charged to expense in accordance with FASB Statement No. 2, Accounting for Research and Development Costs. These costs include costs of planning, designing, coding, and testing that is necessary to establish that the product can be produced to meet its design specifications, including functions, features, and technical performance requirements.
The FASB used the following definition of development in defining activities that should be considered software research and development.
The translation of research findings or other knowledge into a plan or design for a new product or process or for a significant improvement to an existing product or process whether intended for sale or use. It includes the conceptual formulation, design, and testing of product alternatives, construction of prototypes, and operation of pilot plants. It does not include routine or periodic alterations to existing products, production lines, manufacturing processes, and other ongoing operations even though those alterations may represent improvements, and it does not include market research or market testing activities [FASB Statement No. 2, paragraph 8].
The next paragraph of Statement No. 2 notes:
…….additional activities that should be charged to expense as software research and development activities. Engineering activity required to advance the design of a product to the point that it meets specific functional and economic requirements and is ready for manufacture [FASB Statement No. 2, paragraph 9].Even though all other criteria for capitalization have been met, if a high-risk development issue remains, all costs incurred with regard to a software product should be charged to research and development expense. If subsequent to the establishment of technological feasibility a high-risk development issue is discovered, any development costs that were capitalized for that product, and future costs incurred until the highrisk development issue is resolved, should be charged to research and development expense. After the high-risk development issue is resolved, and provided all other conditions for capitalization are met, capitalization should resume; previously written off capitalized costs, however, remain expensed as research and development costs.
Determination of Technological Feasibility in General
The criteria for determination of technological feasibility and commencement of capitalization of software development costs may vary, depending on whether the development process includes or does not include the preparation of a detail program design. The basis for determination of technological feasibility in either case is discussed in the following sections:
The determination of technological feasibility must be made for an entire software product. If a product includes more than one module and the modules are not marketable separately, the determination of technological feasibility must be made for the entire product, including all the modules, and not on a module-by-module basis. If the criteria for capitalization are met, including technological feasibility and net realizable value, software development costs must be capitalized. A company may not elect to use an accounting policy in which it applies more stringent criteria than those set forth in Statement No. 86. For example, a software company may not elect to use the working model criteria for commencement of capitalization if it meets the detail program design criteria. However, it should be noted that in practice, many software companies do not capitalize costs after technological feasibility because such costs are determined to be immaterial.
Determination of Technological Feasibility If a Detail Program Design Is Used
If the software development process includes the preparation of a detail program design, technological feasibility is determined and capitalization of software development costs begins when the criteria specified in paragraph 4 of Statement No. 86 are met:
A product design is defined in Statement No. 86 as follows:
- A logical representation of product functions in sufficient detail to serve as product specifications [FASB Statement No. 86, paragraph 52]
- A product design should include a description and objectives of the product, an explanation of how data will be input into the product (such as by on-line input or by batch processing), a description of the data and reports to be generated by the product, the major processing and data transformation definitions, data storage and data structure requirements, and a general description of the data flow and interaction of modules and transforming processes.
Statement No. 86 defines a detail program design as follows:
The detail design of a computer software product that takes product function, feature, and technical requirements to their most detailed, logical form and is ready for coding [FASB Statement No. 86, paragraph 52].A detail program design should describe the product function, features, and technical requirements in a detailed, logical way, ready for coding activities. The detail program design should normally include a description of the logic, file layouts, report definitions, field definitions, algorithms, special routines, and specific arrays of data. Ordinarily the combined documentation package of the product design and detail program design should be in the form of outlines, narratives, flow-charts, or a combination.
The precise form of the documentation can vary widely from company to company, partly depending on the development process, the individuals involved, the maturity of the company’s technology, and other factors. If new products are involved, it is generally expected that there will be more documentation than, for example, for enhancements to establish products. An important step in meeting these criteria is ensuring that the information in the product design and the detail program design are consistent and that the technical features and functions described in the detail program design will meet the product specification in the product design.
Technological Feasibility If a Detail Program Design Is Not Prepared
If the development process does not include preparation of a detail program design meeting the previously described criteria, then capitalization of software development costs should begin when the criteria specified in paragraph 4 of Statement No. 86 are met.
A working model is described in Statement No. 86 as follows:
An operative version of the computer software product that is completed in the same software language as the product to be ultimately marketed, performs all the major functions planned for the product, and is ready for initial customer testing (usually identified as beta testing) [FASB Statement No. 86, paragraph 52].
The term working model has sometimes been used to refer to a prototype with the important portions of a product written in pseudocode. Because Statement No. 86 requires that a working model be written in the same computer language as the product to be marketed, such prototypes are not working models for purposes of applying Statement No. 86.
The working model should be compared with the product design for consistency and completeness before capitalization commences. If the working model is the basis for technological feasibility, the amount capitalized will generally be significantly less than under the detail program design approach. Most significantly, under the working model approach, much of the coding activities in creating the software product will be charged to research and development.
Projects That Do Not Precisely Employ Either a Detail Program Design or a Working Model Approach
Sometimes software companies do not use a software development process that clearly follows a detail program design approach or a working model approach. For example: a software company may not prepare a detail program design prior to starting work on constructing a working model, but a detail program design may emerge as a byproduct of the working model development. In such cases, the criteria of a detail program design are met, and capitalization should commence when the detail program design has been completed, rather than waiting to start capitalization until the working model is completed.
Once technological feasibility is established and capitalization commenced, there may be refinements to the detail program design that evolve during the development process—for example, as better ideas are discovered and minor development issues arise and are resolved.
Costs of refining the detail program design and related activities not specifically contemplated in the original detail program design should be capitalized. If, however, there are substantial changes to the original detail program design that indicate that the original logic or concept of the technical features of the product was not feasible, consideration should be given to whether technological feasibility had, in fact, existed. If it is ascertained that technological feasibility was not yet established, capitalized costs should be charged to research and development.
Additionally, subsequent costs incurred up to the point that the detail program design was consistent with the technical features that will be used in developing the final product also would be charged to research and development expense.
Determination of Market Feasibility
The term market feasibility is not used in Statement No. 86. However, it is sometimes used in practice when considering whether a new software product or an enhancement of an existing product will be accepted in the marketplace so as to generate sufficient revenues to enable the capitalized software costs to pass the net realizable value test of Statement No. 86.
Statement No. 86 requires the use of a net realizable value test (discussed in more detail later in this post), as of each balance sheet date for all software products for which costs have been capitalized, including new products and enhancements of existing products for which sales have not yet occurred. The notion of market feasibility points out that in order to capitalize software development costs for a product or a product enhancement, in addition to determination of technological feasibility, the software company must also be able to demonstrate that the net realizable value test will be met for the costs of the product or enhancement that will be capitalized.
Aggregating the Direct Labor Component
Software development is a labor-intensive activity. Accordingly, most software companies base the accumulation of software development costs on hours incurred. Some companies have sophisticated project cost systems that are administered with timereporting procedures by which employees submit time sheets or time cards with hours charged to individual projects. Separate job codes may be set up for a project after the criteria for capitalization have been met. Sometimes one job code is used to accumulate all the hours on a project, and hours charged to the project after the criteria for capitalization are met are isolated for computation of amounts to be capitalized.
Personnel whose hours are normally capitalized usually include programmers, systems analysts, project managers, and, in some cases, administrative personnel involved in the software development process. Most hours incurred will be directly chargeable; however, there may be some supervisory and management time that is appropriate to include in capitalized amounts. In many software companies, executive personnel are technically oriented and actively involved in the development process.
In some cases it is appropriate to include a portion of their hours in software development cost accumulation on a direct charge basis, and sometimes as an overhead factor. For example: in a large software company, there may be an executive who is the company technical director, who is active in software development, managing the projects on a fulltime basis. In such a company, all other executive personnel may be performing general management or other management functions, but not be directly involved in the development process. In smaller companies, all executives, including the chief executive officer, may participate in software development activities.
Although costs have been accumulated for software capitalization in diverse ways, most often software development costs are developed using direct labor as the basis. The software company tabulates the number of hours a particular employee has incurred in working on a capitalizable project, then multiplies the hours by the employee’s compensation rate. Software developers frequently work more than the standard number of hours because of the time pressures involved in bringing a new product or enhancement to the marketplace.
I believe that if the number of hours worked by the software developer significantly exceeds the standard number of work hours, the hourly rate should be adjusted to the actual rate paid.
Example:
Assume that a senior programmer is paid $62,400 per year, or $30 per hour based on a work year of 2,080 hours. The programmer is entitled to 120 hours of vacation and 80 hours of holiday time, so that in a standard work year the programmer would work a net of 1,880 hours.
I recommend that the rate of $30 per hour be used in valuing the hours incurred in capitalization projects. Appropriate recognition of the cost of the vacation and holiday time can be built into the fringe rate included in the overhead factor.
Assume, further, that the programmer actually works 2,400 hours during the year instead of 1,880 hours. The result is that essentially there are 2,600 hour attributable to the programmer’s salary of $62,400—the 2,400 hours worked, the 120 hours of vacation time, and the 80 hours of holiday time. The author would base the amount to be capitalized on $24 per hour ($62,400 divided by 2,600). An extreme illustration shows why this is necessary.
Assume that all 2,400 hours of the programmer’s work time was spent on capitalized projects, and the company’s accountants by rote priced out the time at the programmer’s standard rate of $30 per hour. The company would have capitalized a total of $72,000 (2,400 multiplied by $30), when it paid only $62,400. The error would be further compounded by inclusion of a vacation and holiday factor in the fringe rate included in an overhead factor. Obviously, there must be appropriate systems to capture the information and to monitor activities to determine if or when standard rates need to be adjusted.
Overhead Rates
Overhead rates should be computed using the general approach used in inventory costing or for computing the overhead cost of self-constructed assets.
I have found it effective to develop an overhead rate to apply to capitalized direct labor, which includes the following three factors:
- Fringe costs
- Facilities costs (including computer usage)
- Management and supervision costs
Fringe costs include :
- Costs for vacation, holiday time and other compensated absences (see FASB Statement No. 43, Accounting for Compensated Absences, for a discussion of these costs),
- employer payroll taxes, medical insurance, pension and other retirement contributions, and other fringe benefits.
Using the example of the senior programmer discussed in the preceding section, and assuming standard hours (1,880 hours) worked.
Other Direct Costs
The preceding two sections discussed accumulation of direct costs based on labor hours and computation of an overhead rate. In addition, capitalized costs should include other direct costs that are generally not appropriate for inclusion in an overhead rate.
Examples are costs of outside consultants, purchased software to be included in the software product being developed, travel expenses, materials and supplies, and other direct costs. As shown above, costs of computer usage in development activities should be capitalized as part of overhead. Sometimes these costs can be determined by multiplying the number of hours of computer usage by the average hourly cost of operating the company’s computer facility.
Computer hardware depreciation should be included in capitalized costs to the extent that the computers were used in development activities. This depreciation is often included in the hourly cost of computer usage of the company’s computer facility. There may also be computers outside a central computer facility that are used, sometimes exclusively, in the development process, for which appropriate amounts of depreciation and other costs should be included in capitalized amounts. The specific procedures for accumulating these costs should be based on the company’s internal operations and accounting systems.
Outside consultants may be engaged to perform software development activities at a software company’s site. In such cases, it is appropriate to add to the consultant’s fee an overhead factor for the consultant’s use of the company’s facilities. If this is done, however, in computing the company’s facilities overhead rate, a factor for the use of facilities by outside consultants should be reflected in the determination of the facilities overhead rate to be used for employees. This can be accomplished by adding a factor for fees paid to consultants using the facilities to the net salaries in the denominator of the computation of the facilities overhead rate. The amount added should generally not be the entire amount of the consulting fees, because such fees are usually higher than net salaries paid to employees on an hourly basis. If outside consultants are engaged to work on software development projects, depending on the circumstances, it may be appropriate to include a management and supervision overhead factor if company executives supervised and participated in the consultant’s work.
As for all costs, capitalization of other direct costs should not occur until technological feasibility of the product has been determined. For example: purchased software to be included as part of a product under development (which, therefore, has no alternative future use) which is acquired before technological feasibility of the entire product is determined, should be charged to research and development expense.
Product Enhancements
Product enhancements are defined in Statement No. 86 as follows:
Improvements to an existing product that are intended to extend the life or improve significantly the marketability of the original product. Enhancements normally require a product design and may require a redesign of all or part of the existing product [FASB Statement No. 86, Paragraph 52].
Bug fixes are included in maintenance costs under Statement No. 86, and should be accounted for as period costs and not capitalizable enhancements. This distinction is sometimes confused in practice. How to account for product enhancements was one of the first significant issues on implementation of Statement No. 86.
In Emerging Issues Task Force (EITF) Issue 85-35, Transition and Implementation Issues for FASB Statement No. 86, the EITF considered the question of how Statement No. 86 should be applied to product enhancements.
In the Issue, the EITF was not asked to reach a consensus but the FASB staff provided information on how to apply Statement No. 86 to product enhancements. The FASB staff indicated that if an original product is no longer to be marketed, the net book value of the original product should be allocated to the cost of the enhancement (perhaps more appropriately called the enhanced product). The costs of the enhanced product, including costs “allocated up” from the original product are amortized over the life of the enhancement, and all costs are included in net realizable value testing of the enhancement.
If the software company develops an enhanced product and continues to market the original product, then a portion of the net book value of the original product should be “allocated up” to the enhancement, based on a systematic and rational allocation method. It has been suggested that lines of code could be used in some way to develop a calculation of the allocation. Relative projected revenues could also be used.
Various other bases have been used in practice. In certain circumstances, it may be appropriate to allocate to an enhanced product the value of a third-party development license. For example: this may be appropriate if the original product is the basis of the proprietary technology and will continue to have greater integrity and longevity than the enhancement, and if the technology in the original product may be transferred into other enhancements in the future.
Some software companies continually enhance their products to extend their life and to maintain their marketability in light of competition in the marketplace. In such cases it is impractical to “allocate up” the net book value of the product into the costs of the enhanced product and start a new amortization life every time an enhancement is completed. In these circumstances, the author recommends an “allocation down” approach, in which the cost of enhancements is added to the cost of the original product. This approach should not be used, however, if the enhancement is major and results in the release of a product that is marketed as a new product.
Amortization Capitalized Of Software Cost
Statement No. 86 requires amortization of capitalized software costs for both internally developed and purchased software. Amortization should commence when capitalization ceases upon the availability of the product for general market release. Amortization should begin when a product is available for general market release, even if the software company decides to delay market release because of its competitive situation or other factors.
Amortization must be computed on a product-by-product basis using the greater of straight-line amortization or revenue-based amortization. Because amortization is computed on a product-by-product basis, within a particular period some products may be amortized by using straight-line amortization and others by revenue-based amortization. Straight-line amortization may be used for a particular product in one period, and revenue-based amortization in another, depending on the level of revenue realized in each period.
Straight-Line Amortization Method
Straight-line amortization should be computed by dividing the net book value of a product at the beginning of a period by the product’s remaining useful life at the beginning of the period. Statement No. 86 does not provide any guidance on lives to be used for straight-line amortization. Based on industry practice and SEC views, however, lives in the range of three to seven years are the norm. The SEC has, in fact, indicated that it may challenge lives longer than five years for personal computer-based software and longer than seven years for other software.
If the estimate of useful life of a software product changes from the life originally used in computing further amortization, the new estimated useful life should be used in computing future amortization (a change in estimate). However, the convention of using the most current estimate of useful life should not be employed to unduly extend the amortization period of a software product.
Revenue-Based Amortization
The computation of revenue-based amortization is based on the percentage of currentperiod gross revenues for the product to the total of current period and estimated future gross revenues for the product. Estimated future gross revenue streams should be based on management’s most realistic prediction of future revenues for the software product. Each year, actual revenues should be compared with revenues projected in the past, and present predictions should be compared with revenue levels and trends in the past few years to determine whether they are reasonable.
Statement No. 86 does not specify how many years into the future the revenue stream should be projected in computing revenue-based amortization. I believe that it is appropriate to use projected revenues only for the remaining useful life used for straight-line amortization, even if the software company believes the revenue stream will continue further. The projected gross revenue stream for revenue-based amortization should be consistent with the projected revenue stream used in the net realizable value test.
Because in practice many revenue projections for the net realizable value test and amortization take the shape of a bell curve, amortization is typically determined on a straight-line basis, rather than a revenue basis. Projected revenue curves tend to grow from the initial year leading to the straight-line minimum in initial periods, and straight-line and revenue-based amortization are generally similar in later periods.
Amortization of Enhanced Products
If a software company has developed an enhanced product, and the net book value of the original product has been fully “allocated up” to the enhancement, the estimated life of the enhancement is used to compute straight-line amortization of the net book value “allocated up”, as well as the capitalized cost of the enhancement.
If only a portion of the net book value of an original product was “allocated up”, straight-line amortization of the portion of the net book value left with the original product continues to be based on the estimated life of the original product. Straightline amortization of the portion of the original product’s net book value that was “allocated up” to the enhancement and the capitalized cost of the enhancement is computed based on the life of the enhancement.
If a company’s software products are continually enhanced, and the company follows the convention of adding the cost of the enhancement to the cost of the original products, the company may continue to use the life of the original product to compute straight-line amortization of both the net book value of the original product and the enhancements. If the enhancements continually extend the useful life of the product, and the costs of the enhancements are sufficiently significant that amortizating them over the life of the original product would distort amortization expense, the author recommends an alternative convention seen in practice. Using this convention, straightline amortization of the original product continues to be computed over the original product’s estimated useful life, and straight-line amortization of the enhancements is computed using the same life as that used for the original product, but starting with the year in which the enhancements were completed. In such situations, the software company might be justified in “allocating up” all net book value each year and starting the original estimated useful life over again each year. By using this “vintage account” approach, the software company does not have to go through the “allocation up” approach each year, and is, furthermore, probably amortizing its capitalized software somewhat more quickly than if it had selected the “allocation up” approach.
Clearly, though, the company must carefully reassess the useful life of the product each period to ensure that the amortization is not being unduly extended.
Reporting Amortization in Interim Periods
Some companies allocate amortization to interim periods in a practical way, by computing the estimated total amortization for the year and recognizing the total amount on a straight-line basis throughout the year. However, if revenue levels vary substantially from quarter to quarter and amortization amounts are significant, it may be necessary to allocate more precisely the annual estimated amortization to quarters, based on the amount of revenues for each quarter in relation to estimated annual revenues.
No comments:
Post a Comment