Valuing Internally Developed Software Using the Cost Approach in a Dispute Resolution Context

The following article was prepared by its authors. The opinions expressed in the article represent the authors’ and may not reflect the view and/or opinion of Vallit Advisors and its staff. Views/opinions are based on the specific facts and circumstances of each matter.

Internally developed software may be a valuable intangible asset owned by some companies. In cases where these companies are involved in disputes that may involve a business valuation or damage analysis, the value of this internally developed software may be at-issue. In such cases, the value of the internally developed software may be estimated based on the application of the cost approach. This discussion (1) defines internally developed software, (2) describes valuing software in a dispute context, and (3) summarizes software valuation approaches and methods (specifically, the cost approach, replacement cost new less depreciation method).

Introduction

In some business valuation and damage disputes, the value of a company’s intangible assets may be pertinent. Therefore, it may require the valuation of a company’s intangible assets. For companies with valuable internally developed software, that intangible asset may have to be assessed.

This discussion focuses on the valuation of internally developed software as an intangible asset. There are generally accepted approaches (cost approach, market approach, and income approach) that may be used to value internally developed software. The estimated value of such software may be material in an asset-based approach valuation of an entire company. This discussion focuses on the application of the cost approach, and the replacement cost new less depreciation (or “RCNLD”) intangible asset valuation method.

The RCNLD method is commonly applied to value internally developed software.

This discussion (1) defines internally developed software, (2) describes valuing software in a dispute resolution context, and (3) summarizes software valuation approaches and methods (specifically, the cost approach—RCNLD method).

Defining Internally Developed Software

Computer software may be understood as the programs that instruct a computer on what to do. In Revenue Procedure 2000-50, the Internal Revenue Service (the “Service”) defines “computer software” as follows: 

any program or routine (that is, any sequence of machine-readable code) that is designed to cause a computer to perform a desired function or set of functions, and the documentation required to describe and maintain that program or routine. It includes all forms and media in which the software is contained, whether written, magnetic, or otherwise. Computer programs of all classes, for example, operating systems, executive systems, monitors, compilers and translators, assembly routines, and utility programs as well as application programs, are included. Computer software also includes any incidental and ancillary rights that are necessary to effect the acquisition of the title to, the ownership of, or the right to use the computer software, and that are used only in connection with that specific computer software.

Moreover, the Service provides the following definition in Title 26 of the Code of Federal Regulations, Section 1.197-2 – Amortization of goodwill and certain other intangibles:

computer software is any program or routine (that is, any sequence of machine-readable code) that is designed to cause a computer to perform a desired function or set of functions, and the documentation required to describe and maintain that program or routine. It includes all forms and media in which the software is contained, whether written, magnetic, or otherwise. Computer programs of all classes, for example, operating systems, executive systems, monitors, compilers and translators, assembly routines, and utility programs as well as application programs, are included. Computer software also includes any incidental and ancillary rights that are necessary to effect the acquisition of the title to, the ownership of, or the right to use the computer software, and that are used only in connection with that specific computer software…

For the purposes of this discussion, we focus on software that has been “internally-developed” by the subject company. That is, the subject of this discussion does not include software that is bought, sold, licensed, or otherwise part of regular transactions between the subject company and its suppliers or customers. This discussion focuses on software that is internally developed by a company and is used in the day-to-day operations of the company. 

Valuing Software for Dispute Contexts

From the internally-developed software owner’s point-of-view, the rights related to the internally-developed software should be guarded. 

A valuation of the internally-developed software may be helpful when it is the subject of a dispute such as marital dissolution. Moreover, a damages analyses that includes consideration of the internally-developed software may be helpful in an economic damages dispute over lost business value. There exist many other dispute contexts in which the value of internally-developed software may be relevant.

For example, in a business valuation related to a marital dissolution, let’s assume that the subject company (“Alpha Company”) is owned by a husband and wife and that the company is a real estate management enterprise that primarily holds non-operating parcels of real estate (e.g., land). Let’s further assume that Alpha Company has internally-developed a software suite that tracks, records, and processes all the data related to the underlying real estate (“Alpha Software”). The Alpha Software is essential to Alpha Company in that it manages all the data related to the  underlying real estate assets. Let’s further assume that significant time (on the part of employees) and significant cost (likely through expenses related to the software developers’ time) went into the development of the Alpha Software.

In this example, Alpha Company has recorded notable costs related to the Alpha Software, however such costs may not have been entirely (or at all) capitalized on the company’s balance sheet and rather have been recognized as expenses on the company’s income statement.

If the husband-and-wife owners were to dissolve their marriage, the valuation of Alpha Company would likely be required. Since Alpha Company primarily operates as a non-operating real estate holding company, an income approach valuation may be difficult. Moreover, if data on comparable sales of companies or data on comparable publicly traded companies is not available, a market approach valuation may be difficult.

In this circumstance, an asset approach may be appropriate for the business valuation. In the asset approach, the value of the company is based on the company’s historical cost-based balance sheet, adjusted to fair market value (or the subject dispute and jurisdiction’s required standard of value). All the assets and liabilities of the business are identified and listed on the balance sheet, then brought to fair market value, as of the valuation date. The difference between the fair market value of the assets and the liabilities is the indicated equity value of the business under the asset approach.

In our preceding example, Alpha Company’s balance sheet may report current assets such as cash, long-term assets such as real estate, and other assets recognized under U.S. generally accepted accounting principles (“GAAP”) based on historical cost. However, Alpha Company’s balance sheet may not report the valuable Alpha Software (or may not report all costs incurred in developing it). In this instance, a discrete valuation of the Alpha Software may be necessary to determine the fair market value (or other applicable standard) to be applied in the marital dissolution dispute. 

In a damages dispute relating to lost business value, economic analyses necessary for the damage conclusion may include: 

1. an estimate of any decrease in value for the internally-developed software, 
2. a “cost to cure” the internally-developed software (i.e., to restore it to its pre-damage condition), or 
3. another measure of damage to the internally-developed software owner “but for” the alleged damage.

Software Valuation Approaches and Methods

The three generally accepted intangible asset valuation approaches are the (1) income approach, (2) market approach, and (3) cost approach. These three generally accepted valuation approaches are summarized below, though the cost approach is the focus of this discussion. 

Income Approach

The income approach involves the identification of the expected revenue, expenses, profit margins, and necessary investments related to the ownership of an intangible asset. The income approach estimates the value of an intangible asset based on the present value of projected income. That income is commonly measured using net cash flow but may be based on other measures of income. This income may be estimated over the intangible asset’s expected remaining useful life (“RUL”).

This projected income is discounted to its present value by the use of an appropriate market-derived, risk-adjusted discount rate (or required rate of return).

In the case of internally developed software (such as that used in our earlier example), it may be difficult or impossible to identify an income stream related to the intangible asset. If the software is used in the day-to-day operations of the company, and the company’s income attributable to the software is not individually separate and distinct, then application of the income approach may not be warranted.

Market Approach

The market approach measures the value of an intangible asset using valuation pricing multiples sourced from arm’s-length transactions (sale or license) of comparable intangible assets. Common sources for these data include ktMINE’s Royalty Rate Database and RoyaltySource. 

Intangible asset sale or license transactional data may not be readily available as it relates to internally-developed software that is used in the day-to-day operations of a business. This is because such software is usually not made available for sale for commercial use by other organizations. In cases where internally-developed software is made available for sale (i.e. by a company that develops and licenses software as its primary product), intangible asset sale or transactional licensing data may be readily available.

In the case of internally developed software (such as that used in our earlier example), it may be difficult or impossible to find comparable arm’s-length transactions for the intangible asset. If the software is used in the day-to-day operations of the company, and is uniquely suited to that company’s particular operations, it may be difficult or impossible to find transactions of software that are comparable. If this is the case, then application of the market approach may not be warranted.

Cost Approach

The cost approach yields the value of an intangible asset as the cost (based on current dollar expenditures) necessary to create an intangible asset with equal utility and functionality as the subject intangible asset. The following cost components are typically considered in a cost approach valuation: direct costs, indirect costs, developer’s profit, and entrepreneurial incentive.

The cost approach valuation may also consider the various forms of depreciation if the replacement intangible asset is superior to the subject intangible asset. The various forms of depreciation include (1) physical deterioration (“PD”), (2) functional (including technological) obsolescence (“FO”), and (3) external (including economic) obsolescence (“EO”).

This discussion will focus on the application of the cost approach to value internally-developed software.

Cost Approach Methods

The cost approach starts with some measure (or metric) of cost. The common types of cost that may be used in an internally-developed software cost approach valuation include the following:

1. Reproduction cost new (“RPCN”)
2. Replacement cost new (“RCN”)

The RPCN represents the cost to create an exact replica of the software (i.e., “reproduced software”). The RPCN relates to the cost to create the functionality and utility of the original software, in a form that is identical to the original software. The RCN represents the cost to create the functionality and utility of the original software, but in a form that may be different from the original software (i.e., “replacement software”).

In this context, functionality means the ability of the software to perform its designed task. Utility means the ability of the software to produce the same amount of satisfaction to the software user. 

Both the reproduced software and the replacement software perform the same task(s) as the original software. However, the replacement software is usually better than the original software, in some way. An adjustment for these potential enhancements in the replacement software as compared to the reproduced software or original software may be made in the consideration of depreciation. 

Both the RPCN and the RCN cost metrics may be used in a cost approach analysis of internally-developed software. The RPCN may be used in a reproduction cost new less depreciation (“RPCNLD”) method analysis and the RCN may be used in a replacement cost new less depreciation (“RCNLD”) method analysis. The RPCNLD method and the RCNLD method (as they relate to internally-developed software) are summarized next.

Reproduction Cost New Less Depreciation Method

As mentioned previously, the RPCNLD method is based on the RPCN cost metric. That is, the RPCNLD method considers the cost to create an exact replica of the original software. Next, the RPCN is adjusted for the appropriate forms of depreciation.

The first procedure in an RPCNLD method analysis is to estimate the RPCN. One accepted model for estimating RPCN is by applying a trend factor adjustment to historical costs (i.e., trended historical cost). A trended historical cost adjusts the actual historical costs of creating the internally-developed software by an appropriate cost adjustment trend factor. The result of this model is the RPCN of the software. 

For this model, the actual historical software development costs incurred by the software owner are identified and quantified. Next, these historical costs are “trended” to the valuation date by an appropriate cost index factor. This trending model may include all the historical costs associated with software development.

The software owner’s overhead costs, employee fringe benefit costs, and employee payroll costs are typically allocated to the software-related costs if the company’s personnel are involved in the software development process.

Historical costs ordinarily include consideration for: 

1. a developer’s profit component related to the software development, 
2. an entrepreneurial incentive component to prompt the software development, 
3. direct development costs (e.g., salaries), and 
4. indirect development costs, (e.g., overhead, employment taxes and benefits).

The trended historical cost model typically results in the RPCN of the internally-developed software. Usually, due to programming languages or tools advancements, the RPCN may be higher than the RCN for the internally-developed software.

The second procedure in an RPCNLD method analysis is to consider and measure all relevant forms of depreciation. The forms of depreciation considered in an RPCNLD method analysis are (1) PD, (2) FO, and (3) EO.

PD represents the diminution in value of assets due to wear and tear and all physical aspects that may diminish life and serviceability. Regarding internally-developed software, PD is not typically applicable.

FO represents the diminution in value of assets due to an inability of the asset to sufficiently perform the function for which it is used. FO typically relates to asset super-adequacies, asset inadequacies, excess operating costs, and excess capital costs. Regarding internally-developed software, FO is often present in an RPCNLD method analysis. This is because, if the RPCN estimate is based on trended historical costs, it is likely that the historical costs were incurred based on the use of less efficient programming languages or tools, among other issues. In this instance, an allowance for FO should be applied to the RPCN indication.

EO represents the diminution in value of assets due to external factors. Examples of these factors may include supply/demand changes, changes in law, industry conditions, economic conditions and other external factors. EO may be applicable in an RPCNLD method analysis. Typically, EO is not considered on an asset-by-asset basis but rather on a total entity basis. That is, EO is typically considered as one overall adjustment that is allocated to each company asset. EO can be further segmented into locational obsolescence (obsolescence resulting from the company or assets being located in a specific are) and economic obsolescence (obsolescence resulting from economic factors). Regarding internally-developed software, EO may be applied by considering and performing generally accepted EO measurement methods to the entire company operations (e.g., applying a capitalization of income loss method analysis). The measurement of EO is beyond the scope of this discussion.

The third and final procedure in an RPCNLD method analysis is to apply the various depreciation adjustments to the RPCN to estimate the RPCNLD of the internally-developed software.

Replacement Cost New Less Depreciation Method

In addition to the RPCNLD method, the RCNLD method may be applied to estimate the value of internally-developed software. The RCNLD method relies on the RCN cost metric and considers the same forms of depreciation considered in the RPCNLD method. As previously mentioned, the RCN cost metric relates to the cost to create the functionality and utility of the original software, but in a form that may be different from the original software.

The following section of this discussion will present one model for estimating the RCN cost metric (based on software development effort estimation models and current costs). However, we note that the RCN cost metric may also equal the RPCN cost metric in some circumstances (i.e., may be based on trended historical costs). This situation is common when the software subject to analysis is relatively new and, therefore, was developed using current programming technology and tools.

Even in situations where the software was developed less recently, and older programming technology and tools were used, RPCN can still be used to estimate RCN. In this instance, the formula for arriving at RCN, based on RPCN is as follows:

RPCN

Less:

Excess Capital Costs

Equals:

RCN

If the software owner is able to provide detailed information that can isolate excess capital costs related to the software development (costs related to software development that was never used in the end-product) the subtraction of those costs can result in the RCN.

Regardless of which model is used to estimate RCN, the next procedure is the consideration and measurement of all relevant forms of depreciation. The forms of depreciation considered in an RCNLD method analysis are (1) PD, (2) FO, and (3) EO.

As stated previously, PD is not typically applicable.

The FO estimate for an RPCNLD method analysis and an RCNLD method analysis would likely see the greatest divergence. This is because FO represents depreciation that is based on the functionality and utility of the software, often for technological reasons. As stated previously, if the software value indication is based on trended historical Effort Costs (i.e., RPCN) that were incurred long ago, the indicated FO may be high. By contrast, if the software value indication is based on Effort Models and current Effort Costs (i.e., RCN), the indicated FO may be low.

As stated previously, EO is typically considered as one overall adjustment to the software owner assets that is then allocated to each company asset. Regarding internally-developed software, EO may be applied by considering and performing generally accepted EO measurement methods to the entire company operations (e.g., applying a capitalization of income loss method analysis). The measurement of EO is beyond the scope of this discussion.

The final procedure in an RCNLD method analysis is to apply the various depreciation adjustments to the RCN to estimate the RCNLD of the internally-developed software.

Application of the Cost Approach Using the RCNLD Method

The following example will present the application of the cost approach, RCNLD method to estimate the fair market value of the Alpha Software. This example will be performed as of December 31, 2023, and is assumed to be applied in a marital dissolution context.

Cost Metric

The first procedure in our RCNLD method analysis is to estimate the cost metric to be used to value the Alpha Software. In this example, we will rely on a combination of (1) software development effort estimation models (or “Effort Models”) and (2) an estimated cost per development effort unit (or “Effort Cost”).

Software Development Effort Estimation Models

In our example, we relied on Effort Models to estimate the RCN of the Alpha Software. Broadly, Effort Models were created to help software developers estimate the effort, time, and resources needed to complete a software project. These Effort Models also include cost estimates for software projects.

Effort Models are also used by intangible asset appraisers to value internally developed software.

The primary input to Effort Models is a size-related metric for software. Two common size-related metrics include lines of code and function points. Either size-related metric may be applied. We will focus our example on lines of code. The exact interpretation of a line of code and the associated counting convention varies among the common Effort Models.

A line of code is often defined as source code instructions, and may be segmented as follows:

1. instructions written by human programmers or 
2. object code instructions, that is, what a computer creates one it has compiled the source code into instructions that can be processed.

A line of code may be different based on the computer language employed to write it. Computer languages mature over time (often classified into generations). Generally, newer languages require less written source code to perform the same tasks than older languages. That is, some level of FO may be inherent based on the generation of language used in the subject source code.

There are numerous assumptions and adjustments that may be applied in the analysis of the lines of source code to be used within Effort Models when performing a software valuation. Based on which assumptions and adjustments are made, certain forms of depreciation may or may not be relevant. Some of these assumptions and adjustments relate to:

1. estimated RUL of the software,
2. any necessary conversion from physical executable to logical executable lines of source code,
3. any necessary consideration of “copybook” lines of source code,
4. an estimate of “ideal” lines of source code as compared to the “actual” lines of source code, and
5. various other assumptions and adjustments.

A review of all of these potential assumptions and adjustments is beyond the scope of this discussion.

Some common Effort Models are the (1) Constructive Cost Model (“COCOMO”) and its derivatives, (2) Software Lifecycle Management-Estimate (“SLIM”) model, (3) KnowledgePlan (“KPLAN”) model, and (4) SEER for Software (“SEER-SEM”) model. 

These “algorithmic” Effort Models generate effort estimates using quantified inputs which are analyzed based on metrics and formulas determined based on an empirical analysis of databases with completed software development projects. Normally, Effort Models estimate the effort required to develop software based on person-months (time a full-time employee’s work efforts would be needed). The number of person-months is multiplied by the Effort Cost (in this case, cost per person per month) to estimate the value of software. The Effort Cost is usually based on a “full absorption cost” that includes all direct costs, indirect costs, developer’s profit, and the entrepreneurial incentive related to software development.

A detailed discussion of the COCOMO, SLIM model, KPLAN model, and SEER-SEM model is beyond the scope of this article. In our example, we will rely on the application of COCOMO II (discussed below) to estimate the value of the Alpha Software. A brief description of COCOMO follows.

COCOMO

COCOMO was first developed in the 1980s by Barry W. Boehm, PhD. COCOMO forecasts the effort needed to develop software, considering size, software characteristics, and the development environment. Boehm created an effort equation that estimates the person-months required to develop software based on delivered source instructions. This estimate includes all development phases.

Boehm later refined COCOMO by introducing 15 “cost drivers” and their associated “effort multipliers.” The product of the effort multipliers is defined as an “effort adjustment factor.”

A new model, COCOMO II, was later developed by researchers at the University of Southern California (“USC”) in 1995. COCOMO II supports a variety of third and fourth generation languages. COCOMO II also includes function point analysis as well as two new effort multipliers. COCOMO II consists of three separate models, the most recent and detailed of which is the COCOMO II.2000 (or “post-architecture model”). COCOMO III (an update to COCOMO II), is currently being developed by the Boehm Center for Systems and Software Engineering (“CSSE”). Boehm CSSE aims to improve the model with functional size inputs, a new software security parameter, removal of certain COCOMO II parameters, an update of certain COCOMO II parameters, and adjustments to cost drivers based on application domain.

Cost Per Development Effort Unit

The cost per development effort unit (i.e., Effort Cost) is a “full absorption cost.” The Effort Cost includes the salaries of the software development personnel and other costs. These other costs include, but may not be limited to, bonuses, payroll taxes, benefits (e.g., health and dental insurance, pension plans, etc.), and a company overhead allocation (e.g., costs related to administrative support, office space, equipment, office supplies, advertising, management, etc.).

The Effort Cost may also include (1) developer’s profit and (2) entrepreneurial incentive. A discussion of these components of the Effort Cost follows. 

Developer’s Profit

Developer’s profit is the expected return that an intangible asset developer expects to generate above the direct costs and the indirect costs related to the intangible asset development. Developer’s profit may be estimated as a percent return on the company’s investment in direct costs and indirect costs to replace the internally-developed software.

For valuing software, one way to estimate developer’s profit is to utilize publicly traded computer programming services companies to identify a reasonable developer’s profit. This can be accomplished by benchmarking the operating margins of those companies. Because operating margin is based on a return on revenue (i.e., profit margin) and developer’s profit is based on cost, the selected operating margin should be converted to a developer’s profit using the following:

Operating margin

Divided by:

(1 – Operating margin)

Equals:

Developer’s profit

An operating margin that is 13.6% higher than the total development cost is equivalent to a profit margin of 12.0% (ignoring rounding). If a software developer incurred total direct costs and indirect costs of $100, the developer would need income of $113.64 (i.e., $13.64 of profit) to generate an operating margin of 12.0%. In this case, the operating margin is calculated as $13.64 divided by $113.64.

Entrepreneurial Incentive

The entrepreneurial incentive component may also be included in the Effort Cost analysis and is estimated by considering the following:

1. A rate of return, (e.g., a weighted average cost of capital),
2. The time required to replace the software, and
3. The sum of the developer’s profit, direct costs, and indirect costs incurred during the time required to replace software.

Next, the direct costs, indirect costs, developer’s profit, and entrepreneurial incentive are added together to estimate the Effort Cost to be applied in the valuation of the Alpha Software. This “full absorption cost” is then applied to the Effort Model indications to estimate RCN. 

In our example, let’s assume that the Effort Cost (in person-months) related to the Alpha Software equals $4,450 and includes the estimated direct costs, indirect costs, developer’s profit, and entrepreneurial incentive related to Alpha’s development of the Alpha Software. Let’s further assume that the Alpha Software can be segregated into three individual software programs.

These programs can be summarized as follows:

Based on our estimated Effort Cost of $4,450, and the above-presented Effort Model estimates, the RCN of the programs would be as follows:

• Parcel Management—$513,975
• Financial Analysis—$669,725
• Marketing Flyers—$64,525

The next procedure would be to consider, measure, and apply any relevant forms of depreciation. 

Depreciation Measurement

As previously discussed, when valuing internally developed software for dispute resolution purposes, the intangible asset appraiser should make any needed adjustments for all forms of depreciation. These may include PD, FO, and EO. These forms of depreciation were described earlier in this discussion.

As it relates to our example, we may consider the various forms of depreciation below, as they relate to the Alpha Software. 

Physical Deterioration

In our example, we analyzed the Alpha Software and found no indication that the software suffered from PD. Therefore, no PD was applied in our valuation.

Functional Obsolescence

In our example, we were told by Alpha management that the “Marketing Flyers” software program had a limited RUL due to a plan to replace it soon with licensed software from a 3^rd party. Alpha management indicated that they put “Marketing Flyers” into production 2 years prior to the valuation date and planned to replace “Marketing Flyers” with the 3^rd party licensed software 3 years after the valuation date. Therefore, we estimated a useful life of 5 years and an RUL of 3 years. This results in a 40% FO adjustment. This adjustment is calculated as:

(1 – ((1 / useful life in years) x RUL in years)) = FO %

The results of this adjustment were to decrease the RCN of “Marketing Flyers” from $64,525 to $38,715 (i.e., by 40%). No other adjustments for FO were deemed necessary.

External Obsolescence

In our example, the last procedure would be to consider and measure any economic obsolescence that was affecting the Alpha Software. As stated earlier, a summary of EO measurement is beyond the scope of this discussion. For the purposes of our example, we assume that no indications of EO were found.

Application of the Cost Approach, RCNLD Method Conclusion

Based on the above, the indicated RCNLD (i.e., value) of the Alpha Software equals $1,222,415 as of December 31, 2023. This value can be used as the fair market value of the Alpha internally developed software in an asset-based approach to business valuation for the purposes of the marital dissolution.

Summary and Conclusion

This discussion provides a summary of valuing internally developed software using the cost approach in a dispute resolution context. We (1) defined internally developed software, (2) described valuing software in a dispute resolution context, and (3) summarized software valuation approaches and methods (specifically, the cost approach).

Connor J. Thurman is a Manager with Vallit Advisors, LLC. Mr. Thurman has over 6 years of experience in business valuation, tangible and intangible asset appraisal, and various other litigation services. He has written numerous articles in professional and peer-reviewed journals covering a variety of topics in his areas of expertise and has presented on these topics via webinars and conferences. He is an Accredited Senior Appraiser (ASA) with the American Society of Appraisers and is Accredited in Business Valuation (ABV) with the American Institute of Certified Public Accountants.

Mr. Thurman can be reached at 443-482-9500 Ext 114 or cthurman@vallitadvisors.com

Archibald Cullen is a Senior Analyst, with Vallit Advisors, LLC. Mr. Cullen provides support on business valuation, forensic accounting, and dispute advisory engagements. He also assists the Senior Management in the development of analyses and report preparation for a variety of cases.

Mr. Cullen can be reached at 443-482-9500 Ext 121 or acullen@vallitadvisors.com