---
name: sox-control-design
description: >
  SOX 控制设计 — 为财务报告相关的关键业务流程设计和记录内部控制，
  建立控制点、控制活动和控制证据要求。
  适用情形：SOX 合规项目启动时，或业务流程变更后重新设计控制时执行。
  核心：识别风险 → 确定控制点 → 设计控制活动 → 定义证据要求。
argument-hint: "[业务流程名称] [控制范围：收入/采购/库存/固定资产/薪酬/财务报告] [SOX适用性：是/否]"
last_reviewed: 2026-06
version: 1.0.0
risk_level: high
---

## 加载上下文

**首次使用时：** 读取 `../../CLAUDE.md` 获取场景级配置（SOX 控制框架/风险容忍度/证据标准）。

---

# /sox-control-design — SOX 控制设计


## Examples

→ 示例：用户说"新收入准则后，我们担心收入确认的内控有漏洞，需要重新审视"，系统应调用本技能，识别风险点并设计新的控制。

→ 示例：用户说"IT 一般性控制之前没怎么管，SOX 外审提了意见，帮我设计一套"，系统应调用本技能，按 ITGC 框架设计控制。

→ 示例：用户说"准备 IPO 前需要建立完整的内控体系，从哪里开始"，系统应调用本技能，按 IPO 内控要求设计完整控制框架。
## 第一步：流程梳理与风险识别

**流程描述：**
```
□ 业务流程：[名称]
□ 涉及部门：[部门列表]
□ 流程起始：[触发事件]
□ 流程终点：[输出结果]
□ IT 系统支撑：[系统列表]
```

**风险识别（梳理可能导致财务报告错报的环节）：**
```
□ 风险类型：
  → 完整性风险：应记录未记录（如收入未开票）
  → 准确性风险：记录金额错误（如价格输入错误）
  → 存在性风险：资产/负债不存在（如虚假采购）
  → 截止风险：记录期间错误（如跨期确认收入）
  → 分类风险：科目分类错误（如费用误归类）
  → 权利义务风险：交易无商业实质

□ 已识别风险：
| # | 风险描述 | 风险类型 | 影响科目 | 风险等级 |
|---|---------|---------|---------|---------|
| 1 | [描述] | [类型] | [科目] | [高/中/低] |
| 2 | [描述] | [类型] | [科目] | [高/中/低] |

□ 重大缺陷风险（如有）：
  → 风险 [描述] — 是否为重大缺陷：[是/否]
```

---

## 第二步：控制点设计

**预防性控制 vs 检查性控制：**
```
□ 预防性控制（在错报发生前阻止）：
  → 职责分离（SOD）：如审批与执行分离
  → 访问控制：系统权限限制
  → 审批控制：多级审批流程
  → 验证核对：系统自动校验

□ 检查性控制（在错报发生后发现）：
  → 对账：银行对账、账龄分析
  → 复核：管理层复核
  → 调节：科目调节
  → 盘点：实物盘点
```

**控制点设计（为每个已识别风险设计控制）：**
```
| # | 对应风险 | 控制类型 | 控制描述 | 控制频率 | 责任人 |
|---|---------|---------|---------|---------|--------|
| 1 | [风险1] | [预防/检查] | [描述] | [实时/每日/月] | [岗位] |
| 2 | [风险2] | [预防/检查] | [描述] | [实时/每日/月] | [岗位] |
```

---

## 第三步：控制活动详细设计

**控制活动规格：**
```
□ 控制编号：[流程]-[序号]
□ 控制名称：[描述]
□ 控制类型：[预防性/检查性]
□ 控制频率：[实时/每日/每周/每月/每季度/每年]

□ 控制执行步骤：
  1. [执行动作]
  2. [执行动作]
  3. [执行动作]

□ 自动化 vs 人工：
  → [人工控制/系统自动控制/混合]
  → 自动化控制依赖IT一般控制：[是/否]

□ 依赖的前置控制：
  → 控制 [编号] — [控制名称]
```

---

## 第四步：证据要求定义

**控制证据清单：**
```
□ 证据类型：
  → 纸质文档：[描述]
  → 电子记录：[系统名 + 查询路径]
  → 系统截图：[字段/报告名称]
  → 审批记录：[系统名/邮件/纸质]

□ 证据完整性要求：
  → 证据须包含：[日期/金额/执行人/复核人] 等字段
  → 异常情况处理：[描述，如签字/备注]

□ 证据保存要求：
  → 保存期限：[X] 年
  → 保存位置：[系统/档案室]
  → 格式要求：[纸质/电子/两者都要]
```

**证据与控制的映射：**
```
| 控制编号 | 控制名称 | 证据类型 | 保存位置 | 保存期限 |
|---------|---------|---------|---------|---------|
| [C-01] | [名称] | [类型] | [位置] | [X]年 |
```

---

## 第五步：生成控制设计文档

```
═══════════════════════════════════════
SOX 控制设计文档
流程：[业务流程名称]
设计日期：[YYYY-MM-DD]
设计师：[姓名]
═══════════════════════════════════════

【流程概览】
□ 流程名称：[名称]
□ 涉及系统：[系统列表]
□ 控制数量：[X] 个（预防性 [X] / 检查性 [X]）

【风险-控制映射】

| 风险 | 风险等级 | 控制编号 | 控制名称 | 控制类型 |
|------|---------|---------|---------|---------|
| [风险1] | [高] | [C-01] | [名称] | [预防] |
| [风险2] | [中] | [C-02] | [名称] | [检查] |

【控制明细】

控制编号：[C-01]
控制名称：[名称]
控制类型：[预防性] | 控制频率：[每日]

控制步骤：
1. [步骤1]
2. [步骤2]

证据要求：
□ 类型：[纸质/电子]
□ 包含字段：[列表]
□ 保存期限：[X] 年

IT一般控制依赖：[✅ 是/否]

【职责分离矩阵】
□ 不相容职责：[审批] vs [执行] — 责任人 [A] vs [B]
□ SOD 合规检查：[✅ 通过 / ⚠️ 需关注]

═══════════════════════════════════════
置信度：[✅ 高 / ⚠️ 中 / 🔴 低]
设计状态：[✅ 可执行 / ⏳ 待IT确认 / 🔴 存重大缺陷]
═══════════════════════════════════════
```

---

## 升级触发条件

- 存在无法设计有效控制的重大风险点
- 风险等级为"高"但只能设计检查性控制而非预防性控制
- 职责分离（SOD）冲突无法解决
- 控制依赖 IT 一般控制，但 ITGC 尚未通过审计
- 控制设计涉及新系统上线，与现有流程不兼容
- 管理层对控制设计存在实质性异议

---

*Finance Skills — sox-control-design atomic skill*