Many organizations don’t think of software development as a core part of their business. But whether it’s a website redesign, a new ERP system, or internally built tools, most organizations are investing more in technology than ever before.
That's why FASB's recent amendment to the accounting for internal-use software is worth a closer look. FASB Accounting Standards Update (ASU) 2025-06 represents a welcome change to current GAAP. Going away is the outdated and difficult-to-apply "stages" framework that has long governed when internal-use software costs can be capitalized.
ASU 2025-06, issued in September 2025, is effective for calendar-year entities in 2028 (2029 for fiscal-year entities). Early adoption is permitted and may be beneficial for some organizations.
This standard is not just for software companies. Any organization (including nonprofits) with material internal-use software, such as websites or internal systems, is impacted. This change will affect how they evaluate and account for technology investments, how those costs are reflected in financial statements, and how prepared they are for audits, diligence, and transactions.
Importantly, the update does not change the accounting for software that is sold, licensed, or otherwise delivered to customers—it is focused solely on internal-use software.
“Internal-use software” is any software an organization builds, buys, or significantly modifies to run its own business, not to sell to customers. At a practical level, it’s any system your team uses behind the scenes to operate, manage, or improve your organization.
What Counts as Internal-Use Software
Common examples include:
What Does Not Count
Software is not considered internal-use if it’s:
The current GAAP model breaks internal-use software into three stages: the preliminary project stage, which covers planning, evaluation, and vendor selection; the application development stage, where the software is built, configured, and tested; and the post-implementation stage, when the system is live and ongoing maintenance and support occur. Costs incurred during the preliminary and post-implementation stages are expensed as incurred, whereas costs in the application development stage are capitalized as assets.
The challenge is that modern development makes it difficult to clearly define where one stage ends and another begins. Today, development is iterative, and systems are continuously updated, improved, and expanded.
The new standard addresses much of that ambiguity. It eliminates the rigid stage-based approach and replaces it with guidance that better aligns with how modern software is created and maintained.
Under the new standard, an entity begins capitalizing costs once management has:
In evaluating “probable to complete recognition threshold”, an entity is required to consider whether there is significant uncertainty associated with the development activities of the software. There are two main factors to consider:
In our experience, many organizations are not fully aligned with (or even aware of) current GAAP requirements in this area. That misalignment may go unnoticed until it matters most. These situations are often avoidable, but they start with awareness.
Properly accounting for internal-use software can directly affect how your organization is perceived. When those costs are not captured, organizations may unintentionally misstate their value. Capitalizing eligible costs places assets on the balance sheet, which can strengthen an organization’s financial position, particularly when:
A practical first step is to evaluate whether your organization has a documented policy for internal-use software and whether current practices align with existing GAAP.
Although the updated standard is not required to be implemented until 2028, early adoption is allowed and may make sense for some organizations, especially if:
Even if you do not plan to adopt the standard early, now is a good time to review how internal-use software costs are being tracked, evaluated, and documented.
This change brings GAAP more in line with how software is developed and used today. For many organizations, the bigger risk may not be the technical details of the standard, but assuming it does not apply.
In practice, internal-use software is often overlooked until it becomes a focus during an audit or transaction. Taking a proactive look now can help avoid surprises later and ensure your financial reporting reflects the full picture of your organization.
At Redpath, we partner with clients to help ensure their financial reporting reflects the full picture of their organization and supports long-term goals. If internal-use software has not been part of the conversation, it is worth revisiting.