与信限度はSAPに入っている。与信リスク区分も設定してある。それでも、出荷が止まった案件がその日のうちに動いているなら、与信管理は機能していない。止まらないのではない。止まったものが、誰かの手で開けられている。 開けている人の名前と、開ける根拠が残っているかどうかで、この仕組みは監査に耐える統制にも、月次の作業にもなる。SAPの側は、どちらにでも設定できるように作られている。 以下、保留を解除する担当者の決まり方、限度額の外にある抜け穴、限度額改定の仕組みを順に確かめる。
解除しているのは人ではなく、マスタに書かれた担当者である
誰が与信アナリストになるかは、得意先マスタの側で決まっている。
SAPの与信管理ロール（UKM000）でビジネスパートナーを開き、関係（Relationships）に 「Is Processed in Credit Management」 というカテゴリの関係を登録すると、参照先のビジネスパートナーがそのパートナーのアナリストまたはアナリストグループになる。この関係は、一つの与信セグメントに限定することも、すべての与信セグメントに有効とすることもできる。 アナリストは与信限度使用率リストの選択条件としても使える。
ここが運用設計の最初の分岐になる。アナリストを営業担当に紐づけた会社では、保留を解除する人と、出荷を急いでいる人が同一人物になる。 SAPは何も違反していない。設定どおりに動いている。この一件を決めていない会社は、決めていないという事実を、マスタの登録を見るまで自覚しない。
保留を解除できる人は、得意先マスタに登録した関係で決まる
権限の側も分離されている。SAPは、与信管理へのアクセス権を 与信セグメントとアクティビティごとに、権限オブジェクト F_UKM_SGMT で制御する と書いている。アクティビティの定義は、追加・作成（01）、変更（02）、表示（03）、削除（06）、変更履歴の表示（08）、そしてリリース（43） の六つである。リリースが独立した番号を持っている。 DCDの表示と処理そのものは、Case Managementコンポーネントの権限オブジェクト S_SCMG_CAS 等で制御される。
つまりSAPの標準では、与信マスタを見る権限、直す権限、そして解除する権限が、別々の番号として最初から分かれている。 一つのロールにまとめて配ることもできるし、分けることもできる。標準ロール SAP_FIN_FSCM_CR_USER は、この権限オブジェクトのすべての権限を持って提供される。導入時にこのロールをそのまま営業部門へ配った会社では、解除権限も一緒に配られている。
リリースは独立した番号で、標準ロールには最初から含まれている
与信の抜け穴は、限度額ではなくマスタの「チェック例外」にある
与信が機能していない会社を調べると、限度額そのものは意外にきちんと入っている。抜けているのは別の場所である。
SAPの与信管理には チェック例外（Check Exception） という仕組みがある。設定ガイドはこう書いている。「For the info category Check Exception, SAP delivers three info types … This means that you can temporarily deactivate up to three check steps in a check rule for a business partner without having to define a new check rule.」 新しいチェックルールを定義することなく、特定の得意先について、チェックルールの中のチェックステップを最大三つまで一時的に無効化できる。そして、既存のエントリを基に追加すれば、三つを超えて無効化することもできる。
設定する場所は、得意先マスタである。与信管理ロール（トランザクションBP）でパートナーを呼び出し、与信プロファイル（Credit Profile）タブの追加情報の Relevant 列でチェックボックスを選択または解除する。 有効期間を指定でき、情報タイプは複数登録するためのカウンタになっている。チェックが省略されるのは、現在日付が例外の有効期間内にあり、かつチェックルールのカスタマイジングで Consider Check Exceptions 指標が設定されている場合である。
この欄の意味は明確である。限度額を一円も動かさずに、その得意先についてだけ与信チェックを外せる。 限度額の変更なら変更履歴が残り、承認ワークフローの対象にもできる。チェック例外は、得意先マスタの一項目として、限度額とは別の権限で触られている可能性がある。
同種の穴がもう一つある。担保と与信保険である。SAPは、Statistical Check of Credit Limit Utilization または Dynamic Limit Check with Credit Horizon というチェックステップにおいて、限度額との比較を行う前に、与信エクスポージャーが担保および与信保険の金額の分だけ減額されるとしている。条件は、カスタマイジングで Consider Collateral または Consider Credit Insurance の指標が設定されていること、現在日付が担保または与信保険の有効期間内にあること、そして関連性指標が設定されていることである。担保の登録を営業側で運用している会社では、実効的な与信枠が、限度額の表示より大きくなっている。
チェック例外と担保・与信保険は、限度額を動かさずに与信枠を広げる
逆方向の道具もある。与信セグメントデータのブロック指標である。ブロック指標が設定された与信勘定、すなわちパートナーと与信セグメントの組み合わせに対する与信チェックは、常に否定的な結果になる。ブロック理由を入れておけば、与信チェックのログに表示される。 限度額をゼロにするのではなく、この指標を使う。限度額をゼロにする運用は、後で誰かが元に戻したときに、元の水準が分からなくなる。
与信が機能しているかどうかは、限度額の水準と、解除・例外の権限の所在という二軸で決まる。
限度額の引上げは、SAPが二重統制として設計している
限度額の改定を稟議で処理している会社は多い。SAPには、そのための仕組みが最初から入っている。
設定ガイドは、権限の組み方を整理した表の中で、F_UKM_SGMT のアクティビティ43の用途を 「Release and reject credit limit changes/increases requested (dual control principle)」 と説明している。二重統制の原則という言葉が、製品文書に明記されている。 要求された限度額の変更・引上げをリリースし、または却下する権限が、それ専用のアクティビティとして切られている。
仕組みの中身はこうである。ルールで定めた率を超える引上げが、手動または自動処理（例として一括変更が挙がっている）で行われた場合、引き上げられた値は Credit Limit フィールドへ即座には反映されず、Credit Limit Requested フィールドに入る。同時にワークフローアイテムが生成され、その要求の内容と、ビジネスパートナー保守へのアクセスが提供される。適切な権限を持つユーザーだけが、要求された限度額を受け入れる（限度額に反映される）か、却下することができる。
そして、設定を忘れたときの挙動が書かれている。「An empty entry is interpreted as 0%, that is, in this case, each credit limit increase requires approval.」 空欄は0％と解釈され、その場合はすべての限度額引上げが承認を要する。つまり、しきい値を設定していない会社は、全件承認になるはずである。 ならないのは、この Credit Limit Change Requested のイベント種別に対するフォローオンプロセス、すなわち Check Request for Limit Change と Start Workflow が定義されていないからである。イベントと後続プロセスを定義していない限り、ルールも承認も発火しない。 与信の設定を「マスタと限度額」だと理解して導入した会社では、この定義が空のまま本番に入っている。
後続プロセスを定義しない限り、限度額の引上げに承認はかからない
限度額の改定を、年一回の稟議から外す
限度額が古いままだと、権限をどれだけ正しく分けても運用は元に戻る。正常な取引が毎日止まるからである。改定を人の判断から外す道具も、標準の中にある。
SAPの与信管理は、イベントとフォローオンプロセスの組み合わせで動く。設定ガイドが例示している定義はこうなっている。ビジネスパートナー保守（MAIN）でスコアが無効（Score Invalid）になったらスコアを決定する（EVL_RATING）、スコアが変更された（Score Changed）ら与信リスク区分を決定する（EVL_RISK_C）。 与信チェック（REQUEST）の側では、スコアが変更されたらパートナーの全勘定の与信限度を決定し（EVL_LIMITS）、与信リスク区分を決定する（EVL_RISK_C）。与信限度が無効（Credit Limit Invalid）になったら、その勘定の与信限度を決定する（EVL_LIMIT）。
スコアの入力になるのが、支払行動サマリ（Payment Behavior Summary）である。イベント種別として、督促データ無効（VD）、期日データ無効（VO）、支払データ無効（VP）、支払行動指数無効（Payment Behavior Index Invalid、VX） が用意されている。入金の遅れ、期日の状況、督促の履歴が変われば、スコアの再計算が起動する。 さらに、負の与信事象（negative credit events）を有効期間・削除日・情報タイプ付きで登録でき、スコアや与信限度の算式では NEGATIVE_CHARS 関数でその存在を判定できる。 SAPは、この関数を使ってそうしたパートナーに悪いスコアを割り当てるのが通常の使い方だと書いている。
入金実績と滞留の状況から限度額を再計算する仕組みは、追加開発ではなく設定である。 年一回、営業から提出された更新申請を経理が審査するという運用を続けている会社は、標準機能で済む作業に人手を割いている。
支払行動の変化をイベントにつなげば、限度額は設定だけで再計算される
グループ与信も押さえておく。Superordinate Credit Account From / Subordinate Credit Account To という関係を登録すると、あるビジネスパートナーに対する与信チェックで上位の与信勘定もチェックされ、チェックは複数の階層にまたがりうる。 子会社ごとに限度額を配っている取引先グループでは、この階層を組まない限り、グループ全体の与信残高は見えない。
外から入る信用情報と、止めた後の回収をつなぐ
S/4HANAの与信管理（FIN-FSCM-CR）は、旧来のFIの与信管理（FI-AR-CR）と違い、外部のシステムや情報とつなげるように作られている。SAPはS/4HANAへの移行の整理で、FI-AR-CRはS/4HANAでは提供されず、機能として対応するのはSAP Credit Managementだとしている（SAP Community「Simplification Item: SD / FIN Credit Management」）。ここまでの権限と限度額の話は社内の情報で完結していたが、仕組みの側は社外の情報を受け取れる。
国内には、外部の信用情報をつなぐ取り組みを発表した例がある。2020年3月23日、帝国データバンク、SAPジャパン、BASFジャパンの3社は、SAP Credit Managementと帝国データバンクの企業情報データベースをAPIで連携させ、取引先の信用度の判断を効率化すると発表した。BASFジャパンは同年4月から利用を始める予定とした（BASFジャパン ニュースリリース）。
外部の評点をスコアの入力に加えると、限度額の再計算は、自社への入金の遅れだけでなく、取引先そのものの信用状態の変化でも動くようになる。自社への支払が遅れる前に、取引先の業績や信用状態の悪化を拾えるのが、外部情報を入れる意味である。 自社の取引データで兆候をつかむ設計と組み合わせれば、二方向から網を張れる（取引先の倒産は決算書の与信では防げない、自社の取引データで兆候をつかむ）。ただし、外部の評点をどの頻度で取り込み、評点の変化をどのイベントにつなぐかは、先に見たイベントとフォローオンプロセスの定義の中で決める。取り込んだだけでは限度額は動かない。
回収の側では、保留を解除した得意先のその後を誰が追うかが問題になる。SAPには回収業務のワークリストを管理するCollections Managementがあり、与信管理と同じFSCMの中に置かれている（SAP Learning「SAP Collections Management プロセスの概説」）。解除を判断する与信アナリストと、督促をかける回収担当が別の部署にいると、解除の根拠になった「来週入金予定」という営業の説明は回収担当に届かない。DCD（文書化された与信判断）に書いた解除理由を、回収の担当が見られる状態にしておく。入金予定日を理由に解除したなら、その日を過ぎても入金がないときに、次の出荷を止める判断へ戻れる。督促を営業と経理のどちらが持つかという分担は別稿で扱った（売掛金の督促は営業と経理のどちらが担うか、経過日数で担当を移す設計）。
与信管理で決めておく三つのこと
第一に、DCDの起票と、解除の承認を、別の人格に置く。 SAPは Documented Credit Decision を、法的な理由から与信判断を文書化する義務に対応する仕組みとして説明しており、解除は「My Documented Credit Decisions」のワークリストで、与信アナリストとして割り当てられた人物が行う。割り当ては得意先マスタの「Is Processed in Credit Management」関係で決まるため、決めるべきは権限設計ではなくマスタの登録ルールである。 営業に任せるのはDCDの起票までとし、リリースは権限オブジェクト F_UKM_SGMT のアクティビティ43で分離する。
第二に、チェック例外と担保・与信保険の欄を、限度額と同じ統制下に置く。 チェック例外は、新しいチェックルールを定義せずに、特定の得意先についてチェックステップを一時的に無効化できる。担保と与信保険は、限度額との比較の前に与信エクスポージャーを減額する。どちらも限度額の数字を動かさずに与信枠を広げられるため、限度額だけを承認対象にした統制は素通りされる。 変更履歴のレビュー対象に、この二つを加える。
第三に、限度額の改定をイベント連動に切り替える。 支払行動サマリの督促データ・期日データ・支払データ・支払行動指数のイベントからスコアを再計算し、EVL_LIMITS・EVL_LIMIT で限度額を更新する。あわせて、限度額引上げのしきい値ルールと、Credit Limit Change Requested に対する Check Request for Limit Change・Start Workflow のフォローオンプロセスを定義する。設定していなければ空欄は0％と解釈され全件承認になるはずだが、イベント定義がなければワークフロー自体が起動しない。 定義したうえで、しきい値を意図して置く。
売上高760億円の産業機械商社で、S/4HANAへの移行と同時に旧来の与信管理（FI-AR-CR）から新しい与信管理（FIN-FSCM-CR）へ切り替えた。移行から二年目の内部監査で、与信保留の解除件数が年間で1,940件、うち当日中に解除されたものが1,710件という数字が出た。解除の理由コードは全件が「営業判断」で、内容の記載があるものは一割に満たなかった。 調査の起点になったのは、ある得意先に対する売掛の滞留が四か月を超えているのに、出荷が一度も止まっていなかったことである。原因は限度額ではなかった。その得意先のビジネスパートナーマスタの与信プロファイルに、チェック例外が二件、有効期間を三年後に設定した状態で登録されていた。 登録者は営業事務の担当者で、四年前の一時的な出荷対応のために設定し、そのまま期限を延長し続けていた。マスタの変更履歴には残っていたが、レビューの対象が限度額の変更だけだったため、誰も見ていなかった。是正は三段で行った。第一に、権限の切り分けである。標準ロールをそのまま配っていた営業部門のロールから、F_UKM_SGMT のアクティビティ43を外した。あわせて、与信プロファイルのチェック例外と担保・与信保険の登録権限を、営業事務から債権管理課へ移した。 担保の登録権限を移す際に、既存の登録内容を全件洗い直したところ、有効期限が切れているのに関連性指標が立ったままの与信保険が十一件見つかっている。第二に、アナリストの割り当てを直した。それまで「Is Processed in Credit Management」の関係は登録されておらず、解除は権限を持つ全員のワークリストに流れていた。得意先を売上規模で三層に分け、上位層は債権管理課長、中位層は債権管理課の担当二名、下位層はセグメント単位でグループを割り当てた。第三に、限度額の改定である。それまでは年一回、営業部門から提出される更新申請を債権管理課が審査していた。これを、支払行動サマリのイベントからスコアを再計算し、EVL_LIMITS で限度額を更新する設定に切り替えた。同時に、限度額引上げのしきい値を10％と定め、Credit Limit Change Requested に対するフォローオンプロセスを定義した。 定義前は、しきい値を空欄にしていたにもかかわらず承認ワークフローが一度も動いていない。イベントと後続プロセスが未定義だったためである。切り替え後三年目の実績は、与信保留の発生件数が年2,830件、解除が2,060件、却下が340件、残りが得意先側の入金や条件変更で自然解消したもの。当日中の解除は510件まで下がったが、これは解除が遅くなったのではなく、そもそも止まる件数のうち正常な取引の割合が減ったためである。 限度額をイベント連動にしたことで、取引が伸びている得意先の枠が自動的に上がるようになり、営業から「毎日止まる」という苦情が消えた。債権管理課長の総括はこうである。権限を締めた最初の半年が一番きつかった。解除が遅いという苦情が毎日来る。それを人を増やして捌こうとすると必ず折れるので、限度額の更新を自動にする設定を先に終わらせるべきだった。 順序を逆にしたことが唯一の反省だと言っている。
※設例。会社、数値は説明のために置いた架空のもので、特定の会社の実績ではない。
