Blog & Insights

What Your Software Firm Should Hand You for an R&D Credit Claim

A checklist of what a software firm should be able to produce for your tax partner, what we provide as a normal part of an engagement, and what we do not do. From working alongside clients' CPAs and credit specialists on their claims.

When a client’s tax partner calls us about a research credit claim, the conversation is short if the engagement was run properly. They ask for a handful of documents. We send them. The specialist writes the narrative from what is there.

When the conversation is long, it is because the firm that did the work kept nothing, or the client did not know to ask. This post is the checklist we wish every owner had before their first project, whoever builds it. It closes with what we provide and, just as important, what we do not.

What to ask for, whoever builds your software

Ask any firm you are considering whether they can produce the following at the end of a project. If the answer is a blank look, that tells you something about how they work, credit or no credit.

  1. A statement of work with a technical objective. Not just a feature list. What the system is meant to do that your business could not do before, and what was uncertain about getting there.
  2. The rights and payment terms in writing. You own the code, the IP, and the data. You pay for the work itself, not only for a result promised in advance. Those two clauses are what let your CPA count the firm’s fees.
  3. A record of the design decisions. What alternatives were considered for the architecture, the integrations, and the hard problems, and why the team chose what it chose. This is the experimentation the credit rewards.
  4. Sprint or milestone history. What was built when, what was reworked, and what changed after testing or user feedback.
  5. Test records. Test plans, results, performance and integration testing.
  6. Time by person and role. Who worked on the project and how much. Contract research counts at 65 percent of the fees, but the narrative still wants to know who did the engineering.
  7. A closeout report. What was delivered, how it was validated, and what remains. This one document usually gives the specialist most of the narrative.
  8. Invoices tied to statements of work. So the qualified spend can be separated from anything that was not research, such as hosting or support.
  9. Where the work was done. Development outside the United States does not count toward the federal credit. Ask.

What we provide, and why it is not extra

Most of that list is a byproduct of how we run a project, which is the reason our clients’ claims have tended to go smoothly.

The planning step writes the objective. Every new build starts with a fixed-fee Validation, Design & Planning engagement, and every existing system starts with a System Evaluation. Both produce a written description of the goal, the constraints, the unknowns, and the recommended approach. That is the technical objective, documented before the first line of code, which is exactly what a claim wants.

The delivery process records the experimentation. Sprint reviews, decision records, architecture notes, and the backlog history live in your repositories and your project space, not ours. When something is tried and replaced, it is visible.

Testing is part of the work, not a phase at the end. Test plans and results exist for each release, because that is how we keep software safe to depend on. They double as evidence of the process.

Our contracts are written the right way around. You own everything we build. Our statements of work pay for the effort. Your CPA can read them in ten minutes.

The team is in Texas. Nothing is handed offshore after you talk to someone local, which means the federal credit is not at risk on the question of where the work happened.

We break out support. Managed hosting and support run on their own agreements, so the research spend is not mixed with the cost of keeping systems running.

We take the call. When a client’s CPA or credit specialist needs something explained, we get on the phone. We have worked with clients’ tax partners ranging from their own accountants to specialist firms such as Houston-based alliantgroup, and the pattern is the same every time: the fewer surprises in the records, the faster the claim.

What we do not do

We do not prepare claims, calculate credits, or give tax advice, and we will not tell you whether your project qualifies. That judgment belongs to your CPA or a specialist who knows the rules and your return. What we can promise is that if you tell us at the start that you intend to claim, the evidence will be there at the end, organized by project, in your own systems.

Before you sign with anyone

Three questions that take a minute and save a month:

  • Will I own the code and the IP outright?
  • Am I paying for the work, or for a result?
  • At the end, can you hand my CPA a written objective, the decision history, the test records, and time by person?

If the answers are yes, yes, and yes, you have a firm whose work can support a claim. If any answer is no, you have learned something before it cost you.

The two earlier posts cover whether custom software qualifies and how the claim itself works.

This is general information, not tax advice. Talk to your CPA or a credit specialist about your situation.

More like this, in your inbox. Subscribe for our latest thinking, resources, and events.

Get started

Not sure where to start? Start here.