How to capitalize engineering costs.

executive (31), management (189), how-to (3)

There are many important meetings in your first ninety days as a new engineering leader, but one that’s both easy to forget and surprisingly important is your first meeting with the finance team. There’s a lot to learn from the finance team, particularly drilling into your profit and loss statement, but there’s one narrow topic that causes a surprising amount of frustration between engineering and finance teams: how do you capitalize software engineering costs?

Capitalizing software costs is a financial concern, not an engineering one, driven by the finance team’s obligations to follow the Generally Accepted Accounting Principles (GAAP). Generally, the finance team’s auditors won’t certify their annual financial audits unless they’ve followed GAAP, part of which is deciding whether to capitalize or expense each incurred cost. Capitalizing costs is generally preferable, as it allows them to be amortized over time, showing a higher net income. That said, most finance teams are much more focused on GAAP compliance than on maximizing capitalization. (Exceptions do exist, particularly as the relative size of engineering spend increases.)

The general guidance on capitalizing software engineering costs is straightforward: development of new software capabilities should be capitalized, and everything else should be expensed. In practice, there’s a great deal of flexibility in deciding what is or isn’t a new capability. This is the same challenge as agreeing on whether a given task is really a new feature and bug fix: most changes can be reasonably argued either way.

A surprising number of engineering capitalization discussions don’t start with a clear articulation of what each side needs, which makes it very challenging to agree on a good approach. My experience is that there are only three core criteria to address to keep everyone involved happy:

  1. Easy to explain and justify to an auditor
  2. Available in a timely manner for finance’s financial reporting
  3. Minimizes both finance and engineering team’s ongoing efforts

Before deciding on your approach to capitalization, make sure both engineering and finance agree on their needs! Going further without agreement is madness, and will always end with a political solution rather than a reasoned one.

Capitalization approaches

Although you can solve this problem in many different ways, most organizations end up going with one of four approaches:

  • Ticket-based: track capitalization status and time for each ticket. Establish a default for tickets without a capitalization status (likely that it will be expensed), and then sum hours of capitalizable work across tickets for each engineer, multiplied by hourly cost, to determine capitalizable engineering costs
  • Project-based: track hours for each project, and determine a capitalization weighting for each project (80% capitalized, 0% capitalized, etc) based on the nature of the work. Finance then combines this with a synthetic hourly engineering cost based on average team or organization hourly rate
  • Role-based: set a fixed percentage of time for each role. For example, 80% of product engineer time should be capitalized, 0% of infrastructure engineering time should be capitalized, etc
  • Vendor-specific: There are also a number of vendors, including Jellyfish, that provide methodologies for capitalization

Most companies rely on either ticket or project-based approaches. Engineering teams tend to prefer the role-based model, but many finance teams and auditors will view this approach with skepticism, so it’s less common than you might imagine, although some companies do indeed practice it. That said, it is common to see a hybrid ticket or project plus role based approach: relying on tickets to track capitalizable work on product engineering teams but assuming other engineering teams have no capitalizable work.

Finally, there are many vendors that want to help you with this problem. Each should be evaluated according to the three core criteria discussed above, particularly ensuring that your auditor would be comfortable with the methodology, along with their pricing.

There is no perfectly clean solution here, although hopefully you can now have a more fruitful discussion with your finance team about the options. I’m still annoyed by the overall inefficiency here, but for the foreseeable future most product engineering teams will find themselves doing some level of tracking to support capitalization.