ASC 350-40: Internal-use software capitalization, explained

Internal-use software development is one of the most common and least understood forms of capital investment. ASC 350-40 provides clear guidance on how these costs should be treated, but applying the rule consistently becomes harder as organizations scale, software projects expand, and development activities span multiple teams and reporting periods.

In practice, most challenges arise not from the accounting guidance itself, but from how software development costs particularly internal labor are captured, classified, and defended across development stages.

This page explains what ASC 350-40 covers, how capitalization works across the development process, and why clear, time-based labor documentation is essential for audits, financial reporting, and long-term confidence in financial statements.

What ASC 350-40 covers and why it matters

ASC 350-40 is issued by the Financial Accounting Standards Board (FASB) and forms part of the Accounting Standards Codification (ASC), the authoritative source of U.S. GAAP. The guidance applies specifically to internal-use software software developed or acquired to support a company’s internal operations, rather than software built for external customers.

Internal-use software includes internally developed software applications, configured platforms, and certain hosted or cloud-based solutions used to support internal business processes. For many organizations, these computer software projects represent a significant and recurring investment.

Whether software development costs are expensed immediately or capitalized as an intangible asset directly affects operating expenses, net income, and the balance sheet. As companies prepare for audits, interim and annual reporting periods, fundraising, or public filings, consistent application of ASC 350-40 becomes increasingly important—and that consistency depends on whether costs incurred can be clearly attributed to qualifying development activities and project stages.

At a glance

• Stage-based accounting: Costs are treated differently depending on the project stage
• Financial impact: Expense timing affects the income statement and balance sheet
• Documentation required: Development costs must be attributable to the correct stage and function

Key terms to know

Internal-use software
Software applications developed or acquired for internal business use rather than resale.

Internally developed software
Software built in-house or under a service contract for internal use.

Software development costs
Internal and external costs incurred while developing, configuring, or implementing internal-use software.

Capitalization criteria
The conditions under which eligible development costs may be capitalized rather than expensed.

ASC 350-40 provides the accounting model for applying these definitions consistently, but it does not prescribe how organizations should operationally capture the underlying development activities.

The three stages of internal-use software development

ASC 350-40 divides the development process for internal-use software into three project stages. Each stage has distinct accounting treatment and documentation requirements.

Stage 1: Preliminary project stage

The preliminary project stage includes conceptual design, evaluation of alternatives, feasibility analysis, and determining performance requirements.

Accounting treatment
Costs incurred during this stage are expensed as incurred and recognized in the income statement.

Practical challenge
Early planning often overlaps with development activity, making it difficult to clearly document which labor and external costs should remain expensed—particularly when significant development uncertainty exists.

Stage 2: Application development stage

The application development stage begins when management authorizes the software project and development activities commence. It includes coding, configuration, testing, data conversion, and direct labor associated with building the software.

Accounting treatment
Eligible software development costs incurred during this stage may be capitalized, provided they meet capitalization criteria. Capitalized costs are recorded as an intangible asset and amortized over the software’s useful life.

Practical challenge
Capitalization depends on whether development expenses especially internal labor can be clearly attributed to qualifying activities and specific time periods, rather than reconstructed after the fact.

Organizations need systems that capture CapEx vs. OpEx labor classification at the moment of entry, not months later during audit preparation.

Stage 3: Post-implementation stage

The post-implementation stage begins when the software is ready for its intended use. It includes training costs, maintenance, and routine upgrades.

Accounting treatment
Costs incurred during this stage are expensed as incurred. Certain software upgrades or enhancements may qualify for capitalization if they add additional functionality or represent a major feature and meet application development criteria.

Practical challenge
Without time-based documentation, implementation costs incurred after deployment are frequently misclassified or adjusted during audit or financial review.

Internal and external costs under ASC 350-40

ASC 350-40 applies to both internal costs (such as employee compensation) and certain external costs, including fees paid to vendors under a service contract, consulting arrangement, or hosting agreement—when those costs are directly related to qualifying development activities.

Costs related solely to ongoing support, training, or services that do not contribute to actual development must be expensed immediately.

Cloud computing and hosting arrangements

For cloud computing arrangements, capitalization depends on whether the arrangement includes a software license or qualifies as internal-use software under ASC 350-40. Costs related exclusively to hosting arrangements or service components are generally expensed, while capitalizable costs must meet the same development-stage and eligibility requirements as internally developed software.

ASC 350-40 and research and development expenses

Development activities involving significant uncertainty, exploratory research, or efforts to establish technological feasibility may fall outside ASC 350-40 and instead be treated as research and development expenses until feasibility is established. Determining where development transitions from R&D to capitalizable activity requires clear documentation of actual development work performed. Organizations claiming R&D tax credits face similar documentation requirements, making labor tracking essential for both compliance purposes.

Why ASC 350-40 is challenging in practice

The accounting guidance is clear. Execution is not.

Software development frequently spans multiple teams, timelines, and reporting periods. Engineers may work on capitalizable and non-capitalizable tasks within the same week. Without structured, time-based records, organizations are forced to estimate or reconstruct development costs after the fact—introducing risk during audits, financial reporting, and diligence.

Why labor documentation matters

Unlike vendor invoices or software licenses, labor costs are rarely self-describing. Accounting for internal-use software requires more than knowing how much was spent—it requires knowing what development activities occurred, when they occurred, and whether they qualify.

Clear labor documentation makes it possible to:

• Apply capitalization policies consistently
• Support audit and review requests with evidence
• Maintain confidence in reported financial statements

For many organizations, labor represents the largest and least defensible component of internal-use software capitalization.

Supporting ASC 350-40 with finance-ready labor data

ASC 350-40 does not require specific tools, but spreadsheets and retrospective analysis often break down as internal software investment grows. Labor cost visibility systems play a supporting role by:

• Capturing work as it happens
• Categorizing time by project and purpose
• Distinguishing capitalizable from non-capitalizable activity at the source
• Preserving approval history and audit trails

ClickTime does not determine capitalization policy or replace accounting systems; it operates upstream of them by providing the labor evidence those systems depend on and that auditors require. This allows capitalizable costs to flow into ERP and financial reporting systems supported by documentation rather than assumptions—especially when capitalized labor represents a material portion of internal software investment.

Preparing for ASU 2025-06

The shift introduced by ASU 2025‑06 will require updated accounting policies reflecting the clarified capitalization threshold, including assessments of management authorization, funding commitment, and the resolution of significant development uncertainty.

While ASU 2025-06 doesn't take effect until fiscal years beginning after December 15, 2027, organizations should begin preparing now. The shift from stage-based to principles-based capitalization criteria will require:

• Updated accounting policies reflecting the new "probable-to-complete" threshold
• Clear processes for determining when management authorization and funding commitment occur
• Documentation practices that capture when significant development uncertainty exists—and when it has been resolved through coding and testing
• Transition disclosures under ASC 250

Organizations with robust, time-based labor tracking systems will be better positioned for this transition. The underlying need—defensible records of who worked on what, when, and for what purpose—remains constant regardless of which accounting framework applies. Schedule a free consultation to see how ClickTime provides the clean, verified labor data you need.

‍