《研发费用加计扣除项目鉴定案例（第三辑）》深度解析系列之三：双维审视——创新性与真实性的核心地位

前言

2026年1月9日，科技部二司与国家税务总局所得税司联合发布《研发费用加计扣除项目鉴定案例（第三辑）》。这是继2023年7月31日第一辑、2024年12月13日第二辑案例发布后，监管层就研发项目“边界”界定问题释放的又一强烈信号。

本次发布的案例，直指深层次合规审查，标志着研发费用加计扣除政策的执行，已正式步入“强支持”与“严监管”深度并行的新阶段。当前，政策执行正站在一个关键节点：一方面，税收激励的“真金白银”持续加码，力度空前；另一方面，监管的“显微镜”与“探照灯”也精准聚焦，要求企业跨越“形式合规”的表层，在“业务－技术－财务－税务”深度融合的层面，证明其研发活动的真实性与创新性。

鉴于内容的专业深度与实践指导性，本文将分十期连载发布，本期为系列之三，点击以下系列之一、系列之二即刻查看往期文章，后续篇章将逐一拆解研发项目的鉴定要点，并提供规范化管理的实践路径，敬请持续关注。

系列之一：政策风向——强支持严监管下的政策解读

系列之二：案例解析——三辑鉴定案例的趋势与逻辑

系列之三：双维审视——创新性与真实性的核心地位

系列之四：四重标准——研发活动的鉴定框架与边界

系列之五：软件辨析——软件开发活动研发属性判定

系列之六：流程筑基——研发项目管理的体系与要点

系列之七：过程留痕——研发关键节点证据链的构建

系列之八：文档为证——技术资料的撰写要点与规范

系列之九：成果固化——专利布局佐证研发创新价值

系列之十：路径导航——研发全流程规范化管理指南

本辑四个案例的鉴定结论，清晰地揭示了专家在判断项目是否属于可享受加计扣除政策的“研发活动”时，主要围绕“创新性”与“真实性”两大核心维度进行审视。这两个维度如同审核的两大支柱，缺一不可，共同构成项目能否通过鉴定的决定性基础。

一 创新性：判断“是否构成技术突破”

创新性是研发费用加计扣除政策对项目内涵的核心界定标准。它聚焦于项目是否真正致力于获取新知识、创造新技术，或对现有技术进行实质性、非显而易见的改进，旨在回答核心问题：“该项目在科学技术层面是否实现了有意义的进步？”

（一）根本判定：“技术创造”与“技术应用”的清晰分野

核心在于区分项目是进行创造性的技术突破，还是对现有技术的简单应用或组合。创新性要求项目必须在科学技术上实现“从无到有”的创造，或对现有技术进行“从有到优”的实质性改进。

1.正面案例（案例1、2）：均涉及底层算法的开发与优化。例如案例1开发了“基于人工智能的视觉识别算法”，案例2涉及“生成对抗网络”及“阴影模式提取算法”。它们的创新点在于对技术原理本身的突破。

2.反面案例（案例3、4）：仅仅是现有成熟技术的组合应用。案例3使用的是现成的SaaS框架、ERP后台；案例4使用的是标准的B/S架构和HTML5技术。

3.结论：如果项目仅仅是利用现有的编程语言、成熟的框架（如Spring，Vue）、通用的数据库搭建一个业务系统，而未在算法模型、核心工艺、材料配方或系统架构等层面形成自主的、优于公知方案的创新点，则极易被归入“对现有技术的简单应用”，难以被认定为研发活动。

（二）关键支撑：对照“负面清单”的边界判断

创新性的认定需要严格遵守政策划定的边界。《财政部、国家税务总局、科技部关于完善研究开发费用税前加计扣除政策的通知》（财税〔2015〕119号）明确列出了七类不适用加计扣除的活动，为创新性判断提供了明确的“负面清单”。本辑案例尤其警示了以下两类常见情形：

1.“对现存产品、服务、技术、材料或工艺流程进行的重复或简单改变”（对应案例3）：

具体表现：常规的企业资源计划（ERP）、客户关系管理（CRM）、办公自动化（OA）等管理信息系统的开发、升级或定制；利用成熟开发工具进行的网站、移动应用（APP）搭建；对现有软件功能的简单扩展或用户界面（UI）改造。

判定逻辑：此类活动是对已有技术方案的重复实施或表层调整，目的在于满足特定运营需求，缺乏科学技术上的新颖性和创造性。

2.“对某项科研成果的直接应用，如直接采用公开的新工艺、材料、装置、产品、服务或知识等”（对应案例4）：

具体表现：直接采购并部署商业化的软件产品或解决方案（如直接使用成熟的财务软件系统）；采用行业公开的标准技术架构（如直接套用微服务架构）进行系统设计；完全依据公开的技术手册或标准协议进行产品生产或服务交付。

判定逻辑：此类活动是对他人已完成的、公开的科技创新成果的商业化利用，企业自身并未主导或参与该成果的研发过程。

小结：企业在立项时必须对照七类“负面清单”进行自审。其他相关负面活动还包括：常规性升级、售后技术支持、市场调研与管理研究、常规质量控制与维护、人文社科研究等。

（三）“跨领域融合应用”的关键：超越“简单叠加”的集成创新

将一项已知技术创造性地应用于一个新领域，可能构成创新，但必须跨越“简单叠加”的门槛，形成集成创新。

1.判断逻辑：将一项已知技术应用于新领域时，是否解决了特定场景下的适配难题，或产生了新的技术化学反应，形成了一套新的技术解决方案。

2.案例解析：案例1将机器视觉技术引入传统建筑构件生产。如果只是买一套通用视觉设备安装，则不是创新。案例1的成功在于为了适应建筑构件生产现场复杂的光照、粉尘环境及多样的缺陷类型，对通用视觉算法进行大量的针对性优化、模型重训练和与工业控制系统的深度集成，构成了一个完整的新技术方案，属于高水平的集成创新。

（四）价值延伸：从“企业受益”到“行业推动”的外溢效应

项目的创新价值不仅体现在技术本身，其对行业技术进步或产业升级的潜在推动作用，也是专家进行综合判断时的积极考量因素。

1.正面佐证：案例1的成果有助于推动建筑业向智能化、数字化转型；案例2的技术降低了高质量文档数字化的门槛，具有普惠价值。这种行业层面的技术外溢性和示范效应，增强了项目创新性主张的说服力。

2.反面参照：案例3和4的成果主要服务于申报企业自身的运营管理效率提升，其技术成果通用性弱，难以被同行业其他企业直接借鉴或采用，缺乏显著的行业技术进步贡献。这从侧面反映了其创新层次可能局限于企业自身应用层面。

3.总结：对“创新性”的审核是一个从技术原理、到政策边界、再到产业价值的立体化评估过程。企业必须证明其项目在技术层面具有“突破性”，在政策层面不触及“负面清单”，在价值层面具备一定的“行业前瞻性”，方能在这一核心维度上站稳脚跟。

二 真实性：判断“是否真实开展规范的研发活动”

真实性是研发费用加计扣除政策对项目落地的核心实践要求。如果说“创新性”考察的是项目的技术高度（想做什么），那么“真实性”考察的则是项目的执行深度（做了什么）。它关注的是企业是否真正组织了人员、投入了资源、并按照科学的研发流程实施了相关活动，旨在回答：“该项目是否真实发生，且过程是否规范可追溯？”

（一）根本判定：研发过程的“不确定性”与“迭代特征”

核心在于区分项目是探索未知的试错过程，还是目标明确、路径既定的 “技术实施与工程交付过程”。真实的研发活动必须具备不确定性、迭代性、创造性，是对技术不确定性的探索，必然包含“尝试—失败—调整—再尝试”的迭代循环。

1.正面案例（案例1、2）：均展现了清晰的技术攻关路径。例如案例1在算法训练过程中，针对特定场景的识别率低问题，进行了多次模型参数调整和样本库扩充；案例2在处理阴影提取时，经历了从粗糙提取到精细化边缘修正的技术迭代过程。这种面对技术难题的反复试验，是真实研发的最有力证明。

2.反面案例（案例3、4）：呈现出明显的线索特征。项目流程往往是“需求分析—系统配置—上线运行”，中间缺乏对技术难题的攻关记录。案例3和4更像是一个标准的工程实施项目，路径确定、结果可预知，不存在技术层面的尝试与失败，缺乏研发活动特有的“探索性”痕迹。

3.结论：研发活动的本质在于对未知的探索与对不确定性的克服。如果一个项目从立项到结题，技术路径完全清晰，方案无需调整，过程一帆风顺，未遭遇技术瓶颈，也未留下任何实验、试错、参数优化或方案迭代的痕迹，那么它实质上更接近一项成熟技术的应用、重复性生产或标准化工程实施，而非真正意义上的研发活动。

（二）关键支撑：全生命周期的“证据链条”

研发活动必须有迹可循。专家评审不仅看总结报告，更看重过程文档的完整性与逻辑性。

1.关键要素：真实的研发活动应具备完整的“立项—实施—验收”闭环文档。

2.立项阶段：需有明确的技术可行性分析报告，界定技术难点与目标。

3.实施阶段（真实性核查重点）：具备翔实的实验记录、测试数据、阶段性技术研讨会议纪要。

4.验收阶段：需有第三方测试报告或详细的技术验收报告，证明技术指标的达成情况。

5.案例对比：案例1能提供针对视觉算法的具体测试数据集和准确率对比分析表；而案例3、4往往只能提供简单的用户操作手册或系统功能截图。缺乏过程数据的支撑，使得后者的研发主张显得苍白无力，易被视为是为了享受政策而进行的“事后包装”。

（三）逻辑校验：技术路线与资源投入的“匹配性”

研发活动的真实性还体现在“人、财、物”与研发内容的高度一致。

1.判定逻辑：申报的研发人员专业背景、工时投入、使用的设备仪器，必须与该项目的技术路线相匹配。

2.反面警示：在很多被否定的案例中（类似案例3、4），常见的问题包括：

（1）人员不匹配：项目声称进行底层算法开发，但核心人员多为业务实施顾问或UI设计师，缺乏算法工程师。

（2）时间不匹配： 研发工时记录与业务交付高峰期完全重合，无法区分是做研发还是做项目交付。

（3）费用不匹配：申报了高额研发费用，但无相应的专用研发设备折旧或云资源消耗记录。

结论：企业的财务账目（辅助账）必须如实反映研发活动的实际消耗。如果技术说明书写得“高大上”，但人员分工和费用结构却显示其仅仅在做普通的系统维护，这种逻辑断层将直接导致真实性被否定。

（四）成果验证：从“形式成果”到“实质贡献”

最终成果的形式，是检验研发真实性的重要辅助维度。

1.正面佐证：案例1、2产出的成果通常包含发明专利、核心算法软件著作权（非通用系统软著）、查新报告或在核心期刊发表的技术论文。这些成果直接对应项目中的具体技术创新点，构成了“研发—产出”的闭环。

2.反面参照：案例3、4的成果往往仅限于软件产品证书、一般的软件著作权（仅保护代码形式）或销售合同。如果一个研发项目的最终产出仅仅是帮助企业签下了一个销售订单，或者获得了一个普通的计算机软件著作权，而无任何实质性的技术秘密或性能突破，其真实性将受到质疑。

3.总结：对“真实性”的审核，是一场“证据还原”的过程。企业必须确保证据链条的完整性（有头有尾）、逻辑性（过程与结果呼应）和一致性（技术与财务匹配）。任何试图通过事后编造资料来“拼凑”研发项目的行为，在逻辑严密的证据链核查面前，都将通过不自然的“断点”和“矛盾”而暴露无遗。

（五）外部合作与实验环境：增强真实性的有力支撑

外部合作与实际验证环境能为研发活动的真实性提供有力佐证。

1.正面体现：案例1与预制构件厂共建联合实验室和示范产线，说明项目具备真实工业场景验证条件，增强了技术落地的可信度。

2.反面警示：纯内部模拟或无实际部署环境的“纸上研发”，其成果的可行性与实用性易受质疑，难以证明研发活动的真实性与技术成熟度。

总结：创新性是“灵魂”，真实性是“骨架”

创新性决定项目是否“值得”加计扣除——它体现技术价值与政策导向的契合度。

真实性决定项目是否“能够”加计扣除——它体现企业执行的规范性与合规性。

只有当一个项目既有技术创新的内核，又有真实研发的外显证据，才能经得起专家鉴定与税务核查的双重检验。企业在规划和管理研发项目时，必须同步在这两个维度上发力，建立“创新有高度、执行有深度、证据有厚度”的良性循环，方能行稳致远，在合规基础上充分享受政策激励。