Connect with us


Capitalization And Amortization Of Software Cost



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.


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.



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.



  1. dee

    Nov 17, 2009 at 10:26 pm

    do we record the amortization as Cost of Sold or as operating expense along with depreciation of PP&E? thanks

  2. amortization formula

    Dec 27, 2009 at 6:52 am

    How to calculate the extra payment in the amortize calculation? I need to determine the cost after I pay for it. Any advise please help.

  3. Dd lhamo

    Jan 10, 2010 at 3:43 pm

    In my opinion, it is operating expense

  4. Dd lhamo

    Jan 10, 2010 at 3:49 pm

    Hi Putra – question for you – if we purchase license to use software (database) costing us 50,000 but paying it 4 i correct in recording this as a software as and when we pay each installment?
    say we got invoiced on 12/1 for 15000 and then the second one on 1/1 for another 15000.
    is it right to record it is as a software asset for 15000 on 12/1 and depreciate only 15000 for 2 years starting 12/1 or
    should i record the full 50,000 on 12/1 (say this is date we started using the database) and depreciate this full amount for two years starting 12/1?

    thanks for your advice

  5. Putra

    Jan 12, 2010 at 3:16 pm

    Dd Ihamo,

    It depends on the term of the contract. So if your contract is for a full 2 years usage, you should recognize the software license in full amount [50,000 in your case] and amortized over the contract’s life-time. But if the contract is for a partial license which is determined based on the installment, then you should recognize it in partial as well.

    However, having the fact that you’re invoiced partially, it is most likely a partial contract, means the contract could be terminated [or extended] after the first period is expired. Therefore it is correct that you recognize and amortized it partially.

  6. Dd lhamo

    Jan 14, 2010 at 9:09 pm

    Thanks Putra!

  7. terry glover

    Jan 19, 2010 at 11:38 pm

    Putra, are operating systems, middleware, and the people that install and run this, to be capitalized or is it an operating expense?

  8. Lucuerne

    Jan 21, 2010 at 5:20 pm

    Putra,question for you.Our fixed asset system crash last year just before our audit.As a result the incorrect amount of depreciation expense was given to the auditor.Should i booked the depreciation amount for last year to retained earnings

  9. Putra

    Jan 23, 2010 at 8:39 am


    In general, the easier way to decide whether to “Capitalize or Expense” any expenditure, is by asking at least the following 3 questions:

    – Is the expenditure considered as “material” or “immaterial”? If it is immaterial then do not waste your time by capitalization, just expense it. It is’n worth capitalizing.

    – Will the activities [that cause the expenditure to occur] make the main asset [i.e. computer in your case] have longer economic-lifetime? If the answer is “Yes” then capitalize it, otherwise don’t.

    – Is the propose of the activities [that cause the expenditure to occur] is just to keep the asset function properly?; OR to make it run faster/generate better/more output? If the first purpose is applicable then expense it, otherwise capitalize it.

    In my experience, this basic approach always compliance to any standards of any similar-circumatnaces.


    Yes, you should make a correction entry by crediting/debiting the “accum deprec” account against the “retained earning” account, depending on whether the depreciation was understated or overstated.

    Cheers everyone!

  10. John

    Jan 28, 2010 at 11:06 pm

    Putra – Question for you

    I have a company that developed an application software in 2006. They have sold and implemented the software several companies, beginning in 2006. They continue to add modules and make product enhancements. They release a new version each 6-9 months(currently on v8). They have expensed all software development costs in the past. My question is whether they could have capitalized these costs in the past and whether they should capitalize in the future. How would amortization work if product enhancements are capitalized for say version 9, but version 10 is released 6 months later?

    Do you have any good insight on dealing with a single product that is constantly creating new versions? Keep in mind this new versions extend the life of the product and make it more desirable in the market.


  11. YMikael

    Feb 3, 2010 at 2:12 pm

    I have exactly the same questions that John asked…

  12. George

    Feb 24, 2010 at 1:17 am

    Thanks for the excellent post Putra.

    Like many new software projects, our company develops using an “Iterative” approach. Our current project has up to 14 proposed iterations from the start of the project until it is ready for general release. Because of this approach, we did not create documentation that meets the descriptions of Detail Program Design or Product Design at the start of the project. Instead, we created an Architecture Design that describes how the software will be built in more general terms (I.E. where data will live, where logic code will live, how the system will interact with a user interface, how the software will integrate with other systems, etc.). This gave us enough design to know exactly how the system would function under the hood, but also gave us freedom to refine our idea of exactly which features and functions we want to support in the first release and adapt to the market as we get closer to launch. At the start of each iteration, we do create documents that match the ones described in Statement 86.

    Based on this, do you have any guidance on when we can declare R&D to be over and begin capitalization?

  13. Alice E.

    Apr 29, 2010 at 8:03 pm

    Amortization of FAS 86 costs are recorded as cost of sales

  14. Violet Weed

    May 14, 2010 at 3:28 pm

    Your website is very detailed and informative! I have bookmarked it for future reference. Thanks so much for maintaining it as I find it quite useful.

  15. Toni Bockhop

    Jun 16, 2010 at 1:00 pm


    For operating leases. Can you capitalize any of the internal effort associated with the install?

  16. Blair

    Aug 27, 2010 at 3:11 am

    can you capitalized purchased software like Microsoft Office?

  17. John

    Oct 27, 2010 at 11:06 pm

    Your definition of a detailed program design is “A detail program design should describe the product function, features, and technical requirements in a detailed, logical way, ready for coding activities.” Other FAS 86 research indicates that technilogical feasibiltiy is established when “all planning, designing, coding and testing activities have been completed.” Can you clarify? it seems your definition excludes the coding and testing where others indicate it should be completed before capitalization should start.

  18. Louise

    Jan 24, 2011 at 8:40 pm


    I have a situation where my client has purchased permission to use software for an indefinite period of time for $5,000. It is an online site for tracking shipments. How do I handle this?


  19. David

    Jan 27, 2011 at 9:09 pm

    Hi Putra,

    How about a scenario where you are contracting with a SAAS provider who charges 50k setup fee and 10k per month for a 2 year contract. What guidance is there for whether to immediately expense the 50k or spread it over the life of the 2 year contract.


  20. Michael Gentle

    Mar 10, 2011 at 10:38 am

    Hi George,

    Did you get an answer to your question – from Putra or elsewhere? I am also very interested in how to treat the financials in iterative or agile development projects.

    Michael Gentle

    • Royce Shewman

      Mar 14, 2012 at 10:21 am


      I have been researching practices of software development in an agile environment also and have not been successful locating relevant articles or information. Have you learned anything you would be able to pass on?

  21. janey

    May 10, 2011 at 6:44 pm


    My company developed a software product that we have amortized over several years. Unlike the others above, the software has now become obsolete. How do we go about amortizing the remaining cost?

  22. Steven

    May 15, 2011 at 1:26 am

    Microsoft spends $8 billion per year on R&D (as stated in income statement). They have $12 billion in goodwill on the balance sheet. I assume that when R&D is capitalized it becomes part of the goodwill.

    What percentage of the annual R&D spend becomes goodwill and how long does it take?

  23. Michael Gentle

    May 23, 2011 at 3:21 pm

    Hi Janey,

    It’s less a question of whether the software is obsolete from a usability or market perspective and more a question of whether it has reached it’s useful life from an accounting perspective (usually somewhere between 3 and 6 years). If it hasn’t, then you have to write it off and charge the outstanding depreciation to current year expense.

    Michael Gentle

  24. Kay G

    Jun 14, 2011 at 8:54 pm

    We are a public educational institution that is using a content management system developed by a sister public institution to offer an online educational program that we are developing under a federal grant. For the next three years we need to match what the federal government will give us. I thought that we might be able to count the online content management system which our sister institution developed and is giving to us to use as a match and thought that using the federal amortization guidelines for software development might be a good means to calculate the match. How is the development of online content management systems amortized?

    Thank you for your kind assistance,

  25. Rhonda

    Jan 18, 2013 at 10:53 pm

    I am a Controller for a sofware enterprise company and had additional questions as to the project tracking for capitalization purposes. We are having a debate as to how this information should be caputured. We currently use a project time tracking system that tracks time by project. Then the employee rate plus overhead is applied to calculate the capitalized amount plus allocation of executive time. However, a debate is on as to if we should just allocate time/salary based on % of time spent on project. Seems to me that % of time would be difficult to calculate and be less accurate that posting time. Your thougts on this and do other enterprise software companies do this? Thanks!

  26. Justin

    Jun 22, 2015 at 2:37 am

    I am researching accounting options for expensing or capitalizing the purchase of a perpetual license for software needed to run a business. Not necessarily revenue generating, but will be used for at least a few years.
    1) What would be the typical accounting treatment of such a purchase? The implementation phase? The ongoing maintenance costs?
    2) How to determine useful life?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Are you looking for easy accounting tutorial? Established since 2007, hosts more than 1300 articles (still growing), and has helped millions accounting student, teacher, junior accountants and small business owners, worldwide.