Engineering leaders don’t get into engineering leadership because they want to spend time thinking about balance sheets. However, there comes a time in every engineering leader’s life when a Slack message pops up from the CFO:
Hey, we’ve been looking into Very Important Tax Credit Scheme 123 and it looks like we’re able to capitalize some more costs from engineering. Do you think you could get back to me with a breakdown of your org’s work items and which category they fit into?
Cue panic. If you haven’t had a nightmare about software capitalization yet, this is about the time you might start.
But here’s the thing: understanding and being proactive about CapEx can make you a more effective leader and partner to the business, which is a win-win in our books.
The ability to capitalize software development costs is a powerful tool in your arsenal, and it can significantly improve how your company’s financial health is perceived by investors, shareholders and your teams — turning a year of heavy investment into a story of smart asset building, rather than a negative on the balance sheet.
When you expense software development costs (OpEx), the full cost hits your balance sheet immediately, potentially showing lower profitability even when you’re building valuable assets.
Capitalizing (CapEx), on the other hand, spreads the cost over time, matching expenses to the period when the benefits are realized.
If we take a $10M investment and expense it in the year it’s incurred, the balance sheet would show an immediate $10M loss. If you capitalize the investment cost, it may show (for example) a $2M loss annually over 5 years, while generating additional revenue from day one.
This might be easy for a factory that purchases a $10M machine that produces X number of widgets at $X, but for companies that build software, there’s a bit more grey area.
Regardless, as companies mature or prepare for funding rounds, IPOs, or audits, finance will inevitably ask engineering for capitalization data. Without preparation, this creates a fire drill of spreadsheets, guesswork, and developer interruptions.
Proactive engineering leaders (that’s you) establish capitalization processes before they’re urgently needed, earning credibility with finance and protecting your engineering teams’ flow.
While the tax benefits of capitalizing software development costs are nice (potentially 10-20% returned through various schemes), there are a few other benefits: it improves your EBITDA, gives a more accurate picture of profitability, and most importantly, better reflects the actual value being created by your engineering organization.
For growth companies, this can mean the difference between looking like a cash-burning operation versus a value-generating business.
Smart software companies (that’s you) use capitalization to demonstrate to investors that they’re building valuable assets, not just spending on operations. This distinction becomes important during fundraising, M&A discussions, or public market reporting. Companies that capitalize appropriately can show improved profit margins without changing anything about their actual operations.
There are risks of not capitalizing software costs, too — without proper capitalization, you’re risking:
Which are all pretty important risks to avoid. But how?
Common software development capitalization methods are basically the Vogon poetry of modern accounting. Messy, painful, and generally just not a good time. Many companies first try to approach it one of three ways:
What all three of these approaches have in common is inefficient processes. And in an engineering organization, that’s a problem. Processes that disrupt engineering workflows are bound to face either passive resistance or active rebellion.
Complex capitalization procedures often go unfollowed, which leads to incomplete data collection and breeds resentment. Engineers value autonomy and meaningful work; so administrative burdens that don’t contribute to product quality are met with minimal compliance at best.
Depending on where you are in the world, your approach to software capitalization will need to abide by the accounting framework that governs your region. And since we’re an international friendly bunch here at Swarmia, we’ll cover the international standards (IFRS) along with a few other geography-specific standards.
Despite their differences, however, all of the following standards share one thing in common: the view that costs that create future economic benefits should be capitalized and spread over the software’s useful life.
Still, understanding which approach applies to your organization is the first step in building a defensible capitalization approach.
As the name suggests, IFRS are a set of comprehensive standards used in over 140 countries. Their approach to software capitalization is set out in IAS 38 (Intangible Assets), which establishes a key distinction between the research phase (so exploratory, theoretical, and planning activities) and the development phase (applying those research findings to create commercially viable new products or features).
Research costs must be expensed, while development costs can be capitalized — but only after commercial and technical viability have been reached. So basically once it’s a legitimate product that customers could or would buy.
Under IFRS, you’ve got to demonstrate the following:
If you’re operating in the U.S. you’ll be looking towards the U.S. GAAP (Generally Accepted Accounting Principles) for guidance on software capitalization.
US GAAP tends to be more prescriptive than IFRS, with specific guidelines on when capitalization starts and stops. US companies must also consider ASC 606 (Revenue Recognition) when capitalizing costs related to cloud computing arrangements or SaaS implementations.
Within U.S. GAAP, there are a few standards that specifically apply to software companies:
If you’re north of the border, you can be sure of a few things: distance measured in kilometers, weird bacon, and favorable R&D tax credits for software companies.
Canadian companies follow one of two frameworks depending on whether they’re publicly listed:
Canadian companies should also consider the Scientific Research and Experimental Development (SR&ED) program, which offers tax credits of 15-35% on qualifying R&D expenditures. Importantly, SR&ED treatment is separate from capitalization decisions — so expenses can qualify for SR&ED regardless of whether they’re capitalized or expensed for financial reporting.
Not entirely unlike our Canadian counterparts, European Union member states require IFRS for public company consolidated financial statements, with the aim of creating consistency across the EU for listed companies.
However, individual EU countries may allow or require different standards for non-listed companies and standalone financial statements (we’ll cover a few of those in a moment).
The EU also offers various innovation-focused tax incentives that companies can take advantage of regardless of their capitalization decisions, such as “innovation box” regimes that provide reduced tax rates on income derived from patented technologies or innovative processes.
EU country-specific standards:
Post-Brexit, the UK continues to use UK GAAP (FRS 102) for most companies, with public companies and some larger entities using IFRS. FRS 102 Section 18 handles intangible assets similarly to IAS 38, requiring capitalization of development costs when technical and commercial feasibility is demonstrated. The UK offers two main R&D incentive schemes: the Research and Development Expenditure Credit (RDEC) for larger companies (providing a 20% credit on qualifying expenditures) and the SME R&D Relief (offering up to 230% deduction on eligible costs). Regardless of whether costs are capitalized or expensed, they may qualify for these incentive programs if they meet the criteria for R&D.
Finally, to Australia — an unassuming software company’s paradise where flat whites flow freely and one of the world’s most generous R&D tax incentive schemes awaits.
Aussie companies follow the Australian Accounting Standards Board standards (AASB), which are more or less the same as IFRS. AASB 138 mirrors IAS 38 for intangible assets, requiring the same distinction between research (expensed) and development (potentially capitalized) phases.
The Australian Tax Office offers the Research and Development Tax Incentive program, providing:
The R&D incentive interacts with capitalized development costs in an interesting way: companies that capitalize software development can either offset the R&D benefit against those capitalized costs or treat it as a government grant in their financial reporting. This gives Aussie software companies even more flexibility in how they present their financial position.
So now that we've covered the benefits of capitalizing software development costs and how the rules work in different parts of the globe, you might be wondering: Which of my engineering team's activities are actually worth capitalizing? Fear not — we’re about to get into the nitty gritty here.
If you’re running agile teams, capitalizing software costs might feel like trying to fit a square peg into a round hole.
Traditional accounting guidance assumes nice, neat phases of development — but your sprints blur the lines between research, development, and post-implementation faster than you can say daily standup.
The good news is that you can still capitalize agile work — the key is determining your unit of account: is it a single sprint, a group of interconnected sprints, or an entire epic? For simple features that ship independently, each sprint might qualify as its own capitalizable unit.
For complex features requiring multiple interconnected sprints, you’ll want to treat the whole group as one unit. Just remember that within each sprint, you’ll need to track which activities qualify for capitalization (typically the actual coding and testing work) versus what must be expensed (planning, maintenance, and bug fixes).
Yes, it requires some discipline in how you tag and track work — but with the right tooling that integrates with your existing workflow, you can capture this data without turning your developers into timekeeping machines.
Alright, now that we’re here, you might be wondering: what are they leading up to? — and, well… this is it.
At Swarmia, we built software capitalization capabilities because we kept hearing the same story from engineering leaders: they were burning days on manual reporting every quarter, disrupting their teams with timesheets, and still ending up with data their CFOs questioned.
Swarmia integrates with the tools engineers already use (GitHub, Jira, Linear) as well as your company’s HR system and automatically captures actual engineering activity without requiring manual entry or disrupting workflows.
Unlike timesheet-based approaches, Swarmia’s data comes from the actual systems of record for engineering work, providing a more accurate reflection of where time was spent. And rather than manually tagging each piece of work, you can set rules in Swarmia that automatically categorize work as capitalizable or not based on attributes in your issue tracker (labels, project tags, custom fields, etc.). This means you’re able to consistently apply capitalization criteria across your organization without requiring ongoing manual classification.
Swarmia goes as far as connecting commits and pull requests back to the issues they map to, creating a complete picture of engineering effort. This level of granularity and traceability is the key ingredient in audit-defensible capitalization since it shows which engineers contributed to which capitalizable features, and to what extent.
Lastly, you can generate detailed, audit-ready reports straight from Swarmia that provide clear visibility into what work was capitalized and why. These reports include the specific work items, the engineers who contributed, their level of contribution, the FTE amount, and how the work maps to capitalization criteria.
By this point, you well and truly know where your towel is, and you’re ready to start building the systems that will eventually make software cost capitalization a breeze. Here are a couple of things to keep in mind on the way:
Most engineering leaders wish they’d known three things about capitalization: start earlier (before it becomes urgent), recognize its significant financial impact, and avoid building complex tracking systems when existing engineering data could do the job.
The best approach for many businesses is simple: use automated systems that grow with your organization and make use of the data you already have.
Beyond just financial benefits, proper capitalization turns your engineering organization into a visible, value-generating asset factory. This shift in the balance sheet can positively impact budget allocations, hiring approvals, and your team’s strategic priorities across the organization.
Subscribe to our newsletter
Get the latest product updates and #goodreads delivered to your inbox once a month.
