 |
| Image: digitalart |
Many of our clients are either publicly traded firms or firms that would like to be publicly traded someday. And something anyone working with these firms will be likely to tell you is that the way they account for software development costs can be tricky.
Let’s start with the following fill-in-the-blank question:
The way accounting treats software development from a financial reporting perspective can be ______.
a) Financially significant to the firm in terms of profits, losses, taxes, etc.
b) A potential source of financial fraud
c) Mind-numbingly confusing
d) All of the above
The correct answer, of course, is (d). But despite the potential financial impact, capitalization is a topic that rarely comes up within the agile community. My goal for this post is to shed some light on the problem for the non-accountants out there, so please excuse any definitions and categorizations that aren’t totally correct. I’m not an accounting expert.
What is Capitalization?
Capitalization is the act of categorizing an expenditure as an asset rather than an expense. Imagine that a company has one million dollars in cash but no real estate or other assets. In this case, the company’s total amount of assets is one million. Now imagine that they construct an office building for $500,000. They still have one million in assets: $500,000 in the building and $500,000 in remaining cash. Because the building has long-term economic value, it’s been classified as an “asset” to the firm. In other words, it’s been classified as “capital” or has been “capitalized”. Compare this to a firm taking everyone out for a big $500,000 party. This would definitely be categorized as an expense rather than an asset, because it has no long-term economic value to the firm. In both cases, they spent $500,000 but accounted for the $500,000 expediter differently on the books based on what it was spent on.
The Kinds of Software
There are basically two kinds of software recognized by financial types: software for internal use and software for sale to outside parties. You’ll need to figure out which one applies in your situation, and in some cases, it may be both: You sell software and also build software for internal use. The same software could also fit into both categories in the case where you build the software for internal use but plan to sell it eventually.
The way we capture expenses, assets, etc., will depend to some extent on the kind of software it is, even though the basic premise is similar for both. Expenditures with long-term economic value are treated as assets (“capitalized”). Otherwise, expenditures are treated as expenses.
Who Cares?
Many people, as it turns out. How you categorize your software costs can have a huge impact on profits, losses, assets, depreciation, taxes, etc. And many an accounting fraud has been perpetrated by willfully mis-categorizing assets versus expenses in order to cook the books. Remember Worldcom? By the end of the investigation, it was estimated that the company’s total assets had been inflated by about $11 billion. How? You guessed it: by capitalizing what should have been expensed.
Financial Accounting for Software
Many (but not all!) of the costs associated with building software can be capitalized, or in other words, considered an asset like the construction of a building I mentioned earlier. But not all of the costs can be capitalized. This is where accounting rules come into play. The way you treat software from a financial reporting standpoint depends on its kind. If it’s software for sale, then I believe that more costs can be treated as expense. If the software is for internal use, then it’s treated slightly differently. I think that fewer costs are treated as an expense and more are treated as assets. But we’ll leave the minutiae to the accountants.
In general, it’s fairly safe to say that actual software development and test time is capitalized or treated as an asset, whereas up-front R&D, feasibility, prototypes, etc., may be considered expenses. I’m pretty sure that time spent on operational support and defect fixes count as expenses, and therefore cannot be capitalized. The time spent on architecture and design, however, can be capitalized. I’m not sure whether requirements analysis time counts as an asset or expense. So, for example, if you spend:
- $250,000 on design
- $500,000 on development and test
- $100,000 on operational maintenance
Then you might have $250 + $500 = $750,000 in new assets, and you might have $100,000 in profit-sucking (or tax-lowering) costs.
Agile Complicates Things (Again)
All of this was easier in waterfall because you entire phases could be treated as assets or expenses. You could just say that all of the money spent during the development phase and test phase could be capitalized. In the agile world, we don’t have these phases, so it becomes a little trickier to track the numbers. My advice would be to track the time spent on each activity so that the accountants have what they need to figure it all out. In agile product development, you’d need to do this on a per-user story basis, which can be a pain.
I don’t generally break user stories down into tasks anymore, but this is a case where it would definitely help. Create a requirements task, design task, dev task, test task, etc., for each user story. Keep track of which stories are new features and which are support/operational-bug-fixes. You’ll need to track the time spent on each task and then roll it all up for the bean-counters so that they can get a total amount of time spent on requirements, dev, test, etc.
Finally, talk to your corporate accountants. One of the reasons that you may not hear much about this topic is that your accountants have come up with reasonable ways to estimate the breakdowns using historical averages, etc. Still, every now and then, we run into firms where this topic requires a more accurate treatment. I’m sure that you can come up with ways to get the information the accountants require, such as by doing it on a per user-story basis. – Roland Cuellar
Roland Cuellar is a software and product development process consultant specializing in program management leadership and agile software development, and lean business process improvement.
