The R&D Credit Risk Most Companies Miss: Evidence, Not Activity

Why CFOs, Tax Directors, and PE operators should treat R&D documentation as an evidence governance system—not a year-end cleanup exercise.

Many companies that struggle to defend R&D tax credit positions do not lack legitimate technical activity. They lack the evidence architecture to prove it.

This article provides a diagnostic framework for CFOs, Tax Directors, Controllers, PE operating partners, and CPA/tax advisory firms to assess whether their R&D documentation would withstand scrutiny—and what structural changes to make if it would not.

The Claiming Versus Defending Gap

Many companies optimize for credit identification and calculation. They focus on identifying qualified research expenses, calculating wage allocations, preparing studies, and filing returns.

That is claiming.

Defending is different.

Defending requires you to move from the claimed credit to the underlying evidence without relying on memory, reconstruction, or a consultant-written narrative. It requires contemporaneous records that show what was uncertain, what alternatives were evaluated, what was tested, what failed, who performed the work, and how the claimed costs were allocated.

The gap between claiming and defending is where many companies discover their vulnerability.

When the IRS, a buyer, an auditor, or an internal reviewer asks for support around one material R&D project, the company should be able to answer from the record. If your answer depends on asking engineering what happened six months ago, you have a governance problem.

The Form 6765 changes reinforce the importance of project-level support.

Under the IRS instructions for the December 2025 revision of Form 6765, Section G is optional for tax years beginning before 2026 and required for tax years beginning after 2025, subject to the Section G guidelines and exceptions.

For taxpayers required to complete Section G, the form requires reporting qualified research expenses by business component for at least 80% of total QREs, with no more than 50 business components reported individually.

That matters because it moves the conversation closer to project-level support. Generalized narratives are becoming less sufficient. Companies need a clearer connection between claimed expenses, business components, activities, and evidence.

Why Documentation Is Narrative-Heavy but Evidence-Light

The most common failure pattern is documentation that tells a convincing story but cannot substantiate it with contemporaneous records.

Here is what that looks like in practice:

The narrative looks credible. A polished R&D study describes the project as technically challenging. It explains that the team evaluated alternatives and performed experimentation. The language is confident. The structure is clean.

But the underlying record reveals gaps. The study says the team evaluated multiple technical alternatives. When you review the Jira tickets, you see only implementation tasks. No architectural debates. No proof-of-concept comparisons. No rejected approaches.

The study says uncertainty existed. When you review the design documents, you see descriptions of what was built—not what failed, not what alternatives were tested, not why one technical path was chosen over another.

The study claims several engineers spent 60% of their time on qualified research. When you ask how that percentage was calculated, you learn it was reconstructed months later through interviews. No contemporaneous time records. No sprint-level tagging. No project mapping. No manager review or approval.

That is the vulnerability.

The company may have performed legitimate technical work. But the evidence trail does not support the level of confidence expressed in the study. The narrative says one thing. The record proves something weaker.

This gap is what makes an R&D position difficult to defend. It is not the absence of activity. It is the absence of reviewable proof that connects the narrative to contemporaneous records.

IRS audit guidance generally emphasizes the value of contemporaneous, supportable records over estimates or after-the-fact reconstruction.

Claims built primarily on interviews, estimates, or after-the-fact reconstruction are more vulnerable than claims supported by contemporaneous project records, time support, technical evidence, and reviewable business-component mapping.

The stronger posture is contemporaneous support, not after-the-fact reconstruction.

Documents may exist across Jira, GitHub, email, meeting notes, design files, product specs, and test logs. But if those records are scattered, unmapped, and unreviewed, the company does not have a defensible evidence system. It has fragments.

What a Defensible Evidence System Contains

A defensible evidence system does not depend on a polished study written after the work is complete. It connects the technical story, the underlying project records, the people involved, the time and cost allocation, and the review process into one organized, audit-ready evidence trail.

The system should allow a reviewer who was not involved in the project to move from the claimed credit to the supporting evidence without relying on informal reconstruction.

Here is what that system should include, grouped into six categories:

Business component map. The claim should not simply say "we developed the platform." It should map evidence to specific business components: a payment workflow, reporting engine, data ingestion pipeline, API integration layer, permissioning module, automation workflow, or performance improvement.

Technical uncertainty statement. An explanation of what the team did not know at the outset. Could the platform process a certain volume of transactions within a required latency threshold? Could two systems be integrated without data loss? Could an algorithm produce accurate results under specific constraints?

Experimentation and iteration evidence. Test logs, failed builds, prototype notes, QA results, performance benchmarks, bug records, pull requests, GitHub commits, deployment notes, sprint reviews, architecture notes, design documents, technical decision records, proof-of-concept comparisons, or rejected approaches. The evidence should show what alternatives were considered, what was tested, what failed, what was changed, and what was learned.

People, role, time, and cost mapping. The company should be able to identify which employees or contractors worked on the project, what role they played, what activities they performed, and how those activities relate to the qualified research position. If the claim includes wage costs, the company should be able to connect time allocations to projects, sprints, tickets, commits, reviews, or manager-approved estimates. The strongest system captures this contemporaneously, not through memory months later.

Decision traceability. The system should show why the team selected one technical approach over another. Technical decision records, engineering review notes, architecture approval notes, or meeting summaries that tie a decision back to uncertainty, testing, constraints, or performance results.

Review and governance layer. Someone should review whether the evidence actually supports the claim before the credit is finalized. That review should test whether the uncertainty, experimentation, people, time, and costs are connected and whether non-qualified work has been separated from potentially qualified activity.

When done right, a reviewer should be able to move from the claimed credit to the business component, from the business component to the technical uncertainty, from the uncertainty to the experimentation, from the experimentation to the people and time involved, and from the people and time to the claimed costs.

That traceability is what separates a defensible system from scattered documentation.

A narrative explains the claim. An evidence system substantiates it.

The Diagnostic Question

If the IRS, an auditor, a buyer, or an internal reviewer asked you to defend one material R&D project today, could you move from the claimed credit to the underlying evidence without relying on memory, reconstruction, or a consultant-written narrative?

That question exposes where you actually stand.

You can break it into more specific questions:

Can you identify the specific business component being claimed, or are you just describing a broad project?

Can you clearly state the technical uncertainty that existed at the start?

Can you show the alternatives considered, the tests performed, the failed approaches, and the decisions made?

Can you connect the work to contemporaneous evidence such as tickets, commits, test results, design records, technical decision notes, sprint reviews, or engineering documentation?

Can you identify who performed the work and what role they played?

Can you support the time and cost allocation without relying only on after-the-fact estimates?

Can you separate potentially qualified activities from routine implementation, maintenance, support, deployment, or business-as-usual work?

Can someone outside the project team review the file and understand why the claim is defensible?

If the answer is yes, you may have a defensible evidence system.

If the answer is "probably, but we would need to ask engineering," you have a governance gap.

If the answer is "we have a study, but the support is scattered," you have an evidence architecture gap.

If the answer is "we would need to reconstruct it," you have a defensibility problem.

The cleanest version: Could you defend this claim from the record, or only from memory?

That question separates documentation maturity from documentation optimism.

Why This Matters in PE Diligence

Weak documentation maturity changes how buyers and investors evaluate the reliability of the tax position, the quality of management controls, and the likelihood of future exposure.

A buyer is not only asking, "Did this company perform R&D?"

They are asking: Can this company defend the credits it claimed? Could those credits be challenged later? Is there a reserve or indemnity issue? Does this affect normalized earnings or cash flow quality? Does the company have repeatable controls, or is it relying on informal knowledge? Will this become our problem after close?

That is where documentation maturity can affect valuation or deal terms.

If a portfolio company has claimed meaningful R&D credits for several years but cannot show business component mapping, technical uncertainty, experimentation evidence, employee time support, cost allocation, and review documentation, the buyer may view the credit as a risk item rather than a value item.

The buyer may discount the quality of the tax asset. They may request a deeper tax diligence review, which slows the process and creates additional scrutiny. They may ask for a specific indemnity, escrow, purchase price adjustment, or representation around tax credits and related documentation. They may challenge add-backs, cash tax assumptions, or historical financial presentation if the credits materially affected cash flow.

They may also view the issue as a broader operating maturity signal.

If the company cannot govern R&D evidence, the buyer may wonder what other areas rely on informal process rather than controlled execution.

A weak company enters diligence with a narrative. A mature company enters diligence with an evidence system.

That difference affects risk perception. And risk perception affects how buyers think about value, holdbacks, indemnities, diligence burden, and confidence in management.

For PE operating partners, the diagnostic question is: If we had to defend this portfolio company's R&D credits to a buyer today, would we be presenting an evidence system or requesting a reconstruction project?

The First Structural Change

If you realize you are in the reactive cleanup camp, the first structural change is to create a formal R&D evidence owner and evidence capture rhythm before the claim is prepared.

Most companies try to fix the problem at the end of the process. They wait until the credit study is being prepared, then ask engineering to explain what happened, ask finance to estimate costs, and ask tax to turn the story into a defensible position.

That is backwards.

The first change should be moving evidence capture upstream into the operating rhythm of the work.

You do not need to build a perfect system on day one. The first step is to designate a cross-functional evidence owner and create a simple project-level evidence review cadence.

Every potentially qualified R&D project should have a lightweight evidence file that answers five questions:

1. What business component is being developed or improved?
2. What technical uncertainty existed at the start?
3. What alternatives, tests, iterations, or failures occurred?
4. Who performed the work, and what role did they play?
5. What records support the time, cost, and activity allocation?

That evidence file should be reviewed periodically, not reconstructed months later.

The structural change is ownership plus cadence.

Ownership means someone is accountable for making sure evidence is captured, mapped, reviewed, and preserved.

Cadence means the review happens during the project lifecycle, not after the credit is calculated.

A practical first version could be a monthly or quarterly R&D evidence review where finance, tax, and technical leadership review active projects and ask:

Which projects may be in scope? What uncertainty is being resolved? What evidence already exists? What evidence is missing? How are time and costs being supported? Who needs to update the record before the next review?

That single cadence changes the posture from reactive cleanup to proactive evidence capture.

The goal is not to create bureaucracy. The goal is to prevent the company from depending on memory later.

One practical starting point is an R&D Evidence Register.

For each project, track: business component, technical uncertainty, experimentation or iteration evidence, source systems where evidence lives, employees or contractors involved, time/cost support, reviewer, evidence status, gaps to resolve, and final claim inclusion decision.

That register becomes the bridge between engineering activity, finance records, tax analysis, and audit-ready support.

The first structural change is not simply to write better documentation.

It is to create an owner, a cadence, and a project-level evidence register before the claim is prepared.

That is how a company starts moving from cleanup to governance.

The One Mistake That Undermines the Effort

The mistake you are most likely to make is turning the evidence register into another static compliance spreadsheet instead of making it part of the operating rhythm.

You may assign an owner, create a register, and build a clean template. But if the register is only updated at quarter-end, year-end, or when the credit study begins, you have not actually moved from reactive cleanup to proactive evidence capture. You have just created a better-looking cleanup tool.

The register fails when it becomes an administrative artifact rather than a control point.

In the first 90 days, the evidence owner may focus on collecting documents instead of changing behavior. They may ask engineering to upload tickets, design notes, test results, and time estimates, but they may not establish when evidence should be captured, who reviews it, what qualifies as sufficient support, or how gaps are resolved while the work is still active.

That is the mistake.

The register should not simply answer, "Where are the documents?"

It should answer: Which business component is being evaluated? What technical uncertainty is being resolved? What evidence supports experimentation or iteration? Who performed the work? How is time or cost being supported? What evidence is missing? Who reviewed the file? Is this project ready to support a claim, or does it need remediation?

The second version is governance. The first version is file collection.

The most important point is that the evidence register should create a review habit, not just a repository.

If you do not create a monthly or quarterly review cadence, the register will drift. It will fill with incomplete records, unclear project names, unsupported time estimates, and links to documents nobody has actually reviewed.

That undermines the whole effort because it gives you a false sense of maturity.

You think, "We have a register now."

But the real question is: Is the register changing how evidence is captured while the work is happening?

If not, you are still reactive. You just have a more organized spreadsheet.

Do not confuse creating the register with governing the evidence.

The register is only useful if it changes the rhythm of how you capture, review, and preserve support.

Why You Should Act Now

The absence of an audit is not evidence that your system is defensible. It only means your system has not been tested yet.

Many CFOs and Tax Directors are understandably focused on immediate pressure: close the books, file the return, support the claim, move on. If you have claimed credits for years without challenge, it can feel reasonable to assume the current process is sufficient.

But the real question is not, "Have we been audited?"

The better question is: If scrutiny arrived tomorrow, would we be defending from the record or reconstructing from memory?

That is the business case for investing now.

The value of proactive evidence governance is not limited to audit defense. It improves diligence readiness, advisor confidence, management review, financial statement support, institutional memory, and your ability to explain the basis for material tax positions without a fire drill.

Waiting until scrutiny arrives usually means you pay for the system twice.

First, you pay through disruption: engineering interviews, finance rework, advisor requests, document searches, management distraction, and delayed responses.

Second, you pay through weaker defensibility: after-the-fact estimates, incomplete records, unclear ownership, and a claim that may depend more heavily on narrative than evidence.

You do not need to build a burdensome compliance program just because an audit might happen. The more practical reason to invest is that R&D evidence governance is an operating control. It protects the quality of the claim while the facts are still fresh and the work is still visible.

The companies that wait are often forced into reconstruction.

The companies that act early build reviewability.

That difference matters not only with the IRS, but also with buyers, investors, auditors, boards, and future advisors.

If credits are small, immaterial, and low-risk, a lightweight process may be enough. But if you claim meaningful credits, expect to continue claiming them, have PE ownership, are preparing for diligence, rely on technical development, or have meaningful wage allocations tied to R&D, then documentation maturity is not optional infrastructure. It is part of responsible governance.

You do not build an evidence system because you are certain scrutiny will arrive.

You build it because the credit is only as strong as the record that supports it.

And the best time to create that record is while the work is happening, not after someone asks you to prove it.

Review Your Documentation Risk Surface

Before assuming your R&D documentation is defensible, review whether your evidence, ownership, and decision traceability would hold up under scrutiny.

If you would need to reconstruct the story, you have a governance gap.

If you want to assess whether your current process would withstand IRS scrutiny, buyer diligence, or internal review, request a documentation defensibility diagnostic.

Archway helps CFOs, Tax Directors, Controllers, PE operating partners, and CPA/tax advisory firms build defensible R&D evidence systems before scrutiny exposes gaps.