请发行人说明研发费用合规体系建设的时间表如何安排？

发行人回复：

研发费用合规体系建设的时间表，监管关注的不是“是否有一份时间规划”，而是控制是否在申报前已经真实运行了足够长的周期，使中介的穿行测试和控制测试能够覆盖到“整改后的控制”而非“整改动作本身” 。财税尽调整改通常需要提前12—24个月启动，越早介入可选择的整改路径越多；若申报前18个月尚未启动，多项整改（系统上线、部门调整、历史数据重建）将被迫并联，单件耗时3—5个月、叠起来6—8个月，时间窗口即告关闭。-5-25

公司合规体系建设的时间表以申报时点为锚点倒排，划分为四个阶段：诊断与方案（申报前18—24个月）→ 制度重构与系统上线（申报前12—18个月）→ 运行与固化（申报前6—12个月）→ 验证与申报准备（申报前6个月） 。时间表的关键约束不是“每个阶段做了什么”，而是关键控制的上线时点必须留出足够的运行记录长度——工时系统若在申报前3个月才上线，控制测试将无样本可取；领料隔离若在申报前6个月才实现，穿行测试只能覆盖极短的窗口，无法证明“一贯执行”。

二、时间表为什么必须倒排：监管检验的是“运行周期”，不是“制度文本”

注册制审核关注的是“报告期内是否一贯规范”。制度修订、文件发布、审批流设置，这些动作本身不构成合规体系，只有当控制已经嵌入日常流程、产生了可调取的运行记录，中介机构才能对控制的有效性执行测试并发表意见。深交所审核问询中反复出现的核查程序是“了解并测试与研发费用归集相关的内部控制，执行穿行测试和控制测试，核查报告期内执行是否一贯执行”。“一贯执行”的前提是控制已经存在了足够长的时间；如果控制在申报前才上线，“一贯”二字即无从谈起。-

这也是为什么工时系统的建设路径被拆分为“0—3个月先用标准化Excel、3—9个月利用OA系统搭建简易模块、9—18个月申报前必须上线独立系统”。这一渐进路径的实质不是技术选型的逐步升级，而是为控制的运行留出时间：Excel阶段解决“有没有记录”，OA阶段解决“有没有审批留痕”，独立系统阶段解决“记录能否被交叉验证”。每一步的时点安排，都是为了让下一阶段的验证有足够的样本可追溯。

三、分阶段时间表

阶段一：诊断与方案（申报前18—24个月）

核心任务：完成三数对齐与高风险领域的穿透诊断，锁定需要整改的事项清单，并按“发现概率×修复紧迫性”排序。

关键动作：拉取报告期各期“申报表（A107012）+审计报告研发费用+税务汇算A107012”三组数据，差异超过5%的必须查明原因；检查辅助账是否按研发项目设置（而非“公司级一口价”），每一项目下的人员工时、材料、折旧、委外、其他费用五栏是否可拆分；对非专职研发人员（含实际控制人、董监高）的工时依据、研发与生产领料的系统隔离状态、委外研发的科技部门登记情况、资本化时点的证据支撑进行穿透诊断。诊断的产出应是分级的整改清单：哪些事项需要在阶段二启动系统或流程重构（长周期），哪些可以通过追溯调整解决（短周期），哪些属于单据补证即可修复（但须警惕事后补证的定性风险）。

这一阶段之所以需要6个月以上，是因为诊断本身不是“查一遍账”，而是对人员、项目、成果三层证据链的交叉验证，发现的问题往往需要进一步追溯才能确定其性质和整改路径。

阶段二：制度重构与系统上线（申报前12—18个月）

核心任务：完成研发与生产边界的结构性隔离、工时记录机制的建立、辅助账的项目级重建，使关键控制在申报前至少12个月上线。

关键动作：

研发与生产领料的系统隔离。ERP系统中研发领料单与生产领料单使用不同的单据类型、审批流和项目编号索引，使两者在系统底层不可混同。系统上线后，财务部门按项目设置辅助账、分项目记录研发支出的流程才具有底层数据基础。

工时记录机制的分步建立。可参照“Excel逻辑校验→OA审批留痕→独立工时系统”的渐进路径，但独立系统必须在申报前9—18个月内上线。系统上线时，工时填报须按周关联具体项目、每条工时须有对应的日志痕迹；研发人员打卡签入后系统自动按项目累计工时，并与门禁记录按月比对，确保工时与薪酬分摊的勾稽可验证。

辅助账的“项目级”重建。按“人员工时+材料+折旧+委外+其他”五栏拆分，逐项目归集，而非在公司层面汇总。历史老数据不要为了“好看”而清洗补录，原样保留并标注清楚时间节点——事后集中补编的痕迹一旦被系统日志识别，后果重于原始瑕疵本身。

制度与流程的同步修订。出台《研发项目管理制度》《研发费用核算办法》《研发内控手册》，将人员认定边界、工时分摊规则、领料隔离标准、委外登记要求、资本化时点判断依据嵌入制度文本，但制度的价值取决于其能否在系统中被强制执行，而非文本本身的完备程度。

这一阶段是时间表中耗时最长、不可压缩性最强的环节。部门调整、系统选型、数据迁移、审批流配置、人员培训，任何一项的延迟都会直接压缩后续的运行周期。

阶段三：运行与固化（申报前6—12个月）

核心任务：让已上线的控制在无人为干预的状态下持续运行，积累可供中介测试的完整运行记录。

关键动作：工时系统的逐月数据、ERP领料隔离的系统记录、共用设备的使用登记、委外研发的节点检查记录，在这一阶段形成连续的、可追溯的运行轨迹。中介机构的穿行测试和控制测试应在此阶段介入，而非等到申报前才执行——测试中发现的偏差（如某月的工时审批缺失、某笔领料的项目编号错误）尚有时间修复并补充运行记录，若测试推迟到阶段四，偏差将直接成为申报文件中的缺陷。龙鑫智能的问询回复中，中介机构对整改后内控的评价是“已合理、正常运行并持续有效”，这一结论的支撑正是运行记录的时间跨度足以覆盖报告期内的关键节点。

阶段四：验证与申报准备（申报前6个月）

核心任务：完成一次模拟穿透核查，确认合规体系的证据链能够经得起问询和督导的检验，并将时间表、整改过程和运行记录整理为可调取的底稿。

关键动作：中介机构以“如果督导进场，系统日志和底层数据能否支撑我们发表的每一句结论”为标准，执行模拟穿透核查。核查的重点不是“控制有没有”，而是“控制的形成时间与业务发生时间是否一致”——工时台账的形成日期是否与考勤、项目记录一致，立项文件的时间是否早于费用发生时间，不同来源的同类资料之间是否存在无法解释的矛盾。模拟穿透中无法支撑的结论，要么在申报前修复，要么在申报文件中如实披露并准备解释。同时，将时间表各阶段的产出（诊断清单、系统上线记录、运行数据、测试底稿）按统一目录归档，确保督导进场时能够在合理时间内完成调取。

四、时间表的刚性约束与不可压缩项

以下事项的时间安排不具备弹性，任何压缩都会直接传导为申报阶段的实质障碍：

工时系统上线至申报的间隔不得少于9—12个月。 控制测试需要覆盖足够多的月份样本，以证明控制不是“上线后短暂有效”。若系统在申报前3—6个月才上线，中介只能对极短窗口执行测试，“报告期内一贯执行”的结论无法成立。

研发与生产领料的系统隔离必须在报告期最后一个完整年度开始前完成。 若隔离在年度中途才实现，该年度前半段的领料数据仍然无法区分，穿行测试将在此处断裂。

历史数据的追溯调整必须在阶段二内完成。 涉及会计差错更正的追溯重述需要董事会审议、审计报告附注披露和申报文件的全口径统一，若推迟到阶段四，将与其他申报准备工作形成时间冲突，且更正后的数据无法在申报文件中形成一致的列报。

独立系统的上线不因“先用Excel顶着”而可以无限期推迟。 Excel和OA阶段的记录可以作为过渡期的补充证据，但它们不构成“独立系统”的替代——缺乏系统层面的审批留痕和自动校验，工时数据的真实性和一致性在穿透核查中仍然脆弱。

五、结论

综上，公司研发费用合规体系建设的时间表以申报时点倒排，划分为诊断与方案（申报前18—24个月）、制度重构与系统上线（申报前12—18个月）、运行与固化（申报前6—12个月）、验证与申报准备（申报前6个月）四个阶段。关键控制（独立工时系统、ERP领料隔离、项目级辅助账）的上线时点安排在申报前至少12个月，为中介的穿行测试和控制测试留出了完整的运行周期样本。时间表不存在将系统上线和运行验证压缩在申报前短期内的安排，不构成“制度已修订但控制尚未运行”的情形。

六、中介机构核查程序与核查意见

（一）核查程序

1. 获取公司研发费用合规体系建设的时间表及阶段产出记录，核查各阶段的时间跨度与关键控制的上线时点，评估工时系统、领料隔离、辅助账重建等核心事项的上线至申报间隔是否满足运行记录的最低要求；
   
2. 核查阶段一的诊断清单与三数勾稽底稿，确认差异超过5%的事项是否已查明原因并在后续阶段完成调整；
   
3. 核查阶段二的系统上线记录（ERP配置变更记录、工时系统上线日志、审批流配置截图），确认控制上线的实际日期与时间表的一致性，识别是否存在“计划上线日期远早于实际执行”的情形；
   
4. 对整改后的控制执行穿行测试和控制测试，样本覆盖控制上线至申报之间的连续月份，验证控制执行的一贯性；核查测试中发现偏差的处理记录及修复时间；
   
5. 核查阶段三的运行记录连续性：工时数据是否逐月形成、领料隔离的系统记录是否无中断、委外研发的节点检查是否在各期均有留痕；
   
6. 核查阶段四的模拟穿透记录及底稿归档状态，确认时间表各阶段的产出可按统一目录调取；核查质控、内核部门对时间表执行情况及控制运行有效性的复核意见。
   

（二）核查意见

经核查，保荐机构、申报会计师认为：发行人研发费用合规体系建设的时间表以申报时点倒排，关键控制的上线时点安排在申报前至少12个月，为穿行测试和控制测试留出了完整的运行周期样本。诊断阶段识别的差异已查明并调整，系统上线记录与时间表一致，整改后的控制在运行与固化阶段保持了执行的连续性。发行人不存在将控制上线和运行验证压缩在申报前短期内、或以制度文本替代实际运行的情形。

七、底稿索引

八、实操注意事项

1. 时间表的核心不是“每阶段做什么”，而是“关键控制什么时候上线、上线后跑了多久”。 一份只列示“第1—3月完成诊断、第4—9月系统上线”的时间表，在审核中无法回答“控制测试覆盖了哪些月份”的追问。时间表的有效性取决于上线时点与申报时点之间的间隔：工时系统申报前3个月上线，控制测试只能取3个月样本，“报告期内一贯执行”的结论即不成立；申报前12个月上线，样本才具有说服力。时间表的编排应以“为验证留窗口”为第一原则，而非以“赶在申报前完成”为目标。

2. 阶段二不可压缩，压缩的后果在阶段四才暴露，届时已无修复窗口。 诊断、系统选型、部门调整、数据迁移、审批流配置，这些事项的并联能力有限，单件耗时叠加后容易吞噬整个时间窗口。许多发行人在申报前6个月才意识到工时记录无法支撑分摊、领料隔离的系统记录不完整，此时既无法追溯重建（补录的痕迹会被识别），也无法等待新系统跑出足够的运行周期。时间表的刚性约束必须在阶段一即被识别并纳入规划。

3. “先用Excel顶着”是过渡方案，不能成为最终方案。 标准化Excel和OA审批可以作为独立系统上线前的过渡，但它们的证据强度不足以支撑穿行测试和控制测试的结论——缺乏系统层面的自动校验和不可篡改的操作日志，工时数据的真实性在穿透核查中仍然脆弱。独立系统必须在申报前9—18个月内上线，这一节点不宜因“业务繁忙”或“系统预算”而推迟。

4. 历史数据的问题在于“怎么处理”，不在于“有没有问题”。 历史期间的工时记录不完整、领料未按项目归集、立项文件缺失，这些是多数企业在规范前的常态。时间表中应明确：历史数据原样保留、标注时间节点，不为了“好看”而清洗补录；需要在申报报表中更正的，通过追溯调整处理，而非在系统里修改历史记录。后者一旦被系统日志识别，后果从“归集不准确”升级为“信息披露不真实”。

5. 中介的测试介入时点应前置到阶段三，而非阶段四。 若穿行测试和控制测试等到申报前才执行，测试中发现的偏差（某月审批缺失、某笔领料编号错误）已经没有时间修复并补充运行记录，只能作为缺陷写入申报文件。将中介测试安排在阶段三（申报前6—12个月），偏差尚有修复窗口，修复后的控制还能积累新的运行记录供再次测试。时间表应将“中介测试—偏差修复—再测试”作为一个闭环纳入阶段三和阶段四的衔接。