Amortization and Technological Feasibility

11.3 Amortization and Technological Feasibility

Amortization and technological feasibility are essential concepts when accounting for internally developed software and related R&D activities. Although at first glance these terms can feel like mere details in a broader technical accounting landscape, they greatly influence how development costs are recognized, measured, and presented in financial statements. From ensuring that costs are capitalized at the right time to articulating how they should be amortized, this section will help you navigate the complex financial and regulatory terrains associated with software development.

In this chapter, we build upon the foundational rules covered in Section 11.1 (Capitalization Rules: Internal-Use vs. External Sale) and Section 11.2 (Differentiating Research from Development). We will explore the concept of “technological feasibility,” how it triggers specific capitalization and amortization requirements, and how to track costs effectively throughout the software’s life cycle.

Importance of Technological Feasibility

Technological feasibility often acts as a critical milestone for software projects. In U.S. GAAP, especially for software intended to be sold or leased (governed by ASC 985-20), establishing technological feasibility is the pivot point that changes how costs are recognized:

• Before technological feasibility: Costs must generally be expensed as incurred.
• After technological feasibility: Many direct development costs can be capitalized.

For internal-use software projects, the relevant guidance is outlined in ASC 350-40. Technological feasibility, in such cases, is typically deemed to have been achieved once substantial program design is complete, and the organization has either a working model or can demonstrate that the software can meet its design specifications. Depending on whether the software is for internal use or external sale, nuances exist in assessing feasibility, but the overall concept rests on demonstrating a product’s viability under typical operating conditions.

Key Phases of Software Development

Software development often traverses distinct phases, each triggering different accounting treatments. By carefully delineating these phases, organizations can minimize the risk of overcapitalization or undercapitalization of costs. Though labels may differ from company to company, the following sequence provides a common roadmap:

• Preliminary Project Stage (Research/Planning): Includes brainstorming, feasibility studies, conceptual formulation, and evaluating technology alternatives.
• Application Development Stage (Development/Coding): Involves actual coding, building prototypes, and developing significant functionality.
• Post-Implementation/Operation Stage (Maintenance/Training): Encompasses training end users, performing minor upgrades, and ongoing maintenance.

For Software to be Sold or Leased (ASC 985-20)

Under ASC 985-20, costs incurred after achieving technological feasibility (but before the software is ready for sale) can generally be capitalized. Costs typically included in capitalized amounts are direct labor and certain direct overhead. However, if the project involves ongoing R&D for features outside the established technology blueprint, those additional costs may not qualify for capitalization.

For Internal-Use Software (ASC 350-40)

For internal-use software, the “preliminary project stage” costs must be expensed. Once the project enters the “application development stage,” many direct internal and external development costs (e.g., coding, software configuration, integration with existing systems) are capitalized. After the software is substantially complete and ready for its intended use, any subsequent costs mostly relate to maintenance, which must be expensed.

Establishing Technological Feasibility

Technological feasibility often involves meeting all technical specifications and having evidence that the software can perform as intended under normal operating conditions. While guidance may vary for internal-use and externally marketed software, organizations generally need evidence of:

• A detailed program design and significant progress in coding or programming.
• Confirmation via testing or working prototypes that the software can function as specified.
• The practicality of integrating the new software with existing systems and processes (for internal use).
• Plans for user acceptance testing, data migration, or other sign-off procedures that demonstrate readiness (for external sale, sometimes a beta release).

Below is a simplified flowchart outlining the transition from research phases through achieving technological feasibility to the commencement of the post-feasibility stage:

    flowchart LR
	    A["Research & Development Phase"]
	    B["Technological Feasibility <br/>Achieved"]
	    C["Post-Feasibility <br/>Development"]
	    D["Implementation &amp; Release"]
	    E["Amortization Period <br/>Begins"]
	
	    A --> B
	    B --> C
	    C --> D
	    D --> E

Organizations often rely on objective, documented criteria—such as passing an alpha test, completing certain performance benchmarks, or finalizing system architecture—to ensure consistency in identifying the feasibility date. This is crucial for accurate financial reporting, as misjudging this date can distort reported net income in the short term.

Tracking Costs Across Project Phases

Systematically tracking costs is essential for consistent, compliance-oriented accounting treatment. Below is an illustrative table that outlines how different costs may fall within specific development phases and how to account for them:

While every project’s cost structure is unique, appropriate tracking system or project accounting methods can help you allocate expenses to the correct phase. Strategies may include:

• Assigning unique project codes to each development phase.
• Implementing timesheet systems that allocate labor to differing phases.
• Requiring manager sign-off when transitioning from planning activities to full-scale development.

Amortization of Capitalized Software Costs

Once the software product is ready for its intended use or available for general release, amortization begins. U.S. GAAP generally requires using one of two methods for amortizing capitalized software costs:

• Straight-Line Method: Commonly used for internal-use software. The capitalized amount is amortized over the software’s estimated useful life, typically beginning when it is placed in service.
• Greater of Revenue Method or Straight-Line (for Software to Sell): Under ASC 985-20, for externally marketed software, amortization in a given fiscal period must be the greater of (a) the ratio of current gross revenue to total anticipated gross revenue over the software’s life or (b) the straight-line amount over its remaining estimated life.

In practice, the straight-line method is more common in internal-use scenarios as it reflects a fairly consistent consumption of benefits. For software intended for sale, the “Greater of Revenue” approach accounts for the economic reality that software often yields higher revenues in earlier periods. Applying the revenue-based approach ensures readers of financial statements see an amortization charge tied to the revenue streams generated by the software.

Example of the “Greater of Revenue” Method

Suppose an organization capitalized $400,000 of software development costs for an externally marketed software product with a total expected life of 4 years. The company anticipates total revenue of $2 million over that period:

• In Year 1, the software generates $600,000 in revenue.
• Ratio of current revenue to total expected revenue = $600,000 / $2,000,000 = 30%.
• 30% x $400,000 = $120,000.
• Straight-line over 4 years = $400,000 ÷ 4 = $100,000 per year.

In the first year, the company must use the higher figure: $120,000 based on the ratio, rather than the $100,000 from straight-line. If revenues dip in later years, the company might default to the straight-line figure when the ratio-based method produces a lower amortization amount.

Post-Feasibility Costs

Post-feasibility costs, those incurred after the point of technological feasibility (externally marketed software) or after the commencement of the application development stage (internal-use software), generally qualify for capitalization. These costs may include:

• Direct coding of new features initially scoped in the original project.
• Integration and specialized testing necessary to ready the software for commercial release.
• Certain direct overhead (e.g., the portion of the project manager’s salary specifically devoted to the ongoing development).

However, it is crucial to differentiate between original scope development and new R&D that extends the software well beyond its core functionality. For instance, if you decide mid-development to incorporate an advanced artificial intelligence module that was not contemplated in the initial project plan and requires separate R&D, associated expenses for that new module may need to be expensed until feasibility for that module alone is established.

IFRS vs. U.S. GAAP Considerations

Under IFRS (notably IAS 38 – Intangible Assets), the concept of research and development has some parallels, but the term “technological feasibility” is less formally used. Instead:

• Research Phase: Must be expensed as incurred.
• Development Phase: Costs can be capitalized if (and only if) certain criteria are met, including a demonstration of technical feasibility, intention to complete, and the availability of resources to do so.

While the IFRS framework provides for a similar “milestone” approach, it is more principles-based. Entities often demonstrate feasibility and the ability to complete a project by reference to similar GAAP triggers but enjoy more flexibility in applying IFRS-based judgments.

Best Practices and Common Pitfalls

Best Practices:
• Maintain Clear Documentation: Chronologically track key milestones, official sign-offs, operational tests, and user acceptance results that support your feasibility date.
• Leverage Consistent Criteria: Use the same approach across all projects, ensuring that feasibility is measured uniformly.
• Implement Cost-Tracking Technologies: Project management tools, enterprise resource planning (ERP) modules, and timesheet applications can automate cost allocation.

Common Pitfalls:
• Overlooking Minor Upgrades: Even small modifications after the software is in use are generally expensed unless they significantly alter functionality.
• Failing to Track Internal Labor: If your team’s labor is a significant component of development, you must track each hour spent pre- vs. post-feasibility for consistent treatment.
• Misapplying “Greater of Revenue” Amortization: Omitting or incorrectly forecasting total anticipated revenue can distort the amortization charge under ASC 985-20.
• Inconsistent Policies Across Projects: Applying different thresholds or definitions for feasibility can result in confusion, increased audit risk, and restatements.

Practical Scenario

Imagine a mid-sized technology firm, TechNova, developing a new data analytics application for sale. During the initial concept stage, the R&D team explores technology stacks, potential data visualization frameworks, and possible cloud integration solutions. Internal accounting processes systematically capture these costs as research expenses.

Two months into the project, TechNova finalizes the high-level design, invests heavily in coding, and confirms the software meets functional specifications in a controlled test environment. At that point, management documents a formal declaration that “technological feasibility” is established. All subsequent coding and testing costs related to originally conceived features become eligible for capitalization.

However, the team soon decides to include a programming library for real-time language translation. Since that was not part of the original plan, it triggers a separate, standalone R&D phase whose feasibility is unproven. Thus, costs specifically tied to that new feature remain expensed until the team can confirm the add-on library will meet user performance benchmarks.

Illustrative Journal Entries

Below is a simplified illustration of the journal entries for a software project to be sold to external customers:

• During preliminary phase (expensed):
Dr. Research Expense ……… 50,000
Cr. Cash/Accounts Payable… 50,000

• After achieving technological feasibility (capitalized):
Dr. Software Development (Asset) ……… 150,000
Cr. Cash/Accounts Payable……………… 150,000

• Commencing amortization upon general release (straight-line over 5 years):
Dr. Amortization Expense ……… 30,000
Cr. Accumulated Amortization……… 30,000

(If the greater-of-revenue method applies, the annual amortization expense would follow that calculation rather than a simple straight-line.)

Encouraging Continuous Learning

Keeping abreast of developments in software technology, project management best practices, and evolving accounting standards ensures you can identify capitalization opportunities accurately and measure your projects’ returns fairly. Collaboration with IT professionals and software engineers can provide invaluable insight into the actual stages of development, especially in ambiguous scenarios. Section 13.4 offers additional journal entry illustrations that can provide a more detailed understanding of how to translate theory into practice.

By following these guidelines, you can assure investors, regulators, and other stakeholders that your financial statements accurately reflect the economic reality of your software development endeavors.

Mastering Amortization and Technological Feasibility: 10-Question Quiz

For Additional Practice and Deeper Preparation

Business Analysis and Reporting (BAR) CPA Mock Exams

Business Analysis and Reporting (BAR) CPA Mocks: 6 Full (1,500 Qs), Harder Than Real! In-Depth & Clear. Crush With Confidence!

• Tackle full-length mock exams designed to mirror real BAR questions.
• Refine your exam-day strategies with detailed, step-by-step solutions for every scenario.
• Explore in-depth rationales that reinforce higher-level concepts, giving you an edge on test day.
• Boost confidence and minimize anxiety by mastering every corner of the BAR blueprint.
• Perfect for those seeking exceptionally hard mocks and real-world readiness.

Disclaimer: This course is not endorsed by or affiliated with the AICPA, NASBA, or any official CPA Examination authority. All content is for educational and preparatory purposes only.