Custom Software and the R&D Tax Credit | OneSeven Tech

Custom Software and the R&D Tax Credit | OneSeven Tech

James Sullivan

James Sullivan

Executive desk with open ledger, abstract AI panel, and stacked coins

Yes. Custom software development, including work with OneSeven Tech, may qualify for the federal R&D tax credit when the activities, expenses, and contract arrangements meet the requirements. Hiring a developer or paying a software invoice does not establish eligibility by itself.

The useful question is what technical work the project requires. Are you resolving uncertainty about how a system can function, or configuring a product that already provides the answer?

The IRS instructions for Form 6765 explain the research-credit requirements. The credit is based on qualifying research, not the label “AI,” the size of the development budget, or whether the finished software becomes an asset.

Apply the four-part test to the actual work

Qualifying costs must meet the applicable research-expenditure requirements. Section 41’s four-part test can be summarized as follows:

Requirement

What it means for a software project

Permitted purpose

The work seeks to improve function, performance, reliability, or quality of a business component, such as a software system or a qualifying part of it.

Technological in nature

The work relies on principles such as computer science or engineering, rather than customer preferences or a management study.

Technical uncertainty

At the outset, available information does not establish the capability, method, or appropriate design needed to develop or improve the component.

Process of experimentation

The team evaluates alternatives to resolve that uncertainty through an organized process, such as modeling, simulation, or systematic trial and error.

The tests apply to individual business components, not automatically to an entire engagement. The rules also require substantially all the relevant research activities to constitute elements of a qualifying experimentation process. Exclusions still apply.

Consider a hypothetical integration project. Installing a standard connector and mapping fields does not become qualified research because the systems are new to your company. But developing and testing alternative synchronization designs to resolve uncertain technical behavior could merit a closer review.

The software examples in the federal research-credit regulations draw this distinction. Selecting commercial software, routine configuration, and ordinary quality-control testing are different from experimenting to resolve technical uncertainty.

An AI project follows the same principle. Uncertainty about whether employees will like a tool is not the same as uncertainty about its technical design.

Internal-use software has additional rules

Software developed primarily for general and administrative functions, such as financial management, human resources, and support services, generally faces an additional high threshold of innovation test unless an exception applies.

That test requires:

  • Innovation: a substantial and economically significant cost reduction, speed improvement, or other measurable improvement.

  • Significant economic risk: substantial resources committed while technical uncertainty creates substantial doubt about recovering them within a reasonable period.

  • Commercial unavailability: the software cannot be purchased, leased, or licensed for its intended use without modifications that meet the innovation and risk requirements.

Not every system used inside a company is classified as internal-use software. Certain customer-interaction software and production or research uses can receive different treatment. Mixed internal and third-party functionality needs its own analysis.

Classify the intended use at the beginning of development. A useful internal application is not automatically eligible, but internal use does not automatically disqualify it either.

Contract research: understand the 65% rule

For a business hiring a development partner, the agreement and the qualifying work both matter.

Under the contract-research rules, an agreement must precede the research, the research must be performed on the taxpayer’s behalf, and the taxpayer must bear the expense even if the research is unsuccessful. The taxpayer needs substantial rights to use the results, but not necessarily exclusive ownership. Payment contingent on success can change the treatment.

Generally, 65% of qualifying contract research expenses enters the qualified research expense calculation. That is not a 65% tax credit.

For example, if $100,000 of contract costs meets the applicable requirements, the general inclusion rule produces $65,000 of qualified research expenses. The credit is then calculated separately using the applicable method, company history, and other rules. This illustrative calculation does not produce a $65,000 refund.

A mixed invoice needs allocation. Qualified research, routine implementation, training, and ongoing support should not all be treated as the same activity. Where the work is performed matters too: the federal credit excludes research outside the United States, Puerto Rico, and other U.S. possessions. A U.S. invoice address does not establish where developers or subcontractors worked. Grants and other funding arrangements can also limit eligibility.

Which costs need review?

Potential qualified expenses include eligible employee wages for performing, directly supervising, or directly supporting qualified research, qualifying supplies, and eligible contract research.

Cloud services, model APIs, software licenses, datasets, and general overhead are not automatically qualified expenses because an AI project uses them. Computer-rental expenses have specific rules. Keep these operating costs in the project budget, then have your tax adviser determine whether any particular expense belongs in the credit calculation.

A deduction and a credit are different

A deduction reduces taxable income. A credit reduces tax liability, subject to eligibility and limits. Neither means the government pays the entire development bill.

For tax years beginning after December 31, 2024, Section 174A generally permits a current deduction for domestic research and experimental expenditures. An election to capitalize and amortize over at least 60 months is available. Foreign research expenditures generally remain subject to 15-year amortization under Section 174.

Those deduction rules are broader than the Section 41 research-credit tests. Software costs can receive one treatment without qualifying for the other.

Section 280C coordinates deductions and credits. Generally, a research credit reduces the related deduction or capital account unless a valid reduced-credit election is made. Do not add a full deduction and an unreduced credit as though they were independent benefits. The IRS explains this coordination in the Form 6765 instructions.

There is no universal six-cent return on every dollar paid to a development partner. The usable benefit depends on qualifying expenses, the calculation, the taxpayer’s circumstances, and timing.

Keep records while the work happens

Keep a record of the technical work as it develops, rather than relying on a general project summary at tax time:

  • The business component and improvement being pursued.

  • The technical uncertainty identified at the outset.

  • Alternatives considered, tests performed, and results.

  • Who performed the work, where they worked, and the related cost allocation.

  • Contracts, invoices, and evidence of rights and financial risk.

  • Which activities were research and which were implementation or ongoing operation.

Development tickets, design documents, test results, and financial records should tell a consistent story. An invoice labeled “custom AI development” is not enough on its own.

Common questions

Does the project have to succeed?

No. Success is not required for research to qualify. The activities and expenses must still meet the rules, including the contract conditions where another company performs the work.

Does a smaller project qualify?

Project size does not answer the eligibility question. A focused $50,000 or $100,000 project can be evaluated against the same activity, expense, and contract requirements. A larger budget does not make routine implementation qualified research.

Does buying software mean there are no tax advantages?

No. Purchased software and subscriptions can have deductions or other tax treatment under the applicable rules. The research credit is a separate question about qualifying activities and expenses, not a blanket advantage attached to building instead of buying.

For the delivery decision, see our guide to building versus buying AI software.

Plan the project and the tax review together

Decide whether the software makes operational and financial sense before assuming a credit. Bring your CPA into the planning early enough to review the scope, contract, work locations, and recordkeeping, then have them assess the claim before filing.

Then plan the full software investment, including operation after launch.

If you are considering custom software, book a discovery call to discuss the workflow, technical scope, and delivery budget with OneSeven Tech.

Yes. Custom software development, including work with OneSeven Tech, may qualify for the federal R&D tax credit when the activities, expenses, and contract arrangements meet the requirements. Hiring a developer or paying a software invoice does not establish eligibility by itself.

The useful question is what technical work the project requires. Are you resolving uncertainty about how a system can function, or configuring a product that already provides the answer?

The IRS instructions for Form 6765 explain the research-credit requirements. The credit is based on qualifying research, not the label “AI,” the size of the development budget, or whether the finished software becomes an asset.

Apply the four-part test to the actual work

Qualifying costs must meet the applicable research-expenditure requirements. Section 41’s four-part test can be summarized as follows:

Requirement

What it means for a software project

Permitted purpose

The work seeks to improve function, performance, reliability, or quality of a business component, such as a software system or a qualifying part of it.

Technological in nature

The work relies on principles such as computer science or engineering, rather than customer preferences or a management study.

Technical uncertainty

At the outset, available information does not establish the capability, method, or appropriate design needed to develop or improve the component.

Process of experimentation

The team evaluates alternatives to resolve that uncertainty through an organized process, such as modeling, simulation, or systematic trial and error.

The tests apply to individual business components, not automatically to an entire engagement. The rules also require substantially all the relevant research activities to constitute elements of a qualifying experimentation process. Exclusions still apply.

Consider a hypothetical integration project. Installing a standard connector and mapping fields does not become qualified research because the systems are new to your company. But developing and testing alternative synchronization designs to resolve uncertain technical behavior could merit a closer review.

The software examples in the federal research-credit regulations draw this distinction. Selecting commercial software, routine configuration, and ordinary quality-control testing are different from experimenting to resolve technical uncertainty.

An AI project follows the same principle. Uncertainty about whether employees will like a tool is not the same as uncertainty about its technical design.

Internal-use software has additional rules

Software developed primarily for general and administrative functions, such as financial management, human resources, and support services, generally faces an additional high threshold of innovation test unless an exception applies.

That test requires:

  • Innovation: a substantial and economically significant cost reduction, speed improvement, or other measurable improvement.

  • Significant economic risk: substantial resources committed while technical uncertainty creates substantial doubt about recovering them within a reasonable period.

  • Commercial unavailability: the software cannot be purchased, leased, or licensed for its intended use without modifications that meet the innovation and risk requirements.

Not every system used inside a company is classified as internal-use software. Certain customer-interaction software and production or research uses can receive different treatment. Mixed internal and third-party functionality needs its own analysis.

Classify the intended use at the beginning of development. A useful internal application is not automatically eligible, but internal use does not automatically disqualify it either.

Contract research: understand the 65% rule

For a business hiring a development partner, the agreement and the qualifying work both matter.

Under the contract-research rules, an agreement must precede the research, the research must be performed on the taxpayer’s behalf, and the taxpayer must bear the expense even if the research is unsuccessful. The taxpayer needs substantial rights to use the results, but not necessarily exclusive ownership. Payment contingent on success can change the treatment.

Generally, 65% of qualifying contract research expenses enters the qualified research expense calculation. That is not a 65% tax credit.

For example, if $100,000 of contract costs meets the applicable requirements, the general inclusion rule produces $65,000 of qualified research expenses. The credit is then calculated separately using the applicable method, company history, and other rules. This illustrative calculation does not produce a $65,000 refund.

A mixed invoice needs allocation. Qualified research, routine implementation, training, and ongoing support should not all be treated as the same activity. Where the work is performed matters too: the federal credit excludes research outside the United States, Puerto Rico, and other U.S. possessions. A U.S. invoice address does not establish where developers or subcontractors worked. Grants and other funding arrangements can also limit eligibility.

Which costs need review?

Potential qualified expenses include eligible employee wages for performing, directly supervising, or directly supporting qualified research, qualifying supplies, and eligible contract research.

Cloud services, model APIs, software licenses, datasets, and general overhead are not automatically qualified expenses because an AI project uses them. Computer-rental expenses have specific rules. Keep these operating costs in the project budget, then have your tax adviser determine whether any particular expense belongs in the credit calculation.

A deduction and a credit are different

A deduction reduces taxable income. A credit reduces tax liability, subject to eligibility and limits. Neither means the government pays the entire development bill.

For tax years beginning after December 31, 2024, Section 174A generally permits a current deduction for domestic research and experimental expenditures. An election to capitalize and amortize over at least 60 months is available. Foreign research expenditures generally remain subject to 15-year amortization under Section 174.

Those deduction rules are broader than the Section 41 research-credit tests. Software costs can receive one treatment without qualifying for the other.

Section 280C coordinates deductions and credits. Generally, a research credit reduces the related deduction or capital account unless a valid reduced-credit election is made. Do not add a full deduction and an unreduced credit as though they were independent benefits. The IRS explains this coordination in the Form 6765 instructions.

There is no universal six-cent return on every dollar paid to a development partner. The usable benefit depends on qualifying expenses, the calculation, the taxpayer’s circumstances, and timing.

Keep records while the work happens

Keep a record of the technical work as it develops, rather than relying on a general project summary at tax time:

  • The business component and improvement being pursued.

  • The technical uncertainty identified at the outset.

  • Alternatives considered, tests performed, and results.

  • Who performed the work, where they worked, and the related cost allocation.

  • Contracts, invoices, and evidence of rights and financial risk.

  • Which activities were research and which were implementation or ongoing operation.

Development tickets, design documents, test results, and financial records should tell a consistent story. An invoice labeled “custom AI development” is not enough on its own.

Common questions

Does the project have to succeed?

No. Success is not required for research to qualify. The activities and expenses must still meet the rules, including the contract conditions where another company performs the work.

Does a smaller project qualify?

Project size does not answer the eligibility question. A focused $50,000 or $100,000 project can be evaluated against the same activity, expense, and contract requirements. A larger budget does not make routine implementation qualified research.

Does buying software mean there are no tax advantages?

No. Purchased software and subscriptions can have deductions or other tax treatment under the applicable rules. The research credit is a separate question about qualifying activities and expenses, not a blanket advantage attached to building instead of buying.

For the delivery decision, see our guide to building versus buying AI software.

Plan the project and the tax review together

Decide whether the software makes operational and financial sense before assuming a credit. Bring your CPA into the planning early enough to review the scope, contract, work locations, and recordkeeping, then have them assess the claim before filing.

Then plan the full software investment, including operation after launch.

If you are considering custom software, book a discovery call to discuss the workflow, technical scope, and delivery budget with OneSeven Tech.

Ready to Build Industry Changing Software?

Ready to Build Industry Changing Software?

Ready to Build Industry Changing Software?

Click the button below, tell us more about your project and book a discovery call with our CEO.

Click the button below, tell us more about your project and book a discovery call with our CEO.

The AI Transformation Company

1501 Biscayne Blvd, Suite 501 Miami, Florida 33132

(917) 791-3006

Ask AI for a summary

ChatGPT Logo
Claude Logo
Perplexity Logo

© OneSeven Tech 2017 - 2026. All Rights Reserved - 17 Web Dev, LLC.

Based in the USA, Supporting Teams Globally.

The AI Transformation Company

1501 Biscayne Blvd, Suite 501 Miami, Florida 33132

(917) 791-3006

Ask AI for a summary

ChatGPT Logo
Claude Logo
Perplexity Logo

© OneSeven Tech 2017 - 2026. All Rights Reserved - 17 Web Dev, LLC.

Based in the USA, Supporting Teams Globally.

The AI Transformation Company

1501 Biscayne Blvd, Suite 501 Miami, Florida 33132

(917) 791-3006

Ask AI for a summary

ChatGPT Logo
Claude Logo
Perplexity Logo

© OneSeven Tech 2017 - 2026. All Rights Reserved - 17 Web Dev, LLC.

Based in the USA, Supporting Teams Globally.

The AI Transformation Company

1501 Biscayne Blvd, Suite 501 Miami, Florida 33132

(917) 791-3006

Ask AI for a summary

ChatGPT Logo
Claude Logo
Perplexity Logo

© OneSeven Tech 2017 - 2026. All Rights Reserved - 17 Web Dev, LLC.

Based in the USA, Supporting Teams Globally.