Strike Summary
- R&D credits for software development companies can provide them with a significant source of capital.
- Software companies claiming business tax credits should carefully set up their git log processes to substantiate R&D claims.
- Retraining your development team to improve their records will save you significant time and money in the long run.
55% of software development expenses typically qualify for the research and development (R&D) Tax Credit. For many startups, the R&D Tax Credit can make a significant difference in their bottom line—giving them the stimulus they need to hire new employees and reinvest in their business.
Recent IRS R&D tax documentation changes have changed the quality of documentation that the U.S. government will accept as proof of R&D work. Going forward, it won’t be enough to simply submit the kind of research employees are engaged in. Now, the IRS wants to know who the employee is, the hypothesis they started with, and the information they uncovered. Keeping accurate, current records will protect software companies’ R&D claims from denial.
Fortunately, software development companies already use built-in documentation tools. If a company trains its employees to correctly describe their research activities, Git-based Source Control Management (SCM) systems like GitHub, Gitlab, Bitbucket, etc., can provide an excellent source of R&D documentation.
How Can Git Logs Help with R&D Tax Claims?
As a developer uploads their Git commit logs to the company’s repository, the team can collaborate no matter where they’re physically working. For many software companies, these logs are a robust documentation of their workflow. They can clearly demonstrate a developer’s thought process before, during, and after a product launch. Git commit logs can be one of the best pieces of evidence for defending R&D claims because they’re a snapshot of work in progress.
However, Strike’s personal experience with software development is that development teams don’t provide enough information in the Git logs to pass IRS scrutiny unless they’re trained to do so. A raw git log won’t demonstrate that the work should be included as a qualified R&D expense (QRE). Additionally, including a git log as part of an R&D claim, and then going back to fill in details months or even years later, instills sloppy documentation practices in your software team. Instead, train your software team to create effective Git commit logs from the beginning of your project, and file all of your software R&D claims with confidence.
Make Sure Your Git Records Support R&D Documentation
- CLEARLY DEMONSTRATE THE PROCESS AND APPROACH IN GIT
In order to pass the 4-part test, the software development process needs to demonstrate technical uncertainty and a process of experimentation through which alternative solutions to the uncertainty were evaluated. Therefore, the motivation behind every code push needs to be recorded in every commit message. Developers should follow commit log best practices by:
- Clearly labeling open-source code so reviewers can see where the original code diverges.
- Maintaining the canonical repository as a clean history of the source code.
- Consistently defining what the commit does with tags like [PROD] or [TESTING].
- Including a code message that explains why the codebase or system couldn’t fix the problem.
- Cataloging failures as well as success in code messages.
- Categorizing commits as “feature enhancements” or “bug fixes” to differentiate those commits that meet the 4-part test requirements.
- MAKE GIT ENTRIES SELF-EXPLANATORY
Train your software developers to err on the side of giving more information. Frustrated or tired developers might be in the habit of labeling a commit with “updates” or “fixed this,” which won’t be clear enough to pass an auditor’s inspection.
The commit should include enough context in the title and body paragraph to demonstrate how the change contributed to technological advancement to someone unfamiliar with the project. Otherwise the work and its cost could risk rejection. Everyone needs to be trained on the standardized naming/labeling conventions, terms, acronyms, and avoid confusing abbreviations and jargon at all cost.
Commits should look like:
Subject/title (50 char.) - Short description of the commit, including functionality, performance, quality, or reliability enhancements to the software
Body paragraph (wrapped to 72 chars.) - Extended description of the code being pushed and the results of the QA/QC testing
(Optional) Reference to your issue tracker - Task ID with the hours utilized for the same
- COMMIT AS REGULARLY AS POSSIBLE
Software developers should commit as often as possible, especially when the team’s work is dependent on their changes. Commits that contain many small changes can be difficult to justify. Self-contained commits are easier for accountants, auditors, or reviewers to validate as a QRE. As a result, best practices should be that commits happen every time a specific issue is solved. This helps developers if they need to roll back changes and helps outside eyes on the project quantify R&D.
Final Thoughts on Best Practices for Git Data and R&D
Retraining your software development team to keep better Git commit logs may take some time, but the payoff can be quantified in both time and money. R&D claims are processed more quickly when Strike’s R&D Experts have access to clear documentation, returning funds back to your company’s bottom line. With personal experience in R&D and software development, Strike’s team is prepared to help you claim the money you’re owed for innovations in software.
