研发费用从未单独核算的 SaaS 企业，
如何 4 个月完成首次认定

一、接手时：账上干净，材料空心

这家企业做的是面向制造业的排产 SaaS，客户 400 余家，收入以年费订阅为主。财务很规范——正因为规范，问题才明显：总账里根本没有“研发费用”科目，所有技术人员工资都进了“主营业务成本”。

企业方的理解是“我们做产品的，人都在做产品，不就是研发吗”。这个理解在业务上没错，但认定看的是可核查的归集过程：研发人员要有名单与工时，费用要按项目进辅助账，项目要有立项与结题，成果要能对上产品与收入。四件事，他们一件都没留下书面痕迹。

首次沟通时我给出的判断是：条件不是不够，而是没有证据。研发费用实际水平（按人员结构粗算）大概在 8% 以上，远高于 5,000 万元以下企业 5% 的门槛；但没有归集，就无法向评审证明这 8% 存在。

二、三个断点：人、钱、证据

1. 人员：研发与实施混岗，工时是空白

公司 120 人里技术条线 68 人，但其中 22 人长期驻客户现场做实施与运维。按 183 天规则，这些人当年不能计入科技人员；剩下 46 人里，还有一部分在做定制开发而非产品研发。

我们做的是岗位与工时的双维度切分：把技术条线拆成产品研发、平台研发、实施交付三组，逐人确认当年实际工作内容；对跨岗人员，按月填工时比例，研发工时占比低于 50% 的当月不计入。最终认定科技人员 43 人，占职工总数 35.8%，远高于 10% 的要求。

2. 费用：从总账倒推，而不是从今天开始记

研发费用必须覆盖申报当年的前三个会计年度，也就是要回溯两个已经结账的年度。做法是以总账为源头做追溯调整：把主营业务成本中的人工、云资源、外采测试按项目重新拆分，能直接归属的直接归集，不能直接归属的按工时或调用量分摊。

这里有个常被忽略的点：SaaS 的云服务器与带宽费用，只有用于研发测试环境的部分可以计入。生产环境撑起的是收入，不是研发。我们按环境标签拆出约 18% 的云支出，剩下的留在成本里。

3. 证据：成果转化只有一张软著证书

9 项软著是有的，但每项软著对应哪个产品版本、上线时间、带来多少收入，全部说不清。成果转化评分看的是“近三年科技成果转化的年平均数”与转化形式，光有证书只能证明“有成果”，不能证明“转化了”。

补齐的方式是把软著与产品版本号、上线记录、客户合同串起来：同一套系统的三次大版本迭代，按模块拆成三项独立成果，各自对应上线时间与合同金额。9 项软著最终整理出 12 项转化，年均 4 项，达到评分要求。

三、四个月的推进节奏

四个月里，企业真正投入的时间集中在第 3-9 周：财务出数据、技术出工时、我们做归集与复核。这段时间如果企业配合不上，后面全是空转。

四、7.8% 是怎么算出来的

三年研发费用合计 663 万元，同期销售收入合计 8,500 万元，占比 7.8%。分档依据是最近一年销售收入 3,200 万元，落在 5,000 万元以下档，门槛 5%，余量 2.8 个百分点。

注意这里是三年总量之比，不是三年占比的平均值。三个年度占比分别是 6.6%、7.6%、8.8%，算术平均 7.67%，与总量比 7.80% 有细微差异——评审看的是总量比，申报系统的计算逻辑也是总量比，不要用错口径。

另一个容易出错的地方：分母是销售收入，包括主营业务收入与其他业务收入，但不含营业外收入与投资收益。有企业把政府补助算进分母，直接把占比压到门槛以下。

五、可复用的三条结论

结论一：先看条件够不够，再看材料有没有。这家企业如果一开始就去补材料，会补出一堆对不上的数字。正确的顺序是先算清真实水平——如果真实研发强度就低于门槛，补材料只会放大风险。

结论二：辅助账要在总账之上长出来，不能另起一套。很多企业被建议“建个辅助账”，结果建了一套与总账无关的表，专项审计时四套数据对不上（总账、辅助账、审计报告、申报系统）。追溯调整必须留痕：调了哪笔、依据什么、谁批准。

结论三：SaaS 企业的成果转化，藏在版本迭代里。不要等申报前才想“我们有什么成果”。把产品路线图翻出来，每一次有实质功能变化的大版本，都是一次可以论证的转化，前提是上线时间、合同、验收单能对上。