What a Linear issue can show
For many software teams Linear holds both the plan and the outcome of the work: what someone set out to find, the comments as they went, and the state it closed in. That makes an issue a useful record for an R&D claim, with two limits. It shows that work on a question was underway between two dates and who owned it, not how many hours it took. And it shows what the team wrote, not that the work was R&D: that depends on whether the outcome was genuinely unknown in advance and the work progressed systematically, which a person decides.
AusIndustry's software sector guide lists spike tickets and investigation tasks among the places software R&D records live. Under section 355-25 of the Income Tax Assessment Act 1997, what those records need to show is the systematic progression of work: hypothesis, experiment, observation, evaluation and conclusion.
An example issue, from start to claim
The issue below is made up for illustration; nothing here comes from a customer account.
Issue ML-214 in the ML team, "Test int8 quantised embeddings on device", is created on 28 January, moved to In Progress on 4 February and completed on 19 February. Its comments record two benchmark runs, and a pull request whose branch names ML-214 holds the code.
In Rand that becomes one record in the financial year that contains 28 January, the day the issue was created. It shares a work episode with the pull request, so the code and the ticket count once. Rand's AI reads it with its comments, parent and related issues, because a terse ticket often makes sense only beside its parent, and proposes the core or supporting activity it belongs to; where the issue is ambiguous, the team gets a short question instead. Under active-day time, the assignee's working days from 4 to 19 February become work days in their February estimate, counted towards the R&D share once the issue is decided as R&D. Weekends, leave and public holidays add nothing, and the hours stay an estimate until a director signs the year.
Which issues become evidence
Linear is often a whole-company tool, so team scope matters more here than in a code host. Select the teams that do engineering or research and Rand reads only their issues. As a backstop, Rand's first screen reads each issue's team, state and labels:
- Issues from teams named for finance, payroll, legal, HR, sales, marketing or similar functions are filtered unless the issue mentions R&D terms such as experiment, prototype or benchmark. Teams named Growth, Support or Operations are not filtered but flagged for the AI to look at more closely.
- Triage, Backlog and Todo issues are held back, because a ticket nobody has started records no work. The state rules run again when the issue changes, so it comes back as soon as it moves into a started state.
- Cancelled and duplicate issues are dropped.
- Labels such as chore, ci, dependencies, release or maintenance filter an issue unless it mentions R&D terms; documentation labels send it to the AI with a flag.
Under the hood
- Access. You authorise Rand on Linear's consent screen, which grants the read scope and nothing more; Rand's integration code sends queries only. Linear access tokens last 24 hours, so Rand refreshes the token when it expires and asks you to reconnect only if the refresh fails.
- Timing and scope. Rand imports the claim year month by month, then keeps up through a daily sync and Linear's webhook. The same team selection applies to both.
- Context kept. Up to 100 each of comments, sub-issues and related issues per issue, plus the parent issue and attachment titles and links.
- Work dates. Every working day from started to completed counts when the two are no more than eight weeks apart, because the sync stores no status history. A longer window keeps only the started and completed days. An issue with no assignee is attributed to its creator.
To write issues that read well as hypotheses and results, see Linear issues as hypotheses and results. Linear pairs naturally with GitHub, and design thinking often lives in Notion. For how core and supporting work is separated, see the glossary entries for a core R&D activity and a supporting R&D activity, and the R&D Tax Incentive resources.