Two kinds of evidence from one tool
Many software teams already describe their work in Jira, and some log time there too. Rand reads both and keeps them apart, because they prove different things.
Activity evidence. An issue says what the work was, and its status history shows when it was underway. Each issue becomes a record that Rand's AI assesses once for relevance and placement: is this R&D, and which core or supporting activity does it serve? The answer is a proposal. Where the issue does not say enough, Rand asks a short question in Needs information instead of guessing. An issue supports a claim; whether the work is R&D still turns on its substance, a genuine unknown worked through systematically, and a person decides that.
Time evidence. Rand's default method calculates R&D time from active days. Jira worklogs are the one source it treats as tracked time: a block of time a person recorded against an issue counts as logged, as R&D or ordinary work depending on the decision about that issue. The active-day share then covers the rest of each person's available hours, after leave and public holidays.
A worklog counts on the date the person gave as the start of the work, not the date the entry was typed in. Jira keeps both, which is why entries made on the day hold up better than a month entered at once. The ATO says timesheets or job cards are the most accurate way to allocate time, and that backdated or non-specific records are not appropriate. A worklog entered on the day is close to a timesheet entry; the Jira worklogs guide covers how to write them.
Details that change the numbers
- Worklogs are filtered to the claim year by the date the work was done, never by an all-time total.
- Time logged on a day the person was not working, such as a public holiday or recorded leave, is shown but not counted unless an owner or manager records it as a day worked.
- A day with more logged time than the person's available hours is held to that day's hours and flagged.
- A month above 80% R&D from logged time is not cut down to a monthly ceiling. It is flagged for the director to check when signing the year.
- Without worklogs, the days an issue spent in In Progress, In Development, In Dev, Coding, Developing, Working or Implementation become its work dates. A plain edit or comment never does. Other status names are not recognised, so on custom workflows worklogs are the dependable source.
An issue whose work crosses 30 June becomes a separate record for each financial year, each holding only that year's dated evidence. Epics are screened out as planning containers, so time and evidence belong on the stories, tasks and spikes under them.
Who confirms what
People confirm which issues are R&D and where they belong. After the year ends a director signs each person's hours with the time allocation schedule, and only then are time logs written and costed. Until then, the hours on the Time page are an estimate.
Connection details
- Access. You authorise Rand through Atlassian's consent screen and choose one site. Rand requests read, read and offline_access, which let it read issues and users and keep the connection alive between visits, and none of which allow changes.
- Timing. Rand imports the claim year month by month, then keeps up through a daily sync and, where a Jira webhook is set up, through deliveries that must carry a valid secret and match your site.
- Which issues. Rand searches for issues created before the end of the year and updated after its start, so a ticket opened in March of the previous year still counts if someone logged time on it in August. Inclusion is then decided by the dated work history, not by the update date.
- Completeness. For each issue Rand fetches every page of the changelog and every worklog. If a page fails or the worklog total falls short of what Jira reports, the month is marked incomplete and retried rather than treated as covered.
- Comments. Up to 20 of the comments Jira returns with the issue are kept, so on a long thread the newest may be missing. Write the hypothesis and the conclusion into the issue description, where they are always read.
Most teams connect Jira alongside GitHub so pull requests join their tickets, and alongside Xero so hours meet payroll. The R&D Tax Incentive resources and the contemporaneous evidence glossary entry explain what the records must show.