In this article: Learn what R&D iterations are, how to recognize them in everyday technical work, and how to document them for R&D tax credit claims.
One of the most common questions companies ask during a research and development (R&D) tax credit interview is:
"How many iterations did we perform?"
For many engineers, software developers, scientists, and technical professionals, the answer isn't immediately obvious. They know the project changed over time, but they don't necessarily think about their work in terms of "iterations."
The reality is that many R&D projects involve multiple iterations. When those iterations are tied to technical uncertainty, alternative approaches, and evaluation of technical results, they may help demonstrate a process of experimentation.
An iteration is a repeated cycle of technical development in which information gained from previous work is used to refine, change, or evaluate a design, process, formulation, algorithm, or prototype.
Rather than following a single straight path from concept to completion, R&D projects typically progress through many cycles of testing, observation, refinement, and additional testing until the technical objectives are achieved, or until the team determines a particular approach will not succeed.
Each iteration provides new technical information that guides the next phase of development.
For R&D tax credit purposes, documented iterations may help demonstrate that a company engaged in a process of experimentation rather than simply applying existing knowledge or following established procedures.
The form an iteration takes depends on the type of work being performed.
Manufacturing
A manufacturer developing a new asphalt formulation may produce multiple laboratory batches with varying material compositions. After each round of testing, engineers evaluate the material properties, revise the formulation, and prepare another small batch for evaluation.
Each technical formulation change may represent another iteration.
Software Development
A software team may release multiple internal builds while developing a new feature. Performance testing, load testing, defect discoveries, or architectural limitations may lead developers to revise the code before beginning another development cycle.
Each cycle of coding, testing, evaluation, and refinement constitutes an iteration.
Product Development
A product engineering team may create several prototype versions, each addressing issues identified during functional testing. Design geometry, materials, tolerances, or manufacturing methods may change between prototypes.
Each prototype revision is an iteration.
Civil Engineering
An engineering firm may evaluate multiple roadway alignments, hydraulic models, drainage layouts, or traffic control alternatives when technical constraints require the team to compare performance, reliability, constructability, or functionality before moving the design forward.
Each analytical cycle that refines the technical approach based on engineering observations represents an iteration.
Although the activities differ across industries, the underlying concept remains the same: technical knowledge gained during one cycle informs the next.
There is no minimum or maximum number of iterations that automatically qualifies or disqualifies a project for the R&D tax credit. What matters is whether the technical work involved evaluating alternative approaches to resolve uncertainty related to capability, method, or appropriate design.
Some projects involve only a handful of significant design cycles. Others, particularly software projects using Agile or Scrum methodologies, may involve dozens, or even hundreds, of iterations over the course of development.
The important question is not whether a project had "enough" iterations. Instead, ask:
These questions help demonstrate the ongoing process of experimentation.
Many companies already perform iterative development but simply use different terminology.
Ask yourself how your organization naturally tracks technical progress.
Software companies may recognize iterations as:
Manufacturers may think in terms of:
Engineering firms often describe iterations as:
Research laboratories may refer to:
The terminology is far less important than the underlying technical process. If technical findings from testing, modeling, analysis, or evaluation led your team to revise its approach, that revision may represent an iteration.
One of the advantages of modern engineering and software development is that iterative work often leaves a substantial documentation trail.
Useful documentation may include:
Even when a formal "iteration log" does not exist, these materials often provide a clear record of how technical work progressed over time.
The strongest documentation goes beyond simply counting iterations. Instead, explain what changed during each cycle and why.
For example, rather than stating: "The team completed eight prototype iterations."
Provide additional context:
"The team completed eight prototype iterations while evaluating enclosure geometry, material thickness, internal support layouts, and fastening methods. Results from each round of structural testing guided subsequent design revisions until the required performance characteristics were achieved."
Similarly, instead of writing: "Five software releases were completed."
Describe the technical progression:
"Five development iterations were performed to evaluate alternative caching strategies, optimize database query performance, and improve synchronization logic after performance testing revealed latency under peak workloads."
This approach demonstrates how each iteration advanced the resolution of the underlying technical uncertainty.
Iterations are most helpful when they are connected to the specific technical uncertainty, the alternatives evaluated, and the technical findings that informed later work.
Companies sometimes worry that they cannot support an R&D claim because they did not formally number every development cycle.
In practice, very few engineering teams stop after every technical change to record, "Iteration 17 completed."
Instead, document the development process honestly. Use existing project records to reconstruct the major cycles of technical work where appropriate, and avoid inventing arbitrary iteration counts.
The goal is to accurately explain how the project evolved, not to fit the work into a predetermined format.
Documented iterations are one of the clearest ways to show that a company engaged in a genuine process of experimentation. They show that technical development was not a one-time exercise but a series of informed decisions driven by testing, analysis, and engineering judgment.
By recognizing how your organization naturally performs iterative development and documenting how each cycle contributed to resolving technical uncertainty, you can build stronger, more credible support for your R&D tax credit claim.
Strong documentation does more than record the final outcome. It tells the technical story of how your team arrived there.
Discuss potential R&D credit eligibility and documentation practices with a qualified tax professional.
Schedule a complimentary R&D consultation with Randy Eickhoff, CPA, Founder & Head Coach of Acena Consulting.
Sign up for the Acena newsletter to stay abreast of all upcoming events.
Follow Acena on LinkedIn for the latest industry-specific incentives and tax policy updates.
//
Edited by Laura Whittenburg, M.S., Biomedical Engineering, Sr. Technical Writer
Photo: Seattle Municipal Archives on Flickr