audit-support

审计支持

重要提示：本技能用于协助 SOX 合规工作流，不提供审计或法律意见。所有测试工作底稿和评估均应由合格的财务专业人员审阅。虽然"重要性"和"实质性"是依赖具体情境的概念，最终由审计师评估，但本技能旨在协助专业人员设计、评估有效的内部控制并编制审计文档。

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

SOX 404 控制测试方法论

概述

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

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

确定重要账户

如果某账户可能包含单独或汇总后构成重大错报的可能性不是微乎其微，则该账户为重要账户。

定量因素：

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

定性因素：

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

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

账户类型	关键认定
收入	发生、完整性、准确性、截止
应收账款	存在、计价（坏账准备）、权利
存货	存在、计价、完整性
固定资产	存在、计价、完整性、权利
应付账款	完整性、准确性、存在
应计负债	完整性、计价、准确性
权益	完整性、准确性、列报
财务结账/报告	列报、准确性、完整性

设计有效性与运行有效性

**设计有效性：**该控制是否设计得当，能够防止或发现相关认定中的重大错报？

• 通过穿行测试评估（从头到尾追踪一笔交易的完整流程）
• 确认控制设置在流程中的正确位置
• 确认控制能够应对已识别的风险
• 至少每年执行一次，或在流程发生变化时执行

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

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

样本选取方法

随机选取

**适用情形：**大总体下交易层面控制的默认方法。

方法：

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

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

定向(判断式)抽样

适用场景: 作为基于风险测试的随机抽样补充;当总体规模较小或差异很大时,为主要方法。

方法:

1. 识别具有特定风险特征的项目:
   • 金额较高(超过既定阈值)
   • 异常或非标准交易
   • 期末交易(截止风险)
   • 关联方交易
   • 人工或覆盖性交易
   • 新供应商/新客户交易
2. 选取符合风险标准的项目
3. 记录每个定向抽样项目的选取理由

优点: 聚焦最高风险项目,测试工作量利用效率高 缺点: 不具有统计代表性,可能过度体现某些风险

任意抽样

适用场景: 随机抽样不可行(没有按顺序排列的总体清单)且总体相对同质时。

方法:

1. 在没有任何特定模式或偏向的情况下选取项目
2. 确保抽样分布于整个总体期间
3. 避免无意识偏差(不要总是选取靠前的项目、整数金额项目等)

优点: 简单,无需技术工具 缺点: 不具有统计有效性,容易受无意识偏差影响

系统抽样

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

方法:

1. 计算抽样间隔:总体规模 / 样本规模
2. 在第一个间隔内随机选取起始点
3. 从起始点开始每隔 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

增加样本规模的因素:

• 账户或流程的固有风险较高
• 该控制是应对重大风险的唯一控制(无冗余)
• 上一期间发现过控制缺陷
• 新控制(以前期间未测试过)
• 外部审计师依赖管理层测试

测试底稿标准

底稿要求

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

1. 控制识别:

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

2. 测试设计:

   • 测试目标(要确定的事项)
   • 测试程序(逐步说明)
   • 预期证据(若控制有效,应看到什么)
   • 样本选取方法及理由

3. 测试执行:

   • 总体描述及规模
   • 样本选取详情(方法、所选项目)
   • 每个样本项目的结果(通过/不通过,并注明所检查的具体证据)
   • 记录的例外事项及完整说明

4. 结论:

   • 总体评估(有效 / 缺陷 / 重大缺陷 / 重大缺陷)
   • 结论依据
   • 对任何例外事项的影响评估
   • 已考虑的补偿性控制(如适用)

5. 签字确认:

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

证据标准

充分的证据包括：

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

不充分的证据：

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

工作底稿组织

按控制领域组织测试档案：

SOX Testing/
├── [Year]/
│   ├── Scoping and Risk Assessment/
│   ├── Revenue Cycle/
│   │   ├── Control Matrix
│   │   ├── Walkthrough Documentation
│   │   ├── Test Workpapers (one per control)
│   │   └── Supporting Evidence
│   ├── Procure to Pay/
│   ├── Payroll/
│   ├── Financial Close/
│   ├── Treasury/
│   ├── Fixed Assets/
│   ├── IT General Controls/
│   ├── Entity Level Controls/
│   └── Summary and Conclusions/
│       ├── Deficiency Evaluation
│       └── Management Assessment

控制缺陷分类

缺陷

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

评估因素：

• 控制失效导致错报的可能性有多大？
• 潜在错报的金额有多大？
• 是否存在可以减轻该缺陷的补偿性控制？

重大缺陷（Significant Deficiency）

一项缺陷，或多项缺陷的组合，其严重程度低于重大缺陷（Material Weakness），但足以引起治理层关注。

指标：

• 该缺陷可能导致的错报超过不重要的程度，但低于重大水平
• 发生重大错报的可能性高于极小（但低于合理可能）
• 该控制为关键控制，且缺陷未被补偿性控制充分缓解
• 单独看较轻微的缺陷组合在一起构成重要问题

重大缺陷（Material Weakness）

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

指标：

• 高级管理层存在舞弊行为（无论金额大小）
• 为更正重大错误而重述以前发布的财务报表
• 审计师发现了公司控制未能察觉的重大错报
• 审计委员会对财务报告的监督无效
• 普遍性控制（实体层面、IT 通用控制）缺陷影响多个流程

缺陷汇总

单独看不构成重大缺陷的各项缺陷，合并起来可能构成重大缺陷：

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

整改

对于每项已识别的缺陷：

1. **根本原因分析：**控制为何失效？（设计缺口、执行失误、人员配置、培训、系统问题）
2. **整改计划：**修复控制的具体措施（重新设计、补充培训、系统增强、增加复核）
3. **时间表：**整改完成的目标日期
4. **责任人：**负责落实整改的人员
5. **验证：**如何以及何时对整改后的控制重新测试，以确认其有效性

常见控制类型

IT 通用控制（ITGC）

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

访问控制：

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

变更管理：

• 变更请求在实施前записано并获得批准
• 变更在非生产环境中测试后再推广
• 开发环境与生产环境分离
• 紧急变更程序（有文档记录，事后获得批准）
• 变更审查与上线后验证

IT 运维：

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

人工控制

由人员凭借判断执行的控制，通常涉及复核与审批。

示例：

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

需要测试的关键属性：

• 控制是否由合适的人员执行（具备适当权限）？
• 是否及时执行（在规定时限内）？
• 是否有复核的证据（签名、签名缩写、电子邮件、系统日志）？
• 复核人员是否掌握足够信息以进行有效复核？
• 例外情况是否已被识别并妥善处理？

自动化控制

由 IT 系统在无人工干预的情况下执行的控制。

示例：

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

测试方法：

• 设计测试：确认系统配置按预期执行该控制
• 运行有效性测试：对于自动化控制，若系统配置未发生变化，通常对该期间进行一次控制测试即已足够（并辅以变更管理 ITGC 测试）
• 验证变更管理 ITGC 有效（若系统发生变更，则需重新测试该控制）

依赖 IT 的人工控制

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

示例：

• 管理层对系统生成的例外报告进行复核
• 主管对系统生成的账龄报告进行复核，以评估准备金
• 使用系统生成的试算平衡表数据进行调节
• 对系统生成的工作流所识别交易的审批

测试方法：

• 测试人工控制（复核、审批、对例外情况的跟进）
• 同时测试底层报告/数据的完整性和准确性（IPE，即由被审计单位生成的信息）
• IPE 测试用于确认复核人员所依赖的数据是完整且准确的

实体层面控制

在组织层面运行、影响多个流程的广泛性控制。

示例：

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

重要意义：

• 实体层面控制可以起到缓解作用，但通常无法替代流程层面控制
• 无效的实体层面控制（尤其是审计委员会监督和高层基调）是重大缺陷的有力指标
• 有效的实体层面控制可能减少对流程层面控制所需的测试范围