財務部が取引先ごとの入金の履歴から Python で翌月の入金の遅れの兆しを予測し、金額と確率で並べた確認の優先度の一覧を出す

処理の起点を決める

毎月15日の22時に動かします。 月の前半の入金の消込が終わり、翌月に期日の来る請求が出そろった時点です。翌月末の期日まで2週間以上あるので、営業が取引先に事情を確かめる時間が残ります。 締め日と支払日が自社と違う場合は、翌月の期日の2週間前になるよう日を決めます。

月末の期日の5営業日後にも、もう一度動かします。 こちらは予測ではなく、実際に入金が無かった請求と、15日の一覧で順位が低かったのに遅れた請求を並べるためです。外れた先を見ることが、次の月の項目と基準を直す材料になります。

消込の作業が終わっていない日は、動かしません。 消込の途中で書き出すと、まだ消し込んでいない入金がすべて「未入金」に見え、履歴の項目が一斉に悪く出ます。 消込の担当が「当日分の消込を終えた」と記録してから書き出します。

入力データを集める

質を決めるのは、仮受金の記録です。 名義違いや手数料引きで消し込めなかった入金が、いつ入っていて、後でどの請求に消し込んだかが残っていれば、本当の入金日を作れます。後で消し込んだ請求番号が空のまま残っている仮受金は、担当者に回して結びつけてもらいます。

休日の扱いの列は、空の取引先を無くします。 空のままだと、期日が休日に当たった月だけ遅れが出て、毎年同じ月に「兆し」が出る取引先ができます。 分からない取引先は、過去の入金で休日に当たった月の入金日を見て、前か後かを埋めます。

連絡の記録は、財務部と営業が受けた連絡を1つの表に集めます。 支払日を変えたい、支払の方法を変えたい、分けて払いたいという連絡は、遅れの前ぶれとしていちばん分かりやすい記録です。 メールや電話のままでは読めないので、日付と区分だけでも表に書きます。

データの取得方法を決める

会計システムからは、請求・入金・消込・仮受金を、決まった列の並びで書き出す設定を作ります。過去の記録は、最初に3年分をまとめて書き出し、その後は毎月の差分を足します。

営業日の数え方には、銀行の休業日の表を使います。 土日と祝日、年末年始の休業日を1つの表にして、期日と入金日の間の営業日の数を数えます。表は年に1回、翌年分を足します。

名義の別名は、仮受金の突き合わせで増やしていきます。 担当者が仮受金を請求に結びつけたとき、その振込の名義を取引先の台帳の別名に足します。別名が増えるほど、翌月から仮受金に置かれる入金が減ります。

AIへ渡す前に整形する

1. 本当の入金日を作る … 消込済みの請求は消込のもとの入金日を、仮受金から後で消し込んだ請求は仮受金に入った日を入金日にします
2. 期日を営業日に直す … 期日が休日のときは、取引先の休日の扱いで前か次の営業日に動かします
3. 遅れを数える … 本当の入金日と直した期日の間の営業日の数を、請求ごとの遅れにします。一部入金の請求は、全額がそろった日で数えます
4. 正解を作る … 遅れが5営業日以上の請求を「遅れた」（1）、それ以外を0にします
5. 履歴の項目を作る … 取引先ごとに、直近3回・6回の遅れの平均と最大、遅れの伸び（直近3回の平均 − その前の3回の平均）、一部入金の回数、仮受金に置かれた回数、名義が変わった回数
6. 取引の項目を作る … 請求額の、取引先の過去12か月の平均に対する比、出荷額の前年同月比、受注残、与信の限度額に対する売掛金の割合、支払の方法、業種
7. 連絡の項目を作る … 直近3か月の支払日の変更・方法の変更・分割の依頼の有無

1番目がこの構成の土台です。 第3章の（a）のとおり、消込の日付で数えると、仮受金に置かれていた日数がそのまま遅れになります。仮受金に入った日を入金日にすれば、取引先は期日どおりに払っていたことになります。

4番目で「5営業日以上」にするのは、1〜2日のずれを拾わないためです。 振込の締めの時刻や、取引先の経理の都合で1日ずれることは珍しくありません。どの日数を遅れとするかは、財務部と営業で決めて、規程に合わせます。

AIに処理させる

させるのは、翌月に期日が来る請求ごとに「5営業日以上遅れて入金される確率」を出すことだけです。 並べ替え、理由の印、営業への依頼の判断は、決まった計算と人で行います。

理由の印を、モデルの中身から作らないのは、1社ずつの説明に使えないからです。 permutation_importance は全体としてどの項目が効いているかを示しますが、この取引先の確率が高い理由を教えてはくれません。 印は担当者が読んで確かめられる事実だけで作り、印の無いまま確率だけが高い先は model_only として、担当者が履歴を開いて確かめます。

4行目を守らないと、正解がゆがみます。 金額が近いからと仮受金を請求に機械で結びつけると、別の取引先の入金を消し込んだことになり、その取引先の遅れが消えます。 結びつけは人が行い、結びつけた記録だけを本当の入金日に使います。

指示内容を固定する

この構成は生成AIを使わないので、プロンプトの代わりに、モデルの設定と計算の規則を書いておきます。

【正解】
- y = 1 … 本当の入金日が、営業日に直した期日から5営業日以上後（一部入金は全額がそろった日）
- y = 0 … それ以外
- 学ばせる請求 = 期日が過去3年以内で、本当の入金日が確定したもの
- 仮受金に入ったまま請求に結びついていない入金のある取引先の請求は、学ばせる記録から外す

【モデル】
- HistGradientBoostingClassifier(loss="log_loss", class_weight="balanced",
                                 early_stopping="auto", random_state=0)
  ・業種、支払の方法は pandas の Categorical にする
- 記録の分け方（期日の順）
  ・学ばせる = 期日が古い方から 30か月
  ・較正     = 次の 3か月
  ・確かめ   = 直近の 3か月
- 較正 = CalibratedClassifierCV(FrozenEstimator(学ばせたモデル), method="sigmoid")
  ・fit には「較正」の3か月だけを渡す
- 確かめ = 直近3か月で、確率を10の帯に分け、帯ごとの予測の平均と実際の遅れの割合を比べる
- 学ばせ直しは四半期に1回。permutation_importance(n_repeats=5) を「確かめ」の3か月で測り、
  前回から順位が大きく動いた項目を記録する

【並べ方】
- priority = 較正した確率 × 請求額
- over_limit の請求は priority にかかわらず一覧の先頭に置く
- 同じ取引先に複数の請求があれば、取引先ごとに priority を合計して並べる

【印】
- delay_trend / partial / contact / name_change / order_jump … 上の表の条件
- new_customer … 取引の開始から6か月未満（確率は出すが、印として必ず付ける）
- model_only   … 確率が上位10％で、上の5つの印がどれも無い

記録を期日の順に分けるのは、未来の記録で学ばせないためです。 入金の遅れは、景気や業界の動きで時期ごとに増えたり減ったりします。ばらばらに混ぜて分けると、確かめの当たり方が良く出すぎます。 学ばせる・較正・確かめの3つを期日の順に並べ、使うときと同じ条件で確かめます。

較正の3か月を別に取るのは、FrozenEstimator で包んだモデルは fit に渡した記録をすべて較正に使うからです。 学ばせた記録で較正すると、学ばせた記録に当てはまりすぎた確率をそのまま信じることになります。

出力形式を固定する

請求ごとに、次の形のJSONを作り、取引先ごとにまとめた表にして共有フォルダに置きます。

{
  "invoice_no": "",
  "customer_code": "",
  "due_date": "",
  "due_date_business": "",
  "amount": 0,
  "proba_late": 0.0,
  "priority": 0,
  "flags": ["delay_trend | partial | contact | name_change | order_jump | new_customer | model_only | over_limit"],
  "history": { "delay_avg_last3": 0, "delay_avg_prev3": 0, "partial_count_6": 0, "suspense_count_6": 0 },
  "rank_last_month": 0,
  "model_version": "",
  "review": { "asked_sales": false, "sales_note": "", "by": "", "decided_at": "" },
  "actual": { "paid_date": "", "delay_business_days": null }
}

1つ目の理由は、history に印のもとの数を残すことです。 担当者は、delay_trend が付いた理由を、直近3回とその前の3回の遅れの平均で確かめられます。会計システムを開かずに、一覧の上で「本当に伸びているか」が分かります。

2つ目は、rank_last_month で前月からの動きが分かることです。 先月は下の方にいた取引先が急に上がってきたら、確率が上がったのか、請求額が増えたのかを分けて見ます。 金額が増えただけなら、取引が増えたという良い知らせのこともあります。

3つ目は、review と actual を同じ行に残すことです。 営業に確かめてもらった先が、実際に遅れたかどうかが後から並びます。確かめたことで遅れが防げたのか、確かめなくても期日どおりだったのかは、この2つを並べ続けて初めて見えてきます。

システムへ連携する

通知には、取引先の名前と金額を流しません。 流すのは一覧の場所と件数だけです。どの取引先が遅れそうかという情報は、営業の現場に広く出回ると、取引先への態度に出ます。 営業への依頼は、担当者がその取引先の営業の担当だけに伝えます。

営業から返ってきた事情は、一覧の review の欄に担当者が書き込みます。 営業が直接書き込む作りにはしません。一覧を見られる人を財務部に限っておくためです。

人が確認する

担当者が見るのは、一覧の上から50社ほどと、印の付いた先です。 下の方の取引先は、印が無ければ流し見で済ませます。全社を前の方法で見直す運用にすると、第10章の20.0時間には収まりません。

1. over_limit を先に見る … 与信の限度額を超える請求です。確率にかかわらず、与信の担当と相談します
2. 上位の先の印を読む … delay_trend と contact が付いた先は、営業に事前の確認を頼む候補です
3. model_only の先の履歴を開く … 印が無いのに確率が高い先です。履歴を見て理由が分からなければ、頼まずに翌月まで様子を見ます
4. new_customer を見る … 取引の始まったばかりの先は、履歴が短く確率がぶれます。営業の担当に取引の様子を聞きます
5. 依頼したかと事情を書く … review に残します

3番目で、理由の分からない先に連絡を頼まないのは、意図してのことです。 モデルが高い確率を出しても、担当者が事実で確かめられない理由で取引先に事情を聞けば、まじめに払っている取引先に不快な思いをさせます。 事実の印が付いた先から頼みます。

財務部の課長は、四半期に1回、一覧の上位と実際の遅れを並べて見ます。 確率の帯ごとの実際の遅れの割合がずれてきたら、学ばせ直しの時期を早めます。

例外に対処する

上から2行目は、最初の数か月に多く出ます。 仮受金を請求に結びつけたまま記録を残さない運用だった場合、過去の仮受金の多くが宙に浮いています。 一度にすべてを結びつけるのは重いので、請求額の大きい取引先から順に結びつけ、結びついた取引先から学ばせる記録に入れます。

最後の行の取引先は、予測の対象ではなくなります。 法的な手続きに入った先への対応は、債権の届出や回収の手続きで、この一覧で扱うものではありません。

記録を残す

• 書き出した記録の件数、仮受金の結びつけの状態、休日の扱いを埋めた取引先
• 請求ごとの較正した確率、priority、印、前月の順位
• 担当者が営業に頼んだかと、営業から返ってきた事情（review）
• 実際の入金日と遅れの営業日数（actual）
• モデルの版、学ばせた・較正した・確かめた期間、帯ごとの予測と実際の遅れの割合
• 四半期ごとの permutation_importance の結果

4つ目の実際の入金日は、翌月の期日の5営業日後の実行で書き込みます。 予測と実際が同じ行に並ぶので、確率が高かったのに期日どおりだった先、低かったのに遅れた先を毎月数えられます。後者が続く業種や支払の方法があれば、項目を足す場所です。