audit-readiness

SOX 404 测试生命周期

端到端阶段

1. 范围界定： 确定哪些科目和流程具有足够的风险，需要纳入控制覆盖范围
2. 风险评估： 评估范围内每个科目发生潜在错报的概率和严重程度
3. 控制映射： 记录用于缓解每项已识别风险的具体控制
4. 有效性测试： 评估控制的设计是否合理，以及执行是否始终如一
5. 缺陷评估： 判断测试中发现的任何控制缺口的严重程度
6. 管理层报告： 正式形成整体 ICFR 评估，并披露任何重大缺陷

确定哪些科目纳入范围

如果某科目存在非极低的错报概率，且错报单独或与其他错报合计具有重大性，该科目就应纳入范围。

基于规模的指标：

• 余额超过定量重要性基准（通常为收入、资产或税前利润等参考数值的 3-5%）
• 高交易量会增加发生错误的统计概率
• 余额很大程度上依赖估计或管理层判断

基于风险的指标：

• 会计处理本身较为复杂（多要素收入安排、衍生工具、养老金义务）
• 该科目是常见的舞弊目标（现金、收入、关联方活动）
• 历史审计调整或先前重述曾影响该科目
• 余额基于重大的管理层估计或主观假设
• 该科目或流程为新设，或发生过重大变化

各类科目的财务报表认定

科目类别	需要关注的主要认定
收入	发生、完整性、计量、期间分配
应收账款	存在、计价（准备金充足性）、权利归属
存货	存在、计价、完整性
不动产及设备	存在、计价、完整性、权利归属
应付账款	完整性、计量、存在
应计义务	完整性、计价、计量
股东权益	完整性、计量、列报
结账与报告流程	列报、计量、完整性

设计有效性与运行有效性

设计有效性关注：该控制的设计是否能够拦截或揭示目标认定中的重大错报？

• 通过端到端穿行测试进行评估（将一笔代表性交易追踪至整个流程）
• 确认控制位于流程中的正确环节
• 确认控制直接应对指定风险
• 至少每年重新评估一次，或在流程发生变化时重新评估

运行有效性关注：在整个审查期间内，该控制是否确实按预期运行？

• 通过检查、观察、重新计算或询问（并进行佐证）进行评估
• 样本量必须足以支持可靠的结论
• 必须覆盖整个依赖期间（而非仅某个单一时点）

抽样方法

统计随机抽样

适用范围： 高交易量、交易级控制的标准方法。

步骤：

1. 确定总体：测试期间内所有受该控制约束的交易
2. 为总体中的每项内容分配一个连续编号
3. 使用随机数生成器抽取样本
4. 确认每项内容被选中的概率相同（不存在系统性排除）

优势： 具有统计依据，不存在选择偏差
局限性： 可能无法捕捉高风险异常值；需要完整的总体清单

风险导向（判断性）抽样

适用范围： 通过针对风险特征较高的项目，对随机抽样进行补充；对于规模较小或异质性较强的总体，可作为主要方法。

筛选标准：

• 超过指定金额阈值的交易
• 异常或非标准分录
• 接近期间边界的活动（截止风险）
• 关联方交易
• 人工覆盖或通过例外流程处理的项目
• 首次合作的供应商或客户

优点： 将测试工作集中于风险最高的项目
局限性： 不具备统计代表性；必须记录选择理由

非结构化（随意）抽样

适用范围： 无法获得带编号的总体，且项目相对统一的情况。

步骤：

1. 不按刻意设定的模式选择项目
2. 将所选项目分布到整个测试期间
3. 防止无意识的倾向（例如偏向列表顶部或整数等）

优点： 简单，无需工具
局限性： 不具备统计有效性；容易受到无意偏差影响

间隔法（系统）抽样

适用范围： 希望均匀覆盖期间的顺序总体。

步骤：

1. 计算抽样间隔：总体项目数除以目标样本量
2. 在第一个间隔内随机选择一个起点
3. 从该起点开始，每隔 N 个项目选择一项

示例： 1,000 项的总体，样本量为 25 项 -> 间隔为 40。随机起点为第 12 项。所选项目：12、52、92、132……

优点： 确保均匀覆盖整个总体
局限性： 数据中的周期性模式可能导致结果偏斜

样本量参考表

控制频率	近似总体数量	较低风险样本	中等风险样本	较高风险样本
每年	1	1	1	1
每季度	4	2	2	3
每月	12	2	3	4
每周	~52	5	8	15
每日	~250	20	30	40
每笔交易（少于 250 笔）	< 250	20	30	40
每笔交易（250 笔及以上）	250+	25	40	60

需要扩大样本量的情形：

• 账户或流程的固有风险较高
• 该控制是针对重大风险的唯一保障（没有备用控制）
• 以往测试周期中发现过缺陷
• 该控制刚实施，历史上未经测试
• 外部审计师计划依赖管理层的测试结果

工作底稿与证据标准

必备工作底稿章节

1. 控制概况：

   • 唯一控制标识符
   • 叙述性说明（谁执行什么操作、频率如何）
   • 分类（人工、自动化、依赖 IT 的人工控制）
   • 执行频率
   • 目标风险与认定

2. 测试方案：

   • 明确的测试目标
   • 详细的程序步骤
   • 控制运行正常时预期证据的说明
   • 抽样方法及所选方法的理由

3. 执行记录：

   • 总体说明及项目总数
   • 所选样本项目（方法及具体标识符）
   • 逐项结果（通过/未通过，以及检查的具体证据）
   • 对发现的每个例外情况进行完整叙述

4. 总体结论：

   • 有效性评级（有效 / 缺陷 / 重大缺陷 / 重大弱点）
   • 支持结论的理由
   • 对任何例外情况的影响程度评估
   • 相关时评估的补偿性控制

5. 责任确认：

   • 测试人员签名及日期
   • 复核人员签名及日期

什么构成充分证据

可接受：

• 能显示已执行控制或配置的系统截图
• 带有签名、姓名首字母缩写或电子审批印章的文件
• 包含可识别的审批人和明确日期的电子邮件记录
• 记录操作者、操作和时间戳的应用程序审计日志
• 能复现已记录结果的独立重新计算
• 注明日期、地点和观察者的书面观察记录

单独来看不充分：

• 未经佐证的口头陈述
• 缺少日期的文件
• 没有可识别的执行人或审批人的证据
• 缺少日期/时间元数据的系统生成输出
• 写有“根据与 [姓名] 的交谈”的笔记，但没有支持性文件

文件组织约定

ICFR Testing/
  [Fiscal Year]/
    Scoping & Risk Assessment/
    Revenue Process/
      Control Matrix
      Walkthrough Narrative
      Individual Test Workpapers
      Evidence Attachments
    Purchase-to-Pay Process/
    Payroll Process/
    Financial Close Process/
    Treasury Process/
    Capital Assets Process/
    IT General Controls/
    Organization-Level Controls/
    Aggregation & Conclusions/
      Deficiency Evaluation Workpaper
      Management ICFR Assessment

缺陷严重性框架

一般缺陷

当控制的设计或执行无法使员工在履行日常职责时防止或发现错报，即存在缺口。

评估维度：

• 该缺口导致错报的可能性有多大？
• 由此产生的错报可能有多大？
• 是否有补偿性控制降低剩余风险敞口？

重大缺陷

严重程度低于重大弱点，但影响重大、需要治理机构关注的缺陷（或一组缺陷）。

典型特征：

• 可能导致超过轻微程度但尚未达到重大程度的错报
• 发生重大错报的可能性高于极小，但低于合理可能
• 涉及关键控制，且补偿措施无法完全抵消该缺口
• 多个单独来看较轻微的缺口，合在一起会引发实质性担忧

重大弱点

导致重大财务报表错报有合理可能无法得到预防或发现的缺陷（或一组缺陷）。

重要迹象：

• 高级管理层存在任何金额的舞弊
• 为更正重大错误而重述先前已提交的财务报表
• 审计师发现了被实体自身控制漏掉的重大错报
• 审计委员会对财务报告流程的监督失效
• 影响多个业务周期的广泛控制（组织层面控制或 IT 一般控制）失效，并造成下游影响

汇总分析

单独来看较轻微的缺口，组合起来可能十分严重：

1. 收集影响同一流程或认定的所有缺陷
2. 评估这些缺陷的综合影响是否可能导致重大错报
3. 考虑补偿性控制的弱点是否会加剧其他缺口
4. 记录汇总分析逻辑及由此得出的严重性分类

整改规程

对于每个已识别的缺口：

1. 根因诊断： 确定控制失效的原因（设计缺陷、执行疏漏、资源限制、培训缺口、系统限制）
2. 纠正行动计划： 明确恢复有效性的具体步骤（重新设计、增加人员、加强培训、更改系统配置、增加复核环节）
3. 目标完成日期： 设定切实可行且明确的截止日期
4. 责任负责人： 指定负责执行的具名人员
5. 验证程序： 说明整改后的控制将于何时以及如何重新测试，以确认其运行有效

控制分类体系

IT 通用控制（ITGC）

基础设施层面的控制，确保应用程序控制和自动化流程可靠运行。

逻辑访问治理：

• 新用户开通访问权限前，必须取得有记录的事前批准
• 离职用户的账户须在规定的 SLA 内停用
• 严格限制特权／管理员访问权限，并加强监控
• 定期重新认证审查，以验证访问权限仍然适当
• 密码标准规定复杂度、轮换周期和锁定阈值
• 通过基于角色的访问设计，系统性地防止职责冲突

变更治理：

• 每项变更请求都必须记录，并在部署前获批
• 变更必须先在非生产环境中验证，之后才能推广
• 开发环境与生产环境在逻辑上或物理上相互隔离
• 紧急变更须遵循规定的快速处理流程，并在实施后获得签核
• 部署后审查确认变更按预期运行

运营连续性：

• 监控自动化作业调度，并在出现异常时发出警报
• 按计划执行备份，并定期测试恢复流程
• 根据既定 SLA 跟踪系统正常运行时间和性能
• 记录并演练事件响应和升级流程
• 维护灾难恢复计划，并按既定间隔进行测试

手动（人工执行）控制

依赖个人判断的控制，通常涉及审查、批准或验证活动。

代表性控制：

• 管理层审查财务结果和运营指标
• 对超过金额阈值的日记账分录进行主管签核
• 对采购订单、收货记录和供应商发票进行三方匹配
• 编制账户调节表并由独立人员进行审查
• 实地观察并盘点库存
• 授权变更供应商或客户主数据
• 批准新建或扩大客户关系的信用额度

测试期间需核实的属性：

• 控制由拥有适当权限的人员执行
• 执行时间在规定期限内
• 存在可观察的审查证据（签名、姓名首字母、系统备注、电子邮件）
• 审查人员能够获取充分的支持信息
• 已识别的异常得到调查并妥善解决

自动化（系统强制执行）控制

嵌入应用程序逻辑、无需人工干预即可执行的控制。

代表性控制：

• 未获得必要批准时阻止流程继续的工作流引擎
• 当采购订单、收货记录和发票不一致时，自动三方匹配机制会阻止付款
• 标记或拒绝重复提交发票的重复项检测算法
• 防止订单录入金额超过已批准阈值的信用额度控制
• 系统计算折旧、摊销、利息和税费
• 防止用户拥有相互冲突权限的基于角色的访问配置
• 字段级验证（必填字段、格式掩码、范围限制）
• 对账模块中的自动交易匹配

测试方法：

• 确认系统配置按规定执行控制（设计测试）
• 对于未发生变更的配置，通常一次成功测试即可覆盖整个期间（运行有效性），前提是变更管理 IT 通用控制也有效
• 如果配置在期间内发生变更，则在变更后重新测试

依赖 IT 的人工控制

依赖系统生成数据的完整性和准确性的人工审查或审批活动。

代表性控制：

• 管理层审查系统生成的异常或离群值报告
• 根据系统生成的账龄分析估算准备金
• 使用系统提取的试算平衡表数据进行账户核对
• 系统生成工作流通知后触发的交易审批

测试方法：

• 测试人工环节（审查质量、异常跟进情况、审批证据）
• 单独验证实体提供的信息（IPE）——确认基础报告或数据提取内容完整且准确
• IPE 测试可确保审查人员的结论基于可靠的输入

组织层面控制

确立基调和运行环境、适用于整个控制框架的广泛治理机制。

代表性控制：

• 高管基调与道德标准（行为准则、领导层传达的信息）
• 企业风险评估流程
• 审计委员会对外部和内部报告的监督
• 内部审计章程、范围和活动
• 欺诈风险评估与反欺诈计划
• 道德热线／举报机制
• 管理层对控制状况的持续监控
• 财务报告能力标准（招聘资格、继续教育）
• 期末报告程序（结账治理、GAAP 合规检查点）

评估中的重要性：

• 组织层面控制可以补充流程层面控制，但通常无法取而代之
• 高层基调或审计委员会监督方面的失效，是重大缺陷的有力信号
• 健全的组织层面控制可能足以支持减少流程层面的抽样量或缩小范围