インセンティブ管理
クリーンデータ → 統制されたワークフロー
同期済み
記録ルール
検証済み
承認
適用済み
監査証跡
完了
ステータス
運用中
1
準備2
承認3
同期4
報告
✓ CRM
✓ 会計
✓ ERP
収益漏れを許容できない財務・RevOpsチームに選ばれています
HHubSpot
SFSalesforce
StStripe
ShShopify
SlSlack
frfreee
承認と監査証跡で統制するインセンティブ（成果報酬）管理
インセンティブ（成果報酬）をスプレッドシートで運用すると、商談の更新、返金、入金タイミングのズレのたびに計算が揺れて、承認や支払の根拠が説明しづらくなります。Sankaは、統制された業務イベントからインセンティブを算出し、承認・差戻し・支払までの履歴を追跡できるように設計されています。
決定論的な計算
受注確定や入金などのイベントから、ルールに基づいて安定的に計算。再計算しても結果がブレにくい設計を目指します。
例外の承認と統制
閾値や条件に応じて、マネージャー／財務へ承認回付。誰がいつ判断したかを履歴として残します。
月次の締めと支払
期間（例：月次）でクローズし、合計をエクスポート。支払済みまでステータスで追跡します。
業務イベントから「ブレない」インセンティブを算出する
プランで、基準イベント、レート、統制ルールを定義して運用します。
- 基準イベント: 受注確定（book）または入金（cash）
- レート: 割合（%）または固定額
- 統制ルール: 下限、上限、対象条件
- 再計算: 安定したキー設計で、締め前の見直しに対応
| よくある課題 | 何が起きるか | Sankaで標準化する観点 |
|---|---|---|
| 計算根拠が追えない | 監査・合意形成が難しい | 入力値、計算結果、承認の履歴 |
| 支払タイミングが揺れる | キャッシュや回収と乖離する | 期間の定義、締めの手順 |
| 返金・取消の扱いが曖昧 | 差戻し（clawback）で揉める | 調整レコード、例外承認 |
返金・取消は「上書き」せず、差戻し（clawback）として記録する
返金のたびにシートを作り直すのではなく、差戻しを明示的な調整として扱うことで、履歴が説明しやすくなります。
- 元の算出結果に紐づく、マイナス調整を作成
- 履歴を追記型にして「いつ、誰が、何を」判断したかを残す
- 締めの再現性を高め、例外対応を統制する
計算だけでなく、統制（ガバナンス）まで
インセンティブは収益と人件費に関わるため、承認と監査証跡が重要です。
権限設計
担当者は自分の範囲、マネージャーはチーム、財務は締め・支払の統制、と役割で分離します。
承認履歴
承認者、タイムスタンプ、理由を残し、支払判断の根拠を説明可能にします。
エクスポート
支払処理に必要な合計値を出力しつつ、明細のトレーサビリティを維持します。
よく使われる運用パターン
受注確定 → 下書き → 承認 → 月次クローズ
受注確定で算出し、月次で承認・締め。運用負荷を下げつつ統制を保ちます。
入金 → キャッシュ連動の成果報酬
入金を基準に算出して、回収と支払のタイミングを揃えます。
返金 → 差戻し（clawback）調整
調整を上書きせずに残し、締めと監査で説明しやすい台帳にします。
よくある質問
受注確定と入金、どちらを基準にできますか？
どちらも可能です。受注確定（book）にするか、入金（cash）にするかは、支払の考え方とキャッシュ管理に合わせて選びます。
例外の承認はどう設計しますか？
閾値や条件に応じて承認者を設定し、承認の履歴を残します。締め前の見直しにも対応しやすくなります。
返金や取消が起きた場合は？
差戻し（clawback）を調整レコードとして扱い、履歴を追記型で残す運用が有効です。
月次の支払一覧は出せますか？
期間でクローズし、合計値をエクスポートして支払処理に利用します。明細の根拠は台帳として追跡できます。
