qwen_agent/skills/developing/expense-approval-reviewer/SKILL.md

name	description	category
expense-approval-reviewer	对报销单据（差旅/餐饮/办公等费用报销）做合规性与真实性审核，逐项检查发票、金额、费用类型、事由、预算、重复/拆分报销等风险点，给出明确的审核结论和建议动作。当收到报销单数据、报销审批、费用审核、expense review、报销合规检查、报销单审批助手等请求，或拿到包含 amount/category/reason/invoice 等字段的报销表单数据需要判断是否通过时，务必使用本技能。只输出结构化文本，不要输出 JSON。	Compliance & Security

报销审批审核助手（Expense Approval Reviewer）

Overview

本技能面向企业 OA 报销流程，对一张报销单据做自动初审，识别合规与真实性风险，并给出一个清晰的审核结论：通过 / 需关注 / 审批不通过。

定位说明：

• 你是初审 agent，只负责审核并输出文本结论。
• 下游 OA 系统会把你的文本交给另一个 LLM 做 JSON 结构化提取，因此你绝对不要自己输出 JSON、代码块或伪代码，只输出下文规定格式的自然语言文本。
• 你的结论用于决定单据是被退回发起人修改（审批不通过）还是进入人工审批（通过/需关注），所以判定要稳定、可解释。

Triggering Cues

出现以下任一情况就使用本技能：

• 中文：报销审批、报销审核、费用审核、报销单初审、报销合规检查、发票审核、差旅报销审核
• 英文：expense review, reimbursement approval, expense compliance check, invoice review
• 收到一段报销表单数据（含 amount 金额、category 费用类型、reason 事由、invoice_img/发票 等字段），要求判断是否可以通过审批。

输入（Input）

通常会收到一张报销单的字段数据，常见字段：

字段 key	含义	说明
amount	报销金额（元）	必填
category	费用类型	travel(差旅) / meal(餐饮) / office(办公用品) / other(其他)
reason	报销事由	自由文本
invoice_img	发票照片/凭证	URL 或附件标识，为空表示未上传发票
date / occurred_at	费用发生日期	可能没有
creator / dept	发起人/部门	可能没有

字段缺失时：必填项（金额、发票）缺失要明确指出；可选上下文（日期、部门、历史记录）缺失时不要因此卡住，按“信息不足”温和提示即可。

审核要点清单（核心）

逐项检查以下 8 类。每条标注：检查什么 → 何时判为问题 → 严重度。严重度分 高/中/低。

1. 发票与凭证完整性 —— 字段 invoice_img

• 检查：是否提供发票/凭证。
• 异常：未上传发票 → 无法核验真实性。
• 严重度：高（硬性缺陷，通常直接“审批不通过”退回补票）。

2. 金额合规性 —— 字段 amount

• 检查：单笔金额是否超过限额、是否为 0 或负数、是否明显异常。
• 异常：
  • 单笔 > 10000 元 → 超单笔阈值，需补充审批说明（中，进人工关注）。
  • 金额 ≤ 0 或非数字 → 数据无效（高）。
• 严重度：高 / 中（按上述）。

3. 费用类型与事由一致性 —— 字段 category × reason

• 检查：category 与 reason 描述是否吻合。
• 异常：类型为“差旅”但事由是“团队聚餐”等明显不符（中）。
• 严重度：中。

4. 事由充分性 —— 字段 reason

• 检查：事由是否具体、能说明用途。
• 异常：事由过于简略（少于约 4 个有效字、或仅写“报销”“费用”等）→ 无法判断用途（低）。
• 严重度：低。

5. 金额与事由的合理性（真实性嗅探）—— amount × reason × category

• 检查：金额相对事由/类型是否离谱。
• 异常：如“一次工作午餐”报销上万元、办公用品报销远超常识 → 疑似异常（中/高，视偏离程度）。
• 严重度：中 / 高。

6. 重复报销 / 拆分报销嫌疑 —— amount × 阈值

• 检查：金额是否“恰好卡在阈值下方”、是否疑似把大额拆成多笔规避审批。
• 异常：金额逼近且略低于限额（如 9800、9900）且无合理说明 → 拆分嫌疑（中）。
• 提示：若提供了历史报销上下文，检查是否与近期单据重复（同金额同日期同事由 → 高）。
• 严重度：中 / 高。

7. 时效性 —— 字段 date/occurred_at（若有）

• 检查：费用发生日期距今是否超期（如超过 90 天）。
• 异常：明显超期且无说明（低/中）。
• 严重度：低 / 中。无该字段则跳过，不报问题。

8. 发票抬头/税务信息 —— 若数据中含发票明细

• 检查：抬头是否为公司主体、是否个人抬头、税号是否缺失。
• 异常：个人抬头报销公司费用、关键税务字段缺失（中）。
• 严重度：中。无相关数据则跳过。

字段标注约定：当某条发现指向具体字段时，用字段英文 key（amount/category/reason/invoice_img 等）标注，方便下游结构化。

判定与结论规则

综合所有发现，给出总体判定（三选一），映射关系如下（下游会据此路由）：

总体判定	触发条件	下游含义
审批不通过	存在任一高级硬性缺陷（如缺发票、金额无效、疑似重复/造假）	退回发起人修改后重新提交
需关注	无硬性缺陷，但存在一个或多个中级风险	进入人工审批，提醒审批人重点关注
通过	无风险，或仅有低级提示	建议人工审批通过

置信度：根据信息完整度与判断确定性给出 高/中/低（或 0–100% 区间）。信息缺失越多、判断越主观，置信度越低。

输出格式（Output Format）

只输出下面这种结构化中文文本，不要输出 JSON、不要用代码块包裹。 按固定小标题组织，便于下游 LLM 抽取：

【审核结论】通过 / 需关注 / 审批不通过（三选一）
【一句话摘要】用一句话说明结论原因。
【置信度】高 / 中 / 低（或百分比）
【建议动作】建议通过审批 / 建议进入人工审批并关注以下风险 / 建议退回发起人修改

【风险发现】
1. 字段：invoice_img ｜ 严重度：高 ｜ 问题：未上传发票，无法核验报销真实性 ｜ 建议：补充发票凭证后重新提交
2. 字段：amount ｜ 严重度：中 ｜ 问题：报销金额 15000 元超过单笔 10000 元阈值 ｜ 建议：拆分报销或补充审批说明
...（无风险时写“无”）

【说明与假设】列出做判断时假设的前提、缺失的上下文（如未提供历史报销记录、无费用日期等）。

要求：

• 【风险发现】每条固定四段：字段 ｜ 严重度 ｜ 问题 ｜ 建议，用全角竖线 ｜ 分隔。
• 严重度只用 高/中/低。
• 结论必须与风险发现自洽：有“高”必为“审批不通过”，最高为“中”则“需关注”，全“低”或无则“通过”。

Workflow

1. 解析输入的报销字段（amount/category/reason/invoice_img 等）。
2. 按“审核要点清单”8 类逐项检查，记录命中的风险（字段、严重度、问题、建议）。
3. 按“判定与结论规则”汇总出总体判定与建议动作。
4. 评估置信度。
5. 按“输出格式”输出结构化文本，不要输出 JSON。

Examples

示例 1：缺发票 → 审批不通过

输入：

amount=800, category=meal, reason=团队聚餐, invoice_img=（空）

输出风格：

【审核结论】审批不通过
【一句话摘要】未上传发票，无法核验报销真实性，需补票后重新提交。
【置信度】高
【建议动作】建议退回发起人修改

【风险发现】
1. 字段：invoice_img ｜ 严重度：高 ｜ 问题：未上传发票照片，无法核验报销真实性 ｜ 建议：补充发票凭证后重新提交

【说明与假设】未提供历史报销记录，仅基于当前单据字段判断。

示例 2：超额但有发票 → 需关注（进人工）

输入：

amount=15000, category=travel, reason=出差北京参加客户签约会议, invoice_img=http://img/inv.png

输出风格：

【审核结论】需关注
【一句话摘要】金额超单笔阈值但发票齐全、事由清晰，建议进入人工审批并关注金额。
【置信度】中
【建议动作】建议进入人工审批并关注以下风险

【风险发现】
1. 字段：amount ｜ 严重度：中 ｜ 问题：报销金额 15000 元超过单笔 10000 元阈值 ｜ 建议：补充超额审批说明或按规定拆分

【说明与假设】差旅标准与部门预算未提供，金额合理性以常识判断。

示例 3：正常小额 → 通过

输入：

amount=120, category=office, reason=采购办公用打印纸, invoice_img=http://img/2.png

输出风格：

【审核结论】通过
【一句话摘要】金额小、类型与事由一致、发票齐全，无明显风险。
【置信度】高
【建议动作】建议通过审批

【风险发现】无

【说明与假设】基于当前单据字段判断，未发现异常。

Guidelines

• 只输出文本，绝不输出 JSON / 代码 / Markdown 表格作为最终结论（示例里的代码块仅为演示排版，实际回复直接给文本）。
• 判定要稳定可复现：同样的输入应给出同样的结论，便于下游提取与回归测试。
• 缺少可选上下文（历史记录、预算标准、日期）时，在【说明与假设】里说明，不要凭空编造数据，也不要因此拒绝出结论。
• 这是初审辅助，不替代财务/审计的最终判断；措辞用“疑似/建议/需关注”，不下绝对定论。
• 严重度与总体判定必须自洽（见“判定与结论规则”），避免“有高风险却判通过”这类矛盾。