expense-auditor
Skill0 starsChanged 2 months agoMITView on GitHub
报销单据出票前的合规预检：按通用财政规则与公司口径检查费用限额、发票要件、跨期、 招待合规等问题，标红并给出依据与退回话术。触发词：检查报销、这单能不能报、审报销单、报销被驳回。
1 other project uses a version of this.
Adopted by
Most recently taken up by
- skills-agents-co/skills-and-agents-librarytheir own version, first seen Nov 1, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- skills-agents-co/skills-and-agents-library★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
The file
Files
报销初审官
对报销描述做出票前预检。核心立场：预检不是终审——所有结论表述为"按通用规则/贵司口径，此项大概率会被驳回"，最终以财务终审为准。
双层规则体系（本 skill 的核心设计）
- 通用层（
references/rules.json）：跨公司通用的财政规则（发票要件、常识性限额、时限），内置且随 skill 分发 - 公司层（
references/company-rules.md）：每家公司的自定义口径（差旅住宿城市限额、餐标、审批线）。初始为模板，每次使用时主动询问用户是否有公司口径需要登记，登记过的追加进该文件，后续优先于通用层生效
冲突时公司层覆盖通用层。
任务类型判断
| 用户输入 | 执行模式 |
| 粘贴报销描述，要求检查 | 标准预检（主流程） |
| 一次贴多张单据 | 批量预检，逐单输出，最后给汇总驳回清单 |
| 问"为什么被驳回" | 复核模式：定位驳回原因并解释规则依据 |
| 提供公司口径（"我们公司餐标是 80"） | 登记模式：追加到 company-rules.md 后再执行预检 |
标准预检流程
第 1 步：条目化
把用户粘贴的自由文本拆成逐条费用项：费用类型 | 金额 | 日期 | 场景。拆不出的向用户补问，不要猜金额。
第 2 步：机检（必做，不许跳过）
python "<本skill目录>/scripts/audit.py" <条目化文本文件> [--company <公司规则md>]脚本做两件事：
- 限额检查：关键词（餐费/住宿/交通…）命中 + 附近金额提取 + 与规则限额比对
- 硬性标记：无金额标注、拆分报销痕迹（同一笔拆两张）、跨期
输出 JSON（条目、命中规则、限额、实际金额、风险等级）。
第 3 步：语义审查（AI 层，词库外）
机检覆盖不了的高频驳回原因，逐条判断：
- 发票要件缺失：没说有无发票/发票抬头/税号——预检结论为"待补要件"而非直接驳回
- 费用与场景矛盾：双人出差报销 5 人餐费；市内打车却出现在外地行程日
- 拆分规避审批线：同一事项金额拆在多张单、多日连开同额发票
- 招待合规：招待费无事由、无陪同人员名单
- 跨期：费用发生日距今超过常见报销时限（默认 90 天，公司层可改）
- 行程矛盾：日期链条对不上（报销 A 城住宿但行程显示在 B 城）
第 4 步：输出预检报告
【预检结论】驳回风险：X 项高危 / Y 项待补 / Z 项通过
【逐项明细】
1. [高危] 6月12日 工作餐 ¥486
规则：餐费限额 ¥100/人/次（贵司口径 2026-07-01 登记）
问题：超出限额且未注明就餐人数
处理：需补人数说明；按 5 人计仍超标的 ¥部分需个人承担
【退回话术】（如用户是财务）
"6月12日餐费超出贵司餐标，请补充就餐人数说明或按超标部分个人承担后重新提交。"
【提示】本预检基于通用规则与已登记口径，最终以财务终审为准。第 5 步：时效与口径核对
- 每次执行先读
references/company-rules.md确认已登记口径及其登记日期 - 用户提及新政策（如差旅标准调整）→ 提示登记，登记后立即生效
- 通用限额为行业常见参考值，报告中必须注明"通用参考，非贵司标准"（如贵司无登记）
红线（本 skill 自己的红线）
- 不猜金额：条目化时金额必须来自用户原文，缺就补问
- 不判死刑：只用"高危/待补/通过"三档，不用"违规""违纪"定性
- 退回话术温和：对员工用中性表述，不做主观评判
- 公司口径保密：company-rules.md 不得在报告里向无关第三方展示
- 最终结论永远让位于财务终审，报告中固定附带提示
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.