Which Parts of an AV Job Can Qualify for the R&D Credit? A Task-by-Task Look Author: Strata R&D Tax Group

TL;DR

• On most AV jobs, the credit does not turn on the whole project. It turns on specific engineering tasks inside it, so the useful question is which tasks, not whether the job “counts.”
• Custom control logic, signal-flow and DSP design, and cross-vendor integration problems are the kinds of work that may qualify. Racking, pulling cable, and loading standard templates generally do not.
• Your own project files (revision history, test notes, change requests) are often what separates a defensible claim from a guess.

Start with the task, not the job

Ask an AV owner whether their business does R&D and the answer is often “no, we install systems.” That answer is understandable, and it is often incomplete.

The federal R&D credit under IRC Section 41 is a credit for certain qualified research expenses, mainly wages, supplies, and contract research, tied to work that meets a four-part test. The test is applied to a “business component,” which can be a product, process, software, technique, or design. The regulations let you narrow the question to the most significant part of a component when the whole does not qualify (Treas. Reg. 1.41-4). In practice, a project is not all in or all out. Parts of it may qualify while other parts do not.

To make that concrete, here is a hypothetical job. It is illustrative only, not a client example. An integrator is awarded a multi-room venue: a networked video distribution system, a digital signal processing (DSP) design for a difficult acoustic space, a custom control interface, and integration of equipment from several manufacturers that were never designed to work together.

The four-part test, in AV terms

You do not need to memorize the test, but it helps to see how each element maps to shop-floor reality. The research generally must be:

1. For a permitted purpose, meaning a new or improved function, performance, reliability, or quality.
2. Technological in nature, relying on engineering, computer science, or the physical sciences.
3. Aimed at eliminating technical uncertainty about the capability, the method, or the appropriate design.
4. Part of a process of experimentation, which the regulations describe as evaluating alternatives through approaches such as modeling, simulation, or systematic trial and error.

Two practical notes. Style, taste, and cosmetic design factors do not count toward the permitted purpose. And the statute asks that substantially all of a component’s activities be experimentation, which is one reason the task-level view matters.

Task by task: where the line often falls

Tasks that may be worth a closer look

• Custom control programming where no existing module fits. If your programmer had to develop logic, drivers, or state handling because the off-the-shelf option could not do what the design required, and tried more than one approach to get there, that work may meet the test.
• Signal-flow and DSP design to hit a performance target. Designing a processing chain for a room that fights you, then measuring, adjusting, and re-measuring against a target, looks like a process of experimentation. A single pass through a manufacturer’s wizard does not.
• Cross-vendor integration with unknown compatibility. When it is genuinely uncertain whether devices from different makers can be made to interoperate at the required latency, resolution, or reliability, resolving that question can be technical work.
• Network and timing problems in AV-over-IP. Solving synchronization, bandwidth, or latency behavior that the documentation did not answer may qualify.

Tasks that usually do not

• Mounting, racking, cable pulling, and terminations built to standard practice.
• Loading a manufacturer’s template or a known-good configuration and confirming it works. The statute excludes adaptation of an existing business component and duplication of one (IRC 41(d)(4)), and reusing last month’s program with new room names is likely to fall on the wrong side of that line.
• Routine commissioning and punch-list work that follows a known procedure.
• Appearance-driven choices, such as interface styling or finish selection.

The gray area

Reusing code from a prior job and then modifying it is where many firms get stuck. Whether the changes are routine adaptation or a real technical effort depends on what was uncertain and what was actually tried. Warranty and troubleshooting work can fall anywhere depending on its facts. These are the items that benefit most from a second set of eyes, and they are worth a conversation rather than a guess.

Whose time counts

Qualified wages generally include time spent directly performing qualified research, directly supervising it, or directly supporting it, for people who are your employees. For an integrator, that often means the programmers and system designers, the lead who resolved the integration problem, and sometimes the technician who ran the tests. It does not usually mean the full install crew on a routine day. If you pay an outside programmer or engineer, contract research rules can apply, and those depend heavily on the written agreement.

The paper trail you probably already have

Nothing here requires a new system. Regulation 1.41-4(d) asks that records be kept in a sufficiently usable form and detail to substantiate the claim. The IRS instructions for Form 6765 now ask filers to report qualified expenses by business component for tax years beginning after 2025, with limited exceptions. For an AV firm, the raw material is often already sitting in project folders: program revision history, signal-flow drawings, test and tuning notes, change requests with a line on why the change was made, and the time records that show who worked on what. A one-line “why we changed this” on a revision goes a long way.

What this can look like in practice

One Utah audio-visual firm we worked with identified more than $300,000 in credits after a structured review of its project work. Individual results vary, and depend on the specific activities, documentation, and facts involved. The point is not the number. It is that the work was already happening, and the firm had not looked at it through this lens.

The next step

If your team has built custom programming, solved a stubborn integration problem, or tuned a system to a target that did not come out of the box, the work may be worth a look. Strata offers a $0 initial assessment to help you see where your projects may fall. If you move forward, the turnaround is typically four to eight weeks, depending on the specifics, and most of the work sits with the provider rather than your team. We also offer more than one way to work together, and we are glad to walk through which fits. The study you receive is a documentation package built to support the claim, and your CPA files the return.

Ready to talk it through? Schedule a 15-minute review at stratataxgroup.com/contact.

This post is for informational purposes only and does not constitute tax or legal advice. Consult a qualified tax professional regarding your specific circumstances.