CapEx for software development, or “Help! My CFO wants developers to do timesheets”

CapEx for software development, or “Help! My CFO wants developers to do timesheets”
In the name of CapEx, and imagining it’s but a minor inconvenience, your CFO wants all the engineering team to do timesheets, and all feature development work to be tied back to projects documented in terms of specific phases of development.

Of course, the project documentation will add overhead to the process of making software, but of perhaps greatest concern is the impact of doing timesheets on the morale and motivation of your technologists.
 
In most companies it’s easier to argue the case about the tangible overheads such as extra project documentation, and far more difficult to articulate the value of motivation and morale — intangible as they are.

But in any case, you’re being asked to take a hit on your team’s effectiveness, in exchange for something that you’re told is of vital importance to the company’s accounts. It’s important for you, and other decision makers at your company, to understand the complete cost of this exchange, so that good decisions are made.

This article is written for engineering decision makers, so we’ll start by looking at what CapEx is, how it functions like personal credit card debt.

After that, we’ll learn how companies get into a cycle of CapEx Addiction where the overheads of CapEx are kept despite its benefits having been exhausted — a bit like how sometimes people maintain a continuous credit card balance despite its recurring costs.

Next, we’ll look at the difficulties of implementing CapEx within an agile way of working, and end with some ideas of how to get finance and technology people more connected, so that there’s more of a chance to make beneficial decisions.

What is Capital Expenditure?

Accountancy is a form of storytelling, and CapEx, or Capital Expenditure, is an accounting tool that enables you to tell the financial story of buying an expensive piece of equipment that gets used over many years. Rather than consider the total cost of the equipment to be paid at the time of purchase, the costs are spread across a few years — the useful lifespan of the equipment.

Without CapEx, the business will appear to have misleadingly low earnings in the year of purchase, and misleadingly high earnings in subsequent years when the equipment is used without apparent cost. The accounts tell a more accurate story if, say, 1/5th of the equipment is expensed every year for the five years of its useful life. That way, the cost of running the company in a particular year is reflected in that same year’s accounts.

Capex for software development

CapEx is a useful accounting tool that can make a company’s performance look better and in many cases more accurate, and has virtually no cost to implement when used for buying equipment, off-the-shelf software, or really anything that is already available to buy. But when applied to developing new software in-house, CapEx causes lower productivity and risks team motivation and morale.

While this trade off may be appropriate short-term, over the course of a few years the benefit shrinks to nothing while the engineering costs remain the same.

Worse, there is a lock-in dynamic which shows up as apparent reduction in company performance when easing back use of CapEx. This dynamic leads to CapEx — and its overheads on engineering teams — persisting beyond its useful term, despite the ongoing costs.

Often when decision makers decide to apply CapEx to engineering teams, they do so with clarity about the upside to the company’s financial statements, but without awareness of the complexity involved, and the risks to employee motivation and turnover.

Improving this situation requires better decision making, with finance and business leaders becoming more aware of the impact on software development processes, Engineering leaders understanding the impact of their way of working on the company’s financial accounts, and generation of an exit plan for when CapEx has outgrown its useful phase.

The anatomy of an Income Statement

An Income Statementfn:P&L is one of the standard financial documents a company regularly publishes. It shows over the course of a year how money coming in (income or revenues) is spent on what’s necessary to provide the products or services being offered, with the remainder being earnings (profits or losses).

For a CFO, the Income Statement is one of the main ways to tell the financial story of the company over the past year. As we’ll see shortly, most of the attention on an Income Statement is in the top half of the Income Statement, above the line, and it’s probably one of your CFO’s goals to make the above the line numbers look as good as possible, within the bounds of legality and standard accountancy practice.

Looking at an Income Statement, from top to bottom:

  • The top line states the money coming in (income, revenues)
  • Above the line encompasses the breakdown of revenues, costs of sales, general administrative expenses, R&D costs, depreciation and amortizationfn:amortized.
    In other words, the money used to keep the company running and create and process things to be able to sell. Depreciation and amortization are ways to take into account how physical equipment ages (e.g. laptops need replacing every few years), and spread large up front costs over several years.
  • The line gives operating profitfn:operating profit, which is also called earnings. Calculated by adding up above the line figures, it represents how well the company’s core business is doing.
  • Below the line means two things: it’s the breakdown of other income and expenses that occurred during the year, but are considered non-core. It also means other financial statements that are typically looked at after reading the Income Statement.
  • The bottom line is the actual year’s profit made, that could potentially be paid out to shareholders.

Income Statements are typically printed out with a thick line under “operating profit”. This is The Line, and I like to think of it like The Fold in advertising and journalism: most people read above the fold, while only dedicated readers look below the fold. In the same way, most people interested in a company’s accounts focus their attention above the line. Information that is below the line won’t receive so much attention — it might even be on a separate financial statement altogether.

An imaginary interest-free loan

It’s possible to think of CapEx as a kind of loan.

What kind of loan? An imaginary loan, because although like a regular loan using CapEx can ease up cashflow, no actual money changes hands. And an interest-free loan, because from the accounting point of view, there is no apparent cost to maintaining this loan.

An imaginary interest free loan

Perhaps this sounds too good to be true; just because there is no interest doesn’t mean the loan is without cost. When we’re talking about software development, it would be more accurate to say:

CapEx works like an imaginary loan paid for in engineering team productivity

Most business decision makers would want to weigh the benefits of improved cashflow against the costs to the engineering team. The problem is, while the benefit to the company’s accounting is clear, measuring the productivity of software developers is hard to do. And making a case that something already hard to measure will be adversely affected, is doubly hard.

Faced with clear benefits, and a lack of clarity as to the costs, the decision will almost invariably be “We’re CapEx-ing software development, so let’s talk timesheets”. As VP of Engineering, you’re probably going to lose this one.

How CapEx works like a loan

Let’s work through a software development example. For ease of explanation, we’ll use round numbers and keep the example as simple as possible.fn:team notes

We have a team of 8 developers, at an average £75,000 salary, which gives an annual development cost of £600k. The company has recently started in business, and over the first 6 years, revenues grow each year.

The table below shows the Above the Line numbers on the company’s income statement. For brevity, we’re just showing overall numbers, and developer costs.

Looking at these numbers, it’s unfortunate that the earnings column takes 3 years to show a profit. If we capitalize some of the software development, perhaps we can improve this?

Let’s say we are able to capitalize 66% of developer costs — the rules of CapEx allow the costs of brand new features, but not bugfixingfn:rules of capex. That means, of the £600k developer costs, £200k (33%) goes on OpEx — planning, investigating, meetings, troubleshooting, bug fixing, prototyping, etc. The remaining £400k gets amortized over 5 years at £80k per year.

Year 1

In the first year of using Capex, our above the line fn:above the line developer costs are a fraction of their actual amount, and our Earnings look great. We’ve gone from apparently losing £400k in the OpEx only example, to actually earning £20k. As we’ll see, £480k of developer costs has been smeared across years 2 – 5.

Year 2

In Y2, developer costs have apparently gone up. We include 1/5 of the year’s feature development costs plus our OpEx costs, as in year 1. We also need to add on the second instalment from year 1’s CapEx. Total costs have gone up, but earnings are higher too, and the earnings look very healthy.

Year 3

In Y3, developer costs keep climbing, even though we’re not hiring more people, and no one has received a pay raise. Still, revenues are increasing well, and earnings are very healthy.

Year 4

It’s a good job this is a growing business, otherwise these rising developer costs would start eating into our profits in a big way.

Year 5

In Y5, total developer costs have finally reached their actual non-capexed costs.

Later years…

Costs in Y6, Y7, Y8, and future years, remain exactly the same as Y5. From this point on, even though we continue to capitalize development costs, there is no advantage in the way our earnings are portrayed.

Corporate CapEx addiction

Even after the fifth year, the engineering team continues to suffer the overheads of documenting CapEx, and the indignity of providing timesheets. Let’s suppose in Y7 the engineering team overheads are being considered by the company’s decision makers, and there’s a proposal to stop capitalizing development costs. How does that look?

Year 7: developer costs as OpEx rather than CapEx

To the casual reader, this looks bad. In Y7 costs have gone up faster than revenues After 6 years of continuous growth, earnings have just taken a dip. Development costs seem to have gone up significantly.

Anyone relying on above the line numbers will be concerned about the company’s performance. At best, they’ll become curious about what’s going on, and look at other figures. At worst, they’ll have been psychologically primed to believe the company is troubled, and will look for data that confirms that belief.

What’s actually happened is that we’re paying for all of Y7’s development as OpEx, while still paying for four instalments of previous years’ CapEx.

So, it’s difficult to stop using CapEx for developer salaries cold turkey, as it will take a few years to get back to the situation before CapEx. While it’s possible to gradually reduce the amount of capitalization, and ease out of using CapEx, this takes a lot longer and still risks having the Earnings look worse than they might be if CapEx-ing continues.

Without a clear exit plan agreed in advance, we end up back in the familiar situation of a trade-off between clear benefits and unclear costs. Many businesses will continue to use CapEx to avoid the obvious discomfort of re-OpExing developer salaries; but also continue to tolerate the less obvious overheads of development friction and timesheets.

Why recording CapEx is hard when you’re working agile

Your CFO cares deeply that the development work is recorded accurately, and in line with the rules of accountancy. Every so often, business are visited by auditors from external companies like E+Y, Deloitte, and Accenture, and if they find the work documentation doesn’t fit with the rules, your company can face serious financial and legal problems. In extreme cases, the CFO can get into legal trouble personally.

What do the rules of accountancy say about CapEx for software development?

Software is developed in stages:

  • Technological feasibility: typically includes requirements gathering, prototyping, overall design work
  • Detailed program design: typically designing solutions, overall architecture
  • Building features: typically, writing code to make features that doesn’t include bugfixing, troubleshooting, or exploratory work. Also, testing
  • Available for use: the moment in time when the software can be used by customers

Only work that is classified as “building features”, which has been done before “available for use” can be CapExed. Anything that happens after “available for use” is considered maintenance on an already working system, and must be accounted as OpEx.

You’ll notice the word typically used in the stages above. That’s because the rules aren’t super clear on what kind of work fits into each category.

Although the stages map quite well onto Waterfall projects, the more product-oriented the company is, and the more agile the way of working, the harder it becomes to bridge the gap between what the accountancy rules need, and what actually happens.

Ryan Bouray and Glenn Richards, both Certified Accountants, wrote what is probably the best article on software development ever written by accountants. Don’t be put off by it being in the Journal of Accountancy — it’s a quick 10 minute read, mostly free of finance jargon, and clearly explains the issues in a way that both CFOs and Engineers will understand.

Under an agile model … a project is organized into separate modules, and the development and testing work on these modules is done in short sprints. Identifying when the traditional activities of the waterfall approach occur requires significant analysis and judgment in agile development, which can make it more difficult to apply GAAP guidance for capitalizing expenses.

GAAP is the organisation that writes the accountancy rules.

Demonstrating technological feasibility is likely to require the project team to do more planning and compile more documentation than is typical in most agile projects.
[It is] challenging for entities using an agile model to apply GAAP rules appropriately to software development activities, particularly in determining which costs are capitalized and which costs are expensed.
High-risk development features may require additional analysis of when technological feasibility is reached and, in some cases, expensing of previously capitalized costs.

You need to agree with your CFO that for high-risk features, you might need to go back and convert previously accounted for CapEx into OpEx. Because of this, you’re likely to be asked to avoid high-risk features, because going back and changing previous accounts is awkward to do, and risks throwing out financial predictions that have already been made.

Bear in mind, however, that any maintenance-related or error-correction costs that are incurred during the sprint may need to be expensed rather than capitalized, as many activities during the sprint may not be coding and testing but may be activities such as troubleshooting and discovery.
Distinguishing between costs that can be capitalized and those that cannot be capitalized can complicate the project accounting, reporting, and documentation steps within each sprint somewhat. But the additional administrative work does not have to be onerous. In most cases the various tasks and deliverables within each sprint can be segmented into broad categories, so that all costs associated with that task can be either expensed or capitalized.

So… you need to be able to categorize development work into different buckets that you agree with your CFO, and document the time spent on each.

Unfortunately, as we’ve established, the GAAP categories do not map super clearly onto the activities of agile software development. I have a solution for this though — the CapEx Categorization Card Game.

Playing the CapEx Categorization Card Game with your CFO

How do you get agreement on the categories of work, while also getting a deeper shared understanding between how CFOs and Engineers see technology work?

Here’s one way — a simple card-sorting activity that takes 15 minutes to prepare, and 20-30 minutes to run through with your CFO or finance director. Book a meeting with them to discuss categorization of software activities into CapEx and OpEx. While this is the obvious purpose of this game, the secret mission is sharing knowledge of how software development actually happens.

Preparation

  1. Get 5x3" index cards, ideally in a range of colours. Also get a medium-thickness black marker.
  2. Pick out 4 green ones, and write on them “Capex” “Opex” “Not sure” “Either”
  3. On blue cards, write the names of the meetings you regularly have: “Sprint planning”, “backlog refinement”, “sprint review”, “product demo”, “retrospective”, “code review”, “architecture workshop”, “customer journey workshop”, “manager 1-1”, etc.
  4. On yellow cards, write kinds of work: “fixing a bug”, “troubleshooting”, “developing a feature”, “devops”, “UX”, “visual design”,”front end development”, “database schema design”, “integration testing”, “security testing”, “user testing workshop”, “guerrilla user testing”, etc.
  5. Add to the yellow cards: “developing a feature again because it wasn’t right first time”, “fixing devops scripts because the versioning of dependencies changed”, and perhaps a couple of other more complex circumstances.
  6. Use green cards if you have styles other than individual work: “pair programming”, “mob programming”, “cross-team collaboration”, “code dojo”

Game play

CFO: Come in, please sit down

CTO: thanks for taking the time to meet like this! I understand you’ve asked that our developers do timesheets, so that we can Capex the development work.

CFO: that’s right. this will really help this years accounts come out telling a good story, which as you’ll know is important for looking good to our institutional investors, and the stock market in general. Of course, we aren’t looking to misrepresent anything — just take every opportunity to put our story in the most promising light, given what our investors typically look at.

CTO: Understood. So, I’d like to make sure we’re aligned on what activities we should be allocated as Capex, and which as Opex. I’ve seen your guidance on this, and that’s helpful. I wonder if we might spend the next 20 minutes looking at a few specific cases, to ensure we’re on the same page, and bring this to life.

CFO: Sounds good, I’d be delighted

The CTO shifts her seat to be at right angles to the CFO, so they can look at the same things, and pulls out of her briefcase a deck of coloured index cards, each with a word or two written on it in thick black marker pen

CTO: Think of this as a kind of card game.

She lays out the light-blue cards in a row: Opex, Capex, Either, Not sure

CTO: We’ll sort these cards into whether they’re definitely Opex, always Capex, could be either one. We have a “not sure” column, just in case.

The CTO pulls out the first white card, and turns it over

CFO: User Research. That’s when you send people out to find out what customers need.

CTO: Right!

CFO: We can’t capex that, so that’s always Opex.

The CTO puts the card in the Opex column, and pulls out the next white card. The CFO seems to be playing along with this unconventional presentation. that’s good!

CFO: Front end development. What’s that exactly?

CTO: That’s when software developers build web pages, basically. There’s more to it, of course, but that’s the main job.

CFO: Capex, then

The CTO puts the card in the Capex column. Then turns the next card over, this time placing it on the desk near to the CFO

CFO: (picking up the card) Back end development?

CTO: That’s building the parts of the system that run on servers.

CFO: (placing the card in a column) Capex again

CTO nods to herself… This is good… when someone handles the cards themselves, it’s sign they’re buying into the process more.

CFO: UX design?

CTO: The layout of information, images, and buttons etc. It’s important this is done in a way that makes the product obvious and easy to use

CFO: Got it… When does this happen? Do you do it as part of the overall specification of the whole thing, or is it part of building it?

CTO: A few years ago, we used to do it all up-front before starting. But we’ve learned that it’s better to do most of the detail work integrated into the front-end development, during the building of the product. Less mistakes and better quality that way, you see.

CFO: Got it, in that case… (puts the card in a column)Capex!

The next card is Overall Interaction Design

CFO: What on earth is that?

CTO: that’s looking at the whole way that different users, who are trying to accomplish different things, flow through the system. It’s important work that ties the whole thing together.

CFO: so I imagine that gets done before everything else

CTO: yes, you’d think so. Actually, some of it gets done up front, and then more detail work tends to happen during building.

CFO: The parts done up front will be Opex, if it’s during building then it might be either… not sure.

Next is Integration testing

CTO: This is when we put the finished parts of the system together, to make sure they work together right.

CFO: Capex

A/B testing

CTO: That’s where we have some customers use one version of the system, and some another, so that we can see which performs best.

CFO: How does that work? Is that something you do after you finished?

CTO: It’s something we do as we develop new features on a system that is already being used. Or something we do when we are prototyping and investigating before we start.

CFO: In both cases, that’s Opex, because it’s investigation.

the CTO looks at her watch

CTO: We’re almost out of time… there are still quite a few cards left though. We don’t need to finish today.

CFO: Actually, let’s keep going. This is actually quite fun.

Author’s note: this really happened when I did this exercise with my divisional FD

They keep going for a while, with the activities spread between Capex and Opex, and a few in the Not Sure and Either columns.

At the end of the activity, the CTO carefully gathers the cards for each column, and returns them to her briefcase.

Actually, she could have guessed most of the columns based on the guidance the CFO had given. But, there were a few nuances that changed things. More importantly though, there’s now a much better shared understanding of the actual activities that go into software development — more so than numbers on timesheets or figures on a balance sheet.

Recommendations for working with CapEx of developer salaries

Overall, If you are able keep developer salaries as OpEx, then do so. That said, here are some recommendations to make CapEx as smooth as possible.

  • Use CapEx only for something that the short-term development of something brand new (no more than 18 months)
  • Before starting CapEx, plan the exit: when it will be, whether it will be instant or incremental
  • Discuss up front how to keep product decisions free of CapEx-bias — that is, how to make product decisions based on customer need, rather than need to hit a particular percentage of CapExable work
  • Educate yourself about the basics of accounting, and how accountants are bound by the rules of accountancy which don’t work the same way software development does
  • Educate your developers as to why it’s important for the company’s apparent profitability — appearances matter! — and ask for their buy-in for a temporary introduction of timesheets and higher development friction
  • Plan time within both technology and finance for an ongoing discussion of capex recording. You’ll discover edge cases as you go, and it’s better to discuss these as they come up than to have to make adjustments several months later
  • Build trust and connection with your finance team so that it’s possible to look for mutual wins and keep the big picture of the overall business in mind

fn:P&L: P&L is Profit and Loss. There are lots of names for an Income Statement: P&L account, P&L statement, Statement of profit or loss, Revenue statement, Statement of financial performance, Earnings statement, Statement of earnings, operating statement, statement of operations.

fn:amortized: Amortization: paying off an amount owed over time by making planned, incremental payments of principal and interest. In accounting, amortisation refers to charging or writing off an intangible asset's cost as an operational expense over its estimated useful life to reduce a company's taxable income. — Wikipedia

fn:operating profit: Operating profit is also called Gross profit.

fn:team notes: No change to team size over time. Excluding other employment overheads on top of salary. Capitalization is over 5 years, and with an even schedule of 1/5 every 5 years. We assume amortisation starts within the first year.

fn:rules of capex: The rules of CapEx for software development are based on following a three stage software lifecycle: technical feasibility, building features, available for use. This fits easily with Waterfall projects, but becomes increasingly difficult with more agile ways of working.

fn:above the line: There are different conventions for writing Income Statements. Some of these will have amortization of CapEx above the line, while others will have this on the bottom half of the Income Statement. In either case, the amortization appears on the Income Statement whereas the larger balance of the CapEx appears on a different financial statement called the Balance Sheet.