Grant Thornton - California State University, Northridge



Grant Thornton [pic]

GRANT THORNTON LLP Accountants and

Management Consultants

The U.S. Member Firm of

Grant Thornton International

May 5, 1997

Mr. Daniel Noll

Technical Manager

Accounting Standards, File 4262

AICPA

1211 Avenue of the Americas

New York, NY 10036-8775

Dear Mr. Noll:

We appreciate the opportunity to comment on the proposed Statement of Position (SOP), Accounting for the Costs of Computer Software Developed or Obtained for Internal Use.

We commend the efforts of the Accounting Standards Executive Committee in developing guidance on this issue, which has increasing significance for most entities. We support the overall conclusion presented in the proposed SOP that specified costs incurred in developing or acquiring software to be used internally should be capitalized as fixed assets, once the R&D phase of the project is completed. We have, however, comments and recommendations on aspects of the conclusions, which are discussed below.

Capitalization

We concur that the cost of computer software developed or purchased for internal use should be recognized as an asset, and to facilitate comparisons among entities, entities should not have the option to capitalize or expense such costs.

Theoretically, capitalized costs should not significantly exceed the cost of purchasing the software externally. This is particularly a concern for internal costs, but may also apply to external costs, We recommend that ACSEC consider including a provision that capitalization of costs cease if it is determined that costs incurred to date exceed the cost of purchasing the software externally.

In the section "Capitalize or Expense," it would be helpful guidance to state that if capitalization began and then, because of difficulties encountered or new information about other approaches; management changed paths and began development on a different path, that costs capitalized on the original project should be expensed. Management had not, in fact, completed the preliminary project stage when it began capitalizing costs.

We agree that the benefits of capitalizing specified costs of developing or acquiring software for internal use would exceed the costs, which are essentially the following record keeping costs:

▪ capturing external costs and categorizing them as R&D, costs of program instruction, implementation, post-contract support training, maintenance, upgrade/enhancements, etc.

▪ maintaining a project management system for internal costs to determine if the costs are part of the project, the phase of the project they relate to, and whether they should be capitalized or expensed

▪ maintaining information for interest capitalization

▪ maintaining fixed asset and amortization records

▪ testing for impairment when appropriate.

Amortization

Although specifying any maximum amortization period would be arbitrary, the guidance in paragraph 31 would be more effective if it included a presumption, or at least an observation, that the life should be short (because of the factors listed at the end of the first sentence).

Impairment

The guidance about following SFAS 121, Accounting for the Impairment of Long-Lived Assets and for Long-Lived Assets to Be Disposed Of, is useful and should be retained. This applies particularly to paragraph 29, which clarifies that a project that will not be completed and placed in service should not be accounted for under the impairment provisions of SFAS 121, but under the SFAS 121 provisions for fixed assets to be disposed of. To highlight the fact that this section addresses both impairments and disposals/ abandonments, we suggest changing the section title to "Impairment and Uncompleted Projects."

Paragraph 29 would be clearer if the sentence "The rebuttable presumption is that such uncompleted software has a zero fair value" were moved to follow the bulleted list.

Costs to Be Capitalized

Paragraph 16 presents a clear schematic of the stages of software development (preliminary project stage, program instruction stage, implementation stage), and paragraphs 19-23 address what costs are to be capitalized. Those paragraphs explicitly provide that capitalization does not begin until after the preliminary project stage is complete. It is clear from the context of those paragraphs the costs incurred in the program instruction stage are capitalized. Whether costs incurred in the implementation stage are capitalized is not explicitly state nor is it clear from the context.

It would be helpful if the language in paragraph 21 was more explicit. It now says that after the preliminary project stage, a project proceeds to the program instruction and implementation stages, during which an entity "is likely to" design, code, and implement the software. Is the meaning that these are the costs that should be capitalized? Paragraph 21 is a key paragraph in the proposed SOP that specifies the capitalizable costs. It should explicitly state in the terms of the stages identified in paragraph 16 what can be capitalized. Is it costs incurred in both the program instruction stage and the implementation stage, or only program instruction stage costs? Paragraph 23 states that capitalization should cease no later than the point at which a computer software project is substantially complete and ready for its intended use. Does implementation occur before or after the software is ready for its intended use?

The proposed SOP provides no definition or discussion of software implementation. It is a broad concept and is likely to be interpreted more or less broadly by different entities if no additional guidance is provided. As used in the proposed SOP, is implementation meant to include installation of the software throughout the entity, configuring it based on the hardware at each location, testing it in the company's environment, the cost of running parallel systems? The proposed SOP would be clearer and consistency in its application improved if a definition and/or examples of the intended meaning of implementation was provided.

Paragraph 19 implies that all software development costs that are not R&D costs can be capitalized. It should either be modified to state that certain costs of internal-use computer software should be capitalized or cross-referenced to paragraph 26 for costs that can be capitalized.

Paragraph 26 specifies costs that can be capitalized. Because of the narrow scope of the examples in the first two bullets, it is not clear whether, for example, travel costs incurred by employees in working on an internal software development project could be capitalized. Clearly travel costs for outside consultants would be capitaliz4 and it does not seem appropriate to determine capitalizable costs based on whether they are incurred by an employee or a consultant. Also, it is not clear whether the payroll costs of employees devoting significant time to the software project in capacities other than as software specialists (for example, an accountant working with a programmer to explain how certain computations should be made) can be capitalized. A few additional examples in those two bullets could clarify the implementation of the proposed SOP.

Determining if Software Is for Internal Use

The examples in Appendix A illustrating when computer software is for internal use are helpful in clarifying the intent of paragraph 42 and should promote consistent application of the proposed SOP.

However, there seems to be an increasingly important situation that is not addressed in the examples. We suggest addition of one or more examples that clarify whether software that gives customers access to an entity's services or products is internal use software. In effect, it may be software similar to that in a bank's automated teller machine (ATM), but is available to customers in situations such as the following:

▪ as a remote terminal (ATM) on the customers' premises as long as they remain customers (of the bank) or subscribers (for example, to an online financial news service)

▪ on the Internet, for example if the computerized catalog in Appendix A, example 16, is not sold to customers, but is put on the vendor's website so that customers can order over the Internet

▪ on their own computer systems, for example, software giving access to the broker-dealers' database in example 10.

Software for Internal Use and for Sale

We agree with the Exposure Draft's concept that software should either be for internal use or for sale. However, the guidance should result in accounting for the substance of the transaction, and this could be better accomplished by deleting the work solely from paragraph 11. A software project would continue to be accounted for as internal-use software only if two tests were met:

▪ the software is developed to meet the entity's internal needs

▪ no plan exists to market the software externally.

Omitting the word solely would avoid situations in which entities have historically been able to recoup a small portion of their cost of developing software to meet their own needs through, for example, sales to other entities in their region in the same line of business. If such incidental sales caused the entity not to be able to account for the software as internal use, it would prevent accounting for the substance of the transaction. Deletion of solely would not change the effectiveness of the two tests, but would make it more possible to conclude that efforts to recoup part of the cost of developing the software do not preclude accounting for it as internal use software.

We presume the intention of paragraph 11 is to limit use of the accounting for intemal-use software to projects that an entity does not plan to market. The second bullet states that "no plan exists to market the software." However, the next sentence describes a plan that is quite developed: "a selection of a marketing channel or channels with identified promotional, delivery, billing, and support activities." The paragraph could be understood to mean that if a fairly extensive marketing planning program is not in process during the period the software is developed, the software could be accounted for as internal use. We would suggest rewording the second bullet to say "During the software's development or modification, the entity has no plans to market the software" and deleting the first sentence following the bulleted list.

Disclosure

We recommend that the proposed SOP require the following disclosures:

▪ the estimated total project cost

▪ the amount capitalized to date, distinguishing between external and internal costs.

If significant internal costs are capitalized during an intemal-use software development project, it could cause substantial fluctuations of expenses between periods that need to be explained.

Other Comments and Suggestions

Paragraph 10 indicates that the accounting for costs for reengineering operations and for costs of converting data from old systems to new systems is excluded from the scope of this proposed SOP. We suggest that the scope of the proposed SOP be expanded to include the accounting for such costs.

Because paragraph 18 addresses the preliminary stage of a software project, we presume strategic decisions about allocating entity resources among projects would have already been made. It therefore seems more appropriate for the type of alternative illustrated in the first bullet to be, for example, whether to develop a new payroll system or to correct problems in the existing payroll system.

We suggest that paragraph 26 state that entities should use contemporaneous record keeping to determine the payroll costs to be capitalized as internal-use software.

Paragraph 61 states that capitalization should begin when management believes that it is probable that the project will be completed and the software will be used to perform the function intended. Management beliefs are difficult, if not impossible, to audit. We suggest that in both paragraphs 20 and 61 believes be changed to concludes. It would also be helpful if illustrations of indications of management reaching such a conclusion were provid4 such as budgeting funds to complete the project or minutes of board meetings where the decision was made.

We would be pleased to discuss any of our comments with the Task Force or ACSEC at their convenience.

Sincerely,

s/

Grant Thornton LLP

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download