Your provider should be able to group your Git repositories into separate R&D projects or components based on the names you assign them. Sometimes software engineers give their repositories whimsical names or internal code names. It'll be difficult for an outsider provider to guess that a repository called 'Obi-Wan Kenobi' contains the code for your e-commerce website search indexer.
Equally as important, your provider should be able to differentiate repositories associated with commercial-use code (e.g. your SaaS product and/or its components) vs. internal-use code (e.g. the dashboard you built to help with billing customers).
The reason: The IRS rules for qualifying internal-use software (IUS) projects are more stringent than those for qualifying commercial-use software projects. Therefore, it's especially important to be able to break out IUS repositories from commercial-use repositories, so that you can treat them differently when determining whether and how much the projects might qualify.
Examples: Project_1, Project_2, Component_1, Component_2, IUS_dashboard, IUS_tools.
Often, software companies may use open-source code to satisfy a requirement of their project or product. Sometimes, this will mean making a 'fork' of an open-source repository, and adding custom changes to it. A repository like this will likely contain work by many software contributors outside of your organization, which you don't want to capture for the purpose of documenting your engineering team's R&D activities.
To make things easy come tax time, add a phrase such as "open-source" or "OSC" to the end of the repo name. That way, your provider can address open-source repo(s), and any extraneous data contained therein separately from the rest of your team's (completely proprietary) repositories.
Examples: Component_1_open-source, Component_2_OSC
This is a version control best practice (exclusive of R&D Credit documentation) that most teams already use. Still, it's important to reiterate here.
In an ideal world, you want your team to enter commit messages that are useful enough that a person would be able to identify the type of task the engineer was working on:
We're not suggesting your team spend any extra time than they ordinarily do entering commit messages, only that those messages contain useful notes about the commit.
Entering commit messages like "hhhhhhhhhhh" (that's a sigh, and here’s a relevant xkcd comic), when you're fed up with that broken piece of code won't help you or your engineering teammates in the long run.
For examples, check out the commit messages in the public repositories for Django and React on GitHub.
The IRS requires companies that claim the R&D Credit to keep documentation that substantiates the company's R&D activities (Qualified Research Activities) and the expenses associated with those activities (Qualified Research Expenses; wages, contractor expenses, supplies). The reality is that most startups have a million other things going on that are more critical to the success of their business than to ask their engineers to keep daily time-tracking and activity records so that the company can claim the R&D Credit. Using the contemporaneous Git data your engineering team is creating as part of their regular engineering workflow provides both a data-driven estimate of Qualified R&D and a streamlined way for your company to create the documentation the IRS requires of companies claiming the R&D credit, without the disruption or hassle of engineering interviews or lengthy questionnaires.
The R&D Credit is one of the most significant tax incentives available for startup companies, often returning around 6-10% of engineering payroll back to the company in the form of tax credits. Even pre-profit startups with no income tax can now apply the R&D Credit to offset the FICA portion of their payroll taxes up to $250K per year.
Information Security note: TaxCredit.ai is an R&D Credit SaaS application that analyzes the metadata associated with your team’s Git logs, but not your source code or intellectual property.