For Tax Executives, the Real Risk Isn’t AI. It’s Documentation You Can’t Defend

Tax executives are right to be cautious about AI in tax compliance.

In a high-stakes area like the R&D credit, nobody wants a system thatproduces an answer but cannot explain how it got there. That concern is reasonable. Treasury regulations require taxpayers claiming the research credit to retain records in usable detail, and the IRS continues to push toward more granular, business-component-level substantiation through Form 6765 and related refund-claim requirements.

But that is exactly why the conversation around AI in tax needs to be reframed.

The right question is not whether AI is involved. The right question is whether the process is explainable, controlled, and auditable. If a system can show the source data it relied on, document the steps it followed, preserve changes over time, and produce support that ties back to contemporaneous business records, that system is far more defensible than one that simply depends on human recollection after the fact. That is true whether the“processor” is a machine-learning model, a spreadsheet, or a room full of subject matter experts. This is an inference drawn from the IRS substantiation rules and the agency’s stated focus on contemporaneous books and records.

That distinction matters more than ever for R&D credit claims.

The IRS has long required taxpayers to substantiate both qualified activities and qualified research expenses with records in sufficient detail. The IRS’s own audit guidance says contemporaneous books and records should form the basis of an examination, and that estimates are not a substitute where better records exist. The current Form 6765 developments push in the same direction: more project-level detail, more business-component specificity, and more clarity around what was done, by whom, and at what cost.

That is one reason the traditional R&D study model is under pressure.

For years, many large companies relied on a familiar process: interview engineers and managers well after the tax year closed, ask them to estimate how time was spent, and build a narrative from memory. In many cases, that was the practical reality. But the ongoing Kyocera dispute has put a spotlight on the weaknesses of that model. As described by Bloomberg Tax and Tax Executive, the IRS challenged an interview-based Big Four study that involved retrospective SME input, estimated allocations, and limited contemporaneous support, arguing the claim lacked sufficient documentation. Tax Executive’s summary of the caseputs the lesson neatly: documentation should “pave the road,” while interviews should only “fill the potholes.”

That is why we think calling AI a “black box” often misses the real issue.

In many traditional studies, the actual black box is the human process. If a tax team is asked, during audit, to defend why a certain percentage was assigned to an employee or why a project narrative reads the way it does, “because someone remembered it later” is not a strong answer. By contrast, a modern system built on contemporaneous operational data can be far more transparent if it shows the underlying tickets, project relationships, payroll ties, and review history that led to the result. This is an inference based on the Neo.Tax product architecture and the IRS’s emphasis on contemporaneous substantiation.

That is the problem Neo.Tax was built to solve.

Neo.Tax starts with the data companies already generate in the ordinary course of business: ticketing data from systems like Jira, Linear, and AzureDevOps, along with payroll, vendor, and financial data. Our AI analyzes tens to hundreds of thousands of tickets, groups work into project buckets using both textual and structural signals, evaluates those projects against the Section 41 framework, and then helps generate project narratives and employee-level percentages tied to qualified work. Because the system is designed for messy, real-world data, it does not depend on engineers tagging everything perfectly or filling out quarterly surveys just to support the tax file.

Just as important, Neo.Tax is designed to show its work.

We built an audit log because tax compliance is not just about the final output. It is about lineage. A tax executive should be able to ask: What did the calculation look like on a certain date? Who changed an allocation? When was that change made? What was the source data before and after the revision? Neo.Tax’s audit log is meant to preserve that history so the filing process is not just automated, but reviewable and explainable. In other words, the system is built with the expectation that someone may need to defend it later.

This is especially important for tax departments evaluating AI vendors.

The standard should not be “Does it use AI?” The standard should be: Can it follow a disciplined methodology? Can it operate within clear guardrails? Can it tie conclusions back to contemporaneous source records? Can it preserve an audit trail? Can a tax professional review the result, understand the basis for it, and explain it to an examiner? In tax, accuracy matters, but process matters too. A fast answer without defensibility is not a win. This framing is grounded in the IRS record keeping rules and the stated Neo.Tax design principle of transparency.

For tax executives, that is the practical takeaway.

AI should not replace judgment. It should improve the evidence base behind that judgment. The best use of AI in tax compliance is not to hide complexity behind automation. It is to make a complicated compliance process more consistent, more scalable, and more audit-ready by organizing the underlying facts better than a manual process can. When built the right way, AI is not the black box. It is the mechanism that helps open one. This conclusion is an inference from the sources above, especially the IRS emphasis on contemporaneous substantiation and Neo.Tax’s focus on transparency, ticket-level analysis, and audit-log lineage.