決済精算 照合ルール・運用ランブック様式

照合は同じ取引を二つの場所で見つけ出す作業です。そのため最初の欄はルールではなくキーです。注文番号、自社の取引ID、決済事業者の取引ID、承認番号、売上伝票番号のうち何を基準キーとするかを決め、残りはそのキーに紐づく補助キーとして記載します。決済事業者ごとにファイルへ載せる項目が異なるため、どの列がどのキーに対応するかを事業者別に一行ずつ書いておきます。部分取消や分割配送のように一つの注文が複数の取引に分かれる場合は、注文ではなく取引が照合の単位です。通貨、金額の単位、丸めの桁も同じ欄に記載します。ファイルがいつどの経路で届くのか、時刻がどのタイムゾーンで書かれているかも併せて書きます。タイムゾーンが違えば、同じ取引が別の日付に計上されます。

照合ルールは取引の状態に沿って五つの軸に立ちます。承認は自社の注文と決済事業者の承認記録を突き合わせる軸です。売上計上は承認された件が実際に売上へ移ったかを見る軸です。承認だけされて売上計上されていない件がここで表に出ます。精算は決済事業者の精算ファイルにある入金予定額、実際の入金額、手数料を突き合わせる軸です。返金は自社の返金要求と事業者の取消記録、精算で差し引かれた金額をつなぐ軸です。部分取消は元取引の残高が三つの場所で一致しているかを見る軸です。軸ごとに比較する項目、許容誤差、比較の時点を表に記載します。許容誤差は通貨の最小単位と確認済みの計算方法に基づいて定めます。範囲内であることだけを根拠に、欠落や実際の誤りを自動で閉じません。

不一致が出たら、原因を探す前に種別を付けます。時点差、手数料・消費税の計算差、取消反映の遅れ、ファイル欠落、実際の誤りに分けます。どの種別も根拠を確認してから閉じます。時点差は次の周期に再照合し、ファイル欠落は資料を復旧して再比較します。手数料と取消反映も合意したルールに合うかを確認し、未解決の件は担当者に割り当てます。確認の順序も固定します。まずファイルがすべて届いているか、次に基準キーが両側にあるか、その次に金額と通貨が一致するか、最後に状態が一致するかを見ます。この順序を守れば、ファイルが一つ遅れて届いただけの事象を金額誤りと取り違えることが減ります。種別ごとに誰が処理し何日以内に閉じるかも同じ表に記載します。自動で揃える種別と人が見る種別を分ける条件は、ルールに数値で書きます。条件が文章だけで書かれていると、担当者ごとに読み方が変わります。

ランブックは症状から始まります。欄は、症状、最初に開く画面と照会条件、判断の基準、処置、引き継ぐ担当と決済事業者への受付方法、記録の置き場所の六つです。症状欄には担当者が実際に使う言い方を書きます。入金額が精算予定額より少ない、のように書きます。判断の基準欄には、どの値がどの範囲を外れたら事故として上げるかを数値で書きます。処置欄には戻せるものと戻せないものを分けて書きます。返金の実行のように戻せない処置には承認者を併記します。決済事業者への受付は、窓口、必要な情報、回答までの所要時間を事業者別に分けておきます。記録の置き場所欄には、照会した画面と残したメモがどこに蓄積されるかを書きます。同じ症状が翌月また来たときは、その記録から始めます。

照合結果の要約、未処理件数、種別ごとの残件、繰越の理由を一枚に書き、運用と財務がそれぞれ確認します。未処理が残ったまま締めてよい条件も先に決めます。金額の上限、件数の上限、繰越できる日数を書いておけば、毎月同じ議論を繰り返しません。ルールを変えた日と変えた人も同じ文書に残します。どのルールがどの条件で二件をつないだのかが件単位で残っていてはじめて、数か月後の監査で同じ計算をやり直さずに済みます。