Around 2010, when US companies could count on a recovering domestic economy, a weak US dollar, and growing emerging market economies, CFOs didn't need to work that hard to flatter the income statement. This has changed: the US recovery has been inconsistent, emerging markets are performing poorly and the US dollar is strong (taking the edge off overseas revenue). Plus, firms are carrying more debt than they were a few years ago, making the optics of the P&L that much more important.
One result of this is that tech capitalization is back. It never really disappeared, of course, it just wasn't as common. But while tech capitalization was dormant, tech has changed a lot - quite a lot, in fact.
First, Cloud, SaaS and BYOD change software and infrastructure from capital investments to rent expenses. Renting is an economic convenience more than it is a cost efficiency. Renting is no less expensive than owning (the person who rents a house has to cover the landlord's mortgage, capital improvements, taxes, etc. in the rent payment), so technology costs represent a larger - and discreetly measurable - operating expense. As an expense, it's increasingly being indexed to payroll (that is, headcount), which makes it more like a tax (I need one ERP user license for every employee in sales, so if my sales force grows, I need more licenses).
Second, Continuous Delivery - deploying software hourly or daily instead of monthly or quarterly - blurs the lines among traditional development stages. It makes our packages of deployable work far more atomic than the more traditionally coarse "release" or "project" level deployment. Plus, if we're experimenting through software to see whether there's a need (much less a solution) - something uniquely enabled by Continuous Delivery - our development can't be capitalized at all. It's R&D, which has to be expensed.
What does it mean? Well, we don't know. For one thing, we're not really there yet. We know that this echoes the supercycle of businesses separating into asset-light operating companies (e.g., retailers) and asset-heavy finance companies (e.g., REITs). But we also know that a lot of firms still license captive ERP systems (no SaaS), operate captive data centers (no Cloud), and issue hardware to employees (no BYOD). In development, Continuous Delivery is still more idea than implemented among firms predisposed to capitalize rather than expense their software development costs. The execution trend toward tech asset light matches - but lags - the financial trend.
For another, specifically with regard to capitalizing development, we fit Agile under FASB 350-40 without violating the intent of the original AICPA policy (SOP 98-1), but we never explicitly formulated policy to reflect how work got done in an Agile world. For as much as we made Agile perform better than Waterfall under capitalization policies (e.g., better opex/capex ratio), it's always been an ill-fitting Waterfall suit around an Agile body. Fast forward, an today we have Continuous Delivery, which takes Agile concepts of frequent delivery and Lean development practices to the next degree. This extends the already long tail: accounting policy (treatment) lags tech execution (Continuous Delivery is still wishful thinking in most firms) lags financial expectation (asset light).
But some things we do know, and point to what we should be paying attention to.
The CFOs interpretation of tech as a capital investment is not the same as tech as an operating expense or tech as a tax. The more tech becomes an expense or a tax, the more downward price pressure there will be on tech. This is great for a business, but it could portend the next collapse in tech pricing buoyancy.
Similarly, software development as an R&D expense does the CFO no favors on the income statement. Development labor has commanded a premium price for many years now - it's been counter-cyclical since 2009, rising while labor costs in the broader economy stagnated or sank. CFOs don't have a high tolerance for this. Importing a high cost of labor onto your statement of cash flows because you're investing in an asset that you expect will generate future cash flows is one thing. Importing a high cost of labor onto your statement of cash flows for an R&D experiment is entirely another. As CFO, you're more comfortable paying a premium for labor if you see a path to getting it back; you're less comfortable if you're spending on some "ideation" boondoggle. Labor scarcity, cheap capital, easy profits, and a growth-through-tech-frenzy make boondoggles less onerous; a change in those conditions will make them far less tolerable.
The prevailing business conditions are changing, bringing capitalization back with them. Or, at least, tech is being asked to bring capitalization back. Tech is less well prepared to answer: while tech has evolved beyond fixed assets in data centers and long-cycle Waterfall delivery, it never truly matured how it accounts for its costs in the context of the host or consuming business. If anything, it's thumbed its nose at finance, allowing labor scarcity to afford it the freedom to drive itself more toward a no-strings-attached expense.
If the capital cycle still matters, this is bad for tech. If the tech cycle trumps the capital cycle, it doesn't. We'll look into that a bit more closely next month.
