R&D Credits

The Section 41 Four-Part Test for R&D Credit Eligibility

R&D credit eligibility is not determined by job titles, innovation language, or industry labels. Each claimed activity must satisfy the Section 41 four-part test and connect to a business component.

Defensible R&D credit file with eligibility, QRE, Form 6765, and examination support layers

R&D Credits

Defensible credit file

R&D credit work is visualized as a file, not a claim: eligibility, QRE support, Form 6765, and examination readiness.

What a defensible R&D credit file requires

R&D work is treated as a tax position: Section 41 eligibility, business components, QREs, Form 6765, Section 174A/280C, and examination readiness have to fit together.

Eligibility

Four-part test discipline

Permitted purpose, technological nature, technical uncertainty, experimentation, and business-component support are reviewed before the claim is calculated.

Return

Form 6765 and 174A/280C

Calculations and narratives are connected to current Form 6765 reporting, domestic and foreign R&E treatment, and Section 280C decisions.

Defense

Examination file first

Records, workpapers, technical narratives, employee and contractor support, and response posture are organized before questions arise.

Operating standard

  • Documentation comes first, so credit positions can be reviewed, supported, and defended.
  • Connect software, startup payroll-tax-offset, Form 6765 Section G, Section 174A/280C, state R&D, and audit-defense pages.
  • Support advisor co-advisory and CPA-firm workflows.
  • Keep the page focused on substantiated R&D positions, technical records, and measured professional review.

Who this serves

Companies, founders, CFOs, engineers, product teams, manufacturers, software businesses, and CPA firms evaluating whether activities may support an R&D credit claim.

Common risks

Claims are weakened when the file lists projects without tying activities to technical uncertainty, experimentation, permitted purpose, technological principles, and cost support.

MMVFO process

MMVFO maps business components, interviews technical teams, organizes project evidence, reviews cost categories, and coordinates professional analysis of the four-part test.

Business component focus

Activities should be tied to products, processes, software, techniques, formulas, or inventions rather than broad department-level descriptions.

Documentation standard

The file should support what uncertainty existed, what alternatives were evaluated, who performed the work, what costs were claimed, and how the activity connects to the return.

Four-part test facts to document

Permitted purpose

What was improved?

The business component should be tied to a new or improved function, performance, reliability, quality, or similar permitted purpose rather than a general business goal.

Technological uncertainty

What was unknown?

The file should identify the technical uncertainty at the start of the work and why the answer was not already available through standard practice or existing knowledge.

Experimentation

What was tested?

A defensible narrative explains alternatives, modeling, simulation, prototyping, trial runs, test criteria, failures, iterations, and results.

Qualified services

Who performed or supported the work?

Employee and contractor support should connect direct performance, direct supervision, or direct support to specific qualified activities and cost categories.

Four-part test evidence map

The four-part test should be documented at the business-component level, not just at the company or department level.

TestWhat the file should showEvidence examples
Business component and permitted purposeThe product, process, software, technique, formula, or invention and the intended improvement in function, performance, reliability, or quality.Component list, product briefs, technical specs, release notes, process maps.
Technological informationThe work relied on engineering, computer science, biological science, physical science, or another technological discipline.Design reviews, architecture memos, lab records, modeling notes, technical analyses.
Technical uncertaintyThe uncertainty existed at the outset and related to capability, method, or appropriate design.Issue logs, design alternatives, feasibility notes, failed tests, escalation memos.
Process of experimentationSubstantially all activities involved evaluating alternatives through modeling, simulation, prototyping, trial runs, or other testing.Test plans, prototype comparisons, simulations, QA results, sprint artifacts, failure analyses.

Documentation checklist

Use this checklist to organize records before filing, amendment, diligence, or controversy review. Detailed files should be shared only through a secure portal after written scope.

  • Legal entity chart and controlled-group analysis.
  • Tax-year business component list with unique identifiers.
  • Project descriptions, status, and claim-year activity by component.
  • Four-part-test narratives, technical uncertainty statements, and hypotheses tested.
  • Experimentation evidence, including alternatives, iterations, simulations, prototypes, test cycles, and results.
  • Employee roster with titles, departments, qualified-services rationale, payroll registers, wage detail, and allocation methodology.
  • Supply invoices, usage notes, and exclusion of capital items, depreciable property, overhead, and indirect costs.
  • Contracts, statements of work, invoices, rights terms, and financial-risk terms for contract research.
  • General-ledger extracts and QRE tie-outs to the return position.
  • Software classification support for internal-use, dual-function, or non-internal-use software where relevant.
  • Section 280C election support and research-expense coordination workpapers.
  • Form 6765 drafts, attachments, review memo, and current-instruction checklist.
  • For amended claims, business components, activities for each component, and total qualified wage, supply, and contract research expenses for the claim year.

Common R&D credit audit and claim risks

These are the gaps MMVFO screens before a claim is filed, amended, relied on in diligence, or defended in examination.

  • Using broad department-level narratives instead of business-component analysis.
  • Treating all engineering, product, software, or process-improvement work as qualified without exclusion screening.
  • Claiming work after commercial production began.
  • Including customer-specific adaptation, duplication, surveys, foreign research, funded research, or unsupported internal-use software work.
  • Unsupported wage allocations or interviews that do not match payroll, org charts, repositories, tickets, or project records.
  • Supply claims that include depreciable property, prototypes without support, general overhead, or indirect costs.
  • Contract research claims without adequate contracts, risk-of-loss terms, rights terms, or vendor detail.
  • Controlled-group errors, missing attachments, inconsistent methods, or incomplete Section 280C and research-expense coordination.
  • Amended claims that omit required business components, research activities, QRE totals, or signed declaration support.

Diagnostic questions

  1. What was the specific business component being developed or improved?
  2. What technical uncertainty existed at the start of the work?
  3. Why could the answer not be determined from existing knowledge, standard practice, or ordinary implementation?
  4. What alternatives were considered, modeled, simulated, prototyped, or tested?
  5. What technical criteria were used to evaluate success or failure?
  6. What changed between early and later versions, and what evidence shows the iteration?
  7. When did commercial production begin, and what work occurred after that point?
  8. Was any work performed to adapt an existing product or process for one customer?
  9. Was any part of the work duplicated from an existing product, process, design, or code base?
  10. Was any research performed outside the United States or U.S. territory?
  11. Was any work funded by a customer, grantor, or other third party?
  12. Which employees directly performed, directly supervised, or directly supported the qualified work?
  13. What records were created during the project, and where are they retained?
  14. For software, was the software internal-use, dual-function, or non-internal-use, and what support exists for that classification?

Official source notes

Scope and professional boundaries

FAQs

Routine implementation generally needs careful review. Qualification depends on facts, technical uncertainty, experimentation, and documentation.
Potentially, if the activities satisfy the legal tests and documentation supports the process of experimentation.
No. Eligibility turns on activities and facts, not labels such as engineer, developer, founder, or product manager.
Eligibility conclusions require written scope and qualified professional review, with specialists or affiliates involved where needed.

Request a Private Tax Strategy Diagnostic

If your tax, entity, investment, estate, insurance, or reporting picture has become too complex for one advisor to see clearly, MMVFO can help map the moving parts.

Request Diagnostic

Reviewed by Joshua V. Azran, CPA/ABV/CFF, CMA, CGMA, CFE and Lorenzo Abbatiello, CPA | Last updated