ASC 350-40 software capitalization: a practical guide for engineering leaders

If you lead engineering at a US company, sooner or later finance will mention ASC 350-40. It is the accounting guidance that governs how costs to develop or obtain internal-use software are treated — whether they hit the income statement immediately as an expense, or sit on the balance sheet as a capitalized asset that is amortized over time. You do not need to become an accountant, but understanding the shape of the rules makes you a far better partner to finance, and it helps you set up Jira so the numbers are easy to produce.

This is a high-level orientation, not accounting advice. The standard has nuance, and it has recently changed.

The core idea: capitalize versus expense

The central question ASC 350-40 answers is when software development cost becomes an asset rather than a period expense. The intuition is that money spent building something with lasting future value should be recognized over the life of that value, not all at once. Costs that do not create a durable asset — planning, research, ongoing maintenance — are expensed as incurred.

Historically the guidance framed this around three stages of a project:

• Preliminary project stage. Conceptual formulation, evaluating alternatives, deciding what to build. Costs here are expensed.
• Application development stage. Designing, coding, and testing the software. This is the stage where qualifying costs are generally capitalized.
• Post-implementation / operation stage. Running, maintaining, and supporting the software after it goes live. Costs here are expensed, with limited exceptions for significant enhancements that add functionality.

The takeaway for an engineering leader is that what kind of work a ticket represents, and when in a project's life it happens, drives the accounting treatment.

What changed: ASU 2025-06

In 2025 the FASB issued Accounting Standards Update 2025-06, which modernizes the guidance for internal-use software within ASC 350-40. A significant motivation was that the older, rigid project-stage model did not fit modern, iterative, agile development well — software is rarely built in tidy sequential phases anymore.

Because this is a framework change with transition provisions and effective dates, the specifics of how it applies to your company depend on your facts and timing.

What this means for how you run engineering

Whatever the precise rules, the practical engineering implications are stable:

1. You need a clear signal of work type. New development versus maintenance versus research. This maps cleanly onto how you can tag work in Jira.
2. You need consistency. Accounting standards reward a rational, systematic method applied the same way every period far more than they reward heroic precision in any single period.
3. You need traceability. When an auditor asks why a number is what it is, being able to point to specific classified tickets is a strong position.

How Jira data supports the policy

You can operationalize a capitalization policy without timesheets by classifying tickets and allocating a known cost pool by the share of capitalizable work delivered. Delimetrics models this directly: it reads a capitalizable flag from your Jira Cloud issues and estimates CapEx as period cost multiplied by the capitalizable ticket share. See our deeper write-up on software capitalization from Jira and the broader framing of CapEx versus OpEx for software development.

The point of the tooling is not to replace your auditors' judgment — it is to give you and finance a fast, transparent, continuously updated estimate so the quarterly close is a confirmation rather than an archaeology project.

A sensible starting checklist

• Get your accounting team to write down which issue types and which kinds of work qualify under your policy.
• Add a single capitalizable custom field in Jira and default the obvious non-qualifying cases (bugs, support).
• Pick one team and one closed quarter, and reconcile the estimate against what finance booked.
• Document the method so it can be applied identically every period.
• Review the whole approach with your auditors before it informs reported figures.