R&D Credit Methodology For Auditors

How it works

• Analyze all tickets and related metadata to generate a complete list of qualified and non-qualified projects.
• Use system hierarchy (Epics, Initiatives, etc.) plus deep learning models that group similar tickets by language and context.
• Convert ticket data into numerical representations to match tickets to projects consistently and without interview bias.


Rich data ingestion and QA

• Ingest ticket titles, descriptions, dates, assignees, teams, and hierarchy.
• Normalize user information, team assignments, and project involvement.
• Clean data to remove duplicates and noise, with validations to confirm all tickets are accounted for and evaluated at an appropriate level of granularity.

Neo.Tax evaluates each project against the 4-part R&D test using project summaries and ticket-level details.

1. Technical in Nature

   Checks ticket content and code activity to determine whether substantially all project activities are technical.

2. Qualified Purpose

   Tests project purpose against tax rules. Internal use software projects receive additional scrutiny. Projects with mixed signals are flagged for expert review.
3. Technical Uncertainty
   Identifies documented technical uncertainties and the work performed to resolve them.
4. Process of Experimentation

   Looks for iterative development, testing, experimentation, and systematic approaches to resolving uncertainties.


Projects with ambiguous status are surfaced for human review, with all decisions recorded in the audit trail.

Instead of estimates, surveys, or time sheets, Neo.Tax uses ticket data to allocate R&D effort bottom-up from actual work.
This approach:‍

• Relies on contemporaneous records.
• Applies a consistent, repeatable methodology.
• Maintains a traceable line from raw tickets to final R&D allocation.

Step 1: Effort for each task:


• Use start, progress, review, and completion timestamps.
• Adjust for task type and complexity.
• Normalize for individual work patterns so different working styles are treated fairly.

Step 2: Effort by project

• Aggregate effort across all tasks within a project.
• Compute each project’s share of total effort.
• Apply R&D qualification flags to determine the R&D percentage at the project level, which flows into the Expenses by Project (Credit) sheet and wages view.


The resulting R&D percent is the value shown in the R&D Report > Expenses by Project (Credit) sheet and the Wages page in the application.

How can I verify the calculation?



All steps are transparent. Task-level efforts are visible in the Ticketing view, project-level allocations can be recomputed from exports, and the R&D percentage is the sum of qualified project percentages.


‍

What about people with very different ticket volumes?


Normalization accounts for ticket volume and size. Someone with many small tickets and someone with a few large features both receive allocations driven by modeled effort, not ticket count.


‍

What about different job titles?


The base model treats qualified technical work consistently based on task complexity and timing. Role-based adjustments can be layered on later if needed.

We matched all tickets Jason worked on to a project and evaluated each project against the Four-Part Test to determine qualified R&D projects. This allows us to determine when Jason was actively working on qualified research.
The tickets that are part of the Hardware Enhancements, Billing System Overhaul, Platform Security and Feature Development projects will count towards Jason’s qualified time.Activity ⇒ Effort
For every ticket:


• Extract start and end dates from the source system to create a date-stamped audit trail.
• Calculate Effort Days using the period when the ticket is active and the ticket’s scope.
  
  • If all work on a given day relates to one project, that project receives one Effort Day.
  • If multiple projects have active tickets on the same day, that day is split proportionally using ticket activity and scope, not simple ticket counts.
• Apply a machine learning model to adjust for edge cases such as long-running tickets worked intermittently or bursts of small tickets.

Effort grows with calendar time and technical scope, so complex, long-running work naturally outweighs quick fixes while remaining fully traceable to system timestamps.



The following chart shows the number of tickets that were actively worked on by week. This number is calculated first using the raw timestamps in the source system and then adjusted by the Machine Learning model.

This accounts for the fact that there is some amount of time spent working on the ticket before it is committed, which is when the ticket is first registered in the system.


With the complete set of tickets and their active period, we then sum up the Effort totals. We allocate Jason’s time per project proportional to the sum of effort in each project. For ease of analysis, we round the percentages in a way that minimizes the total rounding deviation and ensures effort adds up to 100%.

This method uses the real-world contemporaneous timestamp data to approximate effort on a day-by-day basis and allocate time accordingly, instead of less accurate methods like assuming equal weight per ticket or using after-the-fact estimates.
Finally, we multiply this by Jason’s W-2 Box 1 wages for the year to determine the amount of qualified expense.