Agile Software Development and CapEx/OpEx

Financial Goverance

An important financial governance concern in modern enterprises is how to expense costs properly.  This of course includes the costs of IT, including the costs associated with agile software development teams.  There is more to this of course than just adding up expenses, these expenses need to be categorized appropriately and in some cases can have a measurable impact on your bottom line.  In this blog posting we explore how to categorize agile software development costs into either capital expenses (CapEx) or operational expenses (OpEx).

Some Basics

Let’s begin with a few important observations:

  1. How you expense cost (and revenue for that matter) is driven first by accounting rules, such as Financial Accounting Standards Board (FASB) in the US, Accounting Standards for Private Enterprises (ASPE) in Canada, and International Financial Reporting Standards (IFRS) IAS 38 in general.  The implication is that CapEx/OpEx decisions in part are driven by geography.  At the end of this posting is an appendix summarizing these regulations.
  2. There are a few categories of expense, such as training and education (including coaching related expenses), which automatically fall into the operational expense category regardless of when they occur in the lifecycle.
  3. Where the appropriate accounting rules provide leeway, for example financial minimums for what to consider for capitalization, your corporate policy will need to guide you.  A common problem in established organizations is that some of this guidance was set before agile approaches were adopted and reflect waterfall-style governance.
  4. How you account for expenses is orthogonal to development paradigm.  It doesn’t matter what method the team follows, the actual capitalization rules remain the same.  The implication is that you need to determine how to apply these rules effectively for each paradigm, and as you’ll see even by lifecycle.
  5. This decision, or as we’ll soon show reporting activity, is typically the purview of Finance, not IT.  You really shouldn’t have to worry too much about this.
  6. You must engage the appropriate Finance, IT, and Audit people to ensure that everyone understands the implications of how you’re working and agrees to how you will approach accounting for expenses.

Why is This Important?

For publicly traded companies CapEx can potentially boost book value through the increase in assets (in this case a software-based solution) and increase in net income (due to lower operating expenses that year). On the other hand, OpEX is accounted for in the year that it occurs and thereby reduces net income which in turn reduces your organization’s taxes for that year.

How DAD Helps

As you can see in the appendix most of the rules for when to capitalize boil down to “start capitalizing when you know its real”, something that works well with DAD’s risk-based milestones.

Agile Software Development and CAPEX/OPEX

As you can see in the diagram, we’ve identified two potential points where you can start capitalizing software development costs:

  • Conservative: Stakeholder vision milestone.  This is the point which most organizations use as their CapEx starting point.  As you can see in the appendix, this milestone lines up perfectly with the regulations – you’ve made the decision to go forward with development, you’ve got a technical architecture strategy in place, you have an understanding of what you hope to produce, and so on.
  • Aggressive: Project/product team start. Some organizations will choose to start capitalizing at the very beginning of a software development project because they have effectively made the decision to move forward with the effort at that point, they know what the architecture is (due to a good understanding of their existing environment and technical road map), and due to their culture it is highly unlikely that they will cancel the effort.

Of course, there are a few more issues to consider:

  • You cancelled the project.  If you cancel a project (or release of a product) most organizations will choose to reverse their capitalization decision for any expenses incurred with that project/release.
  • You’re prototyping.  Prototyping, including time spent on proof-of-concept (PoC) or spikes, is usually considered to be an operational expense because it is a learning activity.  This is the case regardless of when in the lifecycle this work occurs.
  • Your team follows the continuous delivery lifecycle.  Teams following this lifecycle are in the Construction and Transition efforts all the time, so they’re effectively past the Stakeholder Vision milestone (the Conservative point) at all times.
  • Your team follows the exploratory/lean start up lifecycle.  Teams following this lifecycle are not yet at the point where they’ve made the decision to continue with development, and when they do so the typically kick into one of the other lifecycles anyway.  The implication, at least from a conservative point of view, is that these expenses should be operationalized.

Time Tracking

Needless to say, many developers, particularly agile ones, feel that time tracking is a waste.  Spending 5 minutes a week is ok, and to be quite blunt should be more than sufficient, but spending fifteen minutes or more a day doing so is far too much.  For CapEx/OpEx purposes you merely need to track broad categories of software development work such as Development, Prototyping, Vacation, and Training/Education.  These categories will be determined by the applicable accounting rules and should be kept to a minimum.

Our advice is to keep your time tracking strategy as simple as possible, make it very clear to everyone why it’s important to capture their time accurately, and do not use the data to directly measure individuals.  You may find the article Why Time Tracking Might Be the Most Valuable Activity an Agile Developer Performs to be an interesting read.  And, as you would expect from Disciplined Agile, we compare and contrast several Strategies for Tracking Time on Agile Teams.

It’s important to note that tracking time simply for CapEx/OpEx reasons is very hard to justify in practice due to the overhead that it injects plus the loss in team morale (nobody likes tracking time).  Another option is to simply track the amount of time that the entire team spends in a week and then assign a percentage of that time to each category.  This would require a slight amount of effort to track, likely something done by your Team Lead.

The Bottom Line

CAPEX/OPEX decision is fairly straightforward for teams that are following a Disciplined Agile Delivery (DAD) approach.  The team simply needs to keep track of important milestone dates (either the Project/Team Start date or the Stakeholder Vision acceptance date) and track their time in a few broad categories as described earlier.  If you do that, it’s a simple matter of running a report against your time data.


Appendix: What The Regulations Say

Disclaimer: You must read the actual regulations for yourself, what follows is just a summary and may become out of date overtime as the regulations evolve.


  • Internal and external costs incurred during the preliminary project stage shall be expensed as they are incurred
  • Internal and external costs incurred to develop internal-use computer software during the application development stage shall be capitalized
  • Costs to develop or obtain software that allows for access to or conversion of old data by new systems shall also be capitalized
  • Training costs are not internal-use software development costs and, if incurred during this stage, shall be expensed as incurred
  • Data conversion costs, except as noted above, shall be expensed as incurred
  • Internal and external training costs and maintenance costs during the post implementation-operation stage shall be expensed as incurred

International Financial Reporting Standards (IFRS) – IAS 38

You must be able to demonstrate ALL of following BEFORE you can START capitalizing costs:

  • Technical feasibility of completing the intangible asset so that it will be available for use or sale
  • Its intention to complete the intangible asset and use or sell it
  • Its ability to use or sell the intangible asset
  • How the intangible asset will generate probable future economic benefits. Among other things, the entity can demonstrate the existence of a market for the output of the intangible asset or the intangible asset itself or, if it is to be used internally, the usefulness of the intangible asset

Note: It is expected that FASB will recognise IAS 38 in 2016.

Canada – Accounting Standards for Private Enterprises (ASPE)

Based on ASPE, you must be able to demonstrate ALL of following BEFORE you can START capitalizing costs:

  • Technical feasibility of completing the intangible asset so it will be available for use / sale
  • Intention to complete the intangible asset and use / sell it
  • Ability to use / sell the intangible asset
  • Availability of adequate technical, financial and other resources to complete development and use / sell the intangible asset
  • Ability to reliably measure the expenditure related to the intangible asset during development
  • How the intangible asset will generate probable future economic benefits


Related Reading

Have any Question or Comment?

23 comments on “Agile Software Development and CapEx/OpEx

Allison Foster

This article is very helpful but I still have a question. if we are using agile development, should we capitalize or not? The projects are public and continually enhanced – we are going to end up with dozens of small assets so we are thinking we should either bundle up and capitalize on an annual basis or just expense.


Allison, you need to conform to the accounting laws of the country that you are operating in.

Daniel Serodio

What about bug fixes, shouldn’t them be expensed, since it’s a maintenance cost?


Yes, bug fixes are work so they should be expensed.

If the system in question is in sustainment mode then most likely this would be viewed as OpEx, unless the bug was so large that fixing it was considered to be a project in and of itself. If the solution is in development, for example the team is working on release 5 and release 4 is in production, then the work to fix the bug would be CapEx.


I understand training is opex but what about E-learning modules developed for giving training or showing product demo to customer. is this opex or capex?


Good question. Gut feel tells me that the development of the e-learning would be CapEx because it’s part of your overall solution. BUT, the actual time spent doing the learning/training would be OpEx if I’m not mistaken.


Thanks Scott. My view is that any expense pertains to training should be opex. I guess these training modules doesn’t have useful life or >year and so and the context of this will keep on changing and also product demo module which is more like selling and administrative expense in nature.


Good point. I didn’t realize that the training modules were short term things. If truly less than a year then they’re likely opex, but my advice is to read the regs to verify that.

Charmaine Lam

“Canada – Accounting Standards for Private Enterprises (ASPE)
Based on IFRS, you must be able to demonstrate ALL of following BEFORE you can START capitalizing costs”

Is that a typo? Did you mean ASPE and not IFRS?

May Lee

Thank You for the valuable information here.
I am thinking if possible to only count days spent for capitalized epics instead of hours?
User stories are not practiced in kanban. So it is hard to collect standard data across teams.
I thought of epic start date to epic end date multiply the cost of the team.
Thanks in advance if you are answering.


May, a few thoughts:
1. Counting days should work too.
2. Kanban doesn’t say a thing about user stories. You could choose to do user stories with Kanban if you like.
3. Not sure that tracking from the start to end date of an epic will actually follow the laws surrounding CAPEX/OPEX. I highly suggest that you read them.

Rob Kessler

You did not reference the FASB #86 document which says in the glossary that under the ‘Detail Program Design’ path (one of only two allowed) that “The detail design of a computer software product that takes product function, feature, and technical requirements to their most detailed, logical form and is ready for coding.
Isn’t the ‘ready for coding’ pretty explicit that capitalization can only include actual coding (and testing)? And this is what we’re currently using on our External Use software projects. Thank you.


That implies a serial approach, which was the predominant approach at the time. However, with many aspects of requirements and design occurring during construction it’s no longer that way. Unfortunately the regulations aren’t exact, which may actually be a good thing, so you need to interpret them reasonably and then follow through on your interpretation consistently.

Romeo J Gonzalez

Scott, If there is a warranty period to fix post project delivery bugs, Could this be included in the project cost and can this be capitalized ?


That’s a very good question. I’m not completely sure, but gut feel tells me that you would treat the warranty period an extension of development. So it would be a capital expense.

Romeo J Gonzalez

Thank you. A limited one month warranty period included in the original budget. Anything after that bill as support (Opex) .


Agile software development is becoming even more popular by the day. Under IAS 38, we use the SDLC Lifecycle (Research, development and Post Implementation) to help with determining Capex vs Opex of internal labour. How do we approach capitalizing an Agile project under IFRS in the developing phase where not all the time is spent on developing but some time spent on further research etc?


Tammy, good question. In Disciplined Agile this would be clear cut. Sounds like you’d be in the Construction phase so you’d likely be doing a spike or something similar. That would be CAPEX. Unless of course the research is significant enough to motivate you to spin off a team that takes an Exploratory lifecycle approach and that would likely be considered OPEX, but that assumes you’re making a go-forward (or not) decision at the end of the exploration.

Venkata Nanduri

What would the project cost being spent on deprecated/legacy software be? The company is planning to migrate off by end of next year, so, where would the incremental development expense on that software this year be?

Venkata Nanduri


This of course depends on the accounting laws under which your organization operates.

From the sounds of it, the advice in the article applies because it doesn’t matter what the type of the software is.

Tom Rogers

We’re wrestling with capitalization and Minimum Viable Product. Some in CFO are literally interpreting AICPA SOP 98-1 “placed in service” as “first user access” which comes in AGILE with the MVP. With MVPs shrinking as much as possible in AGILE, project value thresholds under our current CAPEX strategy will drive a declining CAPEX ratio. Subsequently, CAP Software credits on the income statement will also decrease resulting in higher current year IT expense and decreasing net profit.

The reflex response might be to lower thresholds to maintain the strategic CAPEX ratio, but that will inflate the project management admin burden in CIO which we are fighting to reduce as well. I thought that I had read in comments on your or similar articles that some CFOs were targeting later releases than MVP for capitalization. This would meet our current strategy standards without increasing CIO admin burden. Do you have any thoughts on disclosure statements or auditor discussions supporting such a policy?


Tom, interesting issue. Here are some thoughts:
1. I don’t have any sort of documentation from auditors or disclosure statements that I could share publicly.
2. Question for you: How are you using the term MVP? An MVP should be an experiment, something you use to learn what the market wants, not the “real system”. The “real system” would be a minimal marketable product (MMP). Short story if it’s a true MVP then no, if it’s an MMR (which is what I suspect you mean), then yes. BTW, in the next few days I hope to have a blog out about MVP vs. MMP vs…
3. BUT, new development on the next release of the system would now be back in CapEx land.
4. What’s more important to you as an organization? Spending the IT investment money wisely to support your business or your CapEx ratio? Agile leads to much better investment than traditional, better market competitiveness, …. Even if the CapEx ratio is changing who really cares compared to that?


Leave a Reply

Your email address will not be published. Required fields are marked *