Your Programmer or Theirs? How AV Integrators Can Decide Whether Subcontracted Work Counts Toward the R&D Credit
When an AV integrator pays an outside programmer or engineer to solve a hard problem, part of that cost may count toward the R&D credit. Five questions help you sort which invoices qualify.

TL;DR
- If you pay an outside programmer or engineer to do qualified research for you, 65% of what you pay them can count toward your R&D credit. The contract has to be set up the right way.
- Four things decide it: the agreement was signed before the work started, you pay whether or not it works, you have a right to the results, and the work happened in the United States.
- When your firm is the subcontractor, the same rules work in reverse. Whether you can claim depends on who carries the risk and who keeps the rights.
Most AV integrators don't do every piece of custom work in-house. A tricky control system gets handed to a freelance programmer. A DSP design for an unusual room goes to an outside audio engineer. A custom interface between a building management system and the AV stack goes to a specialist shop that has solved something like it before.
That's a sensible way to run the business. But many owners assume the R&D credit only covers their own employees' wages, so those outside invoices never get looked at. Sometimes they should be.
The federal research credit under IRC Section 41 rewards companies for working through technical uncertainty in a structured way. Section 41 also lets a company count part of what it pays outside parties to do that work on its behalf. The Treasury regulations call these "contract research expenses." Whether a given invoice qualifies usually comes down to a handful of questions.
Question 1: Was the underlying work qualified research?
Start here, because nothing else matters if the answer is no. The outside work has to meet the same standard your own team's work would: a technical uncertainty resolved through a process of experimentation, grounded in engineering or computer science. That standard is laid out in Treasury Regulation 1.41-4.
In AV terms, that could include a programmer building custom control logic for devices that were never designed to talk to each other. It could include an engineer iterating on a DSP and acoustic design for a room with unusual constraints. Both involve real unknowns and testing.
Standard configuration of a platform the programmer has deployed dozens of times usually won't meet the standard, no matter who does it.
Question 2: Was the agreement in place before the work started?
The regulations say an expense counts only if it's paid under an agreement made before the research is performed (26 CFR 1.41-2(e)(2)). The agreement also has to say the research is performed on your behalf.
For many integrators, the agreement is a statement of work, a purchase order, or an email scope your programmer confirmed before starting. What matters is that the arrangement existed before the work began, not after the fact. If you hire outside help often, it can be worth making sure your standard subcontract paperwork clearly records this.
Question 3: Do you pay whether or not it works?
This is the question that surprises people most. For a payment to count, the agreement has to require you to bear the expense even if the research doesn't succeed.
If you pay a programmer hourly, or a fixed fee for the effort, that generally meets the test. If the programmer only gets paid when the system works as specified, the regulations treat that payment as buying a finished result rather than paying for research, so it doesn't count.
Mixed arrangements are common. Say a programmer bills time and materials plus a bonus if the system passes commissioning. Under the regulations, only the contingent portion is excluded. The rest of the payment can still count, depending on the facts.
Question 4: Do you have a right to the results?
Research counts as performed "on behalf of" you if you have a right to the results. Those rights don't have to be exclusive (26 CFR 1.41-2(e)(3)).
This matters in AV because freelance programmers often reuse modules across clients. A programmer who keeps the right to reuse a driver or code library doesn't automatically disqualify your claim, as long as you can use what was built for you. What to check is whether the contract gives you any right to use the work product.
Question 5: Was the work done in the United States?
Research conducted outside the United States is excluded from the credit under IRC 41(d)(4)(F). If some of your programming goes to an offshore team, those costs generally won't count, even if every other test is met.
When a contractor uses a mix of domestic and offshore staff, it helps to know where the work on your project was actually performed.
Then: how much of the invoice counts?
If an invoice passes all five questions, the amount that generally counts is 65% of what you paid for the qualifying work, not 100%. And only the part of the invoice tied to research or research-support services is eligible.
AV invoices often bundle programming with hardware, travel, rack builds, or routine installation labor. Those other items need to be separated out. An invoice that's half custom control development and half standard install work would typically contribute 65% of the development half.
Treat that as a starting point, not a result. The final figure depends on the specific activities, documentation, and facts.
What if you're the subcontractor?
Plenty of integrators sit on the other side of this relationship. They do custom integration as a sub to a general contractor, a design consultant, or a larger integrator.
The regulations cover that case too. If you do research for someone else and keep no substantial rights in it, you can't count it (26 CFR 1.41-2(a)(3)). Whether you carry the financial risk also matters.
When you're paid only if the system works and you keep the right to reuse what you develop, the analysis can favor you. When you're paid regardless of outcome and hand over all the rights, it generally favors the party paying you. This is decided contract by contract, so it's worth reviewing your larger agreements rather than assuming either way.
A note on in-house vs. outsourced work
Because contract research counts at 65% while qualified employee wages can count in full, some owners ask whether they should bring programming in-house for tax reasons. In most cases the credit shouldn't drive that decision. Staffing, expertise, and project flow matter far more.
What the credit does reward is knowing where your technical work actually happens, and making sure your contracts and records reflect it.
What to do next
If your firm regularly pays outside programmers or engineers on complex jobs, look at the past year of those invoices alongside the agreements behind them. You don't need to settle every question yourself. Just knowing which invoices are tied to custom technical work, and whether the paperwork predates the work, puts you in a strong starting position.
Strata offers a $0 initial assessment. Studies typically take about 4 to 8 weeks, depending on the company and the years involved, and most of the work sits with our team rather than yours. You pass the finished package to your CPA, who files the return.
Talk with Strata about your projects
For the IRS form used to claim the credit, see About Form 6765, Credit for Increasing Research Activities.
This post is for informational purposes only and does not constitute tax or legal advice. Consult a qualified tax professional regarding your specific circumstances.
Author
Strata R&D Tax Group



