关于这些案例 为避免披露客户信息，文中企业名称、所在地区与可识别细节均已脱敏，金额按保密要求做了等比处理，因此不是某一家的原始报表；业务形态、卡点与处理方式取自同类项目的共性，可直接对照自己公司的情况。
一、客户长什么样
B 公司做行业软件，一条主产品线卖给制造企业，另有两条小产品线。它的研发特点是没有明确的「项目终点」—— 同一个产品一年发四个版本，每个版本都在改架构、加模块、适配新客户。研发一直在发生， 但「什么算一个项目」这件事，公司内部从来没有统一过。
| 维度 | 情况 | 为什么这一项决定了后面的做法 |
|---|---|---|
| 营收规模 | 约 1.6 亿元 / 年，项目型收入为主 | 收入与交付挂钩，研发与实施容易混在一起 |
| 人员结构 | 380 人，研发 290 人，售前 32 人，实施 58 人 | 售前与实施大量参与需求分析与配置开发 |
| 研发形态 | 主产品线持续迭代 + 两个新产品从 0 到 1 + 客户定制开发 | 三种形态的研发属性完全不同，混在一起就说不清 |
| 原来的项目划分 | 43 个「项目」，其中 19 个是同一条产品线的连续版本 | 项目碎，单个金额小，材料厚度不够 |
| 工具基础 | Jira 用了四年，需求、任务、提交记录都在里面 | 数据是有的，只是从来没进过辅助账 |
这家企业的情况说明一件事：软件公司的研发数据往往不缺，缺的是把工程数据翻译成财务口径的那一层。 Jira 里有 18 万条 issue，但没有一条标着「这个 issue 属于哪个研发项目、花了多少工时」—— 于是财务只能按部门工资总额估一个比例。
二、原来怎么做
| 环节 | 原来做法 | 结果 |
|---|---|---|
| 项目划分 | 按版本号立项目：V3.2、V3.3、V4.0……一年立十几个 | 单个项目金额小、周期短，立项报告只能写半页 |
| 人员归集 | 研发部全额 × 85%，售前 32 人 × 100% | 售前被整体算进研发，是最大的风险点 |
| 工时 | Jira 有工时字段，但只用于排期，不导出 | 辅助账里没有任何工时依据 |
| 委外 | 3 家外包团队，年 480 万元，只有发票与框架合同 | 无验收标准，无法证明用于研发 |
| 版本迭代 | 全部计入研发 | 部分版本只是适配客户界面，被质疑为「常规性升级」 |
三、卡在哪
这家企业没有被正式核查，是准备申报专精特新时自己先做了一遍体检，发现材料撑不住。 它的问题和大额被查的企业不太一样，集中在四个「说不清」上。
| 说不清的地方 | 具体表现 | 风险 |
|---|---|---|
| 43 个项目里哪些真的是研发 | 19 个是同产品线的连续版本，V3.3 改的是报表样式，V4.0 换了架构 | 逐个项目问「技术不确定性在哪」，有一半答不出 |
| 售前为什么 100% 算研发 | 售前做方案、演示、POC，确实有技术支持成分 | 没有工时记录，无法拆分，最容易被整体剔除 |
| 委外的成果归谁 | 框架合同写「技术服务」，没有单项目验收 | 可能被认定为技术服务采购，不是研发活动 |
| 迭代与定制的界线 | 客户定制开发按合同收款，也计入了研发 | 定制开发属于交付，不是研发；混淆会被认定为虚增 |
四、改了什么
- 项目从 43 个归并到 17 个
归并规则只有一条：同一个技术目标下的连续迭代算一个项目，跨技术目标的拆开。 V3.2 到 V3.5 都是在解决「多租户数据隔离」，合并成一个项目，立项报告写清四年的技术路线与阶段性目标； V4.0 换架构另立一个。归并后项目数量少了，但每个项目的技术含量说得清了。
- 工时从 Jira 导，按 issue 关联项目
给每个 issue 加一个「研发项目」字段，历史数据按版本号批量映射。每月导出一次工时， 与考勤做比对。这一步花了两周，之后每月自动出数。
- 售前按工单分，不再 100%
售前的 POC 开发、技术方案编写算研发支持，商务拜访、报价、投标不算。按工单统计后， 实际研发参与率约 22%——比原来的 100% 少了近八成，但因为有了依据，这部分反而站得更稳。
- 委外补验收，按里程碑确认
三家外包补签了单项目工作说明（SOW），每个里程碑有交付物与验收记录。 480 万元中约 60 万元因无法对应到具体研发项目，被主动剔除。
- 定制开发单独建类
按合同收款、有明确客户需求的定制开发，归入「交付」而不是「研发」； 只有沉淀到主产品线、可复用的部分，才按工时分摊进研发。这一条让研发费用的口径第一次自洽。
五、结果
| 项目 | 整改前 | 整改后 | 说明 |
|---|---|---|---|
| 研发项目数 | 43 个 | 17 个 | 按技术目标归并，连续迭代合并 |
| 可加计研发费用 | 约 2,050 万元 | 约 2,310 万元 | 委外剔除 60 万，但工时归集让人员人工增加约 320 万 |
| 售前人员 | 32 人 × 100% | 按工单，研发参与率 22% | 口径收紧但依据完整 |
| 工时依据 | 无 | Jira 导出 + 考勤比对，逐人逐项目 | 从「估」到「取」 |
| 委外 | 480 万元，仅发票 | 按 SOW 与验收，420 万元计入 | 程序要件补齐 |
这家企业最值得学的一点是：它把「项目」重新定义了一遍，而不是把「材料」重写了一遍。 项目定义错了，后面的立项报告、工时、验收全都建在错的基础上；项目定义对了， 材料自然就厚了——因为每个项目都有真实的技术目标、真实的参与人、真实的交付物。
六、软件企业特有的三个判断
第一，版本迭代算不算研发，看的是「有没有技术不确定性」，不是「改了多少行」。 换 UI、改文案、适配客户字段，属于常规性升级；解决多租户隔离、性能瓶颈、新协议适配， 才构成研发。判断标准要能落到具体的issue上，而不是笼统地说「整个版本都是研发」。
第二，定制开发与研发的分界，看「成果归谁、能不能复用」。 按客户合同交付、代码只给这一家的，是交付成本；沉淀进主产品线、其他客户也能用的，才可能计入研发。 两者混在一起，是软件企业最常见的虚增来源。
第三，工程工具里的数据要主动翻译。Jira、GitLab、Confluence 里的记录，只要加上「项目」这一层映射， 就是最好的工时与过程证据。反过来，如果这些数据从来没被用过，它对企业毫无价值—— 核查人员不会自己去翻你的 Jira。
七、同类企业自查清单
| 检查项 | 过关标准 |
|---|---|
| 项目定义 | 同一技术目标下的迭代合并，跨目标拆分；每个项目能说清技术不确定性 |
| 项目数量 | 单个项目金额不宜过小（经验值：不低于研发费用总额的 3%），否则材料厚度不足 |
| 工时来源 | 从工程工具（Jira / 禅道 / GitLab）导出，与考勤可比对 |
| 售前与实施 | 按工单或项目参与记录分摊，不整体计入 |
| 委外 | 单项目 SOW + 里程碑验收 + 成果归属条款 |
| 定制开发 | 与研发分账，只有可复用部分按工时分摊进研发 |
| 版本迭代 | 每个版本标注研发属性，常规升级单独列出并剔除 |
| 知识产权对应 | 软著/专利与项目、产品线能对应上，不是年底集中申请 |
说明：本文为脱敏案例，用于理解研发费用归集的通行做法，不构成税务意见或法律意见。具体口径以申报当期有效的法规、公告及主管税务机关的执行要求为准。
项目立了一堆，每个都说不清技术目标？
把近三年的项目清单和 Jira 导出放在一起，我们能帮你判断哪些该合并、哪些该拆、哪些根本不算研发。
关于这个案例，你可能想问
- 软件企业的版本迭代，哪些能算研发？
- 看是否存在技术不确定性。架构重构、性能优化、新协议适配、多租户隔离这类有明确技术难点的，属于研发；界面改版、文案调整、客户字段适配属于常规性升级，不应计入。判断要能落到具体 issue，而不是整个版本一刀切。
- Jira 里的工时能直接作为辅助账依据吗？
- 可以作为基础数据，但要补三件事：每个 issue 关联到研发项目、工时与考勤能对上、项目负责人有审核动作。只有 issue 没有项目映射，财务还是无法归集。
- 售前人员一点都不算研发吗？
- 不是。POC 开发、技术方案编写、原型验证属于研发支持，可以按工时计入；商务拜访、报价、投标不算。关键是按工单或参与记录分摊，而不是整体按一个比例。
- 项目合并之后，单个项目金额变大，会不会更容易被查？
- 相反。单个项目金额过小、周期过短，材料很难写厚，反而容易被认为「为凑数而立项目」。合并的前提是技术目标确实一致，合并后立项报告能写清技术路线与阶段目标。
- 客户定制开发的成本能进研发费用吗？
- 只有可复用、沉淀到主产品线的部分可以按工时分摊计入；按合同交付、代码只归客户的，属于交付成本，计入研发会构成虚增。这也是软件企业最常见的风险点。