Whether you are developing a new software product that will be sold or developing a custom software application for internal use; often you can capitalize on some or most of this work and costs.
Executive Overview
Most of the time whether your organization chooses to Capitalize the cost of your Software Development efforts or not, is a decision made by your Chief Financial Officer and Accounting Department. However, for mid-sized organizations and larger, it can have a huge impact on your Information Technology Department Budgets, as frequently you will have separate budgets for Operating Expenses and Capital Expenses.
In this Blog Article we will discuss why you would or would not want to Capitalize your Software Development costs, as well as rules you need to be careful of, and of course the dreaded write-off. This Article is only meant to give you a general idea of all of the concepts around Capitalization of your Software Development Costs. For more details please consult your CFO, Finance Department or External Accounting Firm.
Why Capitalize your Software Development Efforts and Why Not
Whether you are developing a new Software Product that will be sold to your Clients and/or Consumers through a Software License of some form, or you are developing a Custom Software Application for Internal Use (within the organization); often you can Capitalize some or most of this work and costs. When you Capitalize the costs you are basically moving today’s cost from your Budget today and moving this into future Financial Periods. You can think of it as using a Credit Card to buy something today, but you don’t have to pay for it right away - and it’s a zero percent interest Credit Card (or it may seem that way).
In Finance terms, when you Capitalize a Software Development Project, you are moving it off of your Income Statement (Profit & Loss), and putting it onto your Balance Sheet as an Asset, which will be either Depreciated or Amortized each month over its useful life, once it is in Production or being Sold.
Why Capitalize
Decreases Expenses - initially
Better Aligns Expenses with the Revenue or Internal Productivity Gains from the Software
Spreads the Expenses out over at least a 3 year period of time, potentially up to 5+ years for Core Enterprise systems
Allows you to build a Software Application initially, which can’t be supported by your existing Operating Expense Budget, as you are shifting costs to future periods
Why Keep it as an Operating Expense
When Capitalizing you are spending on a Credit Card, to be paid back at a future date
What happens if your Operating Expense Budget for the Department goes down in future years? Then what? You can’t pay the bill and have to cut in other areas.
What happens if the Software Application never makes it into Production / or is never Sold to Clients / Consumers? Then you get hit with a bill right away, for the full amount.
What happens if the Software Application was supposed to last 3 years, but you took it out of Production after 18 months. “Poof” you suddenly get hit with the remaining half of the Asset for the Software that is still on your books.
Real Story: CRM Implementation for Universal Technical Institute (UTI)
UTI’s IT Department spent over 18 months attempting to implement a modern CRM application with customization for their organization, to be used by their Student Enrollment Advisors. Unfortunately, the CRM selected was not very good at B2C sales at the time. And worse, the Business never really bought into the change from the existing system. Because of these two primary reasons, the new CRM implementation failed and had to be taken as a “Write-Off”, since it never made it into Production.
This was a $ 3.5 Million mistake and so the IT Department’s Operating Expense Budget immediately was hit with the full amount that was previously Capitalized. For that Fiscal Year, we were completely underwater and spending was curtailed. And it costs our CIO his job.
Software Product for Resale (Clients / Consumers)
When Capitalizing (Amortizing) Software Development costs, developing a Software Product for Resale is easier in many ways to figure out, but harder in others. The primary goal is to better align the costs of developing the Software, with the expected Revenue Stream in future Periods.
The easiest way to think about this, is that if you are Selling a Software License for a Product, then you can Capitalize the costs of developing that Product for Resale. Providing “Support”, bug fixes, and patches is not developing the Product or adding Value to it, so these costs are pure Operating Expenses.
Open Source Software | Free
ITEMS
“Community” Versions
Applications
Integrations
Code Libraries
Etc.
CAPITALIZABLE? No
NOTES: If you are giving away your Software under any form of an Open Source License, you cannot Capitalize the development costs - as there is No Revenue associated with the License.
Premium Versions of Open Source | Paid For / Revenue Generating
ITEMS
Premium Modules of the Base Application
Premium Integrations
Etc.
CAPITALIZABLE? Yes
NOTES: Once you start charging for and collecting Revenue, you can Capitalize the software development costs to some extent. You can only Capitalize those efforts involved with those specific “Premium” Modules or Components.
Open Source Software | Support Revenue
ITEMS
Enterprise Support Agreements (Paid For)
Premium Support Agreements (Paid For)
Open Source Patches & Bug Fixes
CAPITALIZABLE? No
NOTES: Even though these may bring in Revenue, it is not considered to be a Capitalizable Expense.
Normal Software License | Either Subscription or Perpetual
ITEMS
Cloud Based
On-Premise Based
Perpetual License
Concurrent License
Subscription License
Major / Minor Software Releases
Does NOT include Support, Bug Fixes and Patches (Revenue).
CAPITALIZABLE? Yes
NOTES: Any Software License that is generating Revenue. However, with Subscription Licenses you must allocate the Support Revenue separately, as this does not go against the Amortization Schedule.
Key Terms:
Research - this includes any and all activities prior to the organization deciding that a Product is Commercially Viable, and the decision is made to move forward with developing the Product. None of these activities can be Capitalized or Amortized, as you may never go to market.
Commercially Viable Product - once the organization has decided that a Product is Commercially Viable AND plans to Offer the Product for Sale, then you can start Capitalizing or Amortizing all of the costs directly associated with developing the Product and creating Value (an Asset) for the organization. This includes:
Cloud Environment for Development and Testing
Hardware
Consultants and Contractors
Software Developers - UI/UX, Front-End, Back-End, Mobile, Database, etc.
Technical Team Leaders
QA Engineers
Project Management
Business Analyst / Product Owners
But does NOT include Executive Management, Marketing, Sales, Internal / External Beta Testers, or Subject Matter Experts
Revenue Projections - this is perhaps the trickiest part. You have to work with Sales and Marketing to determine a realistic projection of how much revenue you expect the product to generate over at least a 3 Year period of time. This should be done on either a Monthly or a Quarterly period of time, depending upon your Accounting Firms preference. The amount of revenue in each Period will determine the percentage of Amortization Expense and reduction in the value of the Product Asset over time.
Failure to Launch - there are times, when a Product is killed prior to it actually going into Production and being sold, or just after the initial launch. In these cases the minute that the organization decides to kill the Product, any remaining value of the Product Asset must be written off at the end of the Current Period. If there is any value that is salvageable and can be used to create a new Product, then only this amount can be carried over to the new Asset. But be careful, don’t kick the can down the road, make sure it is a Commercially Viable New Product and has been approved by the Executive Team.
Adjustments to Revenue Projections - there are also plenty of times where you initial Revenue Projects won’t match the reality in the Field. In these cases, you can adjust the remaining Amortization Expense schedule based on the projection timeframe you are using (monthly / quarterly). This Adjustment would only affect future projections / Periods. You do NOT want to go backwards and make Adjustments to prior Periods.
Every Product will typically go through 4 distinct Phases:
Introduction or Launch
High Growth
Maturity
Decline
So, your Revenue Projections should match this type of a curve, don’t expect everything to keep going up forever. Once you know the total Revenue Projections, you can take a percentage of the total every Period (month or quarter) to determine how much to reduce (Amortize) your Product Asset by each Period. And it won’t be the same amount each Period. Again, you are trying to line up the expected Revenue with the actual Development Costs.
Also, from a Product Management standpoint, the trick is in making sure that you have a new major version of your product ready to launch by the time you hit the “Maturity” Phase. This way you can start the Growth Curve all over again.
Capitalizing Software for Internal Use
If your CFO is going to allow you (or wants you to) Capitalize Software Development costs for Applications that are either Custom Built or Commercial Applications implemented for your own Internal use, then there are a number of rules that you need to be aware of. First some key terms:
In Service Date - this is the exact date that the Asset (Software Application) was first used in Production by actual Users. All qualified expenses prior to this date can be Capitalized and added as an Asset on your Books (Financials). Development, Quality Assurance, Staging, Pilot Testing, and User Acceptance Testing does not count as an “In Service Date.” The application must be in Production and actively being used. However, if you are doing a rolling deployment, then it would be the date when your first Region, Department, Area, etc. starts using the application in Production.
Useful Life - this is typically the number of years that the Asset is expected to last, before it no longer has any appreciable value to the organization, and must be replaced or retired. For most Software Applications this is between 3 and 5 years, although in some cases can be up to 7 years.
Depreciation / Amortization Schedule - while there are several variants, the most common Schedule is Straight Line Depreciation. Meaning you take the Useful Life of the Asset and depreciate it each month at a fixed percentage of the overall amount. Example:
Remaining Value of Asset = $3,500,000 - $58,333.33 = $3,441,667
Then at the End of June another $58,333 is depreciated, etc.
The amount remaining is extremely important as this would be the “Write Off” amount, if you take the Asset Out of Service.
Cloud
ITEMS
Hosted Servers
Containers
Firewalls
Load Balancers
Storage
Etc.
CAPITALIZABLE? No
NOTES: You don’t own it, so it can’t be an Asset. Unless, you sign a long term agreement (3+ years) and Pay Up Front. Then it does become an Asset, as it is treated like a “Pre-Paid” Expense.
Your Hardware
ITEMS
Anything you actually Purchased and Own
CAPITALIZABLE? Yes
NOTES: It doesn’t matter where the physical Hardware is located, if you “Own” it, then you can Capitalize it.
Software License
ITEMS
Subscription - Monthly
Subscription - Annual
CAPITALIZABLE? No
NOTES: You don’t own the License, you are only leasing it or renting the software.
Software License (Pre-paid)
ITEMS
Subscription - 3 Years
CAPITALIZABLE? Yes
NOTES: While you are leasing or renting the software, if the Subscription is for at least 3 years you can Capitalize it. In effect you are “Pre-Paying” for the Subscription, so it does go on your books as an Asset.
Software License (Perpetual)
ITEMS
Perpetual
CAPITALIZABLE? Yes
NOTES: In this case you “Own” the License.
Software Maintenance
ITEMS
Maintenance & Support Fees
CAPITALIZABLE? No
NOTES: This is an Operating Expense to maintain the Asset, similar to hiring a HVAC technician to fix your A/C system.
Research & Project Selection
ITEMS
Project Management
Business Analyst
Technical Review
Technical Research
CAPITALIZABLE? No
NOTES: Any work prior to the actual Decision / Selection to move forward with the Project cannot be Capitalized. At this point in time it is still considered to be a pure “Research” project which may or may never make it into Production.
Software Development (A)
ITEMS
Implementation Consulting
Custom Development
Integration Costs
Report Development
Database Design
Software Architecture
Mobile App Development
Creating ETL Scripts
And other related Development & Design
CAPITALIZABLE? Yes
NOTES: It is adding value to the Asset.
Software Development (B)
ITEMS
Quality Assurance Testing
Automated QA Testing
Bug Fixes during Development
Training Materials
Product Documentation
CAPITALIZABLE? Yes
NOTES: It is adding value to the Asset.
Software Development (C)
ITEMS
Project Management
Business Analyst
CAPITALIZABLE? Maybe
NOTES: During the actual Implementation or Development process, this is normally allowed. Beyond this boundary it is not.
Software Development (D)
ITEMS
User Acceptance Testing
Subject Matter Experts Time
Data Migration
Actual Training
Help Desk Support
Bug Fixes in Production (Unless Incorporated into a Major/Minor Release)
Further Configuration Changes
Patch Releases or Emergency Patches (all Bug Fixes)
Single Reports not done as a Release
Executive Management Oversight (CIO, VP of IT, etc.)
CAPITALIZABLE? No
NOTES: All of these types of Activities are considered to be Operating Expenses.
Software Development (E)
Additional Major/Minor Software Releases (Primarily New Features)
Implementation of New Modules
New Integrations
A Set of Reports when done as part of a Release
CAPITALIZABLE? Yes
NOTES: These Activities are creating additional value to the Asset and extending its Useful Life. So, they can be Capitalized. However, they will have their own Depreciation Schedule.
The bottom line is to think of any Activity, License, Subscription, etc. is whether it is fundamentally adding Value to the Software Application, or is this something that you would need to perform or purchase, in order to Support and Maintain the Application.
Think of this as a Vehicle
If you replace the entire Transmission on a Truck, you are extending the Life Span and Value of that Truck - thus the Truck is worth more.
But changing the Oil every 5,000 miles doesn’t create any additional Value for the Truck. It is something that you need to do in order for the Truck to work properly.
Conclusion
In this Blog Article, we have covered:
Why you may want to Capitalize your Software Development Costs
Why you might not want to do this
The Process for Capitalizing (Amortizing) Software Product Costs for Resale
The Process for Capitalizing Software Development Costs design for Internal Use
David is a VP and Agile Coach within ArkusNexus, having served in multiple CIO, VP of Software Development roles. He assists our Sales, Marketing, and Operations Teams on critical initiatives.
