Load context
On first use: Read ../../CLAUDE.md to obtain scenario-level configuration (supplier tiering/approval levels/compliance red lines).
/supplier-payment-review — Supplier Payment Review
Examples
→ Example: The user says "A supplier requires 50% prepayment, but our policy is to pay only after receipt of goods; help me determine," and the system should invoke this skill to assess whether the prepayment request complies with the payment policy.
→ Example: The user says "A supplier reconciliation found that we underpaid by 30,000, and it needs to be made up next month," and the system should invoke this skill to verify the discrepancy and formulate a payment make-up plan.
→ Example: The user says "A new supplier is applying for payment for the first time; what needs special attention," and the system should invoke this skill and execute according to the first-payment review checklist for new suppliers.
Review dimensions
维度一：供应商主数据
→ 供应商名称/账户/银行信息是否正确
维度二：金额准确性
→ 付款金额是否与应付余额一致
维度三：付款条款符合性
→ 是否按合同约定条款付款（到期日/付款方式）
维度四：反腐合规
→ 收款账户/金额/用途是否合规
Step 1: Supplier master data verification
Obtain supplier master data from [ERP]:
□ 供应商名称是否与付款申请一致？
□ 收款账户是否与 ERP 主数据一致？
□ 收款银行是否与历史记录一致？
□ 供应商是否在黑名单中？（反腐合规）
High-risk signals:
🔴 供应商要求变更收款账户（比历史记录多了新账户）
🔴 收款账户与供应商名称不一致（个人账户？）
🔴 供应商在被制裁/黑名单名单中
🔴 供应商注册地与合同签订地不一致（跨境风险）
If high-risk signals are found:
→ 🔴 立即暂停付款
→ → 须提供供应商书面变更申请（加盖公章）
→ → 须与供应商原对接人电话核实
→ → 须财务经理 + 法务确认后才可付款
Step 2: Amount accuracy verification
□ 付款金额是否与 [ERP] 中应付余额一致？
□ 是否有部分付款（仅付部分应付）？
□ 是否有预付款/首付款（与合同条款一致？）？
金额校验公式：
应付余额 = 历史付款 + 本次付款 + 其他扣款
Common amount issues:
□ 重复付款（同一发票是否已付过？）
→ 检查 [ERP] 历史付款记录
□ 超额付款（付多了）
→ 🔴 立即暂停，查明原因
□ 少付（有意少付一部分？）
→ 须确认是否有争议扣款
→ 须供应商书面确认
Step 3: Payment terms compliance
□ 付款是否在到期日或之后？（不应提前太多，除非有折扣）
□ 付款方式是否与合同一致？（银行转账 vs 承兑汇票）
□ 是否在付款条款范围内？（如月结 30 天）
提前付款检查：
- 付款日距到期日 > [X] 天：须部门负责人说明原因
- 提前付款可获取折扣：须评估折扣收益
Step 4: Anti-corruption compliance check
合规红线检查清单：
[ ] 收款账户是对公账户（非个人账户）
[ ] 收款账户名称与供应商名称一致
[ ] 付款金额与合同/订单一致
[ ] 付款摘要描述清晰
[ ] 无分拆付款规避审批限额
[ ] 无预付款过大（> 30%，除非战略供应商）
[ ] 供应商不在制裁/黑名单中
分拆付款检测：
- 同一供应商，同一天有多笔付款
- 金额刚好在审批限额附近（如 4.9 万/5.1 万）
- 须检查是否为分拆付款规避审批
Step 5: Payment history review
Query supplier payment history from [ERP]:
□ 该供应商是否有逾期付款记录？
□ 该供应商是否连续逾期？
□ 该供应商是否曾要求变更账户？
付款历史风险信号：
⚠️ 过去 3 个月有 2 次以上逾期
⚠️ 曾要求变更收款账户
⚠️ 付款准确率低（频繁出现金额差异）
Step 6: Generate review conclusion
═══════════════════════════════════════
供应商付款审核报告
付款批次：[YYYYMMDD-XXX]
审核时间：[YYYY-MM-DD HH:MM]
═══════════════════════════════════════
【供应商主数据】
供应商名称：[名称]
收款账户：[账户]
收款银行：[银行]
审核结果：[✅ 正常 / 🔴 异常 — 暂停]
【金额准确性】
申请付款金额：[XXX万]
ERP 应付余额：[XXX万]
差异：[XXX万]（如无差异则填 0）
审核结果：[✅ 准确 / 🔴 有差异 — 待核查]
【付款条款符合性】
合同付款条款：[月结30天]
本次付款日：[YYYY-MM-DD]
到期日：[YYYY-MM-DD]
距到期日：[X] 天（负数为提前）
审核结果：[✅ 符合 / ⚠️ 不符 — 说明原因]
【反腐合规】
合规检查清单：
[✅] 收款账户是对公账户
[✅] 账户名称与供应商一致
[✅] 金额与合同一致
[✅] 无分拆付款
[✅] 预付款比例合规
[✅] 不在黑名单中
合规结果：[✅ 全部通过 / 🔴 有红灯 — 详情如下]
【付款历史】
历史付款：[X] 笔
逾期次数：[X] 次
账户变更记录：[有/无]
审核结果：[✅ 正常 / ⚠️ 关注 / 🔴 高风险]
【审核结论】
综合结论：[✅ 批准 / ⚠️ 附条件批准 / 🔴 拒绝 / ⏳ 需补充材料]
批准条件（如附条件）：
1. [条件一]
2. [条件二]
拒绝理由（如拒绝）：
1. [理由一]
2. [理由二]
需补充（如需补充）：
- [补充材料清单]
═══════════════════════════════════════
审核人：[AP主管/财务经理]
审核时间：[YYYY-MM-DD HH:MM]
═══════════════════════════════════════
Escalation trigger conditions
- Supplier requests to change the receiving account
- Suspected split payments
- Supplier is on the blacklist/sanctions list
- Overpayment or suspected duplicate payment
- Single payment > [fill in: e.g., 500,000 yuan]
- Supplier has a prior fraud record
Finance Skills — supplier-payment-review atomic skill