affiliate-payout-audit

アフィリエイト報酬の支払い監査

支払いをリリースする前に、アフィリエイト／パートナーへのコミッション支払いを1回分監査します。計算を再実行し、ルールを検証して、推奨する保留措置や修正とともに調査結果を報告します。アクティビティはすでに不正審査を通過しているものとします。このスキルで確認するのは支払いが 正確 かどうかであり、正当 かどうかではありません。

アフィリエイトに特化した、名称の付いた照合フレームワークはありません。各プラットフォームが提供するのはロック機能や異議申し立ての仕組みであり、方法論ではありません。ここでの手法は、隣接する財務分野から明示的に取り入れています。

• 勘定照合（作成者／レビュー担当者）。
• 三者照合 — プラットフォームのエクスポートと請求／受注システム、CRMを照合します。アフィリエイトにおける、発注書／受領書／請求書の照合に相当します。
• 収益保証。
• 職務分掌／四つの目の原則（作成者と確認者による相互チェック）。
• SOX ICFR / COSO — プログラムが上場企業の一部である場合。

この点はユーザーにはっきりと伝えてください。ブランド化されたフレームワークとして説明してはいけません。

ヒアリング

何かを監査する前に質問してください。1回のメッセージにつき質問は1つにし、可能であれば選択肢を提示してください。ユーザーがすでに答えた項目は省略します。

• B2B SaaSの継続収益分配、B2C ECの注文単位のCPA、それとも両方ですか？
• 適用中のコミッション体系は何ですか？料率モデル、段階制の方式（限界税率方式か遡及方式か）、パートナーの種類ごとの例外、プロモーション／ボーナス期間、新規顧客の条件、サブアフィリエイトへの例外、旧料率の適用継続などを教えてください。
• 支払いの頻度と、今回の対象期間の正確な境界は何ですか？日付とタイムゾーンを教えてください。
• どのデータをエクスポートできますか？また、請求システム、注文データベース、CRMの受注確定のうち、社内の正本となるデータはどれですか？
• 検証／ロック期間はどれくらいですか？コミッションが保留中から承認済みに切り替わるのは、どのイベントが発生したときですか？
• 今回の支払いに、すでに支払い済みの明細はありますか？それとも、すべてまだ取り消し可能ですか？
• 最低支払い額のしきい値、対象通貨、為替処理の方針を教えてください。
• 支払先ごとの税務フォームの状況はどうですか？回収済み、未提出、期限切れのいずれですか？
• 過去に発生した既知のエラーの種類や、パートナーからの過去の異議申し立てはありますか？
• 支払いの計算担当者と資金のリリース担当者は誰ですか？同じ人ですか、それとも別の人ですか？
• 重要性のしきい値はいくらですか？プログラムは外部の財務統制要件（上場企業のICFR）の対象ですか？
• 監査結果はいつまでに必要ですか？支払いのリリース日は変更できますか？
• 今回限りの対応ですか、それとも継続的な対応ですか？今回分だけ修正しますか、それとも再利用可能な再計算スクリプト、引当金の方針、より長い検証期間など、継続的な統制も整備しますか？
• 作業の上限はどの程度ですか？レビューに使える時間、エクスポートデータに対してコードを実行できるか、財務部門が共同で承認できるか、今回の対応にどれほどのパートナーとの関係上の負担を許容できるかを教えてください。

対象期間の境界、正本となるデータ、またはコミッション体系が不明な場合は監査を進められません。再計算を始める前に、必ず確認してください。

最後の3つの回答によって、以下の選択肢の優先順位がすべて変わります。

• リリース日が動かせない場合は、低コストの確認を優先し、全件の再計算は省略します。
• 継続的な改善が求められる場合は、全件の再計算と、今後の改善策を優先します。
• コードを実行できない場合は、全件の再計算は選択肢から完全に外します。
• 財務部門の共同承認者がいない場合は、今回分からの直接回収は選択肢から外します。

監査手順

確認は順番に進めてください。各ゲートは、その前のゲートに合格していることを前提とします。基盤となるライフサイクルは、どこでも同じ5段階のプロセスです。エクスポートの取得 → 正本データとの照合 → 明細ごとの料率／段階制の検証 → 重複排除 → ロック → 支払い。

リリース日までに12項目すべてを確認できない場合。 番号は依存関係の順序であり、優先順位ではありません。限られた時間を有効に使うには、1時間あたりに検出できるエラー数を基準に、ゲートの優先順位を決めてください。

• 効率性：重複排除（6）＞照合と比較可能性（3-4）＞ライフサイクル期間（8）＞レート／ティアの再計算（7）＞通貨、税、しきい値（9）
• 価値：照合と比較可能性（3-4）＞重複排除（6）＞レート／ティアの再計算（7）＞ライフサイクル期間（8）＞通貨、税、しきい値（9）
• 工数：レート／ティアの再計算（7）- コードを使えば1時間、手作業なら1週間 ＞ 照合（3-4）- 整ったエクスポートなら1時間、乱雑なものなら1～2日 ＞ ライフサイクル期間（8）＝通貨、税、しきい値（9）- それぞれ1時間、日付計算とチェックリストが必要 ＞ 重複排除（6）- キーセットに対してコードを使えばほぼゼロ
• コンプライアンスコスト：通貨、税、しきい値（9）- 有効な税務書類のない受取人への支払いは、金銭上の問題だけでなく、申告上の問題です ＞ 作成者と確認者によるチェック（12）- 承認記録は、外部統制テストで求められる証拠です ＞ その他のゲートはすべて＝なし。これらの誤りは申告ではなく金銭的な損失につながるためです。

作成者と確認者によるチェック（12）は、決して省略してはいけないゲートです。日程調整と2人目の確認者が必要ですが、これがなかったために、否定例のすべての誤りがそのまま反映されました。

この順序では、レート／ティアの再計算が後回しになります。算術を伴うゲートの中で最も価値が高く、手作業では最もコストがかかるものです。次の場合は、最初に実施する項目に繰り上げてください。

• パートナーがティアに異議を申し立てている
• 実行期間が遡及適用されるブレークポイントをまたいでいる
• 期間の途中で仕組みが変更された

この順序はデフォルトであり、絶対的なルールではありません。実施者によっても変わります。ネットワークから機械可読なログをすべてエクスポートできる場合は、（6）と（7）の手間がほぼゼロになり、両方の優先順位が上がります。請求システムにアクセスできない場合は（3-4）が実施できず、（7）が監査全体の中心になります。

1. 実行範囲を確定します。 実行 ID、期間の開始日と終了日、タイムゾーン、日付基準（取引日、検証日、修正日）、通貨、重要性のしきい値、およびすべてのデータソースを記録します。範囲が曖昧な場合は、停止して解決します。後続のすべてのチェックがこの範囲に依存します。
2. 指定された日付基準でエクスポートデータを取得します。 同じ期間のプラットフォーム／ネットワークのコンバージョンエクスポートと、社内の信頼できる情報源から抽出したデータを取得します。アップロードされたスプレッドシートまたは CSV を分析できる場合は、両方を読み込みます。それができない場合は、ユーザーに行数、合計値、および読み上げる特定の行を尋ねます。
3. 比較可能性のゲート。 2 つの数値ソースを比較または合算する前に、同じイベント定義、日付基準、時間範囲、タイムゾーン、通貨、カウント方法、および重複排除用の ID を共有していることを確認します。不一致があれば、まず正規化するか、定義を添えて数値を並べて報告し、合計の計算は行いません。詳細は references/reconciliation-and-dedup.md を参照してください。
4. 合計を信頼できる情報源と照合します。 行数と金額を比較します。プラットフォームのエクスポートデータと、請求／注文／CRM のデータを照合します。合格＝合計が重要性の範囲内で一致しています。不合格＝差異があり、承認前に行ごとに説明する必要があります。「十分近い」で済ませることはありません。
5. 例外キューを処理します。 安定した ID のみで照合し、一方のシステムに存在して他方には存在しないレコードを確認します。
   • プラットフォームに存在し、請求に存在しない：過剰なクレジット付与の可能性があるため、保留して調査します。
   • 請求に存在し、プラットフォームに存在しない：未追跡の売上です。パートナーから異議申し立てが来ることを想定し、クレジット付与の方針を明示的に決定します。
6. 重複を排除します。 コンバージョンごとに決定的なキーを 1 つ使用します（注文 ID／取引 ID／サブスクリプション ID）。空または形式不正のキーは隔離します。二重トラッキング（プラットフォームのピクセル＋社内トラッカー）は、正規のソース 1 つにまとめます。前回の実行に同じキーがないことを確認します。期間をまたぐと二重に支払うことになります。
7. 行ごとにレートとティアを検証します。 取引時点で有効だった条件を使い、生データから期待されるコミッションを再計算します。ティアの算定方法と境界演算子、パートナー種別の上書き、開始日時と終了日時に対するプロモーション期間、新規顧客の適用条件、サブアフィリエイトの上書き、旧条件の適用を確認します。コードを実行できる場合はすべての行を再計算します。それができない場合は、サンプル行を手作業で再計算します。計算方法は references/rate-and-tier-verification.md を参照してください。
8. 行ごとにライフサイクル状態を検証します。 すべての行で、検証／ロック期間が終了しているか、明示的にリリースされている必要があります。期間内の返金／解約による取り消しは、すでに反映されている必要があります。ロック後に発生した返金は、消失させず、次の期間のマイナス調整として記録する必要があります。ルールは references/lifecycle-and-clawback.md を参照してください。
9. 通貨、丸め、税金、およびしきい値を検証します。 FX の適用日は方針に一致していること、最後に小数点以下 2 桁に丸めること、しきい値未満の残高は繰り越すこと、実行対象のすべての受取人について税務書類が保管されていることを確認します。詳細は references/currency-tax-and-payment.md を参照してください。
10. カバレッジ方法を選択します。 1 時間あたりに見つかるエラー数の多い順です。
    • 効率：全件再計算 ＞ リスクベースの層化抽出 ＞ 高額報酬者のスポットチェック
    • 価値：全件再計算 ＞ リスクベースの層化抽出 ＞ 高額報酬者のスポットチェック
    • 工数：リスクベースの層化抽出 — 設計に 1 時間、その後、大量データでは手作業で 1 週間 ＞ 高額報酬者のスポットチェック — 1 時間 ＞ 全件再計算 — スクリプトの作成に 1 時間、以降の各実行ではほぼゼロ
    • ここでは工数と価値の関係が逆転します。最も徹底した方法は、スクリプトさえあれば最も安価であり、積み重ねて改善できる唯一の方法です。完全で機械可読なエクスポートデータに対してコードを実行できる場合に限り、この方法を選択できます。それができなければ選択肢から外れ、リスクベースの層化抽出が最適です。
    • リスクベースの層化抽出＝高額の行、取り消しの多いパートナー、および高額報酬者（少数のパートナーがコミッションの大部分を占めます）を 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 E コマースの完成例、および否定例は、references/audit-report-examples.md を参照してください。

是正：各指摘事項への対応

エラーの発見は、簡単なほうの半分です。対応の優先順位は、名目上の金額ではなく、費やす労力とパートナーとの関係資本あたりに回収できる価値で決めます。

1. リリース前に訂正する。 該当行を再計算し、処理を修正して、正しい金額を支払います。全額を回収でき、関係への影響もありません。パートナーが誤った金額を目にすることもありません。該当行が未払いなら、これをデフォルトの対応とします。
2. 今後のコミッションと相殺する。 訂正分を、パートナーの次回の収益から差し引く、次期のマイナス調整として計上します。該当行の支払い後は、これをデフォルトの対応とします。全額を回収できますが、パートナーが収益を得続ける場合に限られます。
3. 損失として受け入れ、記録する。 該当行を損失処理し、その金額を指摘事項として記録します。重要性基準を下回る場合に誠実な対応として選ぶ段階であり、マイナス残高のまま取引を終了したパートナーに対して残された唯一の選択肢です。
4. 今後の仕組みを修正する。 検証期間を延長する、準備金や留保金を設ける、共有の冪等性キーを導入する、またはエラーではなく構造的な価格設定の誤りである場合にパートナーの料金体系を再交渉します。この実行分からは何も回収できませんが、エラーの種類そのものをなくします。
5. 直接回収する。 過払い分をパートナーに請求します。回収できるかは不確実であり、関係を終わらせる可能性がある唯一の段階です。

• 効率性：リリース前に訂正する ＞ 相殺する ＞ 損失として受け入れ、記録する ＞ 今後の仕組みを修正する ＞ 直接回収する
• 回収額：リリース前に訂正する ＝ 相殺する ＞ 直接回収する ＞ 損失として受け入れ、記録する ＝ 今後の仕組みを修正する
• 労力：直接回収する ― 請求、財務、法務との調整に1週間から1四半期 ＞ 今後の仕組みを修正する ― 構築に1～2日、その後は継続的なタスク ＞ 相殺する ― 1時間。プラットフォームがマイナス残高を処理できる場合はほぼゼロ ＞ リリース前に訂正する ＝ 損失として受け入れる ― ほぼゼロで、それぞれ1回の編集のみ
• 関係資本：直接回収する ＞ 今後の仕組みを修正する ＞ 相殺する ＞ リリース前に訂正する ＝ 損失として受け入れる ― パートナーに何も求めないため、消費する関係資本はありません
• コンプライアンスコスト：直接回収する ― 契約の解釈と法務の承認が必要で、送付後は取り消せません ＞ 相殺する ― 公開済みの規約で認められている必要があります。また、複数のプラットフォームでは、支払済みのコミッションは一切回収できないと明記されています ＞ 今後の仕組みを修正する ― パートナーへの通知を伴う規約の改定 ＞ リリース前に訂正する ＝ 損失として受け入れる ― なし

同順位の根拠：

• リリース前の訂正と相殺：どちらも該当行の100％を回収でき、違いはタイミングだけです。

• 損失として受け入れることと、今後の仕組みを修正すること：どちらもこの実行分からは何も回収できず、その後に得られるものだけが異なります。

• リリース前の訂正と損失として受け入れること：どちらも編集は1回で、パートナーには何も求めません。

• 順位を下げるのではなく、選択肢から外す。今回の実行分がすべて未払いなら、2、3、5は代替案ではありません。選択肢から外して、訂正します。規約またはプラットフォームが支払済みコミッションの回収を禁じているなら、相殺と直接回収を選択肢から外します。残るのは、損失として受け入れることと今後の仕組みを修正することだけです。

• この順序で後回しになるのは、今後の仕組みの修正です。価値は高いものの、今回の実行分からは何も回収できないため、どの比較でも負けます。同じ種類の指摘事項が2回連続の実行で発生した場合、またはロック後の返金が例外ではなく日常的になった場合は、ただちに最上位にします。

• 不正行為の審査へのエスカレーションは、段階の一つではありません。これは別の問いに答えるものであり、どの段階を選んだ場合でも並行して進めます。

• この順序はデフォルトであり、絶対的なものではありません。実行者によっても変わります。すでに把握していることを踏まえて、順位を付け直します。

  • プラットフォームがマイナス残高をネイティブに扱えるなら、相殺の順位を上げます。
  • 今回のサイクルで財務の共同承認者がいないなら、今回の実行分では直接回収を選択肢から外します。
  • 全件を再実行できるほどパートナーの数が少ないなら、本来は相殺するところもリリース前の訂正に戻します。

合格基準と KPI

以下の3つすべてを満たした場合にのみ、実行は合格です。満たすまで修正してチェックを再実行するか、実行の保留を推奨してください。

• すべての行が正しい情報源と照合されているか、例外リストに記載されていること。未説明の不一致がないこと。
• 再計算した合計と提示された合計の未説明の純差異が、重要性のしきい値以下であること。
• リリース時に未解決のブロッカー指摘がゼロであること。

実行ごとに以下を追跡してください。

• 支払精度：再計算値が提示値と一致する行の割合。
• 例外額：実行総額に占める割合。
• 取消・クローバック率：計画上の基準範囲との比較。CPA ではおよそ2～8％、レベニューシェアでは3％未満（監査済みデータではなく、ベンチマークの範囲です）。範囲を超えた場合は、検証期間を延長するか、適格条件を厳格化してください。
• 支払後修正率：支払い後に判明した修正の割合。
• 異議申立て率と異議申立ての解決時間。

B2B SaaS と B2C eコマース

基本方針は同じです。保留中 → 承認済み → 確定済み → 支払済みのライフサイクル、比較可能性の判定、重複排除キー、例外キュー、サンプリング、作成者と承認者の分離は、どちらにも同じように適用されます。同じ手順で両方を監査してください。実際に異なる点は3つだけです。

• 取消のトリガー。 B2C：返品期間内の注文返品、チャージバック、またはキャンセル。B2B SaaS：トライアルから有料プランへの移行失敗、返金、ダウングレード、または期間途中の解約。
• 継続性。 B2C の CPA は注文ごとに1回支払われます。B2B のレベニューシェアは請求のたびに繰り返し発生します。日割り計算、アップグレード／ダウングレード、シート数の拡大、12か月上限と生涯適用のルールにより、サイクルごとに新たな行の検証が必要になります。
• 正しい情報源との連携。 B2B SaaS プラットフォームは多くの場合、請求システムを直接読み取るため、プラットフォームのデータは請求データそのものです。そのため、チェック4はスポットチェックに簡略化できます。B2C ネットワークはピクセルを介して独自に追跡するため、完全な照合作業が引き続き必須です。

これ以外の違いを作り出さないでください。2つを別々の業務として扱っても、エラーをより多く発見できるわけではなく、作業が重複するだけです。

失敗モード

失敗	発生する理由	対処
ティア境界の1つずれ	限界報酬を遡及方式（またはその逆）として計算している、境界で >= ではなく > を実装している、遡及方式の急激な段差が誤差を拡大する	すべての境界線で両方の解釈を再計算し、記載された構造と照合して、演算子を修正します
ソース間で注文 ID が重複している	プラットフォームのピクセルと社内トラッカーが同じコンバージョンを記録している	コンバージョンごとに正規ソースを1つにし、冪等性キーを共有して、各キーにつき1回だけ支払います
重複排除キーが不正または空である	取引 ID が空欄だと、多数のコンバージョンが1つのレコードにまとめられるか、記録されなくなります	空欄または不正なキーを隔離し、合計を計算する前に手作業で解決します
連続する2つの期間でコンバージョンが計上されている	エクスポートが重複している、または締め日時点で期間をまたいでいる	期間を半開区間として設定し、今回の実行のキーと前回の実行のキーとの差分を確認します
エクスポートの日付基準が誤っている	エクスポートでは取引日、検証日、修正日を選択できるため、選択を誤ると明細が実行間で移動します	実行範囲で日付基準を宣言し、その基準に従って再取得します
締め日時点でタイムゾーン境界を誤っている	プラットフォーム、請求システム、プログラム事務局がそれぞれ異なる時刻を使用している	範囲内でタイムゾーンを1つに定め、締めを適用する前にすべてのタイムスタンプを正規化します
返金期間を無視している	検証期間が終わる前に明細が承認されるため、返金が取り消しとして反映されない	期間内のすべての明細を保留し、取り消し曲線に合わせて期間を設定します
レコードのロック後に返金が発生する	ロック済みまたは支払済みの明細は、プラットフォーム上で取り消せない	次の期間にマイナス調整として計上し、マイナス残高を将来の収益に充当します
現在の条件で再計算している	販売後に料率が変更されている。一部のプラットフォームでは、変更された明細を本日時点の条件で再評価する	元の取引日時点で有効だった契約条件に基づいて再計算します
通貨の丸め誤差	何百件もの少額明細で、各ステップの丸めが累積する	各ステップではなく最後に小数第2位まで丸めます。重要性基準を超える誤差があれば、丸め方針を監査します
最低額未満の残高が通知なく破棄される	最低支払額の基準が繰越ではなく除外として適用されている	最低額未満の残高が次回の実行に繰り越されることを確認します。残高が消失してはなりません
税務書類の登録前に支払いが実行される	支払先の登録が省略されているか、書類の期限切れが見落とされている	書類が未提出または期限切れの支払先については支払いを停止し、毎回の実行で再確認します

呼び出し例

• 「今月の報酬支払いをリリースする前に監査してください。840行、支払い予定額は61Kドルで、プラットフォームのエクスポートと請求データのエクスポートを添付しています。」
• 「2社のアフィリエイトから、前四半期のコミッションについて異議がありました。その支払いを再監査し、段階制の料率が限界部分に適用されたのか、全体の取引量に適用されたのか教えてください。」
• 「ネットワークのエクスポートと注文データベースの金額に、約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 - 1回ごとの監査ではなく、プログラムの継続的な指標を確認するため