財務部がでんさいと手形の期日の一覧と口座の残高から、期日の資金の不足を判定し、入金予定の確かさを添えて担当に知らせる

処理の起点を決める

起点は Schedule Trigger です。 毎朝8時半に動かします。担当が残高と期日の一覧を出力し終えた時刻に合わせ、その日の手当てを午前中に決められる時刻にします。

ワークフローのタイムゾーンを必ず設定します。 公式のページでは、ワークフローにタイムゾーンが無ければインスタンスのタイムゾーンを使い、自社で動かすインスタンスの既定は America/New York とされています。期日の計算の「今日」がずれると、今日の期日を明日のものとして数えます。

Schedule Trigger は、ワークフローを保存して公開しないと動きません。 公式のページにそう書かれています。

夕方にもう1回動かします。 午後に入った営業の連絡で、翌日以降の入金の確かさが変わることがあるからです。夕方の回は入金予定の判定と残高の計算だけをやり直し、朝の結果と変わった日と口座だけを知らせます。

ファイルの置き忘れに備えます。 3つの銀行のどれかのファイルが当日の日付でなければ、計算をせずに「出力が古い」と知らせて止まります。 前日の残高で計算すると、昨日の引落しが残高に入っていない数字で「足りる」と出ます。

入力データを集める

質を決めるのは、判定の基準の表です。 何をもって「確定」とするかを、財務部で先に決めて文にします。

受取手形は、基準の上では「見込み」として扱います。 残っている手形は少なくなりましたが、でんさいネットの資料では、2027年度初から電子交換所での手形・小切手の交換が廃止され、それ以降は電子交換所を介さない決済になるとされています。取立の流れが変わる時期の手形は、入金の日がこれまでどおりとは限らないので、取立の口座の銀行に入金の日を確かめるまで確定にしません。 振出人ごとに手形からでんさいへの切り替えの予定を聞いておくと、受取手形の行そのものが減っていきます。

受取のでんさいを「確定」にしても、当日の支払に当てるかは別に扱います。 第3章の（d）のとおり、入金の時刻は決まっていないので、同じ日の受取でしか足りない支払は「当日の受取待ち」として、確定だけで足りる場合と分けて知らせます。

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

ファイルは Read/Write Files from Disk で読みます。 File(s) Selector にはパスか glob のパターンを書けるので、フォルダの下の当日の日付のファイルをパターン1つで取ります。 公式のページでは、n8n 2.0 から読める場所の既定が ~/.n8n-files に絞られており、それ以外を読むには N8N_RESTRICT_FILE_ACCESS_TO をはっきり設定するとされています。ファイルサーバーの共有をマウントした場所を、この変数に指定します。

読み込んだファイルは Extract from File で行にします。 公式のページでは、Extract From CSV と Extract From XLSX の操作があります。銀行ごとに出力の形式が違うので、銀行ごとに枝を分けて読み、列の名前を同じものにそろえます。

メールは、入金予定にひも付けてから渡します。 相手先の名前と金額で、入金予定の行に連絡の本文を寄せます。ひも付けられなかった連絡は、AIに渡さずに担当へ「未ひも付け」として出します。 関係の無い連絡を渡すと、別の取引の「遅れる」を読んで不確かと判定します。

AIへ渡す前に整形する

1. ファイルの日付の確認 … 3行分のファイルが当日の出力かを確かめます
2. 列のそろえ … 銀行ごとの列を、口座・期日・金額・相手先・支払受取の区分にそろえます
3. 金額のそろえ … 「1,234,567」「1234567円」を円の整数にそろえます
4. 期日のそろえ … 期日が銀行の休業日に当たるものは、営業日のカレンダーで決済の日にそろえます
5. 重複の除外 … 同じ記録番号のでんさいが2つのファイルに出たら1つにします
6. 相手先の名前を記号に置き換える … AIに渡すのは、入金予定の番号、金額の桁の区分、予定日、メモと連絡の本文だけにします

4番目を省くと、期日の日付で計算した残高が実際とずれます。 休業日の期日は、計算の上では「その日」の支払でも、口座から動く日は別の日です。どの日にそろえるかは銀行の取扱いによるので、各行に確かめてカレンダーに書いておきます。

6番目で金額そのものを渡さないのは、AIに計算させないためです。 判定に要るのは「この入金を数えてよいか」で、金額ではありません。金額を渡すと、AIが頼まれていない足し算を始めます。

AIに処理させる

させるのは、入金予定の1件ずつについて、判定の基準の表に照らして「確定」「見込み」「不確か」を判定し、根拠にしたメモや連絡の文を写すことだけです。

基準に当たるかが文から決められないときは、「不確か」に倒します。 足りない側に倒すと、担当が営業に1本確かめる手間が増えるだけです。足りる側に倒すと、期日の朝に残高が足りないことが分かります。

指示内容を固定する

Basic LLM Chain の Chat Messages の System に次の文を入れます。

あなたは財務部で、入金予定を資金の計算に数えてよいかを判定する立場です。
渡された入金予定1件について、判定の基準に照らして判定してください。

【判定】
- confirmed ... 基準の「確定」に当たる
- likely ...... 基準の「見込み」に当たる
- uncertain ... 基準の「不確か」に当たる、または文から決められない

【厳守事項】
- 判定の根拠には、メモや連絡の文を一字一句そのまま quotes に写してください。
- 渡されたメモと連絡に書かれていないことを推測しないでください。
  「過去に遅れが無いので大丈夫」「大口の取引先なので確実」などと
  書かないでください。
- 迷ったときは uncertain にしてください。likely を選ばないでください。
- 金額の計算や、残高が足りるかどうかについて書かないでください。
- 振替・借入・割引などの手当てについて書かないでください。
- メモと連絡が食い違う場合（メモは「予定どおり」、連絡は「遅れる」など）は、
  uncertain にし、食い違いを conflict に書いてください。
- 連絡が別の取引のことに見える場合は、その連絡を根拠に使わず、
  notes に「別の取引の連絡の可能性」と書いてください。

【判定の基準】{criteria}
【入金予定】番号：{plan_id}　種類：{kind}　予定日：{due_date}
           予定日の変更の回数：{reschedule_count}
【営業のメモ】{memo}
【財務への連絡】{messages}

「迷ったら uncertain」をいちばん強く書きます。 入金の判定は、外れたときの重さが左右で違います。不確かと判定した入金が予定どおり入れば、担当の確認が1本無駄になるだけです。 見込みと判定した入金が入らなければ、期日の支払が止まります。

「別の取引の連絡かもしれない」を書かせるのは、ひも付けの誤りに気づくためです。 相手先と金額でひも付けても、同じ相手先の別の請求の連絡が混ざることがあります。

出力形式を固定する

Require Specific Output Format をオンにして Structured Output Parser をつなぎ、次の形で受け取ります。

{
  "plan_id": "AR-2026-10-3381",
  "judgment": "confirmed | likely | uncertain",
  "criteria_matched": "不確か：メモに「検収待ち」の記載",
  "quotes": ["11/4 先方検収待ち。月内は難しいかもとのこと（営業）"],
  "conflict": "",
  "notes": ""
}

この後ろに、Code ノードが期日ごと・口座ごとに次を計算します。

1つ目の理由は、AIの判定と計算が混ざらないことです。 判定は入金予定の番号ごとに1行で残り、計算はその判定を入力にした規則で決まります。 判定の基準を変えても、計算の式は変わりません。

2つ目は、quotes で担当が根拠を一目で見られることです。 Slack の知らせに「なぜ不確かなのか」が営業のメモの文のまま載るので、担当は営業に何を聞けばよいかが分かります。

スキーマは $ref を使わずに書きます。 公式のページでは、Structured Output Parser の JSON Schema で参照（$ref）を使えないとされています。

システムへ連携する

不足の知らせは、Slack の Send and Wait for Response で送ります。 Response Type を Approval にし、Capture Who Responded をオンにして、誰が確かめたかを記録に残します。 Restrict Who Can Approve で、答えられる人を資金の担当に絞ります。

銀行の画面とでんさいの画面には、この構成から一切つなぎません。 振替や割引の申込みを自動にすると、判定の誤りがそのまま資金の移動になります。

人が確認する

1. 「要手当て」を先に見る … 確定の入金だけで足りない日と口座です。その日のうちに手当てを決めます
2. 「当日の受取待ち」を見る … 同じ日の受取で足りる計算の日です。手当てをするか、入金の時刻を待つかを決めます
3. 「見込み頼み」の根拠を見る … quotes を読み、営業に確かめます
4. 判定を覆したら記録する … どの入金予定を、どの判定に変えたかを残します

3番目で、営業に確かめた結果を入金予定の表のメモに書いてもらいます。 夕方の回でその文を読んで判定がやり直されるので、確かめた結果が次の計算に入ります。

「要手当て」が出た日は、上席への報告を同じ日のうちに済ませます。 知らせには、日付・口座・不足の見込み額・不足の原因になった支払の明細の上位と、確かさが低い入金の quotes を並べます。上席が知りたいのは「どの支払のために、いくら、いつまでに要るか」なので、その形のまま転送できるようにしておきます。

目標は、600件をならして1件1分です。 知らせの来ない日と口座は見る必要が無く、見るのは知らせの来たものと、不確かと判定された入金だけです。

例外に対処する

2行目で「他の銀行の分だけで計算しない」のは、口座ごとの不足が見えなくなるからです。 1行分が欠けた計算は、その銀行の口座の支払を落としたまま「足りる」と出ます。

6行目で、AIが動かない日は全部を不確かに倒します。 判定が無いからといって見込みとして数えると、いちばん確かめが要る日に、いちばん楽観的な数字が出ます。

記録を残す

• その日に使った3行分のファイルの名前と、読み込んだ日時
• 入金予定ごとの判定（judgment、quotes、conflict）
• 期日ごと・口座ごとの計算の結果と、alert
• Slack での確認と、確認した人、時刻
• 担当が判定を覆した記録
• 実際に入金された日と、判定との突き合わせ

最後の行で、判定の当たり外れを月ごとに見ます。 「見込み」と判定して入らなかった入金、「不確か」と判定して予定どおり入った入金を数え、判定の基準の表を直します。 前者が多ければ基準が甘く、後者が多ければ営業のメモの書き方を見直す材料になります。