通関業者から届く輸入許可通知書を読み取り、申告番号・課税価格・関税・消費税を輸入案件の台帳と会計の入力項目にそろえ、見込みとの差を拾う

処理の起点を決める

Google Apps Script の時間主導型トリガーで、数分おきに通関業者からのメールを見ます。 通関業者のメールには受信のルールでラベルを付けておき、Apps Script はそのラベルの未処理のメールだけを開きます。添付の許可通知書を取込フォルダへ保存したら、メールに処理済みのラベルを付けます。

月末にまとめて処理しません。 差が見つかったときに通関業者へ聞くのは、記憶の新しいうちのほうが早く終わります。

1回の実行で処理する件数に上限を置きます。 Apps Script の1回の実行は6分までとされています。1回に5件までとし、残りは次の実行に回します。 処理済みフォルダへ移すのは、照合結果のシートへの書き込みまで成功したときだけにします。

入力データを集める

質を決めるのは、品目の見込みの列です。 見込みの関税率が無ければ、許可通知書の税率と比べる相手がありません。EPA を使う予定だったかが書かれていなければ、一般の税率で申告されていても「差」として出せません。

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

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

税率と金額は、信頼度とあわせて取ります。 関税率の「3.9％」と「8.9％」の違いは、関税と消費税の両方を変えます。信頼度の低い税率や金額は、その通知書を needs_review にして人に回します。

台帳は、インボイスの番号で引きます。 番号が読めない通知書に限り、仕入先と課税価格の合計で候補を出し、候補が2つ以上あれば選ばず unmatched にします。

AIへ渡す前に整形する

1. 形式の確認 … Form Parser の対象は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP です。添付がそれ以外なら取り込まずに担当者へ知らせます
2. ページ数の確認 … 同期処理は15ページまでです。品目の多い通知書で15ページを超えるものは、バッチ処理に回します
3. 添付の仕分け … 許可通知書と請求書が1つのPDFにまとまっている通関業者があります。ページの見出しの文字で分け、許可通知書のページだけを読みます
4. 解像度の確認 … 公式には、OCRの精度のためにスキャンは最低200dpiが望ましく、300dpi以上が一般に最もよい結果になるとされています。紙で受け取ったものをスキャンする場合に限ります
5. 通関業者の推定 … 送信元のアドレスから通関業者を決め、書式メモを引きます
6. 重複の検知 … 同じ申告番号・許可日の通知書が直近にあれば、既処理として印を付けます

3番目を軽く見ないでください。 請求書には、通関業者が立て替えた関税・消費税の額と、通関料・保管料が並びます。許可通知書の税額と請求書の立替額が同じページに混ざると、通関料まで税額として写ります。

AIに処理させる

させるのは、許可通知書に書かれた数字を、決まった項目と品目の行に写すことだけです。 計算はさせません。

右端の列が、この構成でいちばん大事な区別です。 書かれていない項目を、台帳の値や計算で埋めさせません。特に関税率と為替は、書かれていなければ空のままにします。

2行目がいちばん起きやすい失敗です。 関税率の欄が読み取れなかった通知書を渡すと、AIは関税額と課税価格から率を逆算して埋めます。その瞬間、EPA の税率が適用されていなかったという差が「一致」にすり替わります。

指示内容を固定する

あなたは輸入を担当する部署で、通関業者から届いた輸入許可通知書を読み、
輸入案件の台帳と会計に写すための下書きを作る立場です。
OCRが返した読み取り結果だけを見てください。推測で埋めないでください。

【やること】
1. 書類が輸入許可通知書かどうかを判断してください。
   請求書、通関料の明細、船積み書類など別の書類なら、
   写さずに document_type を other にしてください。
2. 申告の項目（申告番号、許可日、輸入者、仕出人、インボイスの番号、
   換算の為替相場、課税価格の合計、関税・消費税・地方消費税の合計）を写してください。
3. 品目の欄を1行ずつ items に入れてください。
   品名、統計品目番号、数量、課税価格、関税率、関税額を写します。

【厳守事項】
- 数字は書類に書かれたものをそのまま入れてください。
  桁区切りや「円」「％」は外してかまいませんが、値は変えないでください。
- 計算をしないでください。関税率が読めないときに、
  関税額と課税価格から逆算して埋めないでください。書かれていなければ空にします。
- 品目ごとの課税価格が書かれていないときに、合計を割り振らないでください。
- 消費税と地方消費税が合計しか書かれていないときに、内訳に分けないでください。
- 為替相場が書かれていないときに、ほかの値から求めないでください。
- 統計品目番号は読み取った文字列をそのまま入れてください。
  桁を補う、似た番号に直すことをしないでください。
- 関税率が従量（数量あたりの額）で書かれているときは、
  rate_type を specific にし、書かれた文字列を rate_text に写してください。
- 関税分類が正しいか、EPA の税率が使えたかについて書かないでください。
- evidence には、各値の根拠にした文字列をそのまま写してください。

【読み取り結果（キーと値の組、表、全文）】{ocr_result}
【この通関業者の書式メモ】{broker_note}

「逆算して埋めない」と「割り振らない」を分けて書くのは、片方だけでは止まらないからです。 税率の逆算だけを禁じると、品目ごとの課税価格を合計から割り振って埋め、品目ごとの差が見えなくなります。

出力形式を固定する

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

{
  "document_type": "import_permit | other",
  "declaration_no": "",
  "permit_date": "",
  "importer": "",
  "shipper": "",
  "invoice_refs": [],
  "fx_rate": { "currency": "", "rate": null },
  "totals": { "customs_value": null, "duty": null, "consumption_tax": null, "local_consumption_tax": null },
  "items": [
    { "line": 1, "description": "", "hs_code": "", "quantity": "",
      "customs_value": null, "rate_type": "ad_valorem | specific | free | unknown",
      "rate": null, "rate_text": "", "duty": null }
  ],
  "table_status": "complete | partial",
  "evidence": [{ "field": "", "text": "", "confidence": 0 }]
}

1つ目の理由は、AIの仕事と計算の仕事を別の層に置けることです。 JSONはAIが埋め、検算と判定は Apps Script が台帳の見込みで行います。

rate_diff と value_diff には、要素ごとの理由を付けます。 Apps Script は、税率・為替・課税価格を別々に比べ、どれが違うのかを reason に入れます。

検算は公式の数字だけに絞ります。 税関の説明では、地方消費税は消費税額の22/78とされています。この比と、品目の関税額の和が合計と合うかの2つを見ます。 公式にも、構文として正しいJSONでも値はアプリケーションの側で検証するよう書かれています。

システムへ連携する

輸入案件の台帳には書き込みません。 書き込むのは、照合結果と入力用の行だけです。入力用の行は3つの形で出します。 台帳用は申告番号・許可日・税額の合計、原価用は品目ごとの課税価格と関税、会計用は関税・消費税・地方消費税を勘定ごとに分けた行です。同じ値から3つを作るので、写し間違いの入り込む余地がありません。

通関業者への照会メモの下書きは、rate_diff と unexplained にだけ作ります。 申告番号、品目、通知書の税率、見込みの税率、EPA を使う予定だったかを並べます。送るのは物流の担当です。

人が確認する

人が開くのは match 以外の行だけです。 match のものは一覧で件数と案件を流し見ます。全件を開く設計にすると、第10章の10.0時間には収まりません。

1. needs_review を先に見る … 金額・税率・申告番号を通知書の画像で確かめて直します
2. rate_diff を見る … epa_not_applied なら、原産地の証明書を仕入先から受け取っていたか、通関業者へ渡したかを確かめます
3. value_diff の reason を読む … fx_diff は見込みの為替を直すだけで済みます。freight_diff は運賃の請求書と見比べます
4. unexplained を照会に回す … 下書きを直して通関業者へ送ります
5. 会計の入力用の行を確かめる … 経理の担当が勘定ごとの額を見て、会計システムへ入力します

2番目を省かないでください。 EPA の税率が使えたのに使われていなかった差は、その後の同じ仕入先の輸入にも続きます。

目標は、120件をならして1件5分です。 開くのは3割前後という想定で、それより多い月は、品目の見込みの列が埋まっていない案件があります。

例外に対処する

4行目がいちばん手間のかかる例外です。 台帳の側に分割の印が無いと、通知書が届くたびに見込みの半分にしか届かず、毎回 value_diff になります。

記録を残す

• 元の許可通知書のPDFと、受け取った日時・通関業者・メールの件名
• Document AI が返した Document のJSONの全文
• Gemini API に渡した書式メモの版と、返ってきたJSON
• Apps Script が出した状態と理由、そのとき照合した台帳の見込みの値
• 入力用の3つの行と、人が直した記録
• 通関業者に照会した日時と回答

1つ目は、仕入税額控除の書類として残します。 国税庁のページでは、仕入税額控除のために保存する請求書等に輸入許可書等が含まれ、課税標準の額や消費税・地方消費税の額などが記載されたものとされています。どのファイルを原本として保存するかは経理と決め、取込フォルダから消さないでください。

4つ目で「そのときの見込み」を残すのは、見込みが後から直るためです。 当時どの税率と為替で比べたかが残っていないと、どの案件の結果をやり直せばよいかが決まりません。