Most startup founders don't think about accounting until they have to. Then they realize the software their team spent months building might actually belong on the balance sheet, not just the income statement. That distinction matters more than you'd think: it affects your burn rate, your tax position, and what investors see when they review your financials.
Getting the accounting right for capitalized software costs is one of those things that separates well-run startups from ones that scramble during due diligence. The rules aren't intuitive, and the line between "expense it now" and "capitalize it" can feel blurry. If your startup is building internal-use software or developing a product for sale, you need to understand these rules before your next close.
This guide breaks down the treatment step by step, covers the mistakes we see most often, and explains what changes as your software moves through its lifecycle. Whether you're a founder handling books yourself or working with an accountant, this is essential for early-stage startups spending real money on development.
Capitalized software costs are development expenditures that get recorded as an asset on your balance sheet rather than expensed immediately. The tricky part is timing: not all software spending qualifies for capitalization, and the rules differ depending on whether you're building software for internal use (ASC 350-40) or for sale to customers (ASC 985-20).
A startup encounters this decision the moment it begins paying developers to build a product or internal tool. Here's the high-level process:
The short version: you expense the research and planning. You capitalize the building. You expense the maintenance. Read on for the specifics that trip startups up.
The correct treatment depends on which standard applies. For internal-use software, ASC 350-40 governs. For software developed for sale or licensing, ASC 985-20 applies. Both share a core idea: costs incurred during certain development phases get capitalized as an intangible asset, not expensed.
Under ASC 350-40, you capitalize costs once the project passes the preliminary stage and enters the application development stage. That means management has committed to funding the project, it's probable the project will be completed, and the software will be used as intended. Qualifying costs include developer salaries, third-party contractor fees, and directly related overhead.
Here's what a sample journal entry looks like when you capitalize $50,000 in qualifying development costs:
| Debit | Credit | |
|---|---|---|
| Capitalized Software (Intangible Asset) | $50,000 | |
| Cash / Accounts Payable | $50,000 |
This entry increases your intangible assets on the balance sheet and reduces cash or creates a payable. You're not hitting the income statement yet. The expense hits later, through amortization, typically on a straight-line basis over the software's useful life (often three to five years for startups).
Once the software is substantially complete and ready for its intended use, you stop capitalizing and begin amortizing. Any costs after that point, like bug fixes, minor updates, and routine maintenance, are expensed as incurred.
For software built for sale under ASC 985-20, the capitalization trigger is different. You begin capitalizing after technological feasibility is established, which usually means you have a working model or a detailed program design. Costs before that point are R&D expenses.
Startups get this wrong in predictable ways. Here are the errors we see most often:
Capitalizing costs too early. Founders sometimes start capitalizing from day one of a project. Costs during the preliminary stage, like evaluating vendors, exploring alternatives, and determining requirements, must be expensed. Capitalization only begins once you've committed to building and entered the development phase.
Failing to separate maintenance from upgrades. After launch, not every dollar spent on software is an expense. If you add significant new functionality, those costs may qualify for capitalization. But routine bug fixes and server maintenance don't. Lumping everything together distorts your financials in either direction.
Ignoring impairment testing. Your capitalized software asset sits on the balance sheet at its amortized value. If the project gets shelved, the market shifts, or the software becomes obsolete, you need to write it down. Skipping impairment reviews means you're carrying a dead asset that misleads investors and auditors.
The lifecycle of your software project directly changes how you record costs. The trigger is the transition between development phases.
During the preliminary project stage, all costs are expensed. Once your team moves into active development (the application development stage under ASC 350-40, or post-feasibility under ASC 985-20), you flip the switch and begin capitalizing. This shift requires documentation: you need evidence that management authorized the project and that completion is probable.
The second major shift happens when the software is ready for use or available for sale. At that point, you stop capitalizing new costs and begin amortizing the asset. If you later decide to build a major new module or feature, that may restart capitalization for those specific costs. Abandoned projects require an immediate write-off of the remaining capitalized balance. Track these phase transitions carefully because auditors will ask for supporting documentation during any review or audit.
Not all accounting platforms treat complex transactions the same way. Here's what to look for:
Automatic phase tracking. Good software lets you tag costs to specific project phases so you don't accidentally capitalize preliminary-stage expenses. It should flag when a project transitions from development to production.
Amortization scheduling. The platform should automatically calculate and post monthly amortization entries once you mark an asset as ready for use. You shouldn't be creating manual journal entries every month for something this predictable.
Impairment alerts and audit trails. Your system should maintain a clear history of every capitalized cost, its associated project, and any adjustments. If an asset needs to be written down, the software should support that entry and preserve the documentation trail for your accountant or auditor.
Is capitalized software a debit or credit?
Capitalized software is a debit. You're increasing an intangible asset account on the balance sheet, which means it sits on the debit side. The offsetting credit goes to cash or accounts payable, depending on whether you've paid the vendor or developer yet. Think of it like buying equipment: you're recording something of value that your company owns and will use over time.
Is capitalized software an asset or a liability?
It's an asset, specifically an intangible asset. Capitalized software costs appear on the balance sheet under noncurrent assets. They represent future economic benefit to your company, whether that's a product you'll sell or a tool your team uses internally. The asset's value decreases over time as you amortize it, eventually reaching zero at the end of its useful life.
What happens if we abandon a software project midway through development?
If a project is abandoned, you must write off the entire remaining capitalized balance immediately. The unamortized cost moves from the balance sheet to the income statement as a loss. This can create a significant hit to your P&L in a single period, so it's worth flagging to your board and investors before it shows up in the financials.
Can we capitalize costs for software we build using open-source components?
Yes, but only the costs your team incurs during the application development stage. The open-source code itself has no cost to capitalize. Your developers' time spent customizing, integrating, and building on top of that code can qualify. Keep detailed time logs so you can separate qualifying work from general research or exploration.
How long should we amortize capitalized software?
Most startups use a useful life of three to five years, though the actual period should reflect how long you realistically expect to use the software. A rapidly evolving product might warrant a shorter amortization period. If the software's useful life changes after you start amortizing, you adjust the remaining amortization prospectively rather than restating prior periods.
Puzzle is the AI-native accounting platform built for startups and the firms that serve them. From SAFEs to stock comp, Puzzle categorizes complex transactions correctly the first time, with a clean audit trail your accountant will actually trust. Spend less time second-guessing journal entries and more time on the work that matters.
