affiliate-payout-audit

联盟佣金付款审计

在发放前审计一轮联盟／合作伙伴佣金付款：重新计算金额、核实规则，并报告发现的问题以及建议暂缓付款和更正的事项。假设相关活动已通过欺诈筛查——本技能检查的是付款是否_正确_，而非是否_正当_。

目前不存在专门针对联盟业务的具名对账框架；平台提供的是锁定和争议处理机制，而非方法论。这里的方法明确借鉴了相邻的财务领域：

• 账户对账（编制人／复核人）。
• 三方匹配——平台导出数据 vs 计费／订单系统 vs CRM，这是联盟业务中相当于采购订单／收货／发票的做法。
• 收入保障。
• 职责分离／四眼原则（制单人－复核人）。
• SOX ICFR／COSO——适用于项目隶属于上市公司的情况。

向用户明确说明这一点；绝不要将其描述为某个品牌框架。

访谈

审计任何内容之前先提问。每条消息只问一个问题；尽可能提供多选答案。用户已经回答过的内容无需再问。

• 属于 B2B SaaS 经常性收入分成、B2C 电商按订单 CPA，还是两者都有？
• 当前生效的佣金结构是什么：费率模式、阶梯计算方式（边际或追溯）、按合作伙伴类型设置的费率覆盖项、促销／奖金期限、新客户门槛、下级联盟覆盖项、沿用旧费率的既有合作伙伴？
• 付款频率如何，本次付款的准确期间边界是什么——日期和时区？
• 有哪些数据导出文件，内部的事实来源是什么：计费系统、订单数据库，还是 CRM 中已赢单的记录？
• 验证／锁定窗口有多长？什么事件会使佣金从待处理变为已批准？
• 本次付款中是否已有任何明细完成付款，还是全部仍可撤回？
• 最低付款门槛是多少？涉及哪些货币？如何处理外汇？
• 每位收款人的税务表单状态如何——已收集、缺失还是已过期？
• 已知的历史错误类型和过往合作伙伴争议有哪些？
• 由谁计算本次付款，由谁发放资金？是同一人还是不同的人？
• 重要性阈值是多少？该项目是否受外部财务控制要求约束（上市公司 ICFR）？
• 审计结果必须在哪天提交，发放日期本身能否调整？
• 是一次性处理还是持续改进：只修正本次付款，还是留下常设控制措施——可重复使用的重新计算脚本、准备金政策、更长的验证窗口？
• 工作量上限：可用于复核的小时数、能否对导出数据执行代码、财务部门能否共同签署，以及本次处理最多可动用多少合作伙伴关系资源？

缺少期间边界、事实来源或佣金结构时，审计无法进行——在重新计算任何内容之前，必须坚持补齐这些信息。

最后三个答案会重新排列下方所有选项的优先级：

• 发放日期已确定且无法延后时，优先采用成本较低的检查，并取消全量重新计算。
• 若要求持续改进，则优先采用全量重新计算和逐步修正措施。
• 无法访问代码时，直接取消全量重新计算。
• 没有财务共同签署人时，取消从本次付款中直接追回款项。

审计流程

按顺序执行检查；每个关卡都以先前的关卡已通过为前提。底层流程在任何场景下都是相同的五关机制：提取／导出 → 与事实来源对账 → 按明细核实费率／阶梯 → 去重 → 锁定 → 付款。

如果发放日期不允许完成全部十二项检查。 编号表示依赖顺序，而非优先级。要有效利用有限的时间，应按每小时能发现的错误数对关卡排序：

• 效率：去重（6）> 对账与可比性（3-4）> 生命周期窗口（8）> 重新计算费率/等级（7）> 货币、税务、阈值（9）
• 价值：对账与可比性（3-4）> 去重（6）> 重新计算费率/等级（7）> 生命周期窗口（8）> 货币、税务、阈值（9）
• 工作量：重新计算费率/等级（7）——用代码需要一小时，手工则要一周 > 对账（3-4）——处理干净的导出文件需要一小时，处理杂乱的则要一两天 > 生命周期窗口（8）== 货币、税务、阈值（9）——各需一小时，涉及日期计算和检查清单 > 去重（6）——用代码处理关键数据集几乎不费工夫
• 合规成本：货币、税务、阈值（9）——向没有有效税务表格的收款人付款，不只是资金问题，也是申报问题 > 制作者-复核者机制（12）——签核记录是外部控制测试要求提供的证据 > 其他所有关卡 == 无，因为这些环节出错会造成资金损失，而不是申报问题

制作者-复核者机制（12）永远不能省略：它只需要安排一次日程和一位复核者，而缺少它正是负面示例中的所有错误得以发生的原因。

重新计算费率/等级是这套顺序中优先级被压低的环节——它在计算类关卡中价值最高，手工处理却最费时。遇到以下情况时，应将其提前：

• 合作伙伴对某个等级提出异议
• 本次结算跨越追溯生效的分界点
• 结构在周期中途发生变化

这套顺序是默认方案，而非铁律；它会随执行者而变化：如果某个网络能导出完整的机器可读日志，（6）和（7）的成本几乎会降为零，两者的优先级也会提前；如果无法访问计费系统，（3-4）就无从开展，（7）也就成为全部审计内容。

1. **冻结运行范围。**记录运行 ID、期间起止时间、时区、日期依据（交易日期、验证日期还是修订日期）、币种、重要性阈值以及所有数据源。范围不明确 → 停止并解决；之后的每项检查都依赖于此。
2. **按声明的日期依据提取数据。**获取平台／网络转化数据导出，以及同一期间的内部权威数据源提取结果。如果可以分析上传的电子表格或 CSV，请加载两者；否则，请用户提供行数、总额以及需要读出的具体行。
3. **可比性关卡。**比较或汇总任何两个数值来源之前，确认它们采用相同的事件定义、日期依据、时间范围、时区、币种、计数方法和去重标识。任何不匹配 → 先进行标准化，否则并列报告数字及其定义，并拒绝计算总额。详见 references/reconciliation-and-dedup.md。
4. **将总额与权威数据源对账。**比较行数和金额：平台导出数据 vs 账单／订单／CRM。通过 = 总额在重要性阈值范围内一致。未通过 = 存在差额，必须逐行解释后才能审批任何内容——绝不能以“差不多”了事。
5. **处理异常队列。**仅使用稳定 ID 匹配只出现在一个系统中的记录。
   • 在平台中、不在账单中：可能存在多计佣金，暂停并调查。
   • 在账单中、不在平台中：未跟踪销售，预计会收到合作伙伴的争议，并明确决定佣金政策。
6. **去重。**每笔转化使用一个确定性键（订单 ID／交易 ID／订阅 ID）。将键为空或格式错误的记录隔离。将双重跟踪（平台像素 + 内部跟踪器）合并为一个规范来源。检查是否有键出现在上一次运行中——跨期间会导致重复支付。
7. **逐行验证费率和等级。**根据原始交易日期生效的条款，使用原始输入重新计算预期佣金：等级计算方法和边界运算符、合作伙伴类型覆盖项、与起止日期时间对应的促销窗口、新客户限制、下级联盟覆盖项、保留旧费率。如果可以执行代码，就重新计算每一行；否则手动重新计算抽样行。计算方法见 references/rate-and-tier-verification.md。
8. **逐行验证生命周期状态。**每行都必须已通过验证／锁定窗口，或已明确放行；窗口内退款／流失对应的冲销必须已应用；锁定后发生的退款必须作为后续期间的负向调整列出，不得遗漏。规则见 references/lifecycle-and-clawback.md。
9. **验证币种、舍入、税务和阈值。**外汇定价日期符合政策，最终统一舍入到小数点后 2 位，低于阈值的余额结转，每位收款人都已在本次运行中存档税务表格。详见 references/currency-tax-and-payment.md。
10. 选择覆盖方法，按每小时发现错误数排序：
    • 效率：全量重新计算 > 基于风险的分层抽查 > 高收入者抽查
    • 价值：全量重新计算 > 基于风险的分层抽查 > 高收入者抽查
    • 工作量：基于风险的分层抽查——花一小时设计，然后按量级手动处理一周 > 高收入者抽查——一小时 > 全量重新计算——花一小时编写脚本，此后每次运行所需时间几乎为零
    • 在这里，工作量与价值反向：脚本写好后，最全面的方法也是成本最低的方法，而且只有它能持续产生复利效应。只有在可以对完整、机器可读的导出数据执行代码时，才采用这一方法；否则完全不考虑，优先采用基于风险的分层抽查。
    • 基于风险的分层抽查 = 对高价值行、高冲销率合作伙伴和高收入者进行 100% 检查（少数合作伙伴贡献了大部分佣金），再根据重要性阈值对其余部分进行随机抽样。高收入者抽查可以发现集中性错误，却无法发现长尾系统性问题——仅在期限紧迫时采用。
    • 仅随机抽样不算一种层级：它与基于风险的抽查耗费相同时间，却能发现的金额更少。随机抽样只用于其余部分，绝不用于整个运行。记录每项抽样选择所用的方法和理由。
11. **编制报告。**将每一行归类为已通过／已暂停／已更正；每项差异都要形成一条发现，注明严重程度、风险金额和建议措施（参见「输出」，然后参见「补救措施」）。发现任何疑似不正当行为模式——例如自我推荐、协同突发行为——都应升级至欺诈审查；此处绝不作出裁定。
12. **编制者-复核者签核。**计算本次运行的人不得同时负责放款；审计报告是复核者的依据。放款前不得存在任何尚未解决的阻断项发现——否则暂停受影响的行或整个运行。 如果你的执行框架具有持久记忆，请记住本次运行的参数和已接受的例外情况（期间规则、事实来源、重要性、已知的单边记录），以便下次运行从这些信息开始；否则，请将它们写入报告标题中以供后续复用。

输出：审计报告

每次审计都应交付以下成果：

PAYOUT AUDIT - <program>, run <id>, period <start>..<end> (<timezone>, <date basis>)
Scope     : <N> lines, proposed total <amount> <currency>; sources: <platform export> vs <source of truth>
Checks    : each numbered check above -> pass / fail / n-a, one line each
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 (ranked below) + escalate to fraud review if warranted
Exceptions: one-sided records with their queue (over-credit vs untracked) and resolution
Variance  : recomputed total vs proposed total; unexplained net variance vs materiality threshold
Cleared   : lines and value cleared for release (at corrected values)
Sign-off  : preparer, checker (must differ), date, release decision

B2B SaaS 和 B2C 电商报告示例，以及一个反例，见 references/audit-report-examples.md。

补救：针对每项发现采取的行动

发现错误只是成本较低的那一半。应按单位投入和合作伙伴关系资本所能挽回的价值来排列响应顺序——绝不能按名义涉款金额来排。

1. 发布前更正。 重新计算该笔金额，修正结算，支付正确金额。完全挽回，不消耗关系资本——合作伙伴从未看到错误数字。只要该笔款项尚未支付，就默认采用此方式。
2. 从未来佣金中抵扣。 将更正记为未来期间的负向调整，从合作伙伴下一笔收入中抵扣。该笔款项已支付后，默认采用此方式。可以完全挽回，但前提是合作伙伴仍有收入。
3. 承担损失并记录。 将该笔金额核销，并将其作为一项发现记录下来，注明金额。对于低于重要性门槛的情况，这是诚实的次优方案；对于余额为负且已停止合作的伙伴，这是唯一剩下的选择。
4. 向前修正。 延长验证窗口、增加准备金／预留款、安装共享幂等键，或在差异源于结构性定价错误而非偶发错误时，重新协商该合作伙伴的费率表。无法挽回本次结算的损失，但能消除整类错误。
5. 直接追偿。 向合作伙伴开具超额付款的发票。追偿结果不确定，而且这是唯一可能终止合作关系的方案。

• 效率：发布前更正 > 抵扣 > 承担损失并记录 > 向前修正 > 直接追偿
• 挽回价值：发布前更正 == 抵扣 > 直接追偿 > 承担损失并记录 == 向前修正
• 投入：直接追偿——需要一周到一个季度的催收、财务和法务协调 > 向前修正——需要一两天构建，之后作为常设任务运行 > 抵扣——需要一小时；平台支持负余额时几乎无需投入 > 发布前更正 == 承担损失——几乎无需投入，各只需一次编辑
• 关系资本：直接追偿 > 向前修正 > 抵扣 > 发布前更正 == 承担损失——不消耗任何关系资本，不会向合作伙伴提出任何要求
• 合规成本：直接追偿——需要解释合同并取得法务签字，一旦发出便不可撤回 > 抵扣——必须得到已公布条款的授权，而且有些平台明确规定已支付的佣金绝不能追回 > 向前修正——需要修订条款并通知合作伙伴 > 发布前更正 == 承担损失——无

平级的理由：

• 发布前更正和抵扣：两者都能挽回该笔金额的 100％，区别仅在于时间。

• 承担损失和向前修正：两者都无法挽回本次结算的损失，区别仅在于它们能为以后带来什么。

• 发布前更正和承担损失：两者都只需一次编辑，且都不会向合作伙伴提出任何要求。

• 删除，不要降级。如果本次结算中没有任何款项已支付，第 2、3、5 级就不是备选方案——删去它们并进行更正。如果条款或平台禁止追回已支付的佣金，就删去抵扣和直接追偿；承担损失和向前修正就是全部选项。

• 向前修正最容易被这个顺序挤到一边：它价值高，但无法挽回本次结算的损失，因此每轮都会落选。一旦同类发现连续两轮出现，或锁定后退款成为常态而非例外，就应立即将其提升到首位。

• 升级为欺诈审查不是一个级别。它回答的是另一个问题，并与所选级别并行进行。

• 这个顺序是默认方案，不是铁律；具体执行方不同，顺序也会改变。应根据已知情况重新排序：

  • 平台原生支持负余额时，应提高抵扣的优先级。
  • 如果本周期没有财务联合签署人，就从本次处理中删去直接追偿。
  • 如果合作伙伴名单规模足够小，可以全部重新结算，就应对原本需要抵扣的款项改用发布前更正。

通过阈值和 KPI

只有同时满足以下三项，运行才算通过；反复修正并重新运行检查，直至满足条件，否则建议暂缓运行：

• 每一行都已与事实来源核对一致，或列入例外清单——不存在未记录的遗漏。
• 重新计算的总额与拟议总额之间无法解释的净差异，不超过重要性阈值。
• 发布时未解决的阻断项为零。

逐次运行跟踪：

• 付款准确率：重新计算值与拟议值相符的行所占比例。
• 例外金额占运行总金额的比例。
• 冲回/追回率与规划区间的对比——CPA 约为 2-8%，收入分成低于 3%（这些是基准范围，并非审计数据）。超出区间 → 延长验证窗口或收紧资格条件。
• 付款后更正率——资金转移后发现的更正。
• 争议率及争议解决时间。

B2B SaaS 与 B2C 电商

两者遵循相同的规范：待处理 → 已批准 → 已锁定 → 已付款的生命周期、可比性门槛、去重键、例外队列、抽样和制衡机制，适用于两者。按相同顺序审计。真正存在差异的只有三点：

• 冲回触发条件。 B2C：退货窗口内发生订单退货、拒付或取消。B2B SaaS：试用转付费失败、退款、降级或周期中途流失。
• 重复发生情况。 B2C CPA 每笔订单支付一次。B2B 收入分成在每次计费事件中重复发生——按比例计费、升级/降级、席位扩容，以及 12 个月上限与终身规则，都意味着每个周期都是需要重新核验的一行。
• 事实来源集成。 B2B SaaS 平台通常直接读取计费系统，因此平台数据就是计费数据——检查 4 可简化为抽查。B2C 网络通过像素独立跟踪，因此仍必须进行完整核对。

不要人为制造其他差异；将两者视为不同的规范，只会重复工作，却无法发现更多错误。

失败模式

失败	发生原因	修复
阶梯边界差一位	将边际费率算成追溯式（或反之）；在临界点将 >= 写成 >；追溯式悬崖效应会放大误差	在每个边界金额处重新计算两种读法；对照书面结构；修正运算符
不同来源的订单 ID 重复	平台像素和内部跟踪器都记录了同一次转化	每次转化指定一个规范来源；使用共享幂等键；每个键只支付一次
去重键格式错误或为空	交易 ID 为空会将多次转化合并为一条记录，或者不生成记录	隔离空白或格式错误的键；汇总前手动处理
同一转化计入连续两个周期	重新导出时有重叠，或转化跨越截止时间	使用左闭右开周期窗口；将本次运行的键与上次运行的键进行差异比对
导出使用了错误的日期依据	导出选项可能使用交易日期、验证日期或修订日期；选错会导致数据行在不同运行间转移	在运行范围内声明日期依据；按声明的依据重新提取
截止时间的时区边界错误	平台、账单系统和项目办公室使用的时钟各不相同	在范围内固定一个时区；应用截止时间前先统一所有时间戳
忽略追回窗口	验证窗口结束前就批准数据行，导致退款无法冲销	暂缓处理仍在窗口期内的所有数据行；根据冲销曲线确定窗口长度
记录锁定后才收到退款	已锁定或已支付的数据行无法在平台上冲销	在后续周期记入负向调整；将负余额结转并抵扣未来收益
按当前条款重新计算	销售后费率发生变化；有些平台会按今日条款重新评估修改过的数据行	按原始交易日期生效的合同条款重新计算
货币舍入误差	对每一步舍入会在数百条小额数据行中累积误差	最后统一舍入到小数点后 2 位，不要对每一步舍入；偏差超过重要性阈值 → 审计舍入政策
低于门槛的余额被悄然丢弃	将最低付款门槛当作排除条件，而不是结转条件	确认低于门槛的余额会结转到下一次运行；不得让余额消失
税务表格尚未存档就发放付款	收款方入驻流程被跳过，或表格已过期却未被发现	对缺少或已过期表格的收款方阻止付款发放；每次运行都重新检查

调用示例

• “发布本月的佣金付款前，先审核一下——共 840 行，拟付款金额为 $61K，已附上平台导出文件和账单导出文件。”
• “两位联盟会员对上季度的佣金提出异议。重新审核那次付款，并告诉我该档位是按边际量还是按总量应用的。”
• “我们的联盟网络导出数据和订单数据库相差约 $3K。核对一下，并告诉我哪些款项应暂缓支付。”

参考资料

• mbfinotti/partnerships-skills@affiliate-commission-structure - 用于设计本次审核所依据的佣金结构
• mbfinotti/partnerships-skills@affiliate-fraud-detection - 用于制定佣金付款计算前的欺诈规则集
• mbfinotti/partnerships-skills@affiliate-program-terms - 用于查看规定验证期限和追回权利的条款与条件文档
• mbfinotti/partnerships-skills@affiliate-performance-dashboard - 用于查看持续性的计划指标，而非针对单次付款的审核