Valuation of Computer SoftwareA fair value estimate for computer software must be considered in the context of the fair value in a hypothetical transaction. Does the software value make sense based on the amount for which an asset (the software) could be exchanged between knowledgeable, willing parties in an arm’s-length transaction? In addition, if more than one method is selected, it is important for the valuator to reconcile the values in reaching a conclusion. In any engagement, the quantity and quality of the available data, the facts and circumstances unique to the situation, as well as the informed judgment of the valuator will determine ultimately the appropriate methods to estimate the fair value of software for financial reporting.


This post addresses the valuation of computer software and related data according to International Financial Reporting Standards (IFRS) with cross-references to International Valuation Guidance Notes (IVGN). Enjoy!


Authoritative Pronouncements to Be Considered

Pronouncements regarding fair value for financial reporting in the United States are referred to as generally accepted accounting principles (GAAP) rather than to individual standards.

These authoritative documents should be considered in valuing software:

  • IFRS 3R “Business Combinations”, issued in January 2008, to be applied to business combinations occurring on or after July 1, 2009. In certain circumstances, it can be applied sooner, but only in an accounting period beginning after June 30, 2007.
  • IFRS 5 “Noncurrent Assets Held for Sale and Discontinued Operations”, applies to intangible assets whose carrying amount is anticipated to be recovered through a sale rather than by continued use.
  • IAS 38R “Intangible Assets”, prescribes the accounting treatment for intangible assets that are not specifically dealt with elsewhere, using principles-based approaches.
  • IAS 36 “Impairment of Assets”, provides guidance with respect to measuring the impairment of an intangible asset, if its carrying amount exceeds the greater of fair value less costs to sell, or value in use.
  • IVGN 4 “Intangible Assets”, provides assistance in rendering or using valuations of intangible assets.
  • IVGN 16 “Valuation of Intangible Assets for IFRS Reporting Purpose”, still in an exposure draft, expands on IVGN 4.


IFRS defines fair value as the amount for which an asset could be exchanged between knowledgeable, willing parties in an arm’s-length transaction. Although both IFRS and GAAP use the same term as their standard of value for financial reporting, they have different definitions:

  • IFRS assumes a hypothetical buyer and a hypothetical seller in a market transaction involving an entrance price. By contrast, GAAP looks at the hypothetical transaction from the perspective of a market participant, therefore as an exit price, fair value is the price that would be received to sell an asset or paid to transfer a liability in an orderly transaction between market participants at the measurement date. This distinction represents the primary difference between IFRS and GAAP concerning the valuation of software.
  • Another difference is that International Accounting Standard (IAS) 38R distinguishes between the research and the development phases with regard to internally developed software. Research costs are expensed as they occur; development costs are capitalized only when the entity can meet certain specified criteria. Under GAAP, research and development costs are capitalized only for acquired software.



What is Computer Software?

Computer software is a written program, procedure, or set of rules and the associated documentation pertaining to the operation of a computer system; they are stored in read/write memory. This definition includes operating systems, utilities, business applications, word processing and spreadsheets as well as computer games and electronic databases.


What Is Being Valued?

The success of Microsoft is a prime example to understand how critical software design and development is to businesses as well as being potentially lucrative to its creators. Consequently, to obtain better protection, software is often copyrighted and/or patented. When software is to be valued, the first question is whether to value the software, the copyright, or the patent; that decision will determine the most appropriate methodology.

Intangible assets are identifiable, nonmonetary items without physical substance (IAS 38R:8). Acquired computer software is a recognized intangible asset as it meets all of these criteria (IAS 38R:10):

  • It is identifiable.
  • The entity has control over the asset.
  • It is probable that economic benefits will flow to the entity.
  • The cost of the asset can be measured reliably.


Expenditures undertaken to generate future revenues do not by themselves create an intangible asset; when recognition criteria are not met, all costs that have been incurred should be expensed (IAS 38R:10). There is a rebuttable presumption that the fair value of an intangible asset acquired in a business combination can be measured reliably (IAS 38:35).

IAS 38 offers guidance on acquired software. If it is included in the amount paid for an acquisition, it may be individually recognized. If the software is an operating system for hardware, it should be part of the cost of the hardware. Amortization of the software (an accounting, not a valuation, issue) is based on its useful life or pattern of benefits; straight-line depreciation is the default.


Data Collection

The valuator should follow the same due diligence for software as with any valuation assignment: a prudent understanding of: what is being valued, how the item is to be used, who has ownership of what (the source code). All relevant data should be collected, including interviews with the acquirer’s and the target’s managements regarding the economic benefits, measurability, substance, life cycle position, obsolescence, and alternative future uses of the software.


Approaches to Valuation

The generally accepted approaches to valuation are:

  • Market Approach
  • Income Approach
  • Cost (Asset-based) Approach


While all three approaches are used for software, one of the methods under the Income Approach is the most common, although depreciated replacement cost (DRC) is used often for internally generated items. It is important to remember that under IFRS, whichever approach is chosen, the valuation inputs should reflect those that would be made by knowledgeable and willing parties in a hypothetical sale transaction.

Next, let’s overview each of the three valuation apporaches. Follow on…


The Market Approach

Quoted prices in an active market are the most reliable measure of fair value (IAS 38R:39); however, there are not many trades in software and there are no active markets for it. Even if “arm’s-length transaction data is available, it is difficult to know the actual comparability between the item sold (guideline) and that being valued (subject), so as to determine what adjustments may be needed.

Market-based valuations must establish the highest and best, or the most probable use of the asset (IVS 1, 4.1); thoseare developed from data specific to the appropriate market[s] and through methods and procedures that try to reflect the deductive processes of participants in those markets.”

Completed-Transaction Method – The completed transaction method used to value software is similar to that for valuing an entity; however, software transactions are significantly less frequent than sales of businesses. If such transactions can be found, valuation multiples indicated by them may provide meaningful input. Comparability of software, in terms of lines of code, costing conventions, functionality, and ease of use, make it very difficult to use this method; therefore, when it can be applied, it is generally used only as a reasonableness check.

Existing Licenses – In many cases, either the acquirer or the target has licensing agreements for software applications. If comparable to the subject software, often these can be used as a guideline. An alternative is information in public filings on sales or licenses of software; the challenge is to find the appropriate information on truly comparable products.

Relief-from-Royalty – A common technique to value software is the relief-from-royalty method; a hybrid of the market and income approaches, it is based on the principle that if the entity did not own the asset, it would have to license it to obtain the same benefits. Put another way, the value of the software is the present value of the royalty payments that the entity saves by being the owner; this method utilizes a market-derived royalty rate.


The Income Approach

In valuing business enterprises, the Income Approach can provide a viable way of estimating the future benefits to be received. Properly applied, it can also offer an indication of value for software. The challenge and difficulty in using this approach for software is in segregating the cash flows relating only to the software from those of the business.

Profit Split Method – In theory, similar to relief from royalty, this method assumes the subject software is owned by a third party and licensed to target under an agreement to split the profits. The percentage for each participant reflects the facts and circumstances unique to the transaction. For a valuator, establishing the appropriate percentages is daunting. Starting with the 25% rule that dates back to Edison (see Chapter 35), one should analyze all possibly relevant factors, such as what each party brings to the transaction and the potential for substitute software.

Useful Economic Life – A fundamental factor in applying the Income Approach is an estimate of the remaining useful economic life of the subject software; in other words, how long will it continue to generate positive cash flows? The term “economic life” can be defined as the period of time over which property may generate economic benefits. Determining this requires consideration of a number of metrics, such as: the software’s age; expected time until a major enhancement or “rewrite” is needed; how the operating system is used; and how well it satisfies the needs of buyers, especially in terms of speed and efficiency.

Multiperiod Excess Earnings Method – A commonly accepted methodology for estimating the fair value of software is the multiperiod excess earnings method. This method projects the cash flows arising solely from the software in three steps:

  • Step-1. Forecasting by year the operating, debt-free, cash flows available from the software for a period, normally five years.
  • Step-2. Deducting from the debt-free cash flows after-tax returns on contributory assets, such as: working capital, property, plant and equipment, other relevant intangibles and the assembled workforce; the results are the debt-free cash flows from the software.
  • Step-3. Discounting them back to present values at an appropriate risk-adjusted discount rate, which should consider the time value of money, inflation, and the risks inherent in ownership of the subject software.

The fair value of the subject software is the total of the present values of such cash flows over its remaining useful economic life plus any applicable TAB.

Subsequent Expenses – The nature of intangible assets is such that there will seldom be additions to or replacements of any part of them; this means software should be valued without modifications to enhance its performance. Expenditures to enable continued functioning as originally planned are expensed as maintenance when incurred. Subsequent costs to enhance software are only rarely capitalized (IAS 38R:20).


The Cost Approach

The Cost Approach establishes value based on the cost of replacing the property, less depreciation from physical deterioration and obsolescence, if present and measurable. The valuator has the choice of:

  • Replacement cost new: the current cost of a similar new property having the nearest equivalent utility to the property being valued; or
  • Reproduction cost new: the current cost of an identical new property.


The primary difference is that replacement cost relates to an asset with similar functionality and utility taking advantage of the latest technologies, while reproduction cost typically re-creates an identical item. IFRS believes that the Market Approach, if the data are available, is the best way to estimate fair value.

Replacement cost, if a similar asset can be identified, is an excellent means of valuing software under the Cost Approach. There are two primary techniques used in the Cost Approach to value software: “trended historic cost” and “engineering build-up“.

For software, the trended historic cost method adjusts the actual monthly or yearly software development expenditures by an appropriate inflationbased factor to convert them to current levels. However, a business rarely knows the actual period development costs for a particular software program in sufficient detail for a valuator to use this method. Consequently, replacement costs usually are estimated using a software engineering model with actual and/or estimated development times. Those are designed to assist software managers and developers to estimate the time, human resources, and other efforts expected to be needed for a software project.

Commonly, metrics such as lines of code, function points, and the like and fully loaded per hour costs of each of the various grades of staff are used. The valuator must make sure that all relevant expenses are counted in the software’s development costs, such as: employee remuneration including options, payroll taxes, employee benefits, allocated overhead costs, installing for beta testing as well as the entity’s customary profit margin on such a project.


Obsolescence or Remaining Useful Life

As described in this post, all three traditional approaches may be used to value software. Each should include an estimate of the software’s remaining useful economic life. A valuator ought to include this and any situations/conditions that might affect the future benefits in an estimate of the software’s fair value. Also he or she should provide a sound analysis of any “obsolescence factors“; however, in most instances, there is insufficient information available about any software program from which to calculate survivor or probable life curves.

These types of obsolescence should be considered for software:

  • Functional represents the loss in value due to a reduction in the utility of the asset over time, such as increased downtime due to maintenance as the asset ages, and redundant or extraneous code.
  • Technological includes its “life cycle,” as new products and upgrades are introduced quickly in the twenty-first century. The value of a program may decline rapidly if a development in the industry or by another vendor renders it obsolete. Other influences on declining values are: lack of major enhancements, a failure to satisfy users’ current and future needs, and the feasibility of similar software being introduced.
  • Economic represents a loss of value from factors that may not have anything to do with the software itself but be merely external economic trends. The 2008 global crisis has shown that companies and their products are perceived to have less value than before it began. Supply and demand should also be considered; for example, does the subject software have many competitive substitutes?