Your Client's AI Project May Be Creating an R&D Tax Credit Opportunity | RHW CPAs

For AI consultants, agencies & fractional CTOs

Your Client's AI Project May Be Creating an R&D Tax Credit Opportunity

A practical guide for AI consultants, agencies, and fractional CTOs: technical experimentation, contract risk, and the evidence clients should preserve before year-end.

By Chea Romine, CPA · Managing Partner, RHW CPAs

AI consultants are moving traditional businesses into territory those businesses may never have associated with research and development. A distributor that once purchased software is now building a custom document-processing system. An insurance agency is testing ways to extract and validate information from carrier documents. A professional-services firm is developing its own method for matching information across emails, meeting notes, phone records, and document systems.

These companies may not think of themselves as technology companies. Yet some of the work they are undertaking may create a legitimate federal R&D tax credit opportunity.

The AI consultant is often the first adviser in a position to recognize it. You understand what the client is trying to build, where the available tools fall short, which technical questions remain unresolved, and how the team plans to test possible solutions. Raising the issue early can help the client evaluate the opportunity while the project, contract, and supporting evidence are still taking shape.

The opportunity often begins when buying turns into building

Purchasing an AI license does not, by itself, create an R&D credit. Neither does deploying a standard chatbot or configuring a commercial platform to perform functions it already supports.

The analysis changes when the available product cannot meet the client's requirements and the client or its consultant begins developing something new around it. That might include a custom data pipeline, retrieval architecture, validation layer, evaluation harness, integration, agent workflow, or performance improvement.

The strongest opportunities generally share a recognizable development story:

The business needs a new or improved function, level of performance, reliability, or quality.

The team does not know at the outset whether the result is technically achievable, which method will work, or what the appropriate design should be.

The developers identify alternatives and evaluate them using testing, modeling, simulation, or systematic trial and error.

The results, including failures, change the technical design.

A practical question for an AI consultant to ask is:

What did the client need the system to do, what technical answer was unknown at the beginning, which alternatives were evaluated, and what results changed the design?

If the project has a substantive answer, it deserves a closer look.

Five AI development patterns worth recognizing

1.Building a custom layer around a purchased platform

Suppose a company buys a document-processing platform that achieves only 65% accuracy on its records. The developers create custom preprocessing, classification, validation, and exception-handling layers. They build an evaluation dataset, compare five approaches, and eventually reach 95% accuracy.

The potentially qualifying work is not the platform purchase. It is the custom technical development and evaluation undertaken to resolve the accuracy problem. License costs, user training, and routine configuration should be separated from that work.

2.Resolving identities across inconsistent data sources

A business wants to connect emails, meeting transcripts, phone notes, and stored documents to the correct customer. No shared identifier exists across every system. The team tests combinations of names, addresses, email addresses, telephone numbers, and source-specific weighting methods. It measures false matches and missed matches, then changes the design for different ingestion sources.

This is more than ordinary data cleanup when the team is resolving genuine technical uncertainty through repeatable testing. The qualifying portion may include the matching architecture, source-specific experiments, automated ingestion methods, and evaluation process, not routine manual corrections after the system is operating.

3.Developing a RAG system with measurable requirements

A client needs an internal knowledge system to return accurate answers within a strict response-time limit. The team does not know whether vector retrieval, a knowledge graph, hybrid search, or reranking will satisfy both requirements. It creates a representative question set, measures retrieval quality and latency, and compares architectures.

The fact that the project uses retrieval-augmented generation does not prove eligibility. The meaningful facts are the technical uncertainty, defined alternatives, evaluation method, and results that guided the architecture. If the system primarily supports general administrative...