海外の仕入先から届く英文のプロフォーマインボイスを読み取り、発注書と品番・単価・数量・支払条件・出荷予定を突き合わせて、送金の前に食い違いを拾う

処理の起点を決める

受付のフォルダ（Amazon S3）にPIのPDFが保存されたことを起点にします。 PIは仕入先の時差で夜間にも届き、送金の締切は仕入先との取り決めで決まっているため、まとめて朝に処理するより、届いた順に読み取っておくほうが確認を早く始められます。

保存の経路は2つ用意します。担当者がメールからPDFを保存する経路と、PI専用の受信アドレスに転送すると添付が自動で保存される経路です。 どちらで入っても、そこから先は区別しません。

読み取りは非同期の呼び出し（StartExpenseAnalysis）で行います。 PIは複数ページになることが多く、同期の呼び出しはPDFが1ページまでという制限があるためです。読み取りが終わったことの知らせを受けて、次の処理を動かします。

入力データを集める

質を決めるのは、3行目の品番の対応表です。 PIに仕入先の品番しか書かれていないと、発注書の行と組にできません。対応表が無い仕入先では、明細の照合がすべて「組にできない」になります。 対応表を仕入先ごとに整えることが、最初の準備作業です。

5行目の過去のPIは、改訂版を見分けるために持ちます。 同じ発注番号でPIが2枚目に届いたら、前の版との違いも一覧に出します。 担当者が「何が変わったのか」を最初に知りたいからです。

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

Textract の読み取りの結果は、ページごとに見出しの項目と明細の行に分かれて返ります。

発注書は、発注番号で基幹システムの書き出しから引きます。 PIの PO_NUMBER が読めなかったときは、仕入先と日付から候補を出して担当者に選んでもらいます。発注番号を推測で決めて照合を進めることはしません。

OTHER の項目は、項目名の文字で拾います。 「Beneficiary」「Bank」「SWIFT」「A/C No.」を含む項目名なら振込先、「Incoterms」「Price Term」「Trade Term」なら取引条件として扱います。項目名の一覧は仕入先ごとに増えていくので、表で持って育てます。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF のいずれかであることを確かめます。XFA の形式の PDF は読めません
2. パスワードの確認 … パスワード付きの PDF は読めません。外してから送ってもらいます
3. 大きさとページ数の確認 … 非同期の呼び出しで PDF は500MB、3,000ページまでです。PIで問題になることはまずありません
4. 文字の大きさの確認 … 文字の高さは15ピクセルが下限で、150DPIで8ポイントの文字に当たります。スキャンし直したPIの小さな注記がこれを下回ることがあります
5. 言語の確認 … 本文が英文でないPIは読み取りに回さず、担当者に戻します
6. 改訂版の確認 … 同じ発注番号のPIが既にあれば、改訂版として前の版と組にします
7. 単位と書き方のそろえ … 「1,200.00」「1.200,00」のような数字の書き方の違い、「PCS」「SET」「KG」の単位を、照合の前にそろえます

7番目を軽く見ないでください。 ドイツの仕入先は小数点にカンマを使うことがあり、「1.200,00」を1.2と読むと、単価が千分の一の行として「大幅な値下げ」と出ます。 仕入先ごとに数字の書き方を台帳に持たせ、そこで読み替えます。

AIに処理させる

させるのは、読み取った値のうち、決まった形にそろえにくいものを、そろえることだけです。 発注書との比べ合わせは、照合のプログラムが行います。

右端の列が、人に回す項目を決めます。 特に no_mapping は、対応表に無い品番がPIに載っているということで、似た型番に替わった可能性があります。 似た品番を推測で当てはめず、そのまま人に回します。

2行目がいちばん起きやすい失敗です。 「AB-1200-S」が対応表に無く、「AB-1200」があると、AIは同じものだろうと引き当てがちです。末尾の「-S」が別の仕様を表しているなら、その時点で替わった品番が見えなくなります。 表記ゆれとしてそろえてよいのは、ハイフン・空白・大文字小文字だけと決めておきます。

指示内容を固定する

あなたは輸入の購買担当として、海外の仕入先のプロフォーマインボイス（PI）を
発注書と比べられる形にそろえる立場です。
OCRが返した読み取り結果だけを見てそろえてください。推測で埋めないでください。

【そろえる項目】
1. payment_terms …… 支払条件の原文を、次に分けてください
   - deposit_percent（前払いの割合）、deposit_timing（前払いの時期）
   - balance_percent（残りの割合）、balance_timing（残りの支払の時期）
   balance_timing は before_shipment / against_bl_copy / after_arrival / other のいずれか
2. lines …… 明細の行ごとに、supplier_part_no（PIの品番）と、
   【品番の対応表】から引き当てた our_part_no
3. shipment …… 出荷予定。日付があれば date、「入金後○日」なら days_after_deposit
4. bank …… 振込先の銀行名、口座番号、SWIFTコード

【厳守事項】
- 支払条件の割合は、原文に書かれた数字だけを使ってください。
  前払いの割合が書かれていなければ、残りの割合から逆算しないでください。
- 品番の引き当ては、ハイフン・空白・大文字小文字の違いだけをそろえてください。
  末尾の記号や数字が違う品番を、同じ品番として引き当てないでください。
  対応表に無ければ our_part_no を null にし、flags に no_mapping を入れてください。
- 数量・単価・金額は読み取った値をそのまま写してください。計算して直さないでください。
- 振込先の口座番号やSWIFTコードは、読み取った文字をそのまま写してください。
  桁を補う、記号を直すことをしないでください。
- 原文の該当箇所を evidence にそのまま写してください。
- 発注書と合っているか、送金してよいかは書かないでください。
- 英文でない部分は読み取らず、flags に non_english を入れてください。

【PIの読み取り結果】{expense_result}
【この仕入先の品番の対応表】{part_mapping}
【この仕入先の数字の書き方】{number_format}

「残りの割合から逆算しない」を書かないと、「balance 70%」から前払いを30%と埋めます。 多くの場合は合っていますが、原文に前払いの割合が書かれていないという事実は、仕入先に確かめるべき点です。逆算させると、その点が消えます。

口座番号を「そのまま写す」のも同じ理由です。 読み取りで1桁欠けた口座番号を、AIが台帳の番号に寄せて補うと、本当に違う口座が書かれていたときに気づけません。

出力形式を固定する

PI1枚ごとに、次の形のJSONで受け取ります。 Claude API の構造化出力を使い、スキーマに沿った形で返させます。

{
  "pi_no": "",
  "revision": "",
  "po_no": "",
  "currency": "",
  "incoterms": "",
  "payment_terms": {
    "raw": "", "deposit_percent": null, "deposit_timing": "",
    "balance_percent": null, "balance_timing": "before_shipment | against_bl_copy | after_arrival | other"
  },
  "shipment": { "raw": "", "date": null, "days_after_deposit": null },
  "lines": [
    { "line_no": 1, "supplier_part_no": "", "our_part_no": null,
      "qty": 0, "unit": "", "unit_price": 0, "amount": 0,
      "confidence": 0, "evidence": "", "flags": ["no_mapping | non_english"] }
  ],
  "bank": { "bank_name": "", "account_no": "", "swift": "", "confidence": 0 },
  "total": 0
}

照合のプログラムは、項目ごとに次の印を足します。

1つ目の理由は、AIのそろえと照合の結果を別の層に置けることです。 lines と payment_terms はAIが埋め、印はプログラムが付けます。取り決めの許容の幅（単価の端数の丸めなど）が変わっても、直すのはプログラムの規則だけです。

2つ目は、構造化出力で形が崩れないことです。 Claude API の構造化出力は、output_config.format に JSON Schema を渡すと、スキーマに合った JSON を返すものです。additionalProperties は false にする必要があり、数値の範囲の制約などは使えません。 値の範囲は照合のプログラムの側で確かめます。なお、AWS の上で Claude を使う場合、構造化出力が使える経路は限られると公式に書かれているため、この構成では Claude API を直接呼びます。

3つ目は、evidence と confidence で確認が速くなることです。 担当者はPDFを開く前に、どの文字を根拠にどの程度の自信で読んだかを一覧で見られます。

システムへ連携する

基幹システムへは書き込みません。 PIの単価が発注書と違っても、発注書を直すかどうかは、仕入先と話したあとで担当者が決めます。

仕入先台帳へも書き込みません。 これがこの構成でいちばん大事な決まりです。振込先の違いを見つけたら、台帳を直す経路ではなく、送金を止める経路に進みます。

人が確認する

人が見るのは、印の付いた項目だけです。 印が line_ok だけのPIは、一覧で合計と前払いの金額を確かめて、送金の依頼に進みます。

1. bank_changed を最初に見る … 送金を止めます。PIやメールに書かれた電話番号ではなく、仕入先台帳にある連絡先に電話して、口座変更の事実を確かめます
2. line_missing・line_added・no_mapping を見る … 品番が替わっていないか、行が落ちていないかを、PIと発注書を並べて確かめます
3. qty_diff・price_diff・terms_diff を見る … 発注のあとで合意した変更かを、仕入先とのやり取りで確かめます
4. revised を見る … 前の版から何が変わったかを見て、送金に使う版を決めます
5. 問い合わせを送る … 下書きを直して、担当者が送ります

1番目は、どんなに急いでいても省かないでください。 口座変更を装った偽の請求は、PIの書式、署名、メールのやり取りまで本物に見えることがあります。 メールの中にある連絡先は偽の側が用意したものかもしれないので、確かめる先は、以前から台帳にある連絡先に限ります。

台帳の口座を直すのは、確かめが済んだあとに経理が行います。 購買の担当者がPIを見て直す運用にはしません。

例外に対処する

上から2行目と6行目が、運用を始めてしばらくの大半を占めます。 どちらもAIの問題ではなく、仕入先ごとの事情と対応表の整備の問題です。 対応表を育てるほうが、読み取りを工夫するより効きます。

記録を残す

• 元のPIのPDFと、受け取った日時、改訂版の番号
• Textract が返した JSON の全文（見出しの項目、明細の行、信頼度）
• AI がそろえた結果と、照合のプログラムが付けた印と、そのとき参照した発注書と仕入先台帳の内容
• 担当者が判断した記録 … どの食い違いを、問い合わせたか・受け入れたか、その理由
• bank_changed の確かめの記録 … 誰が、いつ、どの連絡先に電話して、何を確かめたか
• 仕入先ごとの食い違いの種類と回数

5つ目は、必ず残してください。 振込先の確かめは、後から「本当に確かめたか」を問われる工程です。電話をかけた先が台帳の連絡先だったことまで残します。