You're probably looking at Jira tickets, GitHub commits, contractor invoices, and a Xero file that doesn't cleanly show what counts as R&D. R and D accounting in Australia is the discipline of separating experimental work from ordinary delivery work, then recording those costs correctly for both financial reporting and a possible R&D Tax Incentive claim.

Table of Contents

• What is r and d accounting in Australia
  • Three practical steps to take this week
• How are R and D costs identified and classified under AASB 138
  • What usually sits in the research phase
  • When development costs may be capitalised
  • A startup example
• How do R and D tax incentive rules affect accounting treatment
  • R&D Tax Incentive rates by entity size
  • Why the accounting treatment still matters
  • Self-assessment changes the burden
• What documentation and evidence should finance teams prepare
  • A workable evidence stack
  • What works and what usually fails
• How should software and engineering projects be recorded in accounting entries
  • Journal treatment should follow technical milestones
  • How to post software labour without creating a reconciliation mess
  • A practical example using Jira and GitHub
• What common mistakes should startups avoid in R and D accounting
  • Mistake one is capitalising too early
  • Mistake two is relying on retrospective narratives
  • Mistake three is applying the wrong accounting standard to the offset
  • A short pre-EOFY checklist
• How can finance teams streamline R and D accounting processes
  • What a lean process looks like
  • Where advisers and software fit
• Frequently asked questions
  • Can overseas developers be included in an Australian R&D claim
  • How should we reflect a possible R&D offset in forecasts
  • Should software licences be capitalised or expensed
  • How do we document mixed-scope projects with both R&D and product delivery work

What is r and d accounting in Australia

R and D accounting in Australia means identifying experimental work, tracking the related costs, and applying the right accounting treatment under AASB standards while keeping records that may support an R&D Tax Incentive claim. Done properly, it improves cash flow planning, reduces year end cleanup, and makes ATO-facing documentation far easier to defend.

For an early-stage software company, this usually comes down to one practical tension. Engineering work moves fast, but finance needs clean evidence. If product, engineering, and finance don't agree on what the actual experiment was, the accounting file ends up telling a different story from the technical record.

There's also a national context worth noticing. Australian businesses spent a record $24,410 million on R&D in 2023–24, and 42% of that sat in Information and computing sciences, according to the ABS release on business R&D in Australia. That matters because software startups aren't operating at the fringe of the regime. They're right in the middle of where the spend is.

Three practical steps to take this week

• Map live projects in Jira or Linear: Pull out active epics or projects that involve genuine technical uncertainty. Don't start with the tax schedule. Start with the engineering question being tested.
• Review cost coding in Xero: Check whether staff costs, contractor invoices, cloud costs, and software tools are being grouped in a way that lets finance separate experimental work from general product delivery.
• Set up a claim workflow: If you want a lighter process than year end reconstruction, review the guidance on the ClaimKit home page and the broader ClaimKit blog to see how teams structure evidence gathering before lodgement pressure hits.

Practical rule: If you can't explain the technical uncertainty in one plain-English paragraph, your accounting treatment is probably running ahead of your documentation.

How are R and D costs identified and classified under AASB 138

A lot of confusion starts when founders assume “R&D” is one bucket. It isn't. Under AASB 138 Intangible Assets, internally developed software costs are split into research and development. Research costs are expensed as incurred. Development costs are capitalised only when four criteria are met: technical feasibility, intent to complete, ability to use or sell, and probable future economic benefit, as set out in AASB 138 Intangible Assets.

What usually sits in the research phase

For software startups, research phase work often includes early architecture exploration, proof-of-concept builds, failed prototypes, model testing, and experiments where the outcome isn't known in advance. If a team is still asking, “Can this be made to work at all?” that's usually research territory.

Common examples include:

• Prototype investigation: Building a throwaway service to test whether a new data pipeline can handle a difficult performance constraint.
• Technical comparison work: Assessing competing approaches, such as whether an in-house inference workflow can outperform an off-the-shelf option for your use case.
• Failed experiment cycles: Work that produces learning, but not a stable asset ready for deployment.

Those costs generally go straight to profit and loss.

When development costs may be capitalised

Capitalisation starts later than most founders think. The team needs more than confidence and ambition. Finance needs evidence that the work has moved beyond exploration and into a build path that meets the AASB 138 criteria.

A practical way to test this is to ask four questions:

If one of those isn't supportable, expensing is usually safer.

Teams often over-capitalise because the product feels important. Importance isn't the test. Evidence is.

A startup example

Say your team spends months testing whether a new syncing engine can reconcile offline edits without corrupting customer data. While the result is still uncertain, the labour is typically research-phase expense. Once the architecture is proven, the company approves the build, and the team moves into controlled implementation of the production version, some later costs may move into development-phase capitalisation.

That accounting conclusion is about financial reporting. It is not the same as tax incentive eligibility. The two often overlap, but they don't answer the same question.

How do R and D tax incentive rules affect accounting treatment

The accounting file and the tax incentive file need to talk to each other, but they're not identical. A startup can have valid accounting under AASB 138 and still prepare a weak R&D Tax Incentive claim if the technical narrative is thin. The reverse also happens. A company may expense everything in the accounts but still have eligible activities for incentive purposes.

For Australian startups, the starting point is turnover. Under the R&D Tax Incentive, companies with aggregated annual turnover under $20 million may access a refundable tax offset of up to 43.5% on eligible R&D expenditure, while larger entities receive a non-refundable offset at their tax rate plus 13%, with a $150 million annual cap on eligible expenditure, as summarised in this overview of doing R&D in Australia.

R&D Tax Incentive rates by entity size

There's another threshold that catches founders out. To be eligible, a company must generally incur at least $20,000 in notional deductions on eligible R&D activities during the income year, unless it engages an approved R&D consultant, according to the ATO's eligibility guidance for the R&D Tax Incentive.

Why the accounting treatment still matters

Even though tax eligibility doesn't depend solely on whether costs were expensed or capitalised in the ledger, the ledger still drives your schedule quality. Finance needs to reconcile:

• Who incurred the cost
• Which project the cost relates to
• Whether the activity was experimental
• How much of a mixed-purpose cost belongs in the claim

If you want a plain-English summary of startup qualification rules, the ClaimKit eligibility guide is a useful starting point, and the Australian Government R&D Tax Incentive overview gives the policy-level framework.

For teams comparing workflows and software support, this guide to R&D Tax Incentive Australia is also helpful when you're deciding how much to handle in-house.

Self-assessment changes the burden

The scheme operates on a self-assessment basis. That means the company decides what it believes is eligible, then applies through AusIndustry and includes the tax effect through its tax return process. In practice, that pushes more responsibility onto contemporaneous records, cost allocation, and review discipline than many founders expect.

What documentation and evidence should finance teams prepare

The strongest startup claims don't start with a consultant interview at year end. They start with ordinary working records that were already being created when the work happened. That's where the practical gap usually is. Engineering teams have evidence, but it sits in GitHub, Jira, Linear, Notion, Slack, and design docs without being tied back to accounting.

A common gap in current guidance is exactly that mapping problem. Real-time engineering data from tools like GitHub and Jira needs to line up with the ATO's systemic progression and at risk concepts, and automated contemporaneous documentation becomes more important under the updated draft ruling context noted in this discussion of TR 2021/D3 and documentation expectations.

A workable evidence stack

Finance teams should build one record that links technical work to cost records. In practice, that usually means:

1. Project hypothesis
   State the uncertainty being tested. Not a product goal. A technical question.

2. Experiment trail
   Link Jira tickets, GitHub pull requests, architecture notes, test results, and decision logs that show what was attempted and what happened.

3. Cost trail
   Tie labour, contractor spend, cloud usage, and related overheads back to the activity record in Xero or your general ledger.

4. Internal review
   Have engineering sign off on technical accuracy and finance sign off on cost treatment before lodgement work begins.

What works and what usually fails

What works is specificity. A Jira epic that says “Investigate whether our sync engine can preserve data integrity under offline conflict conditions” is useful. A ticket that says “Platform improvements” is not.

What works is sequence. The records should show a progression from hypothesis to test to result. Dumping screenshots, invoices, and commit logs into a folder after year end usually creates volume without clarity.

Good evidence is chronological. It shows what the team knew at the time, what they tried next, and why the result wasn't obvious in advance.

For technical teams that already document custom build work in complex systems, I've found resources like Automate NetSuite custom code documentation useful as a process reference. It's not about the Australian incentive specifically, but it shows the broader discipline of turning developer activity into structured documentation.

If you need a more detailed checklist for audit-ready records, this guide on how to document for R&D Tax Incentive compliance is a practical reference. For platform-specific support, the ClaimKit help centre also explains how founders connect evidence sources and prepare drafts for expert review.

How should software and engineering projects be recorded in accounting entries

A founder closes month end and asks why two engineers working on the same product ended up in different accounts. The answer usually sits in the project record. One engineer was still testing whether the approach would work at all. The other was building an approved solution after feasibility had been established.

That distinction drives the journals.

Under AASB 138, software and engineering spend does not go into one generic “R&D” bucket. Finance needs entries that reflect the stage of work, the nature of the uncertainty, and whether the development criteria have been met. For startups, the practical challenge is turning live engineering activity into accounting treatment without relying on a retrospective story.

Journal treatment should follow technical milestones

A workable policy for software teams usually separates costs into three streams:

The hard part is deciding when a project moved from research to development. I usually tell founders to anchor that decision to evidence engineering already creates. GitHub pull requests, Jira tickets, architecture decision records, and sprint approvals can show when the team stopped asking “can this work?” and started executing “build it this way.” That is the practical gap many finance teams miss. The accounting policy exists, but the cutoff point is buried in delivery tools unless someone maps it properly.

How to post software labour without creating a reconciliation mess

Labour is usually the biggest balance. Treat it with more precision than overheads.

• Employee wages and super: Allocate based on time tied to research, capitalisable development, or ordinary product work.
• Contractors: Match invoices and statements of work to the same project codes used in engineering systems.
• Cloud and tooling: Capitalise only the portion directly attributable to development activity. Keep research usage and general platform spend in expense.
• Shared engineering management and overheads: Use a documented method and apply it consistently. Round-number estimates with no support rarely survive review.

If your team uses Xero, separate account codes or tracking categories for research expense, capitalised development, and non-R&D engineering save a lot of cleanup later.

Here's a useful explainer on software claim mechanics before you build the final schedule:

A practical example using Jira and GitHub

Suppose a startup is building a recommendation engine for a B2B SaaS product.

In the first phase, Jira epics and GitHub branches show the team testing whether the model can produce reliable outputs with sparse customer data. Experiments fail, assumptions change, and acceptance criteria are still about technical feasibility. Those labour costs are usually expensed.

Later, the records show a different pattern. Engineering signs off on a selected model design, product approves a release path, infrastructure work is scoped, and pull requests relate to implementation, integration, and deployment hardening. From that point, some build costs may be capitalised if the AASB 138 development tests are met.

This is also where founders should keep tax and accounting aligned without forcing them to be identical. A cost can be expensed for accounting in an earlier phase and still matter for incentive working papers, depending on the underlying activity and the rules being applied. For teams preparing those schedules, this guide to the R&D Tax Incentive application process is a practical reference.

A clean month-end process links each journal back to named evidence. If finance can trace a labour entry to a timesheet, a Jira issue, a GitHub commit range, and a management decision on feasibility, the accounting entries are far easier to defend.

What common mistakes should startups avoid in R and D accounting

The most common startup mistake is assuming that all engineering spend is either claimable or capitalisable because the product is new. Neither assumption is safe. Novelty in a commercial sense isn't enough for accounting, and it isn't enough for the incentive either.

Mistake one is capitalising too early

Founders often want a cleaner balance sheet and lower losses, so they push software costs into development too soon. If the team is still resolving whether the solution is feasible, those costs are usually better treated as research expense. Over-capitalisation distorts the balance sheet and creates a weak audit trail.

Mistake two is relying on retrospective narratives

This shows up when finance asks engineering for “the R&D story” after year end and gets a polished summary detached from real working records. ATO-facing documentation is much stronger when it comes from live project evidence rather than memory.

If the claim depends on people remembering why something was uncertain months later, the process is already under strain.

Mistake three is applying the wrong accounting standard to the offset

For refundable offsets, startups sometimes treat the amount as if it reduces income tax expense. That can be the wrong presentation. For large entities, non-refundable offsets affect current tax expense differently from refundable offsets.

The accounting distinction matters. As discussed in HLB's overview of accounting for the R&D Tax Incentive, AASB 120 generally applies to refundable R&D tax offsets as government grants recognised in profit or loss, while non-refundable offsets for large entities are recorded as a reduction to current income tax expense. If finance gets that wrong, EBITDA, tax rate presentation, and board reporting can all become messy.

A short pre-EOFY checklist

• Review project status: Are you still in research, or has the work moved into development?
• Test evidence quality: Can each major project point to hypotheses, experiments, and outcomes in source systems?
• Check offset presentation: Has the finance team aligned the accounting treatment with the correct standard?

How can finance teams streamline R and D accounting processes

The fastest way to make R&D accounting expensive is to leave it until after EOFY. The teams that handle it well do light-touch work during the year, then a structured review before lodgement.

A monthly cadence is usually enough. Engineering flags projects with technical uncertainty. Finance reviews the related cost centres, labour mapping, and contractor coding. That avoids the usual scramble where nobody can tell whether a sprint was experimental or just delivery.

What a lean process looks like

Where advisers and software fit

Different firms solve different problems. Treadstone, Prime Partners, Link R&D Advisory, and Bulletpoint each have their place depending on budget, complexity, and how much manual support you want. Traditional advisers can be useful where facts are messy or governance needs close handling. The trade-off is usually slower information gathering and more back-and-forth with founders and engineers.

For software-heavy startups, a platform model can reduce that friction by pulling records from systems the team already uses. ClaimKit is relevant here because it combines AI-drafted claims, expert review, ATO lodgement support, and integrations with GitHub, Jira, Linear, Notion, and Xero. That's different from a pure advisory model, but it still relies on expert review rather than presenting itself as personal tax advice.

If you're comparing consultants and hybrid platforms, this resource on choosing a research and development tax consultant is a sensible place to start. For company background, the ClaimKit about page gives a clearer view of how its review model works.

Frequently asked questions

Can overseas developers be included in an Australian R&D claim

Offshore development is one of the fastest ways to overstate a claim if finance and engineering treat all sprint costs the same. Separate those costs early, confirm who engaged the developers, and test the underlying activities against the relevant rules before they reach the R and D schedule. If your team is organising evidence in-platform, keep offshore work in its own workflow from the start and use a structured process such as the ClaimKit portal login.

How should we reflect a possible R&D offset in forecasts

Use a conservative assumption.

A forecast can include an expected offset if the basis is credible, but the board paper should clearly separate three things. The accounting treatment. The expected lodgement date. The likely cash receipt date. I have seen startups create avoidable pressure by budgeting against a draft claim before the technical position and supporting evidence were settled.

Should software licences be capitalised or expensed

The treatment usually depends on the licence's purpose within the business. A recurring SaaS subscription used by engineers to do day-to-day work will often be an operating expense. A licence cost that is directly attributable to creating a development asset needs closer analysis under AASB 138.

Founders often focus on the vendor or the contract label. The better test is operational. Ask what the tool was used for, which project it supported, and whether the spend relates to eligible development activity, research activity, or normal business operations.

How do we document mixed-scope projects with both R&D and product delivery work

Document them at task level. That is where the evidence is.

One Jira epic can include experimental work, bug fixes, customer delivery, and technical debt. Finance teams get better results when they map tickets, pull requests, and deployment records to the actual technical objective, then reconcile that activity back to payroll and supplier costs. That approach also makes the ATO position easier to defend because the classification is tied to contemporaneous engineering records rather than an EOFY summary written from memory.

If GitHub and Jira are already part of your delivery process, use them as the primary evidence trail, not as an afterthought. The practical gap in many R and D processes is not identifying projects. It is proving which live engineering activities meet the eligibility rules and which do not.