夜雨聆风学习资料网

ARTICLE · 994748

同样是智能软件,为什么一个能加计扣除,一个被专家否定?

同样是智能软件,为什么一个能加计扣除,一个被专家否定?

一个项目叫“文档智能提取扫描技术”,被专家认定属于研发活动,可以适用研发费用加计扣除政策。

另一个项目叫“平台智能运营管理系统”,同样使用了智能、SaaS、ERP、CRM等技术概念,却被专家认定不属于研发活动。

为什么?

2026年1月,科技和税务部门再次发布研发费用加计扣除项目鉴定案例。两类软件项目的对比,给企业提供了一个非常清楚的答案:

项目名称里有没有AI不重要,关键是企业是否真的在解决一个具有不确定性的技术问题,并留下了能够验证研发过程的证据。

官方案例中的“文档智能提取扫描技术”项目,希望解决手机扫描场景中抗干扰能力弱、图像优化不足、适应性差等问题。

企业没有只写“开发一款扫描软件”,而是进一步说明了拟突破的技术:文档图像背景生成、训练样本生成、动态样本采集训练、阴影模式提取训练等。

更重要的是,项目设置了可验证的技术指标,例如图像逼真度、数据生成周期、扫描效果、泛化性能、样本损失差异和阴影去除准确率等。

在组织和证据方面,企业还提供了:

• 可行性研究报告和立项决议;

• 算法、测试等人员组成的研发团队;

• 立项、需求分析、开发、模块测试、项目测试和结项等阶段安排;

• 专家验收;

• 已授权的发明专利和软件著作权。

专家最终判断,该项目创新目标明确、组织实施系统、研发结果具有不确定性,并有相应材料支撑,因此属于研发活动。

另一个“平台智能运营管理系统”项目,希望解决企业内部数据分散、管理效率低、信息滞后等问题,计划集成财务、供应链、人力资源、ERP、CRM、SaaS应用和第三方服务。

从业务角度看,这个项目当然有价值;但业务有价值,不等于技术上构成研发活动。

专家认为该项目存在几个关键问题:

1. 项目目标主要是整合运营数据、提高管理效率,与市场上常见的企业管理系统相似,缺乏明确的技术创新目标;

2. 前后端使用的是较成熟的软件框架和现有系统,项目主要是运用成熟技术改变业务流程;

3. 项目没有设置定量技术指标;

4. 未提供实验测试记录、性能数据等材料,无法体现研发结果的不确定性。

因此,该项目被认定为运用已知方法和现有软件工具进行商业应用软件开发,不属于符合条件的研发活动。

把两个案例放在一起,可以提炼出四条判断标准。

● 第一,写清技术问题,而不只是业务需求

“提高效率、统一管理、消除信息孤岛、实现移动办公”,这些都是业务目标。

研发项目还要继续回答:现有技术为什么不能直接解决?企业要突破的具体技术瓶颈是什么?

例如:

• 复杂背景下识别准确率不足;

• 特定硬件条件下响应速度达不到要求;

• 现有算法无法处理长尾样本;

• 多源数据实时处理存在稳定性或性能瓶颈。

只有把问题推进到技术层面,才能进一步讨论是否存在研发活动。

● 第二,说明研发结果为什么具有不确定性

普通系统实施通常是:需求明确、技术成熟、路径清楚,按计划配置和开发即可交付。

研发活动则意味着企业在开始时不能完全确定技术路径能否成功,需要通过设计、试验、失败、调整和再验证逐步得到结果。

因此,项目材料中应能够看到:

• 备选技术路线;

• 关键假设;

• 试验方案;

• 失败或异常记录;

• 参数调整与版本迭代;

• 最终验证结果。

如果项目从立项到结题“全程顺利”,材料里只剩功能完成清单,反而难以体现技术不确定性。

● 第三,用量化技术指标代替形容词

“更智能、更高效、更稳定、体验更好”都不能直接验证。

不同软件项目可以结合实际设置:

• 准确率、召回率、误报率、漏检率;

• 响应时间、吞吐量、并发量;

• 数据压缩率、处理效率;

• 系统稳定性、故障率;

• 模型泛化表现;

• 特定场景下的资源占用或性能边界。

指标不必为了“好看”而夸张,但必须与项目技术目标对应,并有测试方法和结果记录。

● 第四,过程证据比结题时补写的材料更重要

研发活动判断不是一场文案比赛。

一份语言漂亮的立项报告,不能替代真实的测试记录;一张软件著作权证书,也不能自动证明此前所有投入都属于研发费用。

更有说服力的证据包括:

• 立项与技术方案评审记录;

• 研发任务和人员分工;

• 代码或版本迭代记录;

• 测试用例、测试结果和异常分析;

• 试验失败及调整记录;

• 第三方检测或用户场景验证;

• 验收结论与原定技术指标对照。

这些资料共同证明:企业不是把成熟功能重新组合,而是在一个有组织的过程中解决技术不确定性。

1. 项目要解决的是技术问题,还是单纯的管理效率问题?

2. 市场上是否已有成熟方案可以直接实施?

3. 企业拟突破的关键技术能否具体描述?

4. 项目开始时,哪些技术结果无法确定?

5. 是否设置了可测试的量化技术指标?

6. 是否设计了试验、测试和迭代过程?

7. 人员、工时和费用是否按项目持续记录?

8. 最终材料能否还原从问题、方案到验证结果的完整链条?

如果前四个问题回答不清,后面即使补齐工时表和费用台账,也不能解决研发活动属性本身的问题。

研小匠可以帮助企业把项目、人员、工时、费用和过程材料按统一编号整理,形成辅助账和证据索引,减少不同部门数据之间的错位。

但系统不能因为项目名称中出现“AI”“大模型”“智能平台”,就自动认定项目属于研发;也不能把缺失的试验和测试记录变成真实发生的研发过程。

工具最适合解决的是整理、映射、核对和留痕。研发活动判断仍应回到技术事实,并结合政策口径和专业意见完成。

如果需要《软件与AI项目研发活动8项自查表》,可在公众号后台回复:项目自查

相关学习资料

返回首页浏览学习资料