売上請求書を発行する前に、契約・注文と突き合わせて請求漏れと金額違いを見つける

処理の起点を決める

毎月18日の朝8時を起点にします。月末の発行作業に入る前に、確認と修正の時間を確保するためです。

Google Apps Script には、スクリプトを時刻で起動する「時間主導型トリガー」があります。1分おきから月1回まで指定できます。公式ドキュメントには「実行時刻は多少ばらつく。午前9時の定期トリガーを作ると、午前9時から10時の間で実行時刻が選ばれる」と明記されています。分単位で正確に動かす必要がある処理には向きません。 今回は朝の時間帯に走ればよいので問題ありません。

月1回だけにせず、月半ばと月末前の2回走らせる構成を勧めます。1回目で見つかった差異を営業に確認し、2回目で直っているかを見ます。

入力データを集める

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

販売管理システム： APIがあればそれを使います。無い場合は、CSVエクスポートを所定のフォルダに置く運用にして、スクリプトがそれを読みます。リアルタイム連携は不要です。 月2回しか走らない処理なので、前日の夜にエクスポートしておけば足ります。

契約管理シート： Google スプレッドシートであれば SpreadsheetApp でそのまま読めます。Excelの場合は、Google ドライブに置いて変換するか、Power Automate 側で読みます。

CRM： 契約ステータスだけが必要です。案件全体を取る必要はありません。「解約予定」「プラン変更予定」のフラグが立っている取引先の一覧が取れれば十分です。

利用実績： 従量課金の数量です。ここは自社サービスの管理画面から取ります。この値は請求金額に直結するため、集計の定義（締め日、カウント単位）を先に文書化してください。 定義が曖昧なままだと、差異が出たときにどちらが正しいか誰にも分かりません。

AIへ渡す前に整形する

1. 取引先名の名寄せ … 販売管理システムと契約シートとCRMで、同じ取引先の表記が違うことがあります。取引先コードで突き合わせられるなら、それを使います。コードが無いシートには、先にコード列を足してください。名寄せをAIに任せないほうが安全です
2. 対象期間の絞り込み … 今月の請求対象だけに絞ります。契約終了日が前月末の契約は、今月の請求対象から外れているのが正しい状態です
3. 金額の型をそろえる … CSVから読むと「1,200,000」のような文字列になります。カンマを外して数値に変換します
4. 差異の計算 … ここまでをスクリプトで済ませます。契約単価と請求単価の差、契約数量と請求数量の差、契約期間と請求期間のずれを、それぞれ数値として出します
5. 突合できなかった行の分離 … 契約はあるが請求予定が無い、請求予定はあるが契約が無い、の2種類に分けます。この2つが一番重要な指摘です

AIに処理させる

スクリプトが出した差異の一覧を渡し、次を行わせます。

適格請求書の記載事項は、国税庁が6項目を示しています。 書類作成者の氏名または名称および登録番号、取引年月日、取引内容（軽減税率の対象品目である旨）、税率ごとに区分して合計した対価の額および適用税率、税率ごとに区分した消費税額等、書類の交付を受ける事業者の氏名または名称です。多くの販売管理システムはこれを満たす形で出力しますが、手で作った請求書や、備考欄で調整した請求書では欠けることがあります。 ここをチェック項目として持たせます。

指示内容を固定する

あなたは経理の売掛金担当を支援する担当者です。
今月の請求予定と契約情報の突合結果を渡します。
各差異について、原因の候補と重要度を付けてください。

【厳守事項】
- 金額、数量、単価を計算し直さないでください。
  渡された差異の値をそのまま引き継いでください。
- 原因は候補として挙げるだけです。断定しないでください。
  根拠が契約情報にない推測は cause に書かず、
  needs_confirmation に「営業に確認すべきこと」として書いてください。
- 請求漏れ（契約が有効で請求予定が無い）は、金額の大小にかかわらず
  severity を high にしてください。
- 契約終了日が請求期間の途中にある場合、日割りが必要かどうかは
  判断せず、needs_confirmation に入れてください。
  日割りの要否は契約書の条項によります。
- 適格請求書の記載事項（登録番号、取引年月日、取引内容、
  税率ごとの対価の額と適用税率、税率ごとの消費税額、交付先の名称）
  のうち欠けているものを missing_invoice_fields に列挙してください。

【突合結果】
{diff_rows}

【契約情報】
{contract_rows}

【契約ステータス（CRM）】
{crm_status}

「金額を計算し直さない」の1行が重要です。 差異の計算はスクリプトが済ませています。AIに再計算させると、渡した値と違う数字を返すことがあり、どちらが正しいか経理が判断できなくなります。

出力形式を固定する

{
  "findings": [
    {
      "invoice_draft_id": "",
      "customer_code": "",
      "customer_name": "",
      "finding_type": "amount_mismatch | quantity_mismatch | period_mismatch | missing_invoice | no_contract | field_missing",
      "severity": "high | medium | low",
      "contract_value": "",
      "billing_value": "",
      "difference": "",
      "cause": "",
      "needs_confirmation": "",
      "missing_invoice_fields": [],
      "confirmation_message_draft": ""
    }
  ],
  "summary": {
    "checked_count": 0,
    "finding_count": 0,
    "high_count": 0
  }
}

difference は、スクリプトが計算した値をそのまま入れさせます。cause と needs_confirmation を分けているのは、AIが分かることと分からないことを、出力の構造で分けるためです。混ぜて自由文で返させると、推測が事実のように読めてしまいます。

システムへ連携する

指摘一覧はスプレッドシートに書き出します。列は、重要度、取引先、指摘の種類、契約側の値、請求側の値、差額、原因の候補、確認事項、経理の判断（プルダウン）です。

経理の判断を書く列を必ず作ってください。 「修正した」「このままでよい」「営業に確認中」のいずれかを記録します。この列が次の月の入力になります。前月に「このままでよい」と判断した取引先の同じ差異は、翌月は重要度を下げて表示します。そうしないと、日割り契約のように毎月必ず差異が出る取引先の指摘が、毎月上位に居座ります。

修正は販売管理システムの画面で人が行います。スクリプトから販売管理システムへ書き戻す構成にはしません。 請求データを自動で書き換える仕組みは、誤りが起きたときに誰も気づけません。

人が確認する

指摘された件は全件、人が確認します。指摘されなかった件は確認しません。

ここが、この構成で工数が減る理由です。600件すべてを目で見比べる運用から、指摘された20〜40件を見る運用に変わります。そのため、指摘の漏れがそのまま事故になります。

漏れを防ぐ設計を2つ入れます。

• 契約側を起点にする。 請求予定データを1行ずつ見るのではなく、有効な契約をすべて列挙してから、対応する請求予定があるかを見ます。請求予定を起点にすると、そもそも作られていない請求書は最後まで現れません
• 突合できなかった行を必ず出す。 取引先コードが一致しない、契約品目が対応しないといった行は、判定不能として一覧の先頭に出します。ここを空振りとして捨てると、静かに漏れます

営業への確認は人が送ります。生成された確認文はそのまま送れる長さ（3〜4行）にしますが、送信前に必ず読みます。

例外に対処する

記録を残す

• 実行日時と、対象にした請求予定データのスナップショット
• 突合結果（差異の全件。指摘に上がらなかったものも含む）
• AIが付けた原因の候補と重要度
• 経理の判断（修正した／このままでよい／確認中）
• 実際に発行された請求書の内容

最後の2つを突き合わせると、検出の精度が測れます。 「指摘した40件のうち、実際に修正されたのは12件」であれば、28件は無駄な指摘だったことになります。逆に、指摘しなかった件で後から誤りが見つかった場合は、検出条件そのものに漏れがあります。 こちらのほうが重大なので、売上照合で見つかった請求漏れを必ずこのログに戻してください。