取引先から届く「支払がまだ」「金額が違う」の問い合わせメールに、支払データと請求書の受付記録から状況を調べて回答の文面を作る

処理の起点を決める

共有メールボックスへの着信を起点にします。 1日に何回かまとめて処理すると、月末の支払日の直後に問い合わせが積み上がり、返信が翌日以降になります。 1通ずつ動かします。

動かすのは、支払の問い合わせだけです。 共有メールボックスには請求書そのものや、請求書の送付の連絡も届きます。件名と本文から ChatGPT が問い合わせの種類を判定し、not_inquiry なら何もせずに終わります。 請求書の受付は別の仕組みの仕事です。

同じ取引先から同じ件で2通目が届いたときは、1通目の下書きと同じ一覧の行にまとめます。 返信の前に2通目が届くと、別々の下書きができて、片方だけに返信して片方が残ります。

入力データを集める

質を決めるのは、2行目の「取適法の対象か」と、5行目の検収日です。 取適法の対象となる取引では、物品等を受領した日から起算して60日以内に定めた支払期日までに全額を支払わないと違反になるとされています。対象かどうかと受領の日が分からないと、問い合わせが支払の遅れにあたるかを分けられません。

取適法の対象かどうかは、購買部門が取引先マスタに記録しておきます。 この構成が判断するものではありません。列が空の取引先は、対象として扱います。

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

取引先は、送信者のメールアドレスのドメインで引きます。 署名の会社名から引くと、表記ゆれで引けないことがあります。ドメインが複数の取引先に当たる場合（グループ会社が同じドメインを使うなど）は、本文の会社名で絞り、絞れなければ担当者へ回します。

請求書は、取り出した手がかりで受付台帳を引きます。 引く順番を決めておきます。

3行目と4行目は、候補が1件に絞れないことがあります。 その場合は下書きを作らず、候補の一覧を担当者に渡します。候補のどれかを選んで文面を作ると、別の請求書について答えることになります。

支払データと検収の記録は、受付番号と発注番号でつなぎます。 受付台帳に発注番号の列が無いと、検収日を引けません。最初の準備は、受付台帳に発注番号を必ず入れる運用にすることです。

支払データと検収の記録は、夜間の書き出しを使います。 問い合わせの多くは「昨日が支払日だったのに入っていない」というもので、前日までの支払が書き出しに入っていれば答えられます。 当日の振込の状況は書き出しに入らないため、支払日の当日に届いた問い合わせは、記録の上で scheduled のまま判定されます。その場合は文面に「本日お支払いの予定です」とは書かせず、担当者が銀行の振込の記録を見て直します。

AIへ渡す前に整形する

1. 引用部分を除く … 返信の引用（「>」で始まる行や、過去のやり取り）を除きます。過去の金額が手がかりとして取り出されるのを防ぎます
2. 署名を除く … 署名の電話番号や住所は使いません
3. 全角・半角をそろえる … 請求書番号と金額の表記をそろえます
4. 取引先の特定を先に行う … ChatGPT に渡す前に取引先コードを決め、本文を渡すときは取引先コードと一緒に渡します
5. 添付は渡さない … 請求書の写しが添付されていても、この構成では読みません。添付があることだけを一覧に書き、担当者が開きます

1番目を軽く見ないでください。 取引先が何度もやり取りしたメールに返信してくると、引用部分に前回の金額や前回の請求書番号が残っています。それを手がかりとして取り出すと、前回の請求書の状況を答えることになります。

AIに処理させる

ChatGPT にさせることは2つで、呼び出しも2回に分けます。

2回の間で、規則が状況を判定します。

escalate にする条件は、文面を作る前に規則で決めます。

どこで「60日に近づいている」とするかは、自社で決めます。 本記事では検収日から45日を過ぎたものを例にしています。取適法の対象となる取引では、受領した日から起算して60日以内に定めた支払期日までに全額を支払わないこと、発注時に決めた代金を中小受託事業者の責に帰すべき理由が無いのに減額することが、それぞれ禁止されているとされています。 この2つにあたるおそれのある問い合わせを、整った文面で流さないための条件です。

指示内容を固定する

1回目（取り出し）の指示：

あなたは経理部で、取引先からの支払に関する問い合わせを受け付ける立場です。
渡すメールの本文から、次の項目を書かれているとおりに取り出してください。

- inquiry_type：not_paid（支払がまだ）／amount_diff（金額が違う）／
  schedule（支払予定日を知りたい）／other（支払に関するその他）／not_inquiry（問い合わせではない）
- invoice_no：取引先の請求書番号。書かれていなければ空
- amount：請求額。書かれていなければ空
- target_month：対象の月。書かれていなければ空
- claimed_received：取引先が受け取ったと書いている入金額。書かれていなければ空

【厳守事項】
- 書かれていない項目を推測で埋めないでください。
- 引用部分（過去のやり取り）に書かれた番号や金額は使わないでください。
- 金額はカンマを除いた数字だけにしてください。計算はしないでください。

【取引先】{vendor_name}
【メール本文】{mail_body}

2回目（文面）の指示：

あなたは経理部の担当者として、取引先への回答の文面の下書きを作ります。
渡す「状況」と「記録の値」だけを使って書いてください。

【厳守事項】
- 記録の値に無い日付・金額・予定を書かないでください。
- 状況が scheduled のときだけ支払予定日を書いてください。それ以外の状況で予定日を書かないでください。
- 状況が returned のときは、差戻しの理由と差戻しの連絡日を書き、再送の方法を案内してください。
- 状況が not_received のときは、請求書が当社で確認できていないことを伝え、
  送付先と送付日を教えてもらうよう依頼してください。
- 状況が diff_explained のときは、記録にある内訳（振込手数料、相殺）だけを書いてください。
- 差額の理由を推測しないでください。
- 支払の遅れを認める表現や、遅延の理由の説明を書かないでください。
- 文末に担当者の名前は入れず、{signature} と書いてください。

【状況】{status}
【記録の値】{record_values}
【取引先名と問い合わせの要旨】{vendor_name} / {inquiry_summary}

「状況が scheduled のときだけ支払予定日を書く」を明記しないと、承認待ちの請求書にも「〇月末のお支払いを予定しております」と書きます。 締め日と支払日の規則から、予定日をもっともらしく導くためです。承認待ちの請求書は、承認されなければその日に支払われません。

「支払の遅れを認める表現を書かない」は、遅れを隠すための制約ではありません。 遅れのおそれのある問い合わせは escalate で人に回っており、文面の下書きが作られるのは、記録の上で遅れていないものだけだからです。 そこに「遅くなり申し訳ありません」と書かれると、事実と違うことを認める文面になります。

出力形式を固定する

1回目は次の形のJSONで受け取ります。

{
  "inquiry_type": "not_paid | amount_diff | schedule | other | not_inquiry",
  "invoice_no": "",
  "amount": "",
  "target_month": "",
  "claimed_received": ""
}

2回目は次の形です。

{
  "subject": "",
  "body": "",
  "used_values": ["payment_date", "paid_amount"]
}

たとえば、状況が returned のときの下書きの本文は次のようになります。

いつもお世話になっております。お問い合わせの請求書（請求書番号 A-2026-0915、
金額 482,900円）について確認いたしました。

本請求書は、9月18日に当社より、請求書に発注番号の記載が無い旨をご連絡し、
差し戻しております。発注番号を記載のうえ、あらためてお送りいただけますでしょうか。
再送いただいた請求書は、受付後に通常の手順で処理いたします。

{signature}

このときの used_values は、請求書番号、金額、差戻しの理由、差戻しの連絡日の4つです。本文に出てくる日付と金額がこの4つの値と一致していることを、担当者は記録の一覧と見比べて確かめます。 支払予定日は書かれていません。差し戻した請求書には、まだ予定日が無いからです。

1つ目の理由は、inquiry_type を enum で縛れることです。 5つ以外の言い方で返ってくると、not_inquiry を除く分岐が作れません。

2つ目は、used_values で文面に使った記録の値が分かることです。 担当者は、文面に出てくる日付と金額が、記録の一覧のどの値から来ているかを確かめられます。 used_values に無い日付が本文に出てきたら、その下書きは使いません。Power Automate で、本文中の日付と金額が記録の値と一致するかを機械的に確かめることもできます。

3つ目は、件名と本文を分けて下書きに渡せることです。 件名には取引先の請求書番号を入れさせ、2通目の問い合わせが届いたときに同じ件として見分けやすくします。

システムへ連携する

受付台帳にも会計システムにも書き込みません。 差戻し中の請求書が再送されてきても、受付台帳の状態を直すのは受付の担当者の仕事です。

人が確認する

担当者は、調べた記録の一覧を先に開きます。

1. escalate を先に見る … 理由ごとに、購買部門・承認者・上長に確かめます。取適法の対象で日数がたっているものを最優先にします
2. 下書きの日付と金額を、記録の一覧と見比べる … used_values と本文が合っているか
3. 候補が1件に絞れなかった問い合わせは、請求書を選んでから下書きを作り直す
4. 文面を直して送る … 言い回しは直してよいが、日付と金額は記録の値から変えない
5. 送った文面と、直した箇所を一覧に残す

目標は、240件をならして1件6分です。 支払済みと支払予定の問い合わせは記録と見比べて数分、escalate のものは確かめに時間がかかります。escalate が月に1割を超えるなら、承認の滞りか、検収の記録の漏れが増えています。

例外に対処する

上の3行が大半を占めます。 どれもAIの問題ではなく、取引先マスタと受付台帳の整い方の問題です。 ドメインと発注番号の列を埋めるほうが、指示文を直すより効きます。

記録を残す

• 問い合わせメールの本文と、受け付けた日時
• 1回目の取り出しの結果
• 規則で判定した状況と、そのとき引いた記録の値（受付台帳の状態、支払日、検収日）
• escalate の理由と、確かめた相手と結果
• 2回目の下書きと、担当者が送った文面、直した箇所
• 返信までにかかった時間

3つ目で記録の値を残すのは、回答の根拠を後から示せるようにするためです。 取引先から「前回はこう回答された」と言われたとき、その時点の記録で何と判定したかが残っていれば、説明が食い違った理由が分かります。

escalate の記録は、毎月まとめて購買部門と見ます。 同じ承認者のところで止まる請求書や、検収の記録が漏れがちな部署が分かります。