Capitalizing Software Development Costs: ASC 350-40 for SaaS

What Is Software Development Cost Capitalization?

Software development cost capitalization records qualifying engineering spend as a long-lived asset rather than period expense, and ASC 350-40-15-2A sets the scope for SaaS.

This is a recognition question, not a valuation question. The cost is real and already paid. The only decision is whether it lands on this month’s income statement or on the balance sheet, amortized across the periods the software actually serves.

Most SaaS finance teams reach the right scope conclusion for the wrong reason. ASC 350-40-15-2A defines internal-use software as software acquired, internally developed, or modified solely to meet the entity’s internal needs, where no substantive plan exists to market it externally. A subscription platform sounds external. It isn’t. Deloitte draws the line at possession and infrastructure, applying ASC 985-20 where the software runs on the customer’s on-premise infrastructure and ASC 350-40 where it runs on your own infrastructure and is accessed online by subscribing customers (Deloitte’s software cost analysis for SaaS, cloud, and on-premise).

Four consequences follow from that scope call:

• The boundary is contractual, not commercial. ASC 985-20 governs only where the customer can take possession of the software at any time during the hosting period without significant penalty and can feasibly run it on its own hardware or with an unrelated host. Fail either condition and internal-use software accounting applies.
• The outcome gap is large. ASC 985-20-25-1 permits capitalization only after technological feasibility, which in practice sits near general availability, so most external-use development is expensed. ASC 350-40 has no feasibility gate and typically produces a materially larger capitalized balance.
• Hybrid vendors carry both populations. A company shipping an on-premise enterprise edition alongside its cloud tenant can hold development cost under two standards in the same period.
• Cash flow moves as well. ASC 230-10-45-13(c) classifies the capitalized spend as an investing outflow, so operating cash flow improves without a dollar of new cash arriving.

That last one is what a lender reads. Any covenant or board metric built on operating cash flow has to be read with the capitalization policy sitting next to it, the same discipline you’d apply to any other capital expenditure decision.

The ASC 350-40 Capitalization Framework

The ASC 350-40 capitalization framework gates recognition at ASC 350-40-25-12, which ASU 2025-06 rewrites for annual periods beginning after December 15, 2027.

Two frameworks are live at once. The legacy stage model governs every close until you adopt the update, so a policy refresh written in 2026 has to describe both and say plainly which one is running.

Under the model still in force, ASC 350-40-25-1 requires internal and external costs incurred before the capitalization criteria are met to be expensed as incurred. The gate itself sits in ASC 350-40-25-12, which historically required the preliminary project stage to be complete and management with the relevant authority to authorize and commit to funding the project, with completion probable.

Legacy stage	What it covers	Treatment	Authority
Preliminary project	Conceptual formulation, evaluation of alternatives, confirming the required technology exists, final selection	Expense as incurred	ASC 350-40-25-1
Application development	Design of the selected path, coding, installation to hardware, testing including parallel processing	Capitalize once the criteria are met	ASC 350-40-25-12
Post-implementation	Training, routine maintenance, bug fixes on shipped functionality	Expense as incurred	ASC 350-40-25-14

Capitalization stops at substantial completion. ASC 350-40-25-14 requires it to cease no later than the point the project is ready for its intended use, meaning after all substantial testing is finished. It can also stop earlier. ASC 350-40-25-13 requires that once the criteria in ASC 350-40-25-12 through 25-12A are no longer met, no further cost is capitalized and the impairment guidance in ASC 350-40-35-1 through 35-3 applies, a sequence laid out paragraph by paragraph in PwC’s full text of the amended subtopic.

The stage vocabulary is what the update deletes. Everything else in the machinery survives, which is why a policy built on the recognition criteria rather than on stage labels transitions cleanly in 2028. That’s the same instinct that makes GAAP accounting for startups durable instead of something you rebuild at every funding round.

Which Costs Qualify

ASC 350-40-30-1 enumerates the capitalizable categories, and ASU 2025-06 left that list untouched.

Cost	Treatment	Authority
External direct costs of materials and services, including contract engineers and third party build shops	Capitalize	ASC 350-40-30-1
Payroll and payroll-related costs for employees directly associated with the project, including salary, bonus, employer payroll taxes, benefits, and allocable equity compensation	Capitalize	ASC 350-40-30-1
Interest incurred while developing the software	Capitalize under ASC 835-20	ASC 350-40-30-1
Software that allows access to or conversion of old data by new systems	Capitalize	ASC 350-40-30-1
General and administrative costs and overhead	Never capitalize	ASC 350-40-30-3
Training, at any point in the project	Never capitalize	ASC 350-40
The data conversion activity itself, as distinct from the conversion software	Expense	ASC 350-40
Post-launch maintenance, bug fixes, and routine support	Expense	ASC 350-40

Two boundaries generate most of the audit friction.

Direct versus adjacent. A staff engineer writing the multi-currency billing service is direct. An engineering manager running sprint planning across six squads is closer to overhead, and the portion of that time not devoted to a specific qualifying project fails ASC 350-40-30-1 and gets caught by ASC 350-40-30-3. Product managers, designers, and QA can qualify to the extent their time is directly associated with the project, but the burden of showing that association sits with you. The contrast with external-use software is instructive, since ASC 985-20 permits capitalizing programmer overhead and dedicated hardware that ASC 350-40-30-3 prohibits outright (PwC on capitalizable software costs).

Enhancement versus maintenance. Upgrades and enhancements capitalize only where it’s probable the spend produces additional functionality. Refactoring, dependency upgrades, security patching, and incident remediation produce none. In an agile team those sit in the same sprint as capitalizable feature work, which is exactly why the allocation method has to be written down before the period it governs rather than reconstructed at year end.

What ASU 2025-06 Changes

FASB issued ASU 2025-06 on September 18, 2025, deleting the project-stage model from Subtopic 350-40 and replacing it with a single recognition threshold.

The original guidance assumed waterfall development. Agile teams don’t move through a conceptual stage once and a build stage once, they cycle through both every two weeks, which made the stage model close to unworkable. FASB named modernized software accounting a top priority coming out of its last agenda consultation, and the full text of ASU 2025-06 carries five changes worth reading before you set 2026 policy:

• Stages are gone. Every reference to the preliminary project, application development, and post-implementation stages is removed from Subtopic 350-40.
• One probable-to-complete threshold. Amended ASC 350-40-25-12 requires capitalization when management with the relevant authority authorizes and commits to funding the project, and it’s probable the project will be completed and the software used as intended.
• A significant development uncertainty screen. New ASC 350-40-25-12A says the threshold isn’t met while significant uncertainty exists, either because the software has novel or unproven features whose uncertainty hasn’t been resolved through coding and testing, or because significant performance requirements aren’t identified or keep being substantially revised.
• Website costs fold in. Subtopic 350-50 is superseded and absorbed, so marketing site work runs the same gate as platform work.
• Disclosure moves to Topic 360. Capitalized internal-use software follows the property, plant, and equipment disclosures regardless of where the balance sits on the face of the balance sheet.

ASC 350-40-65-4 makes the amendments effective for all entities for annual reporting periods beginning after December 15, 2027, and interim periods within them. There’s no split date for public versus private. Early adoption is permitted as of the beginning of an annual period. Three transition methods sit in ASC 350-40-65-4(c):

1. Prospective. The new threshold applies to costs incurred after adoption. Previously capitalized balances stay where they are.
2. Modified prospective. Prospective application plus derecognition of in-process projects that no longer qualify, through a cumulative-effect adjustment to opening retained earnings.
3. Retrospective. Comparative periods recast, with a cumulative-effect adjustment at the beginning of the earliest period presented.

Two of the three can write off in-process software, and that write-off flows straight through covenants built on tangible net worth, EBITDA, or total assets. Model all three before you pick one, and tell your lender before the covenant certificate does.

Amortization and Impairment

ASC 350-40-35-4 requires straight-line amortization unless another systematic and rational basis better represents the software’s use.

Amortization starts at the module level. ASC 350-40-35-6 requires each module or component to begin amortizing when that piece is ready for its intended use, regardless of whether the project ships in planned stages extending beyond a reporting period. If the billing engine goes live in March and the reporting module in July, you’re running two clocks, not one.

Useful life gets set and periodically reassessed under ASC 350-40-35-5 against obsolescence, competition, the rate of change in software products and operating systems, and whether management intends to replace technologically inferior software. Public SaaS filers cluster at three to five years. Run “capitalized internal-use software” through SEC EDGAR full-text search and the disclosures repeat: generally three years, generally three to five, three to four, with amortization frequently classified in cost of revenue rather than in depreciation and amortization.

Impairment runs through ASC 350-40-35-1 through 35-3, which supplies the indicator list and routes measurement to the long-lived asset model in ASC 360-10-35. The indicator that bites most often is simple. The software being used or developed is no longer expected to be of use. For software still in process, ASC 350-40-35-3 carries a rebuttable presumption that uncompleted software has a fair value of zero.

Half-built code is presumed worthless.

Rebutting that presumption almost never survives review, so a killed project is a full write-off rather than a haircut. ASU 2025-06 amends ASC 350-40-35-3 and expands the indicator list, which makes a standing quarterly review more valuable, not less.

SaaS-Specific Application

For SaaS, ASC 350-40-30-1 has to be applied to agile sprints, so the monthly engineering split runs on sprint data, not timesheets.

Growth-stage engineering orgs won’t adopt hourly timesheets, and forcing one is a good way to lose engineers. The workable alternative uses artifacts the team already produces. The Agile Alliance’s guidance on capitalizing agile labor costs describes exactly that, using story point allocation as the primary metric with sprint capacity and release backlog classification as support, specifically to avoid detailed individual timesheets.

A defensible monthly process runs in five steps:

1. Map issue types to treatment once, in writing. Feature stories tied to an authorized epic capitalize. Spikes, discovery, ceremonies, incident response, bug fixes on shipped functionality, dependency upgrades, and security patching expense. This mapping is the policy, and it gets signed before the period it governs.
2. Gate at the epic, not the ticket. The recognition unit is the software project. Attach the funding authorization and the probable-to-complete assessment to the epic and let tickets inherit treatment from it. That’s what keeps the process from collapsing under ticket volume.
3. Derive the ratio from closed work. Capitalizable story points closed in the period, divided by total story points closed in the period.
4. Apply the ratio to fully loaded engineering cost. Salary, employer payroll taxes, benefits, and allocable equity compensation. Exclude engineering leadership time not directly associated with a specific project, which ASC 350-40-30-3 keeps out.
5. Reconcile to payroll. Capitalized plus expensed engineering cost has to tie to the payroll register for the period. Auditors test that first.

Worked example. Twelve engineers at an average fully loaded cost of $16,000 a month puts engineering payroll at $192,000. Two sprints close. Of 640 story points completed, 243 sit on authorized, funded epics that clear the probable-to-complete threshold, a ratio of 38 percent. Capitalize $72,960, expense $119,040.

The monthly entry is Dr Internal-use software, in process $72,960, Cr Capitalized software costs $72,960, with the credit presented as a contra account inside research and development so gross R&D stays visible on the ledger. Board decks that quote gross R&D and financials that quote net R&D are a recurring source of diligence confusion. Label both.

Placed in service. The billing engine accumulates $547,200 over seven and a half months and clears final regression testing in month eight. Capitalization stops under ASC 350-40-25-14 and amortization begins under ASC 350-40-35-6. Book Dr Internal-use software, placed in service $547,200, Cr Internal-use software, in process $547,200. Straight line over a 36-month life is $15,200 a month, Dr Amortization of capitalized software, Cr Accumulated amortization.

Sunset. Twenty-one months in, the company migrates to a third party billing provider and retires the module. Accumulated amortization is $319,200 and net book value is $228,000. The software is no longer expected to be of use, an ASC 350-40-35-1 indicator, so book Dr Impairment loss on capitalized software $228,000, Cr Accumulated amortization $228,000. The trigger is the commitment to cease use, not the day the servers go dark.

The optics. Capitalizing doesn’t create value. It relocates cost. R&D operating expense falls this month and amortization returns the cost over the next 36. Whether it returns through EBITDA depends on one classification call. Amortization inside cost of revenue reduces gross margin and reduces EBITDA in later periods, making capitalization a timing shift. Amortization inside depreciation and amortization gets added back in a standard EBITDA calculation, making it a permanent flattering of the metric. Buyers and lenders normalize for this, and a Rule of 40 that reads 42 on reported numbers can read low 30s once capitalized spend goes back into the expense base. The revenue side of that same margin story runs on ASC 606 revenue recognition, and the two policies need to agree long before a data room opens.

Common Pitfalls

Most software capitalization errors trace to three paragraphs, ASC 350-40-15-2A on scope, ASC 350-40-30-3 on overhead, and ASC 350-40-25-14 on when to stop.

1. Scoping to ASC 985-20 because customers pay for it. Under a hosted subscription where the customer can’t take possession, ASC 350-40 governs even though the software faces customers. The mirror-image error is applying ASC 350-40 to a genuine on-premise edition the customer can run itself.
2. Capitalizing a flat percentage of engineering payroll. A fixed 40 percent with nothing underneath it is a plug, not an estimate. It fails the direct-association requirement in ASC 350-40-30-1, and it fails the auditor’s expectation that data supporting an estimate be tested for accuracy and completeness.
3. Capitalizing engineering management and G&A. ASC 350-40-30-3 prohibits it without qualification, including the finance and HR allocations some teams push into a project cost pool.
4. Never stopping. ASC 350-40-25-14 requires capitalization to cease no later than substantial completion. Continuing to capitalize post-launch iteration on a shipped feature is the single most common audit adjustment in this area.
5. Maintenance dressed as enhancement. Refactoring, performance tuning, and security work add no functionality. The label in Jira doesn’t control the accounting.
6. Not impairing on sunset. Carrying a dead module at book value because nobody told accounting the roadmap changed. Fixing it takes a standing link between product roadmap reviews and the close, not an annual sweep.
7. Assuming book capitalization drives the tax return. It doesn’t. Book follows ASC 350-40 while federal tax follows IRC Section 174A, added by the One Big Beautiful Bill Act, which permanently allows a current deduction for domestic research or experimental expenditures in tax years beginning after December 31, 2024. Software development remains an R&E expenditure under IRC Section 174(c)(3), foreign R&E stays on 15-year amortization under IRC Section 174(a)(2)(B), and Rev. Proc. 2025-28 sets out the elections and method changes. California doesn’t conform to Section 174 or 174A capitalization even after SB 711 moved its conformity date. Book capitalizes, federal tax deducts currently, and you carry a deferred tax liability, the same species of book-tax gap that shows up in deferred revenue tax treatment.
8. Assuming ASU 2025-06 makes capitalization easier. The mechanics get cleaner for agile teams, but the ASC 350-40-25-12A uncertainty screen can push the start date later for genuinely novel work. Work built on proven patterns may capitalize earlier. Work that’s unprecedented may capitalize later.
9. Retroactive documentation. Reconstructing the funding authorization and the probable-to-complete assessment in February for a project that started last March. The assessment is contemporaneous by nature, and an auditor can tell.

Items 4 and 6 are the ones a bookkeeping-only provider almost never surfaces, because catching them means reading the product roadmap alongside the ledger. Indinero’s CPA team reviews the capitalization schedule against the roadmap during monthly close, so a sunset gets caught in the quarter it happens rather than in the audit that follows it.

The Audit-Ready Standard

An audit-ready software capitalization file is an accounting-estimate file, tested under PCAOB AS 2501 and built on contemporaneous ASC 350-40-25-12 evidence.

AS 2501 defines an accounting estimate as a measurement involving subjective assumptions and measurement uncertainty, and directs auditors to give additional attention to potential management bias. When the auditor tests your process, the standard asks whether the method conforms to the applicable framework, whether the underlying data is accurate and complete, and whether the significant assumptions hold up individually and in combination. Translated into a document request list, the file contains:

1. A written capitalization policy naming the governing standard, the ASC 350-40 versus ASC 985-20 scope conclusion with reasoning, the unit of account, the issue-type mapping, the allocation method, the useful life and its basis, the income statement classification of amortization, and the impairment review cadence.
2. Contemporaneous funding authorization per project. A dated approval, budget line, or product council decision showing who held the relevant authority under ASC 350-40-25-12.
3. A probable-to-complete assessment per project. Short and dated. Under ASU 2025-06 it also has to address the ASC 350-40-25-12A uncertainty screen.
4. The monthly allocation schedule with source data. The sprint export, the point counts, the ratio, and the payroll reconciliation, pulled at the time rather than rebuilt at year end.
5. A placed-in-service memo per module, carrying the date, the evidence that substantial testing was complete, and the amortization start.
6. A quarterly impairment review mapping roadmap changes, deprecation notices, and sunset decisions to capitalized balances, with a conclusion recorded even when the conclusion is no indicators.
7. An annual useful life reassessment against the ASC 350-40-35-5 factors, plus an adoption memo covering the ASU 2025-06 transition method, its quantified effect, and any covenant communication.

Contractor-heavy teams add vendor statements of work that identify the project, because ASC 350-40-30-1 capitalizes external direct costs only where they’re consumed developing the software.

A correct capitalization number with no file behind it still generates an audit adjustment. The file is the deliverable. Indinero builds it during the year instead of assembling it when the PBC list lands, which is why audit preparation becomes a document pull rather than a reconstruction.

How Indinero Approaches Software Capitalization

Indinero treats ASC 350-40-25-12 as a monthly control, not an annual memo, because the recognition gate is a judgment somebody has to sign.

Software capitalization is where a bookkeeping-only provider stops being adequate. The classification rests on judgments a bookkeeper isn’t positioned to make, and the cost of getting it wrong surfaces at the worst possible moment, in the middle of a first audit or a Series C data room.

A CPA reviews the judgment every month. The accounting team at indinero is CPA-led, and every monthly close gets a GAAP-discipline review. For a client capitalizing software, that review is where the scope conclusion, the sprint allocation, the placed-in-service dates, and the impairment indicators get read by someone who has defended the position to an auditor before. You’re not just buying a capitalization schedule. You’re buying a position you can defend.

Book and tax sit in one engagement. The book-versus-tax gap on software development is one of the most error-prone areas in growth-stage finance right now, because Section 174A changed the federal answer in 2025 and California went its own way. Because indinero bundles accounting, business tax, and fractional CFO advisory inside a single engagement rather than selling them as carve-outs, the ASC 350-40 schedule, the federal position, and the California adjustment get reconciled by one team that can see all three. Run a separate bookkeeper, a separate tax preparer, and no controller, and the deferred tax mismatch turns up during diligence instead. Our SaaS accounting services are built around that single-team model, with a controller-level review sitting above the close.

The track record behind it. indinero has maintained continuous operations since 2009, serves 500+ regular customers, and carries 100+ years combined team experience. It’s SOC 2 compliant (2026) and holds a 5-star Clutch rating. Pricing starts at $750/mo, with month-to-month engagements available.

Your engineering split shouldn’t be something you reconstruct in February. It should fall out of a close that already asked the right question back in March. If that’s not your current experience, it might be time for a different approach. See how indinero’s accounting services handle software capitalization from the monthly close through your next audit, or reach out for a free consultation.

Frequently asked questions

Software capitalization questions cluster around the same handful of edge cases. Here are the ones controllers and VPs of Finance raise most often when they set or defend a policy.

Can a pre-revenue startup capitalize software development costs?

Yes, ASC 350-40 doesn’t condition capitalization on having revenue, because the probable-to-complete threshold in ASC 350-40-25-12 tests the project, not the company’s P&L. In practice, three things bite. A funding commitment is hard to evidence on four months of runway, going concern doubt undercuts a probable-completion assertion, and the ASC 350-40-25-12A uncertainty screen catches novel, unproven functionality. Expensing everything is often the correct answer at that stage, and that conclusion still needs a dated, contemporaneous memo.

How does the book treatment differ from the Section 174 tax treatment?

Book capitalizes under ASC 350-40 while federal tax deducts domestic software development currently under IRC Section 174A, so the two never agree. The One Big Beautiful Bill Act added Section 174A, restoring current deduction of domestic research expenditures for tax years beginning after December 31, 2024. Foreign R&E stays on 15-year amortization under IRC Section 174(a)(2)(B), and California conforms to neither. The result is a deferred tax liability, and indinero reconciles the ASC 350-40 schedule with the federal and California positions in one engagement.

What documentation supports a software capitalization policy?

A software capitalization file needs a written policy, contemporaneous funding authorization per project, a probable-to-complete assessment, and a monthly allocation schedule reconciled to payroll. Add placed-in-service memos per module, a quarterly impairment review, and an annual useful life reassessment against the ASC 350-40-35-5 factors. PCAOB AS 2501 requires auditors to test the accuracy and completeness of data underlying an estimate, and the sprint export is that data. Indinero builds the file during the year, so audit prep is a document pull.

Does capitalizing engineering salaries affect R&D tax credit eligibility?

No, capitalizing engineering salaries under ASC 350-40 is a book classification that doesn’t change qualified research expense eligibility for the IRC Section 41 credit. Section 41 eligibility turns on the tax rules for wages paid for qualified services, not on whether the wage was capitalized for book. What does interact is IRC Section 280C(c), requiring taxpayers claiming the gross credit to reduce domestic research expenditures by that amount. Indinero keeps the Section 41 study and the ASC 350-40 schedule with one team, so the two stay consistent.

When does ASU 2025-06 take effect and should we early adopt?

ASU 2025-06 is effective for all entities for annual reporting periods beginning after December 15, 2027, with early adoption permitted. ASC 350-40-65-4 sets no split date for public versus private, so a calendar-year company adopts January 1, 2028. Early adoption makes sense when the legacy stage model is forcing awkward sprint allocations or a first audit is coming, and it’s worth waiting when covenants are sensitive to the transition adjustment. Model all three ASC 350-40-65-4(c) transition methods, and tell your lender before the covenant certificate does.

, –