3 Steps to Better Documentation of SR&ED in Git-Based Systems
If you are engaged in software development, then in all likelihood you’re using a Git-based Source-Control Management (SCM) system such as GitHub, Gitlab, Bitbucket or other SCM’s to enforce version-control and to coordinate work amongst your team. If you have a issue tracker or project management system in place, then our default recommendation is for you to leverage it exclusively as a single source of truth for logging work activities and project progression from a SR&ED perspective (check out other articles in our series here), as the CRA has a noted preference for information that’s summarized and hierarchically organized from the project down to the individual activity level (with subtasks which may or may not involve hands-on coding). For companies that rely exclusively on Git, there are a few ways to modify or augment existing interactions and practices such that the Git logs more closely align with documentation requirements as prescribed in the SR&ED policy. At ENTAX, we’ve helped many companies claim SR&ED where the only available evidence or documentation was in Github, Bitbucket or some other SCM. It’s not an uncommon situation but for SR&ED purposes, its also not the most ideal.
CRA policy requirements for making a SR&ED claim require that you demonstrate a logical, systematic approach to problem-solving in the course of experimental development (NOT a trial-and-error one). Be mindful of the fact that this program is all about incentivizing and rewarding activities with a risk of failure in an attempt to advance a science or technology field, rather than the outcome of the effort, therefore it is largely irrelevant whether or not you ultimately succeeded in that effort. In the eyes of the CRA, the closer your R&D processes align with the scientific method (question, hypothesis, test, analysis), the stronger your overall SR&ED claim. In the spirit of the scientific method, which demands carefully maintained and updated records (for reproducibility of experiments, knowledge transfer), a strong SR&ED claim is backed up by documentation of a contemporaneous nature i.e. recorded at the time the work took place, NOT generated retroactively. Documentation that complies with SR&ED requirements should communicate who was involved in what work, when work was performed, how that work was carried out, and relate the work back to a science or technology objective, in order to explain why that work was necessary to overcome a scientific/technological uncertainty.
In theory, a git log is an excellent piece of supporting evidence for your SR&ED claim, as it records the time of each upload to your repository and provides a description of what the associated change was attempting to accomplish. Many companies assume that commit logs are one of the best pieces of evidence for defending SR&ED labour allocations‒after all, they’re indisputable contemporaneous records of work done on a project. However, in our experience most git logs are characterized by variably messy, sparse, and or esoteric commentary that altogether fail to properly contextualize development work in respect of SR&ED. Looking at a raw git log, the CRA reviewer often can’t tell whether or not the commits speak to SR&ED eligible work, at least not without substantial effort by you (unfortunately) to retroactively contextualize and articulate raw Git information in a way that’s easily digestible for an external audience. As a result, changing the way you make commits can have a huge return in terms of SR&ED eligibility and defensibility.
Read our 3-Steps on how to better track SR&ED in Git below...
Use Jira and struggle with documenting SR&ED?
Use Trello and want to document SR&ED better?
Do your Git-based repos need better SR&ED tracking?
Here are 3 Steps to Better DoCUMENTATION IN GIT:
1. Demonstrate your process and approach in Git commit messages
The CRA’s Eligibility of Work for SR&ED Investment Tax Credits Policy defines Experimental Development as “work undertaken for the purpose of achieving technological advancement…”. In this light, demonstrating the motivation behind a given code change is one of the most important factors for your SR&ED claim’s success. Simply presenting a code diff as evidence for what changed is not enough, in order to be good evidence your commit needs to explain why the existing codebase/system wasn’t able to overcome your obstacle, and how a particular change was intended to resolve that.
The most important part of this is the why. The Income Tax Act defines SR&ED as a “systematic investigation or search...” Without the reasoning behind your development, a reviewer might come to the conclusion that you were simply throwing things at the wall to see what stuck, rather than conducting a planned and intentional approach that is admissible under SR&ED requirements. Having context in your commits demonstrates all of the effort that went into the planning and testing of a change.
Within a message, if the title truly says all that needs to be said, then a body paragraph is optional, but there are good odds that spending just a minute or two typing up even a sentence or two for context will make the difference between a finding of “eligible” versus “routine”, especially you can show why a seemingly trivial task is commensurate with the needs, and directly in support of your SR&ED.
If you happen to use issue tracking or project management software in conjunction with Git, then we highly recommend you add references to specific issue IDs or work entries in these systems somewhere within a commit message, or alternatively reference specific commits in the higher-level tracking system. Note that in these situations, the underlying presumption is that the high-level tracking system is sufficiently descriptive and detailed to present as evidence in a SR&ED audit, thereby relegating git commit references to be supplemental supporting information.
2. Make things more human-readable
If your SR&ED claim comes up for review, a CRA auditor will be looking over your supporting evidence to try and understand the work. It’s up to you to make sure that the evidence is clear and understandable. Lazy commit messages such as simply stating “Optimizations” would be interpreted as routine ineligible work, but the exact same code change with a message like “Added parsing logic to ObjectA to boost search speed” might be SR&ED eligible, especially if the commit includes additional lines in the commit with more context as to how this change was done in support of technological advancement. Or the same reason, naming/labeling conventions, terms, acronyms, and insider jargon should all be standardized across commit messages issues to enable an outsider to understand what tasks are logically related to one another. Otherwise, you risk rejection of eligible SR&ED work simply because the language used to describe work was inconsistent with descriptors used in other qualified tasks.
One of the simplest way to ensure that your commits clearly communicate work to an auditor is to treat them as if they were an email to a collaborator: a descriptive subject line followed by a body paragraph, and with any attachments or references at the bottom. The format might look like this:
subject/title (50 char.)
body paragraph (wrapped to 72 chars)
(Optional) Reference to your issue tracker
A subject line should be distinctive and easily searchable. Your auditor won’t take your word on which specific commit among hundreds of “fixed bug” messages is SR&ED.
3. Commit often
Commits that do many things at once can be hard to justify. While small, self-contained commits are easier for an auditor to understand, a CRA reviewer may be tempted to exclude a patch that fixes a UI bug and improves the performance of a feature because there wasn’t a clear separation between SR&ED and routine work. If your commits cover multiple topics, it’s wise to split them up into separate issues, that way there’s less confusion as to what tasks are under what logical umbrella.
It’s perfectly okay to combine commits that are logically related. For example, the development of a feature and the corresponding tests should be in the same commit. That said, you may want to err on the side of too-many, rather than too few, patches. In general, if you can’t summarize your change at a high-level in one sentence, chances are you are trying to cover too many topics at once, and should consider splitting up the commit into multiple individual changes to avoid confusion. Whatever you do, don’t make end-of-day commits with a diff that spans all across the code and has changes that are impossible to follow or understand, as this will surely cause your work to be ruled ineligible from a lack of controls to separate SR&ED from non-SR&ED.
Of course, with all these suggestions the key is how to balance the needs of SR&ED with all the other competing and perhaps, more important, processes you have in your R&D department.
To learn more about how we can help you implementent the best SR&ED documentation practice, contact us today for a no-obligation consultation.
HOW ENTAX CAN HELP
Contact us to learn more about how we can help your software company claim and optimize SR&ED. With our deep understanding of SR&ED in Agile Software environments and with market-leading software tools like SREDtrak for JIRA and SREDbot for Slack, ENTAX can help you reach your SR&ED objectives.
ENTAX is a Research & Development advisory firm for technology companies. We specialize in Scientific Research and Experimental Development (SR&ED) tax credits and other Government incentives across all industries for companies large and small. We provide a full scope of SR&ED tax credit and incentive advisory services and provide the highest quality service. Our goal is to build long term, positive client relationships and with our Government agency partners.