The presentation explains financial capitalization as the practice of spreading the cost of long‑term investments over their useful life, using a bakery‑truck analogy to illustrate how a $50,000 truck is amortized as $10,000 per year. It then maps this concept to software development, where the intangible asset is the intellectual property created by new features or significant improvements. Capitalizable work is defined as the effort performed after a design is approved but before the software is released—essentially the coding, testing, and validation that builds the product. The speaker highlights why identifying and evidencing these costs is difficult in modern agile environments: development is nonlinear, contributions are one‑to‑many, and sprint‑based cycles blur the boundaries between design, build, and release. Traditional waterfall assumptions (fixed teams, clear timelines) no longer hold, making it hard to attribute time and labor to capitalizable activities. The talk stresses the need for systematic, automated data collection (e.g., linking issue trackers, time logs, code reviews) so finance teams can calculate capitalized R&D costs accurately and provide defensible documentation for audits.
Chapters
So to kick things off here, right, what is the capitalization of software development? To answer this question, I'd really like to first take a step back and answer the question of what is capitalization more broadly from a financial perspective. I'm going to avoid the lengthy financial definition that goes into details, the whys, the hows and things of that nature. And instead, just put it more simply, it's a way of handling investments into a business such that the cost of those investments that you're making into your business are really measured in a way that, that more accurately aggregates them or compares them to the actual benefits that you'll get from making that investment itself. All right, so let's put this into something that's a bit of an analogy. One of my favorite examples is this concept of like a bakery buying a delivery truck, right? And while you might buy a truck, let's say it's for $50,000 today, right, you're probably going to use that truck for the years to come, right? You shouldn't expect to have to buy that truck year over year over year, right? Instead, you might buy a truck, I don't know, let's say once every 5 years. And so when you look at your financial statements, you look at how you want to think about your spend and the net benefit or revenue that might come from buying that delivery truck, You shouldn't expect $50,000 a year. Instead, you should probably think about it more so as I need to spend in aggregate about $10,000 a year over the course of 5 years. And when you think about profit as one of the core measurements for a business, right, you shouldn't be comparing 2022's $50,000 for a truck and the next few years see no expenses against the revenue you're going to get from doing all those deliveries. Instead, you should think about, hey, the revenue minus about $10,000 a year. And it allows for the cost of these larger investments, these capital-intensive investments into your business to kind of look a bit more smooth and let people actually understand from a financial perspective, how, how are you really spending and how efficient is that spending as a business? Now, specific to software development, right? It gets a little bit trickier. Trickier, excuse me. You know, you think about the idea of buying a delivery truck, right? With software, right? Well, you could take the servers and the Ethernet cords and heck, maybe even the desk that the engineers are at when they're developing code, and you could stuff all of that into a delivery truck and, and you could think about moving it places. What you can't stuff onto that truck or, or strap it to the back of a flatbed is really the IP that you're developing with that software, right? And so we think of this as like an intangible asset. There are things that you can't put your hands on. There are things that are more intellectual IP, but you are spending a lot and trying to build out new features or new assets or investments into your business. What these really are characterized as, you can think of them as new products or significant improvements to your software, right? If I can go back to that bakery analogy, right, a new product might be the idea of adding a delivery truck, whereas a significant improvement might be the idea of putting an addition on your shop or maybe refactoring some of the elements inside of that shop, um, to open up more floor space for more goods to be sold, right? Those are the things from a software development perspective that, that can be capitalized in a very similar fashion, because at their core, it's money that you're putting back into your business. It's investments that you're making to hopefully drive more revenue downstream for your company and set up more profitable growth. Mechanically, inside of building these new features and significant improvements, there's a set of work that you actually can capitalize and many of us actually have to capitalize based on regulatory requirements. And for the most part, while there's exceptions and various regulations, it's largely the work that's done post-designing your software, but pre-releasing that software. So they're trying to identify what is that bit of work by which we actually built and tested the core thing that we're trying to deploy or invest in. So imagine a new feature launch. It's not everything after the launch, and it's not us saying we want to go do it. It's the actual ones and zeros. It's the pounding away on the keyboard that helps us develop that software itself. So what makes R&D cost, uh, cost capitalization so hard? It sounds so simple, right? Yeah, this was a big effort. We built new product X. It cost X amount to do, right? That should be really easy to get to. Um, but it's not that easy, right? And, and instead it's actually incredibly difficult to get the key inputs that are needed to assist with these cost capitalization workflows for software development. And that difficult really, really lies in two areas. The first is software development itself. Software development is nonlinear. It's complex. It's odd in the sense that there is no one person that works on it, right? It's a one-to-many relationship as to who's contributing code, who's reviewing code, you know, who's putting thought leadership towards it. And then the second piece is that innovation itself and innovation of modern dev practices specifically have outpaced the regulation that governs software development cost capitalization, right? And so what do we mean by this? If you rewind the clocks, let's just say about 20 years ago or so, right? Waterfall development was at its peak, right? That's how you develop software. And it was easy to say that we had 100 developers who worked on this capitalizable project for the past 4 years. 3 months. Really easy calculation. 100 engineers times whatever the salary or cost is for the course of the year times 3 months. Pretty easy calculated. Unfortunately, right, that waterfall idea where things were funded and planned/design and then built/tested and then deployed is not really how software is built today. And today, at risk of oversimplifying agile development, So bear with me here a little bit. But you don't know what that final design or product will actually be. Instead, you're incrementally building this product, right? You're saying, I want to go build a bridge, right? You kind of know you want to build a bridge. You may not know what it looks like, right? And you're going to incrementally build piece by piece by piece and iteratively go back and rethink pieces that you did not get right. And you're going to build upon the previous pieces. And essentially, you're doing these in an idea— was typically this idea of a sprint. Or at least an iterative release if you're working in more of a Kanban function. And in, inside of each of these like iterations, right? You're essentially developing this pressure cooker where within a few week period, let's say 2 to 4 weeks, you're essentially going to fund a project, right? We're gonna go do this. You're gonna design it, you're gonna build it, you're gonna test it, and you're gonna deploy it. And then you're gonna start that process over again and somebody else is gonna work on it, or maybe the same person. And heck, you might even refactor what you just released cuz you learned something about it. And so in that process, we have a cyclical piece by piece by piece with everything happening at the same time, where it's really tough to delineate time spent towards each of the phases of development life cycles. You instead find it really difficult to answer questions like, how do you identify the actual piece of work that was post-design and pre-release? Or how do you know who actually worked on it and how long they actually spent their time? I know it was Team X, And I think Ryan was on that team, but I don't really know how much time Ryan spent on this particular piece of work. Or even, you know, the more difficult piece though is, yeah, how do you know who else contributed to it? Right? People often have, we'll call 'em like issue tracking or planning software in place where it says, hey, Ryan's gonna go work on this new product. But Michael might have spent some time on there as well, whether it's advising with me, reviewing the code I developed, or really just spending time like actually contributing code itself. There's that one-to-many cardinality or relationship of assignee of a task to who worked on it in today's modern development practices. And so once you actually identify who did those elements, it's really a question of trying to communicate to the finance teams as well, hey, here's what we think actually happened. Here are the costs. But also doing so in a way where you can say, hey, here are the actual details, right? We think it was Ryan and we think it was Michael and we think there was X amount of time, but then putting it in a way that finance can then do their calculations. But also at the end of the year when auditing teams come knocking and they say, hey, finance team, we picked 3 random capitalizable projects. Can you please prove for us why you believe the cost for X, Y, or Z? And having that information available then allows you to actually stand behind and feel confident in what you had reported out as cost, as capitalizable cost for any individual initiative that you've been working on.
