名称: 审计支持 描述: 支持SOX 404合规性，包括控制测试方法、样本选择和文档标准。适用于生成测试工作底稿、选择审计样本、分类控制缺陷或准备内部或外部审计。
审计支持
重要: 本技能协助SOX合规性工作流程，但不提供审计或法律建议。所有测试工作底稿和评估应由合格的财务专业人员审查。虽然“重要性”和“实质性”是上下文特定的概念，最终由审计师评估，但本技能旨在帮助专业人员创建和评估有效的内部控制和审计文档。
SOX 404控制测试方法、样本选择方法、测试文档标准、控制缺陷分类和常见控制类型。
SOX 404控制测试方法
概述
SOX第404条要求管理层评估财务报告内部控制(ICFR)的有效性。这涉及：
- 范围确定: 识别重要账户和相关断言
- 风险评估: 评估每个重要账户的实质性错报风险
- 控制识别: 记录应对每个风险的控制措施
- 测试: 测试关键控制的设计和运行有效性
- 评估: 评估是否存在任何缺陷及其严重性
- 报告: 记录评估和任何实质性弱点
范围确定重要账户
如果一个账户有超过远程可能性包含实质性错报（单独或汇总），则该账户是重要的。
定量因素:
- 账户余额超过实质性阈值（通常为关键基准的3-5%）
- 交易量高，增加错误风险
- 账户涉及重大估计或判断
定性因素:
- 账户涉及复杂会计（收入确认、衍生品、养老金）
- 账户容易受到欺诈（现金、收入、关联方交易）
- 账户先前有错报或审计调整
- 账户涉及重大管理层判断或估计
- 新账户或显著变化的流程
按账户类型的相关断言
| 账户类型 | 关键断言 |
|---|---|
| 收入 | 发生、完整性、准确性、截止 |
| 应收账款 | 存在性、估值（坏账准备）、权利 |
| 存货 | 存在性、估值、完整性 |
| 固定资产 | 存在性、估值、完整性、权利 |
| 应付账款 | 完整性、准确性、存在性 |
| 应计负债 | 完整性、估值、准确性 |
| 权益 | 完整性、准确性、列报 |
| 财务结账/报告 | 列报、准确性、完整性 |
设计有效性与运行有效性
设计有效性: 控制是否设计得当，以防止或检测相关断言中的实质性错报？
- 通过走查评估（追踪交易端到端通过流程）
- 确认控制放置在流程的正确点
- 确认控制应对识别的风险
- 至少每年执行，或当流程变化时
运行有效性: 控制是否在整个测试期间按设计实际运行？
- 通过测试评估（检查、观察、重新执行、询问）
- 需要足够的样本大小以支持结论
- 必须覆盖依赖的整个期间
样本选择方法
随机选择
何时使用: 默认方法，适用于具有大总体的交易级控制。
方法:
- 定义总体（期间内受控制的所有交易）
- 为总体中的每个项目顺序编号
- 使用随机数生成器选择样本项目
- 确保选择无偏（所有项目有相等概率）
优点: 统计有效、可辩护、无选择偏倚 缺点: 可能错过高风险项目、需要完整总体列表
目标（判断）选择
何时使用: 随机选择的补充，用于基于风险的测试；当总体小或高度变化时的主要方法。
方法:
- 识别具有特定风险特征的项目：
- 高金额（超过定义的阈值）
- 异常或非标准交易
- 期末交易（截止风险）
- 关联方交易
- 手动或覆盖交易
- 新供应商/客户交易
- 选择匹配风险标准的项目
- 记录每个目标选择的理由
优点: 专注于最高风险项目、有效利用测试努力 缺点: 不具有统计代表性、可能过度代表某些风险
随意选择
何时使用: 当随机选择不切实际（无顺序总体列表）且总体相对同质时。
方法:
- 选择项目，无特定模式或偏倚
- 确保选择分布在总体整个期间
- 避免无意识偏倚（不要总是选择顶部项目、整数等）
优点: 简单、无需技术 缺点: 不具有统计有效性、易受无意识偏倚影响
系统选择
何时使用: 当总体顺序且希望在整个期间均匀覆盖时。
方法:
- 计算抽样间隔：总体大小 / 样本大小
- 在第一个间隔内选择一个随机起点
- 从起点开始选择每第N个项目
示例: 总体1,000，样本25 → 间隔40。随机起点：项目17。选择项目17、57、97、137等。
优点: 均匀覆盖总体、易于执行 缺点: 总体中的周期模式可能偏倚结果
样本大小指南
| 控制频率 | 预期总体 | 低风险样本 | 中等风险样本 | 高风险样本 |
|---|---|---|---|---|
| 年度 | 1 | 1 | 1 | 1 |
| 季度 | 4 | 2 | 2 | 3 |
| 月度 | 12 | 2 | 3 | 4 |
| 周度 | 52 | 5 | 8 | 15 |
| 日度 | ~250 | 20 | 30 | 40 |
| 每交易（小总体） | < 250 | 20 | 30 | 40 |
| 每交易（大总体） | 250+ | 25 | 40 | 60 |
增加样本大小的因素:
- 账户/流程的固有风险较高
- 控制是应对重大风险的唯一控制（无冗余）
- 先前期间识别出控制缺陷
- 新控制（先前期间未测试）
- 外部审计师依赖管理层测试
测试文档标准
工作底稿要求
每个控制测试应记录：
-
控制识别:
- 控制编号/ID
- 控制描述（做什么、由谁做、频率）
- 控制类型（手动、自动化、IT依赖手动）
- 控制频率
- 应对的风险和断言
-
测试设计:
- 测试目标（试图确定什么）
- 测试程序（逐步说明）
- 预期证据（如果控制有效，期望看到什么）
- 样本选择方法和理由
-
测试执行:
- 总体描述和大小
- 样本选择详情（方法、选择的项目）
- 每个样本项目的结果（通过/失败，检查的具体证据）
- 记录的异常，带完整描述
-
结论:
- 总体评估（有效 / 缺陷 / 重大缺陷 / 实质性弱点）
- 结论基础
- 任何异常的影响评估
- 考虑的补偿控制（如果适用）
-
签署:
- 测试者姓名和日期
- 审查者姓名和日期
证据标准
充分证据包括:
- 显示系统强制控制的截图
- 签名/初始的批准文件
- 可识别批准者和日期的电子邮件批准
- 显示谁执行了操作和时间的系统审计日志
- 重新执行的计算，匹配结果
- 观察笔记（带日期、位置、观察者）
不充分证据:
- 仅口头确认（必须佐证）
- 未注明日期的文件
- 没有可识别执行者/批准者的证据
- 无日期/时间戳的通用系统报告
- “与[姓名]讨论”无佐证文档
工作底稿组织
按控制区域组织测试文件：
SOX测试/
├── [年份]/
│ ├── 范围确定和风险评估/
│ ├── 收入周期/
│ │ ├── 控制矩阵
│ │ ├── 走查文档
│ │ ├── 测试工作底稿（每个控制一个）
│ │ └── 支持证据
│ ├── 采购到支付/
│ ├── 薪资/
│ ├── 财务结账/
│ ├── 资金/
│ ├── 固定资产/
│ ├── IT一般控制/
│ ├── 实体层控制/
│ └── 总结和结论/
│ ├── 缺陷评估
│ └── 管理层评估
控制缺陷分类
缺陷
当控制的设计或运行不允许管理层或员工在正常执行分配职能时及时预防或检测错报时，存在内部控制缺陷。
评估因素:
- 控制失败导致错报的可能性是什么？
- 潜在错报的幅度是什么？
- 是否有补偿控制缓解缺陷？
重大缺陷
一个缺陷或缺陷组合，虽不如实质性弱点严重，但足以引起治理层注意。
指标:
- 缺陷可能导致超过微不足道但小于实质性的错报
- 有超过远程（但小于合理可能）可能性的实质性错报
- 控制是关键控制且缺陷未完全被补偿控制缓解
- 个别小缺陷组合代表重大关注
实质性弱点
一个缺陷或缺陷组合，使得财务报告的实质性错报有合理可能性不会被及时预防或检测。
指标:
- 高级管理层识别欺诈（任何幅度）
- 重新发布先前财务报表以纠正实质性错误
- 审计师识别出公司控制未能检测到的实质性错报
- 审计委员会对财务报告的监督无效
- 普遍控制（实体层、IT一般控制）中的缺陷影响多个流程
缺陷聚合
个别不重大的缺陷可能组合起来重大：
- 识别同一流程或影响同一断言的所有缺陷
- 评估组合效果是否可能导致实质性错报
- 考虑补偿控制中的缺陷是否加剧其他缺陷
- 记录聚合分析和结论
补救
对于每个识别出的缺陷：
- 根本原因分析: 控制为何失败？（设计差距、执行失败、人员配备、培训、系统问题）
- 补救计划: 修复控制的具体行动（重新设计、额外培训、系统增强、添加审查）
- 时间表: 补救完成的目标日期
- 负责人: 负责实施补救的人员
- 验证: 如何和何时重新测试补救后的控制以确认有效性
常见控制类型
IT一般控制 (ITGCs)
控制IT环境，支持应用控制和自动化流程的可靠运行。
访问控制:
- 用户访问配置（新访问请求需要批准）
- 用户访问取消（及时移除终止用户）
- 特权访问管理（限制和监控管理员/超级用户访问）
- 定期访问审查（按定义计划重新认证用户访问）
- 密码策略（复杂性、轮换、锁定）
- 职责分离执行（防止冲突访问）
变更管理:
- 变更请求在实施前文档化和批准
- 变更在非生产环境测试后推广
- 开发和生产环境分离
- 紧急变更程序（文档化、实施后批准）
- 变更审查和实施后验证
IT操作:
- 批处理作业监控和异常处理
- 备份和恢复程序（定期备份、测试恢复）
- 系统可用性和性能监控
- 事件管理和升级程序
- 灾难恢复计划和测试
手动控制
由人使用判断执行的控制，通常涉及审查和批准。
示例:
- 管理层审查财务报表和关键指标
- 主管批准超过阈值的日记账分录
- 三方匹配验证（采购订单、收货、发票）
- 账户对账准备和审查
- 实物存货观察和盘点
- 供应商主数据变更批准
- 客户信用批准
测试的关键属性:
- 控制是否由正确的人执行（适当权限）？
- 是否及时执行（在要求的时限内）？
- 是否有审查证据（签名、初始、电子邮件、系统日志）？
- 审查者是否有足够信息进行有效审查？
- 异常是否识别并适当处理？
自动化控制
由IT系统强制执行的控制，无需人工干预。
示例:
- 系统强制的工作流批准（无所需批准无法进行）
- 三方匹配自动化（系统阻止支付如果PO/收货/发票不匹配）
- 重复支付检测（系统标记或阻止重复发票）
- 信用限额执行（系统阻止超过信用限额的订单）
- 自动化计算（折旧、摊销、利息、税）
- 系统强制的职责分离（防止冲突角色）
- 输入验证控制（必填字段、格式检查、范围检查）
- 自动化对账匹配
测试方法:
- 测试设计：确认系统配置按意图强制执行控制
- 测试运行有效性：对于自动化控制，如果系统配置未更改，通常一个测试足以覆盖期间（辅以变更管理的ITGC测试）
- 验证变更管理ITGC有效（如果系统更改，重新测试控制）
IT依赖手动控制
依赖系统生成信息的完整性和准确性的手动控制。
示例:
- 管理层审查系统生成的异常报告
- 主管审查系统生成的账龄报告以评估准备金
- 使用系统生成的试算平衡数据进行对账
- 批准由系统生成的工作流识别的交易
测试方法:
- 测试手动控制（审查、批准、跟进异常）
- AND 测试底层报告/数据的完整性和准确性（IPE — 实体生成的信息）
- IPE测试确认审查者依赖的数据完整和准确
实体层控制
在组织层面运作并影响多个流程的广泛控制。
示例:
- 高层基调 / 行为准则
- 风险评估过程
- 审计委员会对财务报告的监督
- 内部审计职能和活动
- 欺诈风险评估和反欺诈计划
- 举报人/道德热线
- 管理层监控控制有效性
- 财务报告能力（人员配备、培训、资格）
- 期末财务报告过程（结账程序、GAAP合规审查）
重要性:
- 实体层控制可以缓解但通常不能替代流程层控制
- 无效的实体层控制（尤其是审计委员会监督和高层基调）是实质性弱点的强指标
- 有效的实体层控制可能减少流程层控制所需的测试范围