在佣金打款前审计联盟/合作伙伴结算批次是否算对：逐行重算费率…

当需要在一笔联盟或合作伙伴佣金发放前核对金额是否正确（而非是否欺诈）时，按固定顺序执行十二道审计关卡并产出带严重级别与建议冻结项的报告。

适用场景

解决思路

1. 先做访谈再审计：每次只问一个问题，尽量给多选项，跳过用户已答内容。必须问清：B2B SaaS 循环分成还是 B2C 电商订单级 CPA（或两者）；生效的佣金结构（费率模型、阶梯方式为边际还是追溯、按伙伴类型的覆盖费率、促销/奖金窗口、新客户限制、子联盟覆盖、祖父级旧费率）；发放周期与本批次精确周期边界（日期与时区）；存在哪些数据导出、内部真源是计费系统、订单库还是 CRM 已成交；验证/锁定窗口长度、什么事件把佣金从 pending 释放为 approved；本批次是否已有行已付款或全部可逆；最低发放门槛、涉及币种、FX 处理政策；每个收款人的税表状态（已收/缺失/过期）；已知历史错误类型与过往伙伴争议；谁计算本批次、谁放款（同一人还是不同人）；重要性阈值、是否受外部财务控制要求（上市公司 ICFR）；审计结果截止日期、放款日期是否可动；是一次性还是复利式（只修本批次还是留下可复用重算脚本、准备金政策、更长验证窗口）；工作量上限（可用审查小时数、能否对导出执行代码、财务能否联署、本批次可消耗多少伙伴关系资本）。缺失周期边界、真源或佣金结构时，坚持先补齐再重算任何东西。
2. 按依赖顺序执行十二道关卡（前一道通过才做下一道）：1) 冻结批次范围：记录 run ID、周期起止、时区、日期基准（交易日期/验证日期/修正日期）、币种、重要性阈值与所有数据源；范围含糊就停下解决，后续每项检查都依赖它。2) 按声明的日期基准拉取导出：平台/网络转化导出加同周期的内部真源抽取；能分析上传的表格或 CSV 就都加载，否则让用户提供行数、总额与指定行内容。3) 可比性关卡：在比较或加总任何两个数值来源前，确认它们共享同一事件定义、日期基准、时间窗口、时区、币种、计数方法与去重标识；任何不匹配先归一化，或并排报告数字及其定义并拒绝计算总额。4) 对账总额到真源：比较行数与金额（平台导出 vs 计费/订单/CRM）；通过=在重要性内匹配；失败=必须逐行解释差异后才能批准，绝不接受“差不多”。5) 处理异常队列：只按稳定 ID 匹配，找出只在一个系统中的记录；在平台不在计费=可能多计，冻结并调查；在计费不在平台=未追踪销售，预期伙伴会来争议，明确决定授信政策。6) 去重：每次转化一个确定性键（订单 ID/交易 ID/订阅 ID）；隔离空或畸形键；把双重追踪（平台像素+自建追踪器）收敛到唯一权威来源；检查该键未出现在上一批次（周期跨越会付两次）。7) 逐行验证费率与阶梯：用原始交易日期当时生效的条款从原始输入重算应付佣金，包括阶梯方式与边界运算符、按伙伴类型覆盖、促销窗口对照起止日期时间、新客户限制、子联盟覆盖、祖父级费率；能执行代码就重算每一行，否则手工重算抽样行。8) 逐行验证生命周期状态：每行必须已过验证/锁定窗口或被显式释放；窗口内退款/流失的冲销必须已应用；锁定后发生的退款必须作为未来期负向调整出现，不能消失。9) 验证币种、舍入、税与门槛：FX 汇率日期符合政策，最后统一舍入到 2 位小数，低于门槛的余额结转，本批次每个收款人都有税表在档。10) 选择覆盖方法（按每小时发现错误数排序）：效率与价值排序均为全量重算 > 风险分层抽样 > 头部收益者抽查；工作量排序为风险分层抽样（设计 1 小时，量大时手工约一周）> 头部收益者抽查（1 小时）> 全量重算（写脚本 1 小时，之后每次近乎为零）；工作量在此与价值相反：最彻底的方法一旦脚本存在也最便宜，且是唯一能复利的层级；仅当能对完整机器可读导出执行代码时它才领先，否则直接出局，由风险分层抽样领先；风险分层抽样=100% 高价值行、高回拨伙伴与头部收益者（少数伙伴贡献大部分佣金美元），加上按重要性确定规模的其余随机样本；头部收益者抽查能抓集中错误但对长尾系统性问题盲视，仅在硬截止日期下采用；纯随机抽样不是一个层级（与风险分层同样耗时但发现更少美元），随机性只用于剩余部分，绝不用于整批；记录所选方法及理由。11) 编制报告：把每行分类为 cleared/held/corrected；每个差异成为一条 finding，含严重级别、风险金额与建议动作；把疑似不合法的模式（自我推荐、协同爆发）升级到欺诈审查，绝不在此自行裁定。12) 制衡签署：计算本批次的人不得是放款人，审计报告是复核者的证据；放款前零个 blocker finding 未决，否则冻结受影响行或整批。
3. 若环境有持久记忆，记住本批次参数与已接受的例外（周期规则、真源、重要性、已知单边记录），下次批次直接沿用；否则写进报告头部复用。
4. 按固定模板交付审计报告：PAYOUT AUDIT - <program>, run <id>, period <start>..<end> (<timezone>, <date basis>)；Scope：<N> 行、拟发总额 <amount> <currency>、来源 <platform export> vs <source of truth>；Checks：上述每道编号检查 -> pass/fail/n-a，各一行；Findings：F-<n> | severity: blocker/material/minor/informational | $ at risk | affected lines | action: correct before release / hold line / offset against future commission / absorb and document / fix it forward / direct recovery（按下方排序）+ 必要时升级欺诈审查；Exceptions：单边记录及其队列（多计 vs 未追踪）与解决方式；Variance：重算总额 vs 拟发总额、未解释净差异 vs 重要性阈值；Cleared：放行行与金额（按修正值）；Sign-off：preparer、checker（必须不同）、日期、放款决定。
5. 对每条 finding 按“每单位努力与伙伴关系资本回收的价值”排序选择补救动作，绝不按名义金额排序：1) 放款前修正：重算该行、修正批次、付正确数字；全额回收、零关系成本，伙伴从未看到错误数字；只要该行未付就默认用它。2) 冲抵未来佣金：把修正记为未来期负向调整，挂在伙伴下次收益上；一旦该行已付就默认用它；全额回收，但仅在伙伴继续赚钱期间可行。3) 吸收并记录：核销该行并作为 finding 记录其金额；低于重要性时的诚实层级，也是伙伴已流失且余额为负时唯一剩下的选择。4) 向前修复：延长验证窗口、加准备金/扣留、安装共享幂等键，或在差异是结构性错误定价而非错误时重谈该伙伴费率卡；本批次回收为零，但能消灭整类错误。5) 直接追偿：向伙伴开票追回多付；回收不确定，且是唯一可能终结关系的层级。排序：效率为放款前修正 > 冲抵 > 吸收并记录 > 向前修复 > 直接追偿；回收价值为放款前修正 == 冲抵 > 直接追偿 > 吸收并记录 == 向前修复；工作量为直接追偿（一周到一季度的催收、财务与法务协调）> 向前修复（一周搭建，之后常驻）> 冲抵（1 小时，平台原生支持负余额时近乎为零）> 放款前修正 == 吸收（近乎为零，各一次编辑）；关系资本为直接追偿 > 向前修复 > 冲抵 > 放款前修正 == 吸收（不消耗，伙伴从未被要求任何东西）；合规成本为直接追偿（合同解释与法务签署，发出后不可逆）> 冲抵（必须由已公布条款授权，多个平台明确表示已付佣金永不追回）> 向前修复（条款修订并通知伙伴）> 放款前修正 == 吸收（无）。
6. 补救菜单的删除而非降级规则：若本批次无任何已付款，则冲抵、吸收、直接追偿都不是备选，删掉它们直接修正；若条款或平台禁止追回已付佣金，删掉冲抵与直接追偿，吸收与向前修复就是全部菜单。向前修复最容易被饿死（高价值、本批次零回收，每轮都输），一旦同一类 finding 连续两批出现，或锁定后退款成为常态而非例外，就把它提到最前。升级欺诈审查不是一个层级，它回答不同问题，与所选层级并行。排序是默认而非铁律，随执行者变化：平台原生支持负余额时提升冲抵；本周期无财务联署则从本批次删除直接追偿；名册小到可全量重跑时，把放款前修正重新放回本需冲抵的行。
7. 通过阈值：仅当三条同时成立才算通过，否则迭代修正并重跑检查，或建议冻结整批：每行要么已对账到真源、要么在异常清单上（无静默缺口）；重算总额与拟发总额之间的未解释净差异在重要性阈值以内；放款时零个 blocker finding 未决。
8. 跨批次跟踪 KPI：Payout accuracy rate（重算值与拟发值匹配的行占比）；Exception value 占批次总价值比例；Reversal/clawback rate 对照规划区间（CPA 约 2-8%，revenue-share 低于 3%，为基准区间而非审计数据），高于区间则延长验证窗口或收紧资格；Post-payout correction rate（钱已动之后才发现的修正）；Dispute rate 与争议解决时长。
9. B2B SaaS 与 B2C 电商用同一套序列审计，只有三点真正不同：回拨触发（B2C 为退货窗口内的退货、拒付或取消；B2B SaaS 为试用转付费失败、退款、降级或期中流失）；重复性（B2C CPA 每单只付一次；B2B revenue-share 在每个计费事件上循环，按比例分摊、升级/降级、席位扩张以及 12 个月上限 vs 终身规则使每个周期都是新行需验证）；真源集成（B2B SaaS 平台常直接读计费系统，平台数据即计费数据，第 4 项检查退化为抽查；B2C 网络通过像素独立追踪，完整对账仍强制）。不要制造其他差异，把两者当独立学科只会重复工作而不多抓错误。
10. 规避常见失败模式：阶梯边界差一（边际被当追溯或反之、断点处 >= 写成 >、追溯悬崖放大错误）→ 在每个边界行同时重算两种读法、匹配书面结构、修正运算符；跨来源重复订单 ID（平台像素与自建追踪器都记录同一转化）→ 每次转化一个权威来源、共享幂等键、每个键只付一次；畸形或空去重键（空交易 ID 把许多转化塌缩成一条或全无）→ 隔离空/畸形键、合计前人工解决；转化被计入连续两个周期（重导出重叠或截止处周期跨越）→ 半开周期窗口、本批次键与上一批次做差；导出日期基准错误（交易/验证/修正日期选错会把行挪到别的批次）→ 在范围中声明日期基准、按声明基准重拉；截止处时区边界错误（平台、计费系统与项目办公室各用不同时钟）→ 范围中固定一个时区、应用截止前归一化所有时间戳；忽略回拨窗口（行在验证窗口结束前就被批准，退款永不冲销）→ 冻结仍在窗口内的每一行、按回拨曲线设定窗口长度；退款在记录锁定后到达（锁定/已付行无法在平台冲销）→ 记未来期负向调整、负余额挂到未来收益；用当前条款重算（费率已变，部分平台按今日条款重评修改行）→ 用原始交易日期当时生效的合同条款重算；币种舍入漂移（逐步舍入在数百小额行上累积）→ 最后统一舍入到 2 位小数而非每步舍入，漂移超重要性则审计舍入政策；低于门槛余额被静默丢弃（最低发放门槛被当作排除而非结转）→ 核实低于门槛余额滚入下批、绝不消失；税表未在档就放款（收款人入驻被跳过或表格过期未被注意）→ 任何收款人缺表/过期即阻止放款、每批重查。

适用边界 · 注意事项

• 不用于识别欺诈性联盟成员——那是 mbfinotti/partnerships-skills@affiliate-fraud-detection 的职责；本技能假设活动已通过欺诈筛查，只检查付款是否正确而非是否合法。
• 缺失周期边界、真源或佣金结构时不要开始重算任何东西，必须先补齐。
• 若本批次无任何已付款，不要使用冲抵、吸收、直接追偿等补救层级，直接修正；若条款或平台禁止追回已付佣金，不要使用冲抵与直接追偿。