审计支持

重要提示：本技能协助 SOX 合规工作流，但不提供审计或法律建议。所有测试工作底稿和评估应由合格的财务专业人士审核。虽然"重要性"和"重大性"是由审计师最终评估的、取决于具体情境的概念，但本技能旨在协助专业人员创建和评估有效的内部控制及审计文档。

SOX 404 控制测试方法论、样本选择方法、测试文档标准、控制缺陷分类及常见控制类型。

SOX 404 控制测试方法论

概述

SOX 第 404 条要求管理层评估财务报告内部控制（ICFR）的有效性。这包括：

1. 范围界定： 识别重要账户及相关认定
2. 风险评估： 评估每个重要账户出现重大错报的风险
3. 控制识别： 记录应对每项风险的控制措施
4. 测试： 测试关键控制的设计和运行有效性
5. 评估： 判断是否存在缺陷及其严重程度
6. 报告： 记录评估结果及任何重大缺陷

重要账户的范围界定

如果一个账户存在超过极小的可能性包含重大错报（单独或合计），则该账户是重要的。

定量因素：

• 账户余额超过重要性阈值（通常为关键基准的 3%-5%）
• 交易量高，增加出错风险
• 账户涉及重大估计或判断

定性因素：

• 账户涉及复杂会计处理（收入确认、衍生工具、养老金）
• 账户易受舞弊影响（现金、收入、关联方交易）
• 账户以往存在错报或审计调整
• 账户涉及重大管理层判断或估计
• 新账户或流程发生重大变化

按账户类型划分的相关认定

设计有效性 vs 运行有效性

设计有效性： 控制措施是否经过恰当设计，能够防止或发现相关认定中的重大错报？

• 通过穿行测试评估（端到端追踪一笔交易通过整个流程）
• 确认控制措施设置在流程中的正确节点
• 确认控制措施应对了已识别的风险
• 至少每年执行一次，或在流程发生变化时执行

运行有效性： 控制措施在整个测试期间是否按设计实际运行？

• 通过测试评估（检查、观察、重新执行、询问）
• 需要足够的样本量来支持结论
• 必须覆盖整个信赖期间

样本选择方法

随机选择

适用场景： 适用于交易层面控制且总体较大的默认方法。

方法：

1. 定义总体（测试期间内受该控制约束的所有交易）
2. 对总体中的每个项目按顺序编号
3. 使用随机数生成器选择样本项目
4. 确保选择无偏差（所有项目被选中的概率相等）

优点： 统计有效、可辩护、无选择偏差 缺点： 可能遗漏高风险项目，需要完整的总体清单

针对性（判断性）选择

适用场景： 作为基于风险的测试中随机选择的补充；当总体较小或高度多样化时作为主要方法。

方法：

1. 识别具有特定风险特征的项目：
   • 高金额（超过设定阈值）
   • 异常或非标准交易
   • 期末交易（截止风险）
   • 关联方交易
   • 人工或覆盖操作交易
   • 新供应商/客户交易
2. 选择符合风险标准的项目
3. 记录每个针对性选择的原因

优点： 聚焦最高风险项目，测试工作使用效率高 缺点： 统计上不具代表性，可能过度代表某些风险

任意选择

适用场景： 当随机选择不可行（无顺序总体清单）且总体相对同质时。

方法：

1. 不按特定模式或偏差选择项目
2. 确保选择覆盖整个总体期间
3. 避免无意识偏差（不要总是选择顶部、整数等项目）

优点： 简单，无需技术工具 缺点： 统计上无效，易受无意识偏差影响

系统选择

适用场景： 当总体是按顺序排列且希望在整个期间均匀覆盖时。

方法：

1. 计算抽样间隔：总体大小 / 样本大小
2. 在第一个间隔内选择随机起点
3. 从起点开始每隔 N 个项目选择一个

示例： 总体 1,000，样本 25 → 间隔为 40。随机起点：第 17 项。选择项目 17、57、97、137……

优点： 总体覆盖均匀，执行简单 缺点： 总体中的周期模式可能导致结果偏差

样本量参考

增加样本量的因素：

• 账户/流程的固有风险较高
• 该控制是应对重大风险的唯一控制措施（无冗余）
• 以往期间识别出控制缺陷
• 新控制（以前期间未测试过）
• 外部审计师依赖管理层测试

测试文档标准

工作底稿要求

每项控制测试应记录以下内容：

1. 控制识别：

   • 控制编号/ID
   • 控制描述（做什么、由谁做、多久做一次）
   • 控制类型（人工、自动化、依赖 IT 的人工控制）
   • 控制频率
   • 所应对的风险和认定

2. 测试设计：

   • 测试目标（试图确定什么）
   • 测试程序（逐步指导说明）
   • 预期证据（如果控制有效，期望看到什么）
   • 样本选择方法和理由

3. 测试执行：

   • 总体描述和规模
   • 样本选择详情（方法、所选项目）
   • 每个样本项目的结果（通过/未通过，附带检查的具体证据）
   • 发现的例外情况及其完整描述

4. 结论：

   • 总体评估（有效 / 缺陷 / 重大缺陷 / 实质性缺陷）
   • 结论依据
   • 任何例外情况的影响评估
   • 考虑到的补偿性控制（如适用）

5. 签字确认：

   • 测试人员姓名和日期
   • 审核人员姓名和日期

证据标准

充分证据包括：

• 显示系统强制控制的截图
• 已签署/签字的审批文件
• 带有可识别审批人和日期的电子邮件审批
• 显示操作人员和操作时间的系统审计日志
• 重新执行计算且结果一致
• 观察记录（含日期、地点、观察人）

不充分证据：

• 仅口头确认（必须有佐证）
• 未注明日期的文件
• 无法识别执行人/审批人的证据
• 不含日期/时间戳的通用系统报告
• "经与[姓名]讨论"而无佐证文件

工作底稿组织

按控制领域组织测试文件：

SOX 测试/
├── [年份]/
│   ├── 范围界定与风险评估/
│   ├── 收入循环/
│   │   ├── 控制矩阵
│   │   ├── 穿行测试文档
│   │   ├── 测试工作底稿（每个控制一份）
│   │   └── 支持性证据
│   ├── 采购到付款/
│   ├── 薪资/
│   ├── 财务结账/
│   ├── 资金/
│   ├── 固定资产/
│   ├── IT 一般控制/
│   ├── 实体层面控制/
│   └── 总结与结论/
│       ├── 缺陷评估
│       └── 管理层评估

控制缺陷分类

缺陷

当控制的设计或运行未能使管理层或员工在正常履行指定职能的过程中及时防止或发现错报时，即存在内部控制缺陷。

评估因素：

• 控制失败导致错报的可能性有多大？
• 潜在错报的程度有多大？
• 是否存在可减轻缺陷的补偿性控制？

重大缺陷

一种缺陷或缺陷组合，其严重程度低于实质性缺陷，但重要到足以引起治理层的关注。

指示信号：

• 该缺陷可能导致超过无关紧要但低于重大的错报
• 存在超过极小但低于合理可能的重大错报可能性
• 该控制是关键控制，且缺陷未被补偿性控制完全缓解
• 个别不重大的缺陷组合在一起构成重大关切

实质性缺陷

一种缺陷或缺陷组合，存在合理可能性导致财务报表的重大错报无法被及时防止或发现。

指示信号：

• 发现高级管理层舞弊（任何程度）
• 重述此前发布的财务报表以纠正重大错误
• 审计师发现公司控制未能发现的重大错报
• 审计委员会对财务报告的监督无效
• 影响多个流程的普遍性控制（实体层面、IT 一般控制）存在缺陷

缺陷汇总

单独不重大的缺陷组合在一起可能变得重大：

1. 识别同一流程中或影响同一认定的所有缺陷
2. 评估合并影响是否可能导致重大错报
3. 考虑补偿性控制中的缺陷是否加剧了其他缺陷
4. 记录汇总分析和结论

整改

针对每个已识别的缺陷：

1. 根本原因分析： 控制为何失败？（设计缺陷、执行失误、人员问题、培训不足、系统问题）
2. 整改计划： 修复控制的具体措施（重新设计、额外培训、系统增强、增加审核环节）
3. 时间表： 整改完成的目标日期
4. 负责人： 负责实施整改的人员
5. 验证： 如何以及何时重新测试整改后的控制以确认有效性

常见控制类型

IT 一般控制（ITGC）

对 IT 环境的控制，支持应用程序控制和自动化流程的可靠运行。

访问控制：

• 用户访问权限开通（新访问请求需要审批）
• 用户访问权限撤销（及时移除离职用户）
• 特权访问管理（管理员/超级用户访问受限并接受监控）
• 定期访问审查（按既定时间表重新认证用户访问）
• 密码策略（复杂度、轮换、锁定）
• 职责分离强制（防止冲突访问权限）

变更管理：

• 变更请求在实施前经记录和审批
• 变更在上线前在非生产环境中经过测试
• 开发环境与生产环境分离
• 紧急变更程序（经记录，实施后补审批）
• 变更审查和上线后验证

IT 运营：

• 批处理作业监控和异常处理
• 备份和恢复程序（定期备份，测试恢复）
• 系统可用性和性能监控
• 事件管理和升级程序
• 灾难恢复计划和测试

人工控制

由人员运用判断执行的控制，通常涉及审核和批准。

示例：

• 管理层审核财务报表和关键指标
• 主管审批超过阈值的日记账分录
• 三单匹配验证（采购订单、收货单、发票）
• 账户对账的编制和审核
• 实地存货盘点和计数
• 供应商主数据变更审批
• 客户信用审批

测试的关键属性：

• 控制是否由合适的人员执行（适当授权）？
• 是否及时执行（在规定时限内）？
• 是否有审核证据（签名、缩写签名、电子邮件、系统日志）？
• 审核人员是否有足够信息进行有效审核？
• 是否识别出例外情况并得到适当处理？

自动化控制

由 IT 系统强制执行、无需人工干预的控制。

示例：

• 系统强制审批工作流（未经必要审批无法继续）
• 三单匹配自动化（如采购订单/收货单/发票不匹配，系统阻止付款）
• 重复付款检测（系统标记或阻止重复发票）
• 信用额度强制（系统阻止超出信用额度的订单）
• 自动计算（折旧、摊销、利息、税款）
• 系统强制职责分离（防止冲突角色）
• 输入验证控制（必填字段、格式检查、范围检查）
• 自动对账匹配

测试方法：

• 测试设计：确认系统配置按预期强制实施控制
• 测试运行有效性：对于自动化控制，如果系统配置未发生变化，通常一次控制测试即可覆盖整个期间（辅以变更管理的 ITGC 测试）
• 验证变更管理 ITGC 有效（如系统发生变化，重新测试该控制）

依赖 IT 的人工控制

依赖系统生成信息的完整性和准确性的人工控制。

示例：

• 管理层审核系统生成的异常报告
• 主管审核系统生成的账龄报告以评估准备
• 使用系统生成的试算平衡表数据进行对账
• 审批由系统生成工作流识别的交易

测试方法：

• 测试人工控制（审核、审批、对例外情况的跟进）
• 并且测试底层报告/数据的完整性和准确性（IPE — 实体生成的信息）
• IPE 测试确认审核人员所依赖的数据是完整和准确的

实体层面控制

在组织层面运作并影响多个流程的广泛控制。

示例：

• 高层基调 / 行为准则
• 风险评估流程
• 审计委员会对财务报告的监督
• 内部审计职能和活动
• 舞弊风险评估和反舞弊计划
• 举报人/道德热线
• 管理层对控制有效性的监控
• 财务报告能力（人员配置、培训、资质）
• 期末财务报告流程（结账程序、GAAP 合规审核）

重要性：

• 实体层面控制可以减轻但不能替代流程层面控制
• 无效的实体层面控制（尤其是审计委员会监督和高层基调）是实质性缺陷的强信号
• 有效的实体层面控制可能减少流程层面控制所需的测试范围