取引先から届く支払通知書を読み取り、支払額・振込手数料・相殺の内訳を入金予定の台帳にそろえて、消込の前に請求との差額を理由付きで出す

処理の起点を決める

Google Apps Script の時間主導型トリガーで、数分おきに取込フォルダを見ます。 時間主導型のトリガーは、毎分から月1回までの間隔で動かせるとされています。通知書は月末の支払日の前後に集中して届くため、1日1回の定時実行にはしません。 まとめて処理すると、説明できない差額が見つかるのが締めの直前になり、営業担当が得意先に問い合わせる時間が残りません。

入る経路は3つです。郵送の紙をスキャンしたもの、メールに付いたPDF、FAXを複合機でPDFにしたものです。メールのPDFは、経理の共有アドレスに届いたものを Gmail のラベルで分け、Apps Script が添付を取込フォルダへ移します。どの経路も同じフォルダに入れ、そこから先は区別しません。

1回の実行で処理する枚数に上限を置きます。 Apps Script の1回の実行は6分までとされています。Document AI と Gemini API を1枚ずつ呼ぶと1枚に数十秒かかることがあるため、1回に5枚までとし、残りは次の実行に回します。 処理が終わったファイルは処理済みフォルダへ移し、移すのは台帳への書き込みまで成功したときだけにします。

入力データを集める

質を決めるのは、下の2つです。 様式メモがなければ、「貴社伝票No.」が自社の請求書番号なのか得意先の検収番号なのかを、AIが毎回推し量ることになります。区分表がなければ、「協力会費」「安全協力費」「有償支給材」がどこに入るかが通知書ごとに揺れます。

過去に出た差額の理由は、照会の材料として持ちます。 ただし、過去の理由を今回の差額の理由として使うことはしません。 「この得意先はいつも手数料を引く」を根拠に、書かれていない差額に手数料と付けるのは、第3章の（b）をそのまま機械にやらせることになります。

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

読み取りは、Apps Script から Document AI の処理のAPIを呼ぶだけです。ファイルを渡すと、Document という形の応答が返ります。

金額は、信頼度とあわせて取ります。 「38,500」と「36,500」の違いは、差額の理由をまるごと変えます。信頼度の低い金額は、その行を needs_review にして人に回します。

台帳はスプレッドシートを読むだけで足ります。 引く順は、請求書番号が先、得意先コードと金額が後です。番号が書かれていない通知書に限り、得意先・請求額・検収月の組で候補を出します。候補が2つ以上あれば選ばず、unmatched にします。

AIへ渡す前に整形する

1. 形式の確認 … Form Parser の対象は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP です。それ以外は PDF にします
2. ページ数の確認 … 同期処理は15ページまでです。別紙の控除明細を含めて15ページを超えるものは、バッチ処理に回します
3. 解像度の確認 … 公式には、OCRの精度のためにスキャンは最低200dpiが望ましいとされています。FAXは200dpiを下回ることが多いので、受信時の設定を確かめます
4. 圧縮の確認 … JPEG のような非可逆の形式は、強く圧縮すると精度が落ちることがあるとされています。複合機の保存形式は PDF にします
5. 得意先の推定 … メールの送信元や、ファイル名、1ページ目の見出しから得意先を推定し、様式メモを引きます
6. 別紙の結合 … 本紙と控除明細が別のファイルで届いた得意先は、同じ支払日のものを1組にします
7. 重複の検知 … 同じ得意先・支払日・支払額のものが直近にあれば、既処理として印を付けます

3番目と6番目を軽く見ないでください。 FAXの数字はつぶれやすく、「8」と「6」と「0」の読み違いが差額に直結します。別紙を本紙と組にしないと、控除の内訳がそっくり抜け、すべての差額が unexplained になります。

AIに処理させる

させるのは、通知書の各行を区分に仕分けし、書かれた金額と請求書番号を転記することだけです。

右端の列が、この構成でいちばん大事な区別です。 金額だけがマイナスで書かれ、何の控除か書かれていない行を、fee や discount に入れさせません。other に入れて原文の語を残し、人が見ます。

2行目がいちばん起きやすい失敗です。 差額が3,850円で、通知書に何も書かれていないと、AIは「振込手数料と思われる」と書いて fee を作ります。その瞬間、照会すべき差額が消えます。

指示内容を固定する

あなたは経理部門で、得意先から届いた支払通知書を読み、
入金予定の台帳に転記するための下書きを作る立場です。
OCRが返した読み取り結果だけを見てください。推測で埋めないでください。

【やること】
通知書に書かれている行を1行ずつ、次の区分に仕分けてください。
- payment ... 請求ごとの支払額
- fee ....... 「振込手数料」「送金手数料」と明記された控除
- offset .... 相殺（有償支給材の代金、買掛金との相殺、立替金の精算）
- discount .. 値引、返品、数量減、品質不良による控除
- other ..... 上のどれにも当たらないもの、または何の控除か書かれていないもの
迷ったときは other を選んでください。

【厳守事項】
- 金額は通知書に書かれた数字をそのまま amount に入れてください。
  合計に合わせて明細を直すこと、計算して埋めることをしないでください。
- 請求額との差額を計算しないでください。差額の理由を推測しないでください。
- 「手数料」と書かれていない控除を fee にしないでください。
  金額が手数料らしく見えても、書かれていなければ other です。
- 請求書番号は読み取った文字列をそのまま invoice_ref に入れてください。
  桁を補う、似た番号に直すことをしないでください。読めなければ空にします。
- 控除や相殺の行には、通知書の原文の語を label にそのまま写してください。
- 得意先の様式メモは、どの欄を見ればよいかの手がかりとしてだけ使ってください。
  過去に出た差額の理由を、今回の行の区分の根拠にしないでください。
- 支払通知書でない書類（請求書、納品書、案内文）と判断した場合は、
  仕分けをせず document_type に種類を書いてください。

【読み取り結果】{ocr_result}
【得意先の様式メモ】{vendor_note}
【区分表】{category_table}

「差額の理由を推測しない」と「手数料と書かれていなければ other」を両方書いているのは、片方だけでは止まらないからです。 前者だけだと、理由は書かないまま行の区分を fee にします。後者だけだと、区分は other にしても note に「手数料と思われる」と書きます。禁じるのは、書かれていないことを根拠にした仕分けそのものです。

出力形式を固定する

Gemini API の構造化出力で、次の形のJSONに固定して受け取ります。 公式には、指定したJSONスキーマに従う応答を生成させられるとされ、enum で値の候補を限り、required で必須の項目を決められます。

{
  "document_type": "payment_advice",
  "customer_name": "",
  "payment_date": "",
  "total_paid": 0,
  "lines": [
    { "category": "payment | fee | offset | discount | other",
      "invoice_ref": "", "label": "", "amount": 0,
      "confidence": 0, "evidence": "" }
  ]
}

1つ目の理由は、AIの仕事と計算の仕事を別の層に置けることです。 lines はAIが埋め、差額と状態は Apps Script が計算して付けます。

2つ目の理由は、スキーマに合っていても値が正しいとは限らないことです。 公式にも、出力は構文として正しいJSONでも、値はアプリケーションの側で必ず検証するよう書かれています。Apps Script では、lines の payment の合計が total_paid と一致するかを最初に確かめ、一致しなければ全行を needs_review にします。

3つ目は、label と evidence で確認が速くなることです。 other の行に「安全協力費」と原文が残っていれば、画像を開く前に何の控除かが分かります。

システムへ連携する

台帳に書き込むのは、内訳と状態の列だけです。 請求額や入金予定日の列には触れません。消込の印を付けるのも人です。 この構成が出すのは消込の材料までで、販売管理システムの売掛金を動かすのは既存の手順に任せます。

照会文の下書きは、unexplained の行にだけ作ります。 宛先は得意先ではなく自社の営業担当です。得意先に直接問い合わせるかどうかは、取引の関係を知っている営業担当が決めます。

人が確認する

人が開くのは explained 以外の行と、金額の大きい行だけです。 explained のものは一覧で件数と得意先を流し見ます。全件を開く設計にすると、第10章の20.0時間には収まりません。

1. needs_review を先に見る … 金額と請求書番号を画像で確かめて直します。多くはFAXの読み違いです
2. unmatched の行を台帳と照らす … 合算の支払か、分割の支払かを見て、行を手で結びます
3. unexplained の差額を見る … other の行の原文を読み、区分を直すか、照会に回すかを決めます
4. 高額の行を抜き取りで見る … explained でも、1行の支払額が基準を超えるものは画像と突き合わせます
5. 区分を直したら記録する … どの行を、どの区分からどの区分へ変えたかを残します

3番目を省かないでください。 unexplained の差額は、回収すべきお金か、得意先との取り決めの食い違いのどちらかです。 手数料として処理すれば一覧からは消えますが、問題は残ります。

目標は、300枚をならして1枚4分です。 開くのは3割前後という想定で、それより多い月は、様式メモが古くなっているか、FAXの解像度が下がっています。

例外に対処する

上から3行目までが大半を占めます。 どれもAIの問題ではなく、紙の様式と受け取り方の問題です。 得意先にPDFでの送付を頼むほうが、読み取りの精度を上げるより効きます。

記録を残す

• 元の通知書のファイルと、受け取った日時・経路（紙／PDF／FAX）
• Document AI が返した Document のJSONの全文
• Gemini API に渡した様式メモと区分表の版、返ってきた lines
• Apps Script が計算した差額と状態、そのとき照合した台帳の行
• 人が区分や行の結び付けを直した記録
• 照会文を送った日時と、営業担当からの回答

区分を直した記録は、様式メモを育てる材料になります。 同じ得意先で other から offset に直す行が毎月出るなら、その語を区分表に足すか、様式メモに書き足します。