Software Capitalization: CFO Guide to ASC 350-40 & ASU 2025-06

For most SaaS companies, engineering payroll is one of the largest costs on the income statement, and some of it may belong on the balance sheet instead. Which part qualifies, and from what date, is a judgment call your auditor will test. FASB's ASU 2025-06 also changes when capitalization starts, so a policy written under the old stage-based rules will need another look. Below, we'll go through what qualifies today and what changes under the new rules, then cover the entries and evidence that hold up in an audit.

‍

What is software capitalization? 

‍

Software capitalization records qualifying software costs as an asset, not an expense. Build and implementation costs go onto the balance sheet as an intangible asset and amortize over the software’s useful life, instead of reducing the profit in the period you spend the money. You spend the same amount either way. Capitalizing moves the earnings impact into later years.

‍

Two situations put software capitalization front of mind for a finance team. The first is building software you run yourself – it could be your internal systems, or a platform you sell to customers. The second is implementing purchased cloud software, where the SaaS license is a service contract but the implementation work may not be.

Both situations fall under ASC 350-40, the standard we’ll cover in detail later. ^[1] Neither situation gives you a choice about the accounting. The activity and its timing decide whether a cost capitalizes or gets expensed, and a wrong call in either direction is the type of thing an auditor picks up.

What costs can you capitalize? 

Capitalization depends on the activity and its stage. Coding, configuration, testing, and installation costs capitalize. Planning, evaluating alternatives, data conversion, training, and maintenance costs expense. ^[1] The dividing line is whether the work builds the asset itself or supports the people and processes around it. Upgrades that add functionality start a new build, so they capitalize too. ^[1]

‍

In the table below, each activity is mapped to a verdict – capitalize or expense – and the reason behind it. 

Capitalize vs. expense: which treatment to use and why

‍

Here are four things to keep in mind when you're deciding whether to capitalize or expense: 

‍

1. Direct payroll: This is usually the largest capitalized number, so it gets the most scrutiny. Salary, benefits and contractor fees capitalize for people doing the work that builds the software (coding, configuration, testing, installation). General overhead, recruiting, and administrative costs don't, even if you allocate a share of them to the project. ^[1]
2. Data conversion: The costs of cleaning and migrating old data are expensed. The exception is software written specifically to access or convert that data. That’s development work, so it capitalizes like any other coding cost. ^[1] Teams often bundle the whole migration into one capitalized number, but can't defend the split later if someone asks. Be cautious here.
3. Upgrades versus maintenance: New functionality capitalizes, but keeping existing functionality working expenses. ^[1] If your team ships weekly, upgrades and maintenance probably happen in the same sprint. This means you can’t treat the sprint as one decision. You have to look at each work item and ask whether it added functionality or kept the existing software running. 
4. Cloud implementation: The subscription itself is a service contract, so the fee is an operating expense. The cost of configuration and integration work can capitalize under ASU 2018-15 (cloud implementation costs), and the resulting asset amortizes over the term of the hosting arrangement (including any renewal period you are reasonably certain to use) rather than a standard 3-5 years. ^[2] That amortization is presented in the same income statement line as the subscription fee, not in a separate amortization line. ^[2] A long implementation on a short contract compresses the amortization. 9 months of build work on a 2-year subscription leaves 15 months to amortize over.

‍

One thing to note about the stage column in the table above: FASB's ASU 2025-06 removes those stage labels, so the point capitalization starts will change for annual periods beginning after December 15, 2027. ^[1] The treatments themselves mostly stay the same: development work capitalizes, and training and maintenance expense. If you're writing (or rewriting) a policy now, base it on the activity and keep the stage language out of it.

ASC 350-40: the rules for internal-use software 

ASC 350-40 governs accounting for internal-use software costs. That includes software you build to run your own operations and the SaaS platform you deliver by hosting, since your customers get access rather than a copy. The standard currently sorts a project into 3 stages and capitalizes only what happens in the development stage. ^[1]

‍

The current framework assumes a project runs in order through a preliminary project stage, an application development stage, and a post-implementation stage. The stage a cost falls into decides how you treat it.

ASC 350-40’s stages – and what each one allows

‍

ASC 985-20 is the other software standard, covering software you sell as a product a customer installs and runs. If your customers can’t take possession of the software and run it themselves (or have someone other than you host it), your platform is internal-use software, so ASC 350-40 applies instead. ^[1] This catches out a lot of SaaS teams, as their engineers are building the product the company sells. It’s important to get the standard right because ASC 985-20 blocks capitalization until technological feasibility, which arrives much later than the end of the preliminary stage. ^[3]

Cloud / SaaS implementation costs follow ASC 350-40 (per ASU 2018-15). The subscription stays an operating expense, and the configuration and integration work around it gets the internal-use treatment.

What's changing: FASB ASU 2025-06 

ASU 2025-06 removes the project-stage framework from ASC 350-40. Under ASU 2025-06, capitalization begins when management authorizes funding and completion is probable with no significant development uncertainty.^[1] FASB designed the new threshold to be neutral to how software is built, so it works for agile teams that ship in increments as well as for teams that move through phases. It takes effect for annual periods beginning after December 15, 2027. ^[1]

‍

FASB issued the update in September 2025. ^[3] The old framework assumed that software’s built in a straight line, but that hasn’t been the reality for several years. Many teams now build in short sprints, releasing and revising as they go, so a fixed sequence of stages is hard to apply.

‍

Removing the project-stage framework means that the start date is now, essentially, a judgment call. The judgment has two parts: management has to authorize and commit funding to the project, which is usually documented. After this, there's the probable-to-complete test – and that’s harder to back up with evidence.

‍

So what counts as "significant development uncertainty", anyway? FASB names two factors: the software has technological innovations or novel, unique, or unproven functions or features whose uncertainty hasn’t yet been resolved through coding and testing, or its significant performance requirements haven’t been identified or keep being substantially revised. ^[1] While either is present, you keep expensing. FASB expects capitalization not to change significantly for most types of software, but for software delivered through a cloud computing arrangement (which is what a SaaS platform is) it expects the amendments could reduce capitalization – the opposite of what many teams assume when they hear the rules are loosening up. ^[1]

‍

Website development costs move too. ASC 350-50 is replaced, and website work now follows the same ASC 350-40 rules as any other internal-use software. ^[1]

‍

Companies have three ways to adopt the update: apply the new rules prospectively to costs incurred from the adoption date on all projects (including in-process ones); take a modified approach that does the same but writes off, through a one-off adjustment to opening retained earnings, any capitalized costs of in-process projects that no longer qualify; or apply it retrospectively and recast prior periods. Early adoption is permitted as of the beginning of an annual reporting period, so there’s no need to wait until 2028. ^[1]

ASC 350-40 today vs. ASU 2025-06: a comparison

‍

Note: The effective date is annual reporting periods that start after December 15, 2027. For a calendar-year company, that means fiscal 2028.

Journal entries and amortization 

A capitalized software journal entry debits an intangible asset and credits cash, payroll, or accounts payable as qualifying costs accumulate. Nothing amortizes during the build. Capitalized software is amortized over its estimated useful life. Amortization starts once the software is ready for its intended use and runs on a straight-line basis, typically over 3 to 5 years. ^[4]

‍

Just a couple of dates decide most of the numbers in a capitalized software schedule. The first is when you start capitalizing. The second is when the software is ready for its intended use, which stops capitalization and starts amortization on the same day. ^[4] Costs incurred after that date follow the maintenance rules.

‍

Capitalization, amortization, and impairment entries (illustrative)

‍

Software amortization: If the capitalized software runs your product, the amortization usually sits in cost of revenue and pulls down your gross margin. If the capitalized software runs your back office, the amortization is an operating expense instead.

Useful life: What’s a reasonable useful life? 3 to 5 years is common – but it comes down to judgment. ^[4] A platform you rewrite every two years doesn't have a five-year life, whatever the policy says.

Impairment: Test the asset when a project’s abandoned, when functionality’s replaced, or when the expected life shortens. Abandonment is a regular impairment trigger at growth-stage companies, and it trips up teams that capitalized aggressively on a build that later got cancelled. An abandoned build’s whole remaining balance gets written off in one period, instead of spreading out like amortization; in other impairment cases the asset is written down to its fair value. ^{[1], [4]}

Why capitalization gets scrutinized

Capitalizing development costs increases current-period EBITDA and net income. The spend moves off the income statement and onto the balance sheet, where it unwinds slowly as amortization. Nothing about the cash changes. The gap between reported profit and cash out is the reason why auditors and investors watch capitalization policy closely.

‍

So does capitalizing software increase profit? In the current period: yes, and the effect can be large. A team of 30 engineers spending half their time on qualifying work, at a fully loaded cost of around $200,000 each, could move roughly $3 million a year out of operating expenses.

‍

The earnings benefit from capitalizing reverses over time. Amortization from this year's capitalized build shows up in every year of its useful life, on top of whatever you capitalize next year. Once the balance stops growing, the annual amortization charge catches up with the amount you're capitalizing and the reported margin flattens out.

‍

EBITDA is where the misalignment’s most obvious, because amortization never touches EBITDA. A company that expenses its development shows the cost, while a company that capitalizes shows almost none of it in the same line. The two aren't comparable without an adjustment.

‍

Sophisticated investors make that adjustment. Free cash flow already captures the spend: expensed development runs through operating cash flow and capitalized development shows up as an investing outflow, so it reaches free cash flow either way. A Rule of 40 built on EBITDA margin doesn’t capture it, which is why investors who use that version add capitalized development back before comparing companies.

‍

Book capitalization and the tax treatment of research costs follow different rules, so a change to one doesn’t automatically trigger a change to the other. Since the One Big Beautiful Bill Act, domestic research costs (software development included) are deductible immediately under new Section 174A for tax years beginning after December 31, 2024, while foreign research costs stay on 15-year amortization under Section 174. ^[5]

‍

Auditors look at capitalization from the opposite direction to investors. They test whether the costs you capitalized qualify, whether the time allocations are supported, and whether the useful life reflects how long you actually run the software. ^[6]

Tracking and controls: how to build the evidence that auditors want

Most teams get the accounting treatment right and lose the argument with auditors over evidence. To track capitalized software, you need to know which developer time went to qualifying work, on which project, in a form that an auditor will accept. While it’s easy and relatively quick to write a policy, proving that you followed that policy is much trickier.

‍

A defensible capitalization policy comes down to 5 things:

1. A written policy. Name what qualifies, the materiality threshold below which you expense, the useful life by asset type, and who approves a project for capitalization.
2. Time capture by project. Engineers need to book time against projects, and the categories in your tracker need to map to your policy, not to your sprint board.
3. The authorization file. Keep the management authorization, plus any evidence that supports completion being probable. ASU 2025-06 turns this into the start-date proof, so build the habit before you adopt.
4. Preparer and reviewer split. The person calculating the capitalized number shouldn't be the same person approving it.
5. A roll-forward every close. Run the capitalized-software asset forward each period – opening balance, additions, amortization, impairment, closing balance – and tie the closing figure to the GL.

‍

Start with a time-tracking method that your engineering team will follow, then tighten it. Auditors accept reasonable allocation approaches. What they won’t accept is numbers that appeared at year-end with no clear working behind them.

How an AI-native ERP handles software capitalization

An AI-native ERP applies your capitalization policy at the point costs are recorded, rather than at quarter-end. It tracks qualifying costs by project, posts the capitalized-software asset, and schedules amortization automatically. The roll-forward and audit trail come out of the same system.

‍

Consistency is the biggest difference you feel after switching from a spreadsheet-based system to a unified one. When your policy lives in one ledger, every project gets the same treatment, and the reason for each classification is automatically attached to the transaction. This supports a smoother close and audit – so you won’t need to scramble for answers if someone asks you why a particular sprint was capitalized.

‍

DualEntry is an AI-native ERP built for SaaS finance teams scaling past QuickBooks and spreadsheets through to IPO readiness, including those capitalizing internal-use software. It keeps capitalization as a consistent policy in your general ledger, so it stops being a spreadsheet exercise. 

‍

Capitalizing software is a policy you defend, not a loophole

Which costs capitalize isn’t about to change any time soon. Development work capitalizes. Planning and maintenance don't. What’s changing is the start date, and ASU 2025-06 comes into play for annual periods beginning after December 15, 2027.

‍

Capitalizing gives you higher earnings in the near term, but you pay for this in amortization (and scrutiny) later. The teams that come out of an audit cleanly are the ones who made that trade-off deliberately, wrote a clear policy down, and can show their work whenever an auditor, investor, or someone on the board asks.

‍

If you want your policy running in the ledger instead of a spreadsheet, talk to us about automating software capitalization. And for more on the cloud implementation side, check out our guide on what costs to expect.

Software Capitalization FAQs