The software capitalization question isn’t whether you can move qualifying software development costs onto the balance sheet. It’s whether you can defend why, when, and how much.
When you’re capitalizing software development costs, current EBITDA and net income may look stronger. That doesn’t mean the business created more cash or reduced its total cost. It means the expense moved into a later period through amortization, impairment, or both.
Start with the accounting model. Then test the project stage, the costs, the evidence, and the ownership behind the policy.
Key takeaways for CFOs
- Internal-use software, external-use software, SaaS implementation, and IFRS development costs follow different tests.
- Under ASC 350-40, preliminary and post-implementation work is generally expensed. Application development work may be capitalized.
- Under ASC 985-20, software intended for sale is generally expensed before capitalization is permitted.
- IAS 38 requires research costs to be expensed and development costs to be capitalized when all recognition criteria are met.
- Software capitalization can improve current EBITDA without changing cash generation.
- Your policy needs clear stage gates, direct cost rules, project evidence, and named owners.
Start by identifying the accounting model
Before approving a capitalization entry, ask what kind of software you’re accounting for. The accounting model determines the standard, the trigger, and when software capitalization can begin.
Internal-use software is a different question
Software developed for your own operations generally falls under ASC 350-40. This includes systems used by employees, internal platforms, and some software developed to support business operations.
The standard uses a project-stage model. Preliminary planning and evaluation are expensed. Eligible development work may be capitalized after the project moves into the application development stage. Training, maintenance, and post-implementation operations are generally expensed.
BDO’s ASC 350-40 guidance provides examples of how internal-use software costs are evaluated under US GAAP.
SaaS implementation costs need separate attention
Cloud computing arrangements are usually service arrangements, not purchased software assets. But implementation work can still create a capitalized asset under ASU 2018-15, which brought eligible cloud implementation costs into the internal-use software model.
Coding, configuration, customization, and testing may qualify during the implementation stage. Training and data conversion generally don’t. Capitalized implementation costs are usually amortized over the hosting arrangement’s term, often on a straight-line basis.
That asset may appear on the balance sheet even though the recurring SaaS subscription remains an operating expense. Make sure your contract review separates subscription fees, implementation services, configuration, migration, and ongoing support.
Ask when the project crossed the capitalization line
The most important date may not be the first invoice or the first sprint. It’s the date the project met the applicable accounting threshold.
Internal-use software has three practical stages
For internal-use software, ask your engineering and finance teams to identify:
- The preliminary project stage, when you evaluate alternatives, define requirements, and decide whether to proceed.
- The application development stage, when the team builds, configures, integrates, and tests the software.
- The post-implementation stage, when the system is ready for its intended use and the team provides support, maintenance, and routine operations.
The first and third stages generally produce expenses. The application development stage is where eligible costs may be capitalized. This stage-gate approach gives software capitalization a clear starting point.
Agile development makes this less tidy. A single sprint may contain new development, bug fixes, refactoring, security work, and user training. Don’t assign one accounting treatment to the entire sprint. Split the work by activity and stage, using a process that supports developer experience without unnecessary documentation.
FASB issued ASU 2025-06, which changes parts of the internal-use software guidance. Your accounting memo should reflect whether the update has been adopted, when it applies to your fiscal year, and how the transition affects existing projects. Deloitte’s 2025 FASB update is a useful starting point for that review.
External products and IFRS use different tests
External-use software intended to be sold, leased, or otherwise marketed to customers falls under ASC 985-20. The key threshold is technological feasibility. Costs incurred before that point are generally expensed. Costs after feasibility is established may be capitalized until the product is available for general release.
That test differs from the internal-use development threshold. You need evidence showing when the product became technically feasible, what remained to be completed, and when it was ready for release. PwC’s capitalized software guidance covers the distinction between these models. These distinct tests can produce different software capitalization outcomes.
Under IAS 38, research costs are expensed. Development costs are capitalized when all six conditions are met:
- Technical feasibility exists.
- You intend to complete the asset.
- You can use or sell it.
- Future economic benefits are probable.
- You have the resources to finish and operate or sell it.
- You can measure the attributable costs reliably.
If you report under IFRS, capitalization after the criteria are met is generally required, not an elective way to manage earnings.
Ask which costs are directly connected to development
A project label doesn’t make all software development costs capitalizable. Software capitalization requires a direct connection to qualifying development work.
Direct employee and contractor costs may qualify
Eligible costs under the applicable model can include employee compensation and related payroll costs for people who directly perform qualifying development activities. Fees for third-party contractors, external development services, and certain materials may also qualify when directly attributable to that work.
For a cloud implementation, direct configuration, customization, scripting, and testing may be included when they’re part of the qualifying development phase. Direct travel tied to the work may qualify under a consistently applied policy.
Your records need to show more than an employee’s department. “Engineering” isn’t enough. You need a reasonable basis for identifying the person’s qualifying work and the period when it occurred. Document resource allocation for shared engineers and other mixed resources.
Stock-based compensation and other payroll components can add complexity. Don’t assume every compensation category follows the same treatment. Have your controller and auditor confirm the policy before applying it across the engineering organization.
Maintenance, training, and mixed work need discipline
The following costs are commonly expensed:
- Preliminary research and project selection.
- Employee training.
- Data conversion.
- General administrative overhead.
- Routine support, maintenance and bug fixes after release.
- Ongoing hosting and subscription fees.
- Work that keeps an existing system running without adding functionality.
R&D tax credits require a separate tax analysis, so eligibility shouldn’t be inferred from the book treatment.
Refactoring needs judgment. Refactoring that only improves code quality or reduces maintenance burden may be an operating cost. Refactoring that creates new functionality during a qualifying development phase may support software capitalization.
Infrastructure work also needs to be separated. Recurring cloud usage, system administration, and support shouldn’t be swept into a development asset because the engineers supporting them sit on the same team.
Ask what software capitalization changes on the financial statements
Capitalization changes timing. The timing of software development costs doesn’t turn an expense into free value.
EBITDA and net income can move in different ways
During development, software capitalization usually reduces current operating expenses. That can increase EBITDA compared with immediate expensing, since qualifying costs aren’t recognized in the income statement at once.
Amortization is excluded from EBITDA under the usual definition, but adjusted EBITDA policies differ. Investors, lenders, and buyers may ask whether the adjustment reflects a real economic benefit or only a timing decision.
Net income may also improve during the capitalization period. Later, amortization expense reduces earnings. An impairment charge can create a larger expense if the software no longer provides expected benefits.
The balance sheet carries more intangible assets, or an implementation asset where applicable. Cash doesn’t change simply because the reporting presentation changes. Capital expenditures don’t automatically include every technology outlay. Your technology ROI story still needs operating evidence, such as faster delivery, lower support costs, better customer retention, or higher revenue capacity.
Useful life and impairment need an owner
For internal-use software, estimate the useful life based on expected use, replacement plans, technical obsolescence, and the business value the system provides. Amortization begins when the software is ready for its intended use, not when the first planning meeting occurs.
For SaaS implementation costs, amortization generally follows the hosting arrangement’s term. Review the term when contracts renew, terminate early, or change scope.
Your policy should also define how you identify impairment indicators. A failed implementation, abandoned product, major platform replacement, or sharp decline in expected benefits can require a new assessment.
Ask whether your agile process can survive an audit
Manual spreadsheets and blanket timesheets make an audit-defensible software capitalization process harder to maintain. They force engineers to reconstruct work after the fact and create weak evidence when projects change every sprint.
Use a small project taxonomy
An agile development workflow should protect developer experience and avoid retrospective accounting work.
You don’t need to ask developers to document every minute. You do need consistent project and activity records.
Create a limited set of accounting labels in the issue tracker. For example, you might distinguish preliminary work, qualifying development, SaaS implementation, maintenance, training, security operations, and post-implementation support.
Assign the label at the epic or ticket level. Add a project owner, start date, stage-gate date, expected release or go-live date, and resource allocation method for shared staff. Split mixed tickets when one part qualifies and another doesn’t.
Your IT strategy and roadmap should make these investment categories visible. A 12-month technology roadmap or one-page technology strategy can show which initiatives are build, run, security, maintenance, or technical debt work. That gives finance a better basis for reviewing capitalization and technology spend optimization.
Build evidence as the work happens
Each month, reconcile the capitalization schedule to payroll, contractor invoices, approved project records, sprint dates, and delivery milestones. Use Jira, GitHub, or another existing system as supporting evidence, not as a substitute for accounting judgment.
Keep records of:
- The business purpose and expected use of the software.
- The date each accounting stage began and ended.
- The employees and contractors assigned to qualifying work.
- The allocation method used for shared resources.
- Approval of the capitalization entry.
- Testing, release, or go-live evidence.
- Useful-life and impairment assessments.
KPMG’s 2026 software handbook addresses software, website, and related accounting questions that often appear in the same policy review.
The goal isn’t a perfect activity log. The goal is a repeatable record that another person can understand six months later.
Ask who owns the policy and the business story
Finance should own the software capitalization policy. Engineering should explain what the team did and when. The business sponsor should explain why the work matters. No single group can create a defensible answer alone.
Board technology reporting should connect software investment, delivery, risk, and business outcomes. A board-ready technology report doesn’t need every ticket. It should show major investments, resource allocation, spend, expected outcomes, owners, delivery risk, and changes in expected value.
If no one can connect the development schedule to the financial statements, you may have a technology leadership gap. The problem isn’t necessarily weak engineering. It may reflect unclear ownership across finance, engineering, operations, vendors, and the executive team. Clear decision rights can protect developer experience and keep accounting controls from disrupting engineering work.
This is where executive technology leadership can help. A fractional CTO or fractional CTO services engagement may fit when you need ongoing judgment without a full-time hire. An outsourced CTO, virtual CTO, or part-time CTO can provide a similar structure when decision rights and meeting cadence are clear.
An interim CTO or interim CTO services engagement usually fits a vacancy, failed initiative, or urgent stabilization period. A fractional CIO may fit when enterprise systems, data, and operations are the larger issue. A fractional CISO, virtual CISO, or interim CISO may be more appropriate when security evidence and cybersecurity oversight drive the concern.
The difference between a fractional CTO and an IT consultant matters. A consultant may deliver an assessment. An executive technology leader stays close enough to own decisions, reporting, and follow-through.
If your capitalization questions keep exposing unclear priorities, weak reporting, or scattered ownership, a focused Get an Executive Technology Clarity Check can help you identify what needs attention first.
A CFO’s pre-capitalization question set
Before approving a material software capitalization entry, ask:
- Which standard applies to software intended for internal use or software marketed to customers: ASC 350-40, ASC 985-20, or IAS 38?
- Which project stage was active when each cost was incurred?
- Which activities were directly attributable to qualifying development?
- What evidence supports the allocation and timing?
- What changes for EBITDA, asset balances, amortization, and impairment risk?
- Who approved the useful life, and who owns the next review?
- Can engineering, finance, and the board use the same explanation while protecting developer experience and keeping controls practical?
If the answer depends on a spreadsheet nobody trusts, the process isn’t ready.
Conclusion
Capitalizing software development costs can be appropriate. It can also create a misleading financial story when stage definitions, direct costs, useful lives, and evidence are unclear.
Your job as CFO isn’t to maximize the asset balance. It’s to ensure technology investment is classified consistently, tied to business purpose, and supported by records management, auditors, lenders, and the board can trust.
The strongest software capitalization policy gives you more than a compliant journal entry. It provides clearer visibility into technology spending, what that investment produces, and who owns the result.
FAQs about software development cost capitalization
Can all developer salaries be capitalized?
No. Only the portion tied directly to qualifying development activities may qualify. Time spent on planning, training, maintenance, support, or routine operations is generally expensed.
Is internal-use software treated like a product sold to customers?
No. Internal-use software generally follows ASC 350-40. External-use software sold, leased, or marketed to customers follows ASC 985-20, with different capitalization requirements.
Does capitalization improve cash flow?
No. It changes the timing of expense recognition, not cash generation or the underlying development cost. Review cash flow presentation under the applicable accounting guidance.
What should you do when the project contains mixed work?
Separate the activities. Use project labels, stage gates, allocation rules, and monthly reconciliation rather than applying one treatment to an entire sprint or engineering team.