BACKGROUND

Video games industry is an evolving and rapidly developing sector. Growing requirements for games quality and complexity demand contributing substantial resources in the development process. Some video game developers finance their activities by using internal resources or accessing capital markets by issuing debt or equity instruments. Other developers seek external financing from qualified investors, using profit or revenue sharing arrangements, rather relying on internal financing, or issuing traditional debt or equity instruments. Although terms may vary, in a typical revenue share arrangement, third-party investor finances agreed-on percentage of game development costs in exchange of a share in subsequent distribution proceeds. The investor and the developer sign a development financing agreement governing development, financing and distribution terms. Terms of the agreement specify roles and responsibilities of each party, some of which are described below. 

In most cases, the developer, not the investor retains Intellectual Property (IP) rights for a game. 

In a typical develop financing agreement, the investor’s financing is linked to completion of development milestones, as specified in the agreement. Examples of milestones include singing of the agreement, completion of pre-production activities, completion of a prototype, etc. 

Upon the completion of the game, an investor will retain rights to receive its shares of distribution proceeds from end-users or, in some instances, other measure of income, e.g., revenue, EBITDA, etc.  

In some case, investor’s role is limited to being a financing partner and monitoring of the development process. In other cases, the investor may also have game distribution rights, i.e., the rights to distribute the game from its hardware or as an e-commerce (merchant of record) partner. Investor distribution rights may be exclusive or non-exclusive, perpetual or limited in time, depending on specific contract terms. The party that assumed the role of a distributor, will collect proceeds from end-user, retain its own portion and remit the remaining part to the other party. Terms of the agreement will specify the order of distribution of customer proceeds (or other measures of income) as well as respective percentages or allocation rates. 

Many investors raised a question of how to account for financing provided to game developers in entity’s U.S. GAAP financial statements. This publication specifically covers investor’s accounting, not accounting of third-party financing by software developers. 

Guidance provided in this publication was developed based on assumptions that investments in software development projects will not result in consolidation or use of the equity accounting method in relation to the software developer under existing U.S. GAAP and that the investments will not be subject to investment company accounting per ASC 946, Financial Services- Investment Companies.

Investors should carefully analyze the terms associated with financing proceeds and consult their advisors to establish proper accounting treatment. 

EXECUTIVE SUMMARY

Classification & Presentation

Investments in software development projects may be considered a software (View 1) or a financial instrument (View 2). First view is supported by the main goal of the project investment, being development of a marketable software product, with a risk and reward profile similar to a software development project. Although most investors do not “own” the IP rights and may own distribution rights, the lack of ownership rights does not prevent application of the software guidance. View 2 is supported by the fact that economic characteristics of the investments meet the definition of a financial instrument. View 2 is also supported by the nature of the investment and investors role, which may be limited to being a financing partner. 

We believe that View 1 or software approach is a preferred method of accounting of funding provided by investors to third-party game developers. The accounting treatment based on View 1 is supported by U.S. GAAP and is consistent with existing accounting practices followed by U.S. game publishers. View 2 or considering funding provided to third-party game developers as financial assets is not contrary to existing U.S. GAAP but is not widely adopted in the U.S. Application of the financial instrument approach will also require additional analysis of whether the instrument should be classified as debt-like or equity-like. 

When end-users (gamers) can download the game to its hardware, the software satisfies the definition of external-use software per ASC 985-20-15-5 and, therefore, is subject to ASC 985. In other cases involving online hosted games, the software in question will be subject to ASC 350-40, i.e., the guidance applicable to internal-use software. Guidance provided below is relevant to the external-use software. 

Investors should carefully analyze the terms associated with financing proceeds and consult their advisors to establish proper classification of investments in software development projects. 

Initial Recognition

Funding provided to third-party developer prior to establishing of software technological feasibility is recognized as a research and development expense. When the technological feasibility of the software product is established, all subsequent payments made by the Investor to a third-party developer should be capitalized as software development costs.  

Technological feasibility is established when the developer has completed all planning, designing, coding, and testing activities that are necessary to establish that the product can be produced to meet its design specifications including functions, features, and technical performance requirements. More specifically, technological feasibility can be established when the developer finishes complete and tested detailed program design or complete and tested working model, as defined in ASC 985-20. 

U.S. GAAP requirements related to establishing technological feasibility assume that software development process is performed in the sequential order sometimes referred to as a waterfall approach. Many companies follow a different approach to software projects e.g., an agile approach where development and testing work on different features or software modules is done in short sprints. Identifying when the traditional activities attributable to the waterfall approach occur following the agile approach requires significant analysis and judgment. 

Subsequent Measurement

Capitalized software costs shall be amortized on an investment-by-investment or product-by-product basis. The annual amortization is the greater of the amounts computed using a) the ratio that current gross revenues bear to the total of current and anticipated future gross revenues and b) the straight-line method over the remaining estimated economic life of the product.  

Unamortized software costs are assessed for impairment by using the net realizable value approach at each balance sheet date. The amount by which the unamortized capitalized costs of a computer software product exceed the net realizable value of that asset shall be written off. The net realizable value is the estimated future gross revenues from that product. 

ANALYSIS

Question 1: How should the Investor classify its financing provided to third-party developers, i.e., intangible assets, financial instruments, etc.?

Generally, we believe that the financial proceeds provided by the investor have characteristics of software development costs and financial assets. Below we analyzed the two views relevant to GAAP accounting treatment of the funding provided to game developers. 

View 1: Software Development

The Investor is involved in software development process by funding video games development performed by a third-party. After the development is complete, the game will be licensed to end-users. Therefore, the software in question maybe be subject to ASC 985-20, Costs of Software to Be Sold, Leased, or Marketed or ASC 350-40, Internal-Use Software. 

Depending on contract terms, the following considerations point toward classification of investments as software development costs: 

  • The main goal of investment activities is development of marketable software product; 
  • Recoverability of investments solely depends on the outcome of software development and subsequent distribution process; 
  • The investor has substantial control over the development process (i.e., milestones approval rights); 
  • The investor actively participates in game distribution and advertising; 

ASC 985-20-15, Scope and Scope Exceptions does require a reporting entity to legally “own” the software code for the respective asset to be subject of ASC 985. Development of the external use software by utilizing third-party developers rather than using the in-house developing team will still be subject to ASC 985, provided other ASC 985 scope criteria are met. Same consideration, i.e., the fact that the lack of IP ownership rights and use of third-party developing firms do not prevent application of ASC 350-40, apply to the scope of internal-use software. 

Arrangements whereby a game publisher funds game development through third-party developers are common in the United States. There are a number of examples where game publishers treat such funds as advances to third-party developers as software development costs subject to ASC 985. 

Take Two Interactive adopted the following approach to accounting of funding provided to third-party developers, as described in company’s accounting policy for Software Development Costs and Licenses (based on company’s published 10-K):  

We enter into agreements with third-party developers that require us to make payments for game development and production services. In exchange for our payments, we receive the exclusive publishing and distribution rights to the finished game title as well as, in some cases, the underlying intellectual property rights. 

Such agreements typically allow us to fully recover these payments to the developers at an agreed upon royalty rate earned on the subsequent sales of such software, net of any agreed upon costs.  

Subsequent to establishing technological feasibility of a product, we capitalize all development and production service payments to third-party developers as software development costs and licenses. We typically enter into agreements with third-party developers after completing the technical design documentation for our products and therefore record the design costs leading up to a signed development contract as research and development expense. When we contract with third-party developers, we generally select those that have proven technology and experience in the genre of the software being developed, which often allows for the establishment of technological feasibility early in the development cycle. In instances where the documentation of the design and technology are not in place prior to an executed contract, we monitor the software development process and require our third-party developers to adhere to the same technological feasibility standards that apply to our internally developed products. 

Licenses consist of payments and guarantees made to holders of intellectual property rights for use of their trademarks, copyrights or other intellectual property rights in the development of our products. Agreements with license holders generally provide for guaranteed minimum payments for use of their intellectual property. Certain licenses, especially those related to our sports products, extend over multi-year periods and encompass multiple game titles. In addition to guaranteed minimum payments, these licenses frequently contain provisions that could require us to pay royalties to the license holder based on pre-agreed unit sales thresholds. 

Take Two Interactive describes subsequent treatment of capitalized software cost as follows: 

Amortization of capitalized software development costs and licenses commences when a product is available for general release and is recorded on a title-by-title basis in cost of goods sold. For capitalized software development costs, annual amortization is calculated using (1) the proportion of current year revenue to the total revenue expected to be recorded over the life of the title or (2) the straight-line method over the remaining estimated life of the title, whichever is greater.  

For capitalized licenses, amortization is calculated as a ratio of (1) current year revenue to the total revenue expected to be recorded over the remaining estimated life of the title or (2) the contractual royalty rate based on actual net product sales as defined in the licensing agreement, whichever is greater. Amortization periods for our software products generally range from twelve to 30 months. 

Activision Blizzard treats payments to third party developers as “Software development costs and intellectual property licenses”. According to company’s 10-K: 

Software development costs include direct costs incurred for internally developed products, as well as payments made to independent software developers under development agreements. Software development costs are capitalized once technological feasibility of a product is established and such costs are determined to be recoverable. Technological feasibility of a product requires both technical design documentation and game design documentation, or the completed and tested product design and a working model. For products where proven technology exists, this may occur early in the development cycle. 

Software development costs related to online hosted revenue arrangements are capitalized after the preliminary project phase is complete and it is probable that the project will be completed and the software will be used to perform the function intended.  

Significant management judgments and estimates are applied in assessing when capitalization commences for software development costs and the evaluation is performed on a product-by-product basis. Prior to a product’s release, if and when we believe capitalized costs are not recoverable, we expense the amounts as part of “Cost of revenues—software royalties, amortization, and intellectual property licenses. 

Activision Blizzard does not describe their rights in relation to the IP funded by them. However, as noted above, the reporting entity does not need to own the underlying code for the asset to be considered subject to ASC 985 or ASC 350-40. 

Electronic Arts treats payments to third party developers as “advances against subsequent royalties”. According to company’s 10-K: 

We typically advance development funds to the independent artists and third-party developers during development of our games, usually in installment payments made upon the completion of specified development milestones. Contractually, these payments are generally considered advances against subsequent royalties on the sales of the products. These terms are set forth in written agreements entered into with the independent artists and third-party developers. 

The company also specifies that: 

Royalty-based obligations with content licensors and distribution affiliates are either paid in advance and capitalized as prepaid royalties or are accrued as incurred and subsequently paid. These royalty-based obligations are generally expensed to cost of revenue generally at the greater of the contractual rate or an effective royalty rate based on the total projected net revenue for contracts with guaranteed minimums. 

Prepayments made to thinly capitalized independent software developers and co-publishing affiliates are generally made in connection with the development of a particular product, and therefore, we are generally subject to development risk prior to the release of the product. Accordingly, payments that are due prior to completion of a product are generally expensed to research and development over the development period as the services are incurred. 

Electronic Arts describes subsequent treatment of royalty-based obligations as follows: 

Each quarter, we also evaluate the expected future realization of our royalty-based assets, as well as any unrecognized minimum commitments not yet paid to determine amounts we deem unlikely to be realized through future revenue. Any impairments or losses determined before the launch of a product are generally charged to research and development expense. Impairments or losses determined post-launch are charged to cost of revenue. We evaluate long-lived royalty-based assets for impairment using undiscounted cash flows when impairment indicators exist. If an impairment exists, then the related assets are written down to fair value. 

Overall, Electronic Arts appear to report royalty related assets as “Other current assets” or other non-current assets on its balance sheet, not software assets. However, the language above, specifically, amortization of prepaid royalties and impairment analysis, appears to indicate that the assets are treated similar to treatment of external-use software. 

ASC 730, Research and Development has specific guidance related to advances which repayment depends on the results of the research and development activities, as detailed below (ASC 730-25-11):  

If repayment to the entity of any loan or advance by the entity to the other parties depends solely on the results of the research and development having future economic benefit, the loan or advance shall be accounted for as costs incurred by the entity. The costs shall be charged to research and development expense. 

The above treatment is consistent with examples reviewed above as well as the general treatment of funding of third-party software development activities as a software. 

Guidance relevant to external-use software provides additional requirements related to funded software arrangements and referring to ASC 730 (ASC 925-20-25-12): 

A funded software-development arrangement within the scope of Subtopic 730-20 shall be accounted for in conformity with that Subtopic. If the technological feasibility of the computer software product pursuant to the provisions of this Subtopic has been established before the arrangement has been entered into, Subtopic 730-20 does not apply because the arrangement is not a research and development arrangement. If capitalization of the software-development costs commences pursuant to this Subtopic and the funding party is a collaborator or a partner, any income from the funding party under a funded software-development arrangement shall be credited first to the amount of the development costs capitalized.  

Overall, the above guidance appears to suggest that funded software-development arrangements can be subject to ASC 985. However, the above guidance also appears to be written from the developer perspective, not from the perspective of a funding party. 

View 2: Financial Assets

As part of this view, investments into software development projects are considered financial assets, similar to debt or equity investments, e.g., investment in a promissory note or stock. In certain cases, the investor acts as a funding partner, rather than a partner actively involved in the development process. From this perspective, investor’s distribution rights may be viewed as similar to other financial rights, serving as a basis in the definition of a financial instrument. This view maybe further supported if an investor does not act as a traditional publisher of a video game, i.e., it does not distribute the game from its server or website. The investor may support certain marketing activities, i.e., by paying for game ads and public relation activities, intended to promote the game. 

US GAAP defines a financial instrument as follows (ASC 825-10-20, Glossary): 

Cash, evidence of an ownership interest in an entity, or a contract that both:  

  1. Imposes on one entity a contractual obligation either: 
    1. to deliver cash or another financial instrument to a second entity 
    2. to exchange other financial instruments on potentially unfavorable terms with the second entity. 
  2. Conveys to that second entity a contractual right either: 
    1. To receive cash or another financial instrument from the first entity 
    2. To exchange other financial instruments on potentially favorable terms with the first entity. 

Game development investments give contractual right to cash to the investor and obligate the investee, generally, a game developer, to share contractual proceeds with the investor. The investee may share previously collected proceeds when the investee acts as a publisher. In cases when the investor acts as a publisher or game distributor, the arrangement still conveys contractual right to cash and imposes contract obligation to delivery cash by virtue of granting the investor the right to collect gross proceeds, withhold its own share and imposing the obligation to remit the remaining share to the game developer. Based on this view, investments are considered financial instrument. More specifically, from the investor perspective, the investments may be considered a financial asset, as defined in ASC 825-10-20, Glossary 

Accounting treatment for investments that was considered a financial asset may involve consideration consolidation or equity accounting guidance per ASC 810 and ASC 323-10, respectively. 

The investors raised a question of what accounting guidance would apply to the financial assets, i.e., ASC 310, Receivables, ASC 320, InvestmentsDebt Securities, ASC 321, Investments- Equity Securities, ASC 325, Investments- Other. 

Application of either ASC 321 or ASC 310, i.e., equity or debt related guidance, respectively, depends on the nature of the investments in question. If the investment is considered equity-like, ASC 321 appears to be more appropriate, while ASC 310 would be more applicable to debt-like investments.  

If the investments in question are classified as debt-like, cash proceeds received from the payer are recorded as a settlement of the receivable balance, i.e., by debiting cash and crediting the carrying amount of receivable. If the investments in question are classified as equity-like, cash proceeds received from the payer are recorded as an investment income, i.e., by debiting cash and crediting investment income as reported in the income statement, similar to dividends. 

If an investment does not meet the definition of a security per ASC 321-10-20, it does not necessarily exclude the investment from the scope of ASC 321. Non-security equity interest or ownership interest is within the scope of ASC 321 provided that the investor is not required to consolidate the issuer in accordance with the guidance in ASC 810 or account for the ownership interest using the equity method of accounting. The scope of ASC 321 includes investments in equity securities and other ownership interests in an entity, including investments in partnerships, unincorporated joint ventures and limited liability companies.  

Generally, equity investments represent a residual interest in an entity. Terms or features that are not consistent with a residual interest in the issuing entity would most likely be considered equity-like. Otherwise, the relations between the investor and the investee may be more akin to a debtor-creditor relationship than to an ownership relationship. Most common debt investments, e.g., loans carry creditor rights including investor’s ability to seek recourse in a bankruptcy court. 

Master Glossary of ASC 320, Investments- Debt Securities defines a debt security as any security representing a creditor relationship with an entity and provides examples of instruments that meet this definition. The guidance also lists certain instruments that are not considered debt securities. The definition of debt security in ASC 320 includes instruments beyond the legal form of debt. For example, preferred stock that is either mandatorily redeemable or redeemable at the option of the investor is considered a debt security under ASC 320, even though preferred stock is considered an equity security in legal form. 

According to ASC 321, an equity security is any security representing an ownership interest in an entity (e.g., common, preferred, other capital stock) or the right to acquire (e.g., warrants, rights, forward purchase contracts, call options) or dispose of (e.g., put options, forward sale contracts) an ownership interest in an entity at fixed or determinable prices. 

U.S. GAAP provides substantial amount of guidance relevant to equity vs. liability classification from issuer or investees perspective. Limited guidance is provided from investor’s perspective.  

We believe guidance provided in ASC 480, Distinguishing Liabilities from Equity and ASC 815-15, Embedded Derivatives may be relevant to making the determination if the investments should be considered debt-like or equity-like. However, ASC 480 applies to issuers of financial instruments, not investors (ASC 480-10-10-1). ASC 815-15 guidance applies to both issuers and investors or holders of financial instruments as illustrated by the guidance in ASC 815-15-25-11. However, the nature and results of ASC 815-15 application may vary depending on whether the guidance applies to issuers or investors, as illustrated in ASC 815-15-25-20. 

Debt vs. equity classification guidance provided in ASC 815 applies to hybrid financial instruments with an embedded derivative to determine if the host instrument is considered debt or equity. The guidance is used to apply clearly and closely related criterion used to bifurcate the embedded features. Therefore, ASC 815 guidance can only be applied to game development investments by analogy.  

Appendix A Debt and Equity-Like Characteristics illustrates which characteristics of a financial instrument are generally more equity-like or debt-like based on the guidance provided in ASC 815-15-25-17D. 

We believe that View 1 or software approach is a preferred method of accounting of funding provided by investors to third-party game developers. This conclusion is based on the fact that it is supported by U.S. GAAP and is consistent with existing accounting practices followed by U.S. game publishers. View 2 or considering funding provided to third-party game developers as financial assets is not contrary to existing U.S. GAAP but is not widely adopted in the U.S. Application of the financial instrument will also require additional analysis of whether the instrument should be classified as debt-like or equity-like. 

Reporting entities should carefully analyze relevant contract terms and consult their advisors to establish proper accounting treatment. 

External Use vs. Internal-Use

U.S. GAAP provides additional guidance used to determine if a software is considered an external-use subject to ASC 985 or internal-use, subject to ASC 350-40. According to ASC 985-20-15-5: 

The software subject to a hosting arrangement is within the scope of this Subtopic only if both of the following criteria are met: 

  1. The customer has the contractual right to take possession of the software at any time during the hosting period without significant penalty.
  2. It is feasible for the customer to either run the software on its own hardware or contract with another party unrelated to the vendor to host the software.

For purposes of criterion a. above, the term significant penalty contains two distinct concepts: 1. the ability to take delivery of the software without incurring significant cost and 2. the ability to use the software separately without a significant diminution in utility or value (ASC 925-20-15-6). 

If the software subject to a hosting arrangement never meets the criteria in paragraph 985-20-15-5, then the software is utilized in providing services and is not within the scope of ASC 985 and, therefore, the development costs of the software should be accounted for in accordance with ASC 350-40, covering internal-use software.  

Hosting arrangement is defined as an “arrangement in which an end user of the software does not take possession of the software; rather, the software application resides on the vendor’s or a third party’s hardware, and the customer accesses and uses the software on an as-needed basis over the Internet or via a dedicated line.” (ASC 985-20, Glossary). 

Note that ASC 985 classification is specifically based on whether the software can be downloaded by the customer, not by the investor. Most investors do not acquire IP rights and do not take possession of the software code, instead, investors own distributor’s or, sometimes, publisher’s rights.  

We understand that in most cases, customers download the game to its hardware. In these cases, the software satisfies the definition of external-use software per ASC 985-20-15-5 and, therefore, is subject to ASC 985. In other cases, involving online hosted  games, the software in question will be subject to ASC 350-40. The rest of the publication is written assuming the software in question is considered external-use. 

Conclusion. Investments in software development projects may be considered a software (View 1) or a financial instrument (View 2). First view is supported by the main goal of the project investment, being development of a marketable software product, with a risk and reward profile similar to a software development project. Although most investors do not “own” the IP rights and may own distribution rights, the lack of ownership rights does not prevent application of the software guidance. View 2 is supported by the fact that economic characteristics of the investments meet the definition of a financial instrument. View 2 is also supported by the nature of the investment and investors role, which may be limited to being a financing partner.  

We believe that View 1 or software approach is a preferred method of accounting of funding provided by investors to third-party game developers. The accounting treatment based on View 1 is supported by U.S. GAAP and is consistent with existing accounting practices followed by U.S. game publishers. View 2 or considering funding provided to third-party game developers as financial assets is not contrary to existing U.S. GAAP but is not widely adopted in the U.S. Application of the financial instrument treatment will also require additional analysis of whether the instrument should be classified as debt-like or equity-like. 

When end-users (gamers) can download the game to its hardware, the software satisfies the definition of external-use software per ASC 985-20-15-5 and, therefore, is subject to ASC 985. In other cases involving online hosted  games, the software in question will be subject to ASC 350-40, i.e., the guidance applicable to internal-use software. 

Question 2: What accounting treatment should be applied to the Investor’s financing provided to third-party game developers and classified as external-use software?

Initial Recognition

Initial software capitalization guidance is based on certain stages in the software development process, including pre and post technological feasibility stages. 

According to ASC 985 -20-25- 1, all costs incurred to establish the technological feasibility, as defined, of a computer software product to be sold, leased, or otherwise marketed are considered research and development costs. Those costs shall be charged to expense when incurred as required by ASC 730-10. 

The technological feasibility of a computer software product is established when the developer has completed all planning, designing, coding, and testing activities that are necessary to establish that the product can be produced to meet its design specifications including functions, features, and technical performance requirements (ASC 985 -20-25- 2). The above guidance is also consistent with ACS 730-25-11 covering advances related to research and development activities. Establishing of the technological feasibility of a product requires management judgment. 

ASC 985-20-25-2 stipulates two approaches to establishing of the technological feasibility. One is based on completion of a detail program design, as defined. The other one depends on a working model, as defined. 

According to detail program design approach, the technological feasibility of a computer software product is established when the entity has completed all planning, designing, coding, and testing activities that are necessary to establish that the product can be produced to meet its design specifications including functions, features, and technical performance requirements.  

When development of software involves preparing a detail program design, technological feasibility is established by all of the following (ASC 985-20-25-2 par. a.): 

  1. The product design and the detail program design have been completed, and the entity has established that the necessary skills, hardware, and software technology are available to the entity to produce the product. 
  2. The completeness of the detail program design and its consistency with the product design have been confirmed by documenting and tracing the detail program design to product specifications. 
  3. The detail program design has been reviewed for high-risk development issues (for example, novel, unique, unproven functions and features or technological innovations), and any uncertainties related to identified high-risk development issues have been resolved through coding and testing. 

If the process of creating the computer software product does not include a detail program design, the technological feasibility is established by all of the following: 

  1. A product design and a working model of the software product have been completed. 
  2. The completeness of the working model and its consistency with the product design have been confirmed by testing.

Detailed program designed is defined as a 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 (ASC 985-20-20, Glossary). 

Working model is defined as “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).” (ASC 985-20-20, Glossary). 

Costs of producing product masters incurred subsequent to establishing technological feasibility shall be capitalized. Those costs include coding and testing performed subsequent to establishing technological feasibility (ASC 985-20-25-3).  

Financing terms of game development projects link investor funding to developer completion of specific development milestones. The investor can use this information to determine when the technological feasibility is established.  

When the technological feasibility of the software product is established, all subsequent payments made by the Investor to a third-party developer should be capitalized as software development costs. Investor funding provided before establishing of technological feasibility is recognized as research and development expense. 

Capitalization of computer software costs shall cease when the product is available for general release to customers. Costs of maintenance and customer support shall be charged to expense when related revenue is recognized or when those costs are incurred, whichever occurs first (ASC 985-20- 25-6). 

Advances issued after the software is available for general release to customers, i.e., funding of marketing, maintenance and customer support activities should be expensed as issued. 

U.S. GAAP requirements related to establishing technological feasibility assume that software development process is performed in the sequential order sometimes referred to as a waterfall approach. In the waterfall approach a software project includes planning, designing, coding or development, testing and software release. Generally, expenses incurred period to development and testing stages are expensed as incurred. Only cost incurred in relation to coding/developing and testing activities are capitalized as part of external-use software.

Many companies follow a different approach to software projects. One of such approaches is referred to as an agile model. As part of this model, simultaneously carrying out activities such as designing, development and testing of different components or features of the software. Development and testing work on different features or software modules is done in short sprints. Identifying when the traditional activities attributable to the waterfall approach occur following the agile approach requires significant analysis and judgment. This will make application of GAAP guidance for capitalizing expenses more difficult. When following the agile method, demonstrating technological feasibility is likely to require the project team to do more planning and prepare more documentation. 

Subsequent Measurement

Capitalized software costs shall be amortized on a product-by-product or, investment-by-investment basis. The annual amortization shall be the greater of the amounts computed using the following (ASC 985-20-35-1): 

  1. The ratio that current gross revenues for a product bear to the total of current and anticipated future gross revenues for that product 
  2. The straight-line method over the remaining estimated economic life of the product including the period being reported on. 

At each balance sheet date, the unamortized capitalized costs of a computer software product shall be compared to the net realizable value of that product. The amount by which the unamortized capitalized costs of a computer software product exceed the net realizable value of that asset shall be written off. The net realizable value is the estimated future gross revenues from that product.

Conclusion. Funding provided to third-party developer prior to establishing of software technological feasibility is recognized as a research and development expense. When the technological feasibility of the software product is established, all subsequent payments made by the investor to a third-party developer should be capitalized as software development costs. Technological feasibility is established when the developer has completed all planning, designing, coding, and testing activities that are necessary to establish that the product can be produced to meet its design specifications including functions, features, and technical performance requirements. More specifically, technological feasibility can be established when the developer finishes complete and tested detailed program design or complete and tested working model, as defined in ASC 985-20. Capitalized software costs shall be amortized on an investment-by-investment or product-by-product basis. The annual amortization is the greater of the amounts computed using a) the ratio that current gross revenues bear to the total of current and anticipated future gross revenues and b) the straight-line method over the remaining estimated economic life of the product. Unamortized software costs are assessed for impairment by using the net realizable value approach at each balance sheet date. The amount by which the unamortized capitalized costs of a computer software product exceed the net realizable value of that asset shall be written off. The net realizable value is the estimated future gross revenues from that product. 

Appendix A*

Debt and Equity-Like Characteristics 

Feature Equity <- – – – –  – – – – -> Debt-like
Redemption Perpetual Puttable at holder’s option upon contingent event Puttable at holder’s option with the passage of time Mandatorily redeemable
Dividends Cumulative and, potentially, noncumulative participating  

Noncumulative fixed rate and, potentially, indexed variable rate

 

Cumulative fixed rate and, potentially, cumulative indexed variable rate
Voting Rights Votes with common on as-converted basis Votes with common on as-converted basis on specific matters Votes only on matters related to the specific instrument Nonvoting
Covenants Does not include provisions that are substantively protective covenants Includes provisions that are substantively protective covenants
Conversion Rights Mandatorily convertible Optionally convertible Not convertible

 

 

*Based on the diagram provided in section 3.2.6.1.1 Weighing terms and features of EY Issuer’s accounting for debt and equity financings. 

 

FINACCO CONTACTS:

Nick Larchenko, Managing Partner 

646.713.4764 / nick.larchenko@finacco.org 

Polina Leudanskaya, Director- Accounting Advisory 

polina.leuda@finacco.org 

 


Important Note: FinAcco Consulting LLC is not responsible for, and no person should rely upon, any advice or information presented on this website. Note that entity’s financial statements, including, without limit, the use of generally accepted accounting principles (“GAAP”) to record the effects of any proposed transaction, are the responsibility of management. Therefore, any written comments by FinAcco Consulting LLC about the accounting treatment of selected balances or transactions or the use of GAAP are to serve only as general guidance. Our comments are based on our preliminary understanding of the relevant facts and circumstances and on current authoritative literature. Therefore, our comments are subject to change. FinAcco Consulting LLC does not assume any responsibility for timely updates of its website overall or any information provided in the Insights section of the website, specifically.