研发工时和研发费用对不上？IPO审计前先补这3个证据缺口

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}

监管问询里研发工时被反复追问，原因不复杂：薪酬通常占研发费用的六成以上，工时不实，费用归集就站不住。三个证据缺口，决定这笔费用能不能被穿透核查通过。

下文结合审计核查要点和宝企通工时管理的实际配置，把三个缺口逐个拆开讲，每个缺口给出可执行的补齐方式，末尾附一份自查清单。

一、审计为什么盯着工时看

审计的逻辑链条是三段：钱花到哪了（费用归集）→ 人干了什么（工时记录）→ 东西做出来没有（研发产出）。三段要能对上，任何一段断裂，整笔研发费用都要被重新质疑。

纸质签到表和 Excel 台账在这条链条上能提供的证据很有限。障碍不在工具本身，而在于它们缺少三个属性：原始性、时间戳、不可篡改。

现场高频出问题的三类记录：

• 人月满勤，但对应不上项目节点。研发人员当月工时标满，项目里程碑却找不到任何投入痕迹。
• 全员工时整齐划一。每个人每天都恰好 8 小时研发工时，没有波动，这种分布不符合真实工作状态。
• 跨项目分摊没有依据。同一人同时在研发和生产之间投入，研发占多少、生产占多少没有连续记录，只能事后拍比例。

这三类问题指向的不是财务处理方式，而是业务源头的记录方式。从业务源头记录工时的思路，正是宝企通工时管理这类项目工时管理系统的主要设计出发点。

二、缺口一：颗粒度只到人天，没到项目和任务

审计要看什么

审计要的不是"张三这个月研发 200 小时"，而是"张三的 200 小时分别投入哪几个项目、哪个阶段、对应什么交付物"。

只记到人，费用归集只能按固定比例硬分，比例一旦被问"依据是什么"，就答不上来。记到项目和任务，比例是记录出来的，不是算出来的。

工时记录至少应包含的字段

记录维度：人员 / 项目编号 / 任务或阶段 / 日期 / 时长
关联维度：项目阶段（立项-开发-测试-结项）/ 交付物或成果编号
证据维度：填报时间戳 / 修改记录 / 审批人 / 审批时间

字段缺一项，穿透核查时就要多解释一次。其中"项目阶段"这一项尤其关键，它直接影响这笔工时是资本化还是费用化，财务口径离不开它。

系统层面怎么落地

选工时管理系统时，颗粒度这一项可以先用两个问题筛：能不能把项目拆到任务级填报、跨项目投入能不能分开记。

宝企通工时管理的处理方式是把工时直接挂在项目和任务下，填报时先选项目、再选任务或阶段，记录维度是"人 + 项目 + 任务 + 日期"。财务侧拿到的不是一个人的总工时，而是按项目、按阶段汇总的明细。

三、缺口二：工时是事后补的，没有原始时间戳

补记为什么一眼能看出来

月末集中补录，会在数据里留下很明显的痕迹：

• 提交时间集中在月末最后两天
• 同一人多条记录的修改时间几乎相同
• 修改前后的数值差异较大，且没有变更说明

审计师不需要复杂工具，看后台操作日志就能判断这批数据是"记"出来的还是"补"出来的。

怎么补齐

• 工时填报周期从月改成周或天。周期越短，凭记忆补录的空间越小。
• 记录保留创建时间、修改时间、修改人，且这些字段填报人不可编辑。
• 提交后的记录原则上锁定，需要修改走变更流程并留痕。

系统的价值不在于让人填得更快，而在于让"什么时候填的"这件事本身成为证据。

宝企通工时管理在填报环节支持按日、按周、按月三种节奏，考勤数据实时校对，重复提交会被自动标出；审批流可以按组织架构配置，项目经理核工作量、部门负责人核投入合理性，审批时间和处理意见都留在记录上，统计结果能直接导出 Excel。

四、缺口三：工时账和薪酬账是两套数

交叉验证怎么失败

常见状态是：工时系统里一个人这个月研发投入 180 小时，薪酬系统按工资总额的 75% 计入研发费用，两个数谁也不是从对方算出来的。审计一交叉，比例对不上，就要额外解释。

正常的关系应该是单向的：工时比例决定费用分摊比例。

打通的方式

• 工时核准后的比例作为工时分摊依据，而不是财务另行估算
• 分摊结果可反查：任意一笔研发费用能定位到具体的工时明细和审批记录
• 兼任研发与其他职能的人员，按实际填报的工时比例拆分，不使用固定系数

这一步是很多企业卡住的地方，因为工时管理系统和薪酬系统往往分属两个部门。选型时值得提前确认两件事：核准后的工时能不能按项目输出分摊口径、报表能不能按项目和时间段自定义取数。

宝企通工时管理的项目成本模块以核准工时为基础做归集，报表能按项目、按人、按时间段出。财务在关账前可以先自己跑一遍口径，而不是等审计进场了再拼数据。

五、自查清单

逐条对照，任意一条答不上来，就是待补的缺口：

第 8 条可以当作验收标准。十分钟能调出来，说明数据是活的、连着的；调不出来，前面几条做得再好也只是纸面合规。

六、常见问题

Q1：研发人员同时负责多个项目，工时怎么分才算合规？

按每天实际投入时间分别填报，不要月底按固定比例拆。审计看的是分配依据是否客观，日填报加项目经理确认，是目前认可度较高的一种证据形式。

Q2：工时总数要不要和考勤完全一致？

逻辑上研发工时应当小于或等于考勤工时。研发工时长期高于考勤且无加班记录，会被质疑真实性；长期明显偏低，则可能影响研发投入强度的认定。

Q3：Excel 台账审计认可吗？

认可度有限。Excel 缺少权限控制和操作留痕，改动之后无法证明原始值，多数情况下只能当辅助材料。拟上市企业通常会被建议换成带审批流和操作日志的专业系统。

Q4：小微研发团队也需要上系统吗？

人少的时候 Excel 能撑住，但只要有跨项目投入、有加计扣除申报、有外部审计，手工台账的解释成本会迅速上升。团队规模不是判断标准，是否存在对外举证的需求才是。

Q5：加计扣除的工时辅助账，和 IPO 审计的工时要求一样吗？

不完全一样。加计扣除关注研发活动本身的分摊依据，IPO 审计还会追问人员身份、内控流程和证据链闭环。两套要求同时满足的做法是：源头只记一次，按不同口径出报表。

结语

合规不是审计前突击整理出来的材料，而是日常填报留下的痕迹。工时的价值也不止于应对检查，它同时是项目成本核算和研发效率评估的原始数据。

宝企通工时管理要做的就是把这一件事做扎实：让每一次填报都带着项目、时间、责任人和审批痕迹，让数据在需要举证的那一刻是现成的，而不是现凑的。