R&D Tax Credit - Component Descriptions

What This Is

TL;DR: The government gives us money back on our taxes for doing hard engineering work. This document proves our work qualifies.

Background for Engineers

The US government offers R&D tax credits - essentially a discount on the company’s tax bill for doing qualifying research and development work. For software companies like ours, this can mean getting back 6-10% of engineering salaries as a tax refund.

To qualify, we need to prove:

We faced technical uncertainty (we didn’t know how to solve the problem at the start)
We used systematic experimentation (we tried different approaches, not just guessing)
The work is technological in nature (building software that does something new or hard)
It’s for a permitted purpose (improving function, performance, reliability, or quality)

This is called the Four-Part Test by the IRS.

Why This Document Exists

Our tax accountants (via a service called Graphite) need us to break down our engineering work into categories and document:

What technical problems we solved
What uncertainties we faced
How we experimented to solve them
How much of our work was custom client work vs. core product development

This table is that documentation. It shows that all four major components of Momentum involve genuine R&D work that qualifies for tax credits.

What Engineers Should Know

Keep notes on technical challenges you face and how you solved them
Document when you try multiple approaches to a problem
This documentation directly reduces the company’s tax bill, which helps fund more engineering work
Finance may occasionally ask you to categorize your work for this purpose

Component Breakdown for R&D Tax Credits

The table below breaks down Momentum’s four main components and documents how each qualifies for R&D tax credits.

	Building science research	Offline data pipeline to ingest and process building information	Back-end for building science calculations	Core Application - User facing php application, front-end, middle-ware
Describe:	Collection of research analysis and supporting code performed either on behalf of our customers to answer specific requests (as part of contract work or subscription), or to research technical aspects of building science that should drive behavior of our momentum product.	Pipeline for extraction, transformation, and load of building information data sources from public or private external data, and aggregated into a building knowledge base to generate analysis (as part of contract work or subscriptions), enable our Momentum application, and create data artifacts for some of our clients (data is the product).	Service to perform building science calculation to estimate costs of maintenance and improvement, resource impact of these improvements, legal exposure of buildings to local building performance standards. The service results enable analysis for our customers, and are integrated with our Momentum application.	Customer facing “Momentum” application where building owners and their representatives can evaluate building improvements and their impact, costs in a self-service fashion.
Four-Part Test?	Yes/Yes/Yes/Yes * Uncertainty in proper way of modeling building developments for aggregation of energy and other data - addressed by experimenting with various sources of possible building development grouping * Uncertainty in modeling owner specific costs in analysis for L+M, addressed by focusing on costs break down for heating vs cooling systems	Yes/Yes/Yes/Yes * Uncertainty in proper way of modeling building developments for aggregation of energy and other data - addressed by experimenting with various sources of possible building development grouping (shared with other components) * Uncertainty in reconciling diverging data points across our data sources, addressed by performing analysis and contrasting overall results with building science best practices, yielding better data for our building data platform product	Yes/Yes/Yes/Yes * Uncertainty in proper way of modeling building developments for aggregation of energy and other data - addressed by experimenting with various sources of possible building development grouping (shared with other components) * Uncertainty in reconciling diverging data points across our data sources AND our user data, addressed by performing analysis and contrasting overall results with building science best practices, yielding better data for our Momentum application	Yes/Yes/Yes/Yes * Uncertainty in modeling and reflecting to users phases of building projects, and their representation in the product. Addressed by trialing over time and reviewing with building science experts and getting feedback from internal and external customers * Uncertainty in how to generate requests for proposal from our building science analysis, including generation of spreadsheet and ability to parse them, derisked by researching industry standard and past known scope of work and requests for proposal
Customization/Integration	Customization 50% (ballparking, e.g. L+M work or custom analysis for clients, vs 50% work going to improving our overall modeling) Integration 5%	Customization 10% (this was pre NYSERDA BDP!) Integration 50% (because it’s largely about parsing external data)	Customization 10% (few ad hoc requests in 2024, mainly about national expansion) Integration 10%	Customization 10% (few ad hoc requests in 2024, mainly about national expansion) Integration 10%

Notes

This breakdown is used for R&D tax credit reporting (submitted via Graphite service)
The “Four-Part Test” refers to IRS R&D tax credit qualification criteria
Customization percentages represent work done for specific clients
Integration percentages represent work on external data sources and APIs