---
name: control-deficiency
description: >
  控制缺陷评估 — 对发现的内部控制缺陷进行评估，确定缺陷等级（重大/重要/一般），
  分析根本原因，并制定整改计划。
  适用情形：控制测试发现偏差、审计检查发现问题或业务流程出现重大事故时执行。
  核心：缺陷等级评估 + 财务影响量化 + 整改计划制定。
argument-hint: "[控制编号] [缺陷发现来源：SOX测试/内部审计/事故] [缺陷描述] [发现日期]"
last_reviewed: 2026-06
version: 1.0.0
risk_level: high
---

## 加载上下文

**首次使用时：** 读取 `../../CLAUDE.md` 获取场景级配置（缺陷评级标准/财务影响阈值/整改期限要求）。

---

# /control-deficiency — 控制缺陷评估


## Examples

→ 示例：用户说"审计发现了一个重大内控缺陷，说收入确认的控制失效了，需要立即整改"，系统应调用本技能，执行缺陷评估并制定整改方案。

→ 示例：用户说"内控缺陷整改了大半年还没关，审计师在催，帮我分析卡在哪里了"，系统应调用本技能，执行缺陷整改进度分析。

→ 示例：用户说"这次 SOX 审计发现的缺陷评级从重大改成了一般，需要重新评估吗"，系统应调用本技能，评估缺陷评级重评的合理性。
## 缺陷等级定义

```
缺陷等级（按影响程度）：

🔴 重大缺陷（Significant Deficiency）：
  → 单个或多个控制组合，存在重大错报风险，但不至于导致整个账户/披露项重大错报
  → 示例：应收账款账龄分析控制失效，可能导致坏账准备低估

🔴🔴 重大弱点（Material Weakness）：
  → 控制缺陷的组合，导致财务报表存在重大错报的合理可能，且不能被及时防止或发现
  → 示例：收入确认整个控制环境缺失，系统性虚增收入

🟡 重要缺陷（Deficiency in Internal Control）：
  → 比重大缺陷程度轻，但仍须在内部控制报告中披露
  → 示例：审批权限矩阵部分超限，但不影响报表准确性

⚪ 一般缺陷（Control Improvement）：
  → 流程优化机会，不构成缺陷，可在报告中提及但非强制披露
```

---

## 第一步：缺陷确认

**缺陷基本信息：**
```
□ 控制编号：[C-01]
□ 控制名称：[名称]
□ 涉及流程：[流程名称]
□ 发现日期：[YYYY-MM-DD]
□ 发现来源：[SOX测试/内部审计/外部审计/事故报告/管理层发现]

□ 缺陷描述：
  [详细描述缺陷的具体表现]

□ 首次发现时间（如缺陷已存在一段时间）：
  → 首次发现：[YYYY-MM-DD]
  → 存在期间：[X] 个周期/长期存在
```

---

## 第二步：评估缺陷影响

**财务影响量化：**
```
□ 直接财务影响：
  → 涉及金额：[X] 万（如已知）
  → 高估影响：[X] 万
  → 低估影响：[X] 万

□ 对财务报表的影响科目：
  → [科目1] — 影响方向 [高估/低估] — 影响金额 [X] 万
  → [科目2] — 影响方向 [高估/低估] — 影响金额 [X] 万

□ 对财务比率的影响：
  → 资产负债率：[X]%（变动 [±X]%）
  → 应收账款周转天数：[X] 天（变动 [±X] 天）
  → 毛利率：[X]%（变动 [±X]%）
```

**运营影响：**
```
□ 业务连续性影响：[高/中/低]
□ 合规影响：[是/否 — 涉及法规]
□ 声誉影响：[高/中/低]
```

---

## 第三步：评估补偿性控制

**是否存在补偿性控制（降低缺陷实际影响）：**
```
□ 补偿性控制：
  → 控制编号：[C-XX]
  → 控制名称：[名称]
  → 执行效果：[✅ 有效降低影响 / ⚠️ 部分有效 / 🔴 无效]

□ 补偿性控制是否完全消除缺陷影响：[✅ 是 / 🔴 否]
```

---

## 第四步：确定缺陷等级

**缺陷等级判断矩阵：**
```
| 财务影响   | 运营影响 | 是否发现补偿控制 | 缺陷等级 |
|-----------|---------|----------------|---------|
| >[X]万    | 高       | 否              | 🔴🔴 重大弱点 |
| >[X]万    | 中/低    | 否              | 🔴 重大缺陷 |
| [X]-[X]万  | 高       | 否              | 🔴 重大缺陷 |
| [X]-[X]万  | 中/低    | 否              | 🟡 重要缺陷 |
| <[X]万    | 低       | 是（有效）      | ⚪ 一般缺陷 |
| <[X]万    | 低       | 否              | ⚪ 一般缺陷 |
```

**缺陷最终定级：**
```
□ 缺陷等级：[🔴🔴 重大弱点 / 🔴 重大缺陷 / 🟡 重要缺陷 / ⚪ 一般缺陷]
□ 定级依据：[描述]
□ 关键判断因素：[X 项]
```

---

## 第五步：分析根本原因

**根本原因分析（5Why 分析）：**
```
□ 缺陷直接原因：[描述]

□ 5Why 分析：
  → Why 1：[原因] — 因为 [原因]
  → Why 2：[原因] — 因为 [原因]
  → Why 3：[原因] — 因为 [原因]
  → Why 4：[原因] — 因为 [原因]
  → Why 5（根因）：[根本原因]

□ 根因分类：
  → [设计缺陷（控制本身无法有效防范风险）/ 执行缺陷（控制有效但未按设计执行）]
  → [人员能力问题 / 流程问题 / 系统问题 / 管理层问题]
```

---

## 第六步：制定整改计划

**整改措施设计：**
```
□ 短期整改（ [X] 天内）：
  → 措施 1：[描述]
  → 责任人：[姓名]
  → 预期完成：[YYYY-MM-DD]
  → 整改效果：[描述]

□ 中期整改（ [X] 周内）：
  → 措施 2：[描述]
  → 责任人：[姓名]
  → 预期完成：[YYYY-MM-DD]

□ 长期整改（如涉及系统/架构变更）：
  → 措施 3：[描述]
  → 责任人：[姓名]
  → 预期完成：[YYYY-MM-DD]
  → 资源需求：[描述]
```

**整改优先级：**
```
□ 是否须在年度报告前完成整改：[是/否 — 截止 [日期]]
□ 是否须向审计委员会报告：[是/否]
□ 是否须向外部审计师通报：[是/否]
```

---

## 第七步：生成缺陷评估报告

```
═══════════════════════════════════════
内部控制缺陷评估报告
缺陷编号：[DEF-001]
控制编号：[C-01]
发现日期：[YYYY-MM-DD]
评估日期：[YYYY-MM-DD]
═══════════════════════════════════════

【缺陷概况】
□ 缺陷描述：[详细描述]
□ 发现来源：[来源]
□ 影响流程：[流程]

【财务影响】
□ 涉及金额：[X] 万
□ 高估：[X] 万 | 低估：[X] 万
□ 影响科目：[列表]

【缺陷等级】
□ 等级：[🔴🔴 重大弱点 / 🔴 重大缺陷 / 🟡 重要缺陷 / ⚪ 一般缺陷]
□ 定级依据：[描述]
□ 补偿性控制：[✅ 有效 / ⚠️ 部分有效 / 🔴 无效 / 无]

【根本原因】
□ 根因：[描述]
□ 原因类型：[设计缺陷 / 执行缺陷]

【整改计划】
| 措施 | 责任人 | 截止日期 | 状态 |
|------|--------|---------|------|
| [措施1] | [姓名] | [日期] | [待执行/执行中/已完成] |
| [措施2] | [姓名] | [日期] | [待执行/执行中/已完成] |

【报告要求】
□ 须向审计委员会报告：[是/否 — 截止 [日期]]
□ 须向外部审计师通报：[是/否 — 截止 [日期]]
□ 须在年度报告中披露：[是/否]

═══════════════════════════════════════
置信度：[✅ 高 / ⚠️ 中 / 🔴 低]
缺陷状态：[🔴 未整改 / 🟡 整改中 / ✅ 已整改]
═══════════════════════════════════════
```

---

## 升级触发条件

- 缺陷等级为 🔴🔴 重大弱点或 🔴 重大缺陷
- 缺陷影响金额 > [X] 万（如 100 万）
- 须向审计委员会报告（重大缺陷及以上）
- 须向外部审计师通报
- 须在年度报告/中期报告中披露
- 整改计划在截止日前未完成且无合理解释

---

*Finance Skills — control-deficiency atomic skill*