海外出張の英文の領収書を読み取り、日付・金額・通貨・支払先を精算の明細にそろえて、外貨換算と旅費規程の上限に照らした確認点を出す

処理の起点を決める

経費精算システムで出張者が提出したことを起点にします。 提出された精算の添付を受付の場所（Amazon S3）へ写し、1枚ずつ処理を始めます。月末にまとめて処理しません。 問い合わせは、出張者の記憶が新しいうちに出したほうが早く片づくからです。

1回の出張の領収書は、出張の番号でひとまとまりに扱います。 重複や期間の確認は、出張単位で見ないと分からないからです。出張の番号が付いていない提出は、処理を止めずに check で受け、理由に「出張の番号が無い」と出します。

処理が終わった画像は処理済みの場所へ移します。移すのは、判定の一覧への書き出しまで成功したときだけです。 受付の場所に残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、真ん中の3つです。 出張申請が無ければ国も期間も分からず、規程の上限が表になっていなければ照らせません。国ごとの表が無いと、第3章の（a）と（c）がそのまま機械に移ります。

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

1ページのものは、Lambda から AnalyzeExpense を呼んで結果をその場で受け取ります。 複数ページのPDFは StartExpenseAnalysis で始め、完了の通知を受けて GetExpenseAnalysis で取ります。ClientRequestToken に添付ごとの値を入れ、同じ画像の処理が二重に始まらないようにします。 非同期の JobId は7日間しか有効でないので、完了を受けたらすぐに結果を自社のバケットへ書き出します。

通貨は、読み取りの結果と出張先の国の両方から決めます。 読み取りが USD を返しても、出張先がシンガポールなら check にします。読み取りが返した値を、国の表で上書きはしません。 食い違いとして人に見せます。

カードの支払いは、利用明細と突き合わせます。 利用日・加盟店名・外貨の金額で照らし、一致すれば明細の円の金額を使います。

AIへ渡す前に整形する

1. 形式の確認 … 同期の処理はJPEG・PNG・PDF・TIFF、非同期はJPEG・PNG・PDFが対象です。XFA形式のPDFには対応していません
2. サイズとページ数の確認 … 同期はPDFとTIFFで1ページ・10MBまで。フォリオが2ページ以上なら非同期へ回します
3. パスワードの確認 … パスワードで保護されたPDFは読めません。 航空会社やホテルから届いたものに付いていることがあります
4. 写真の確認 … 読み取れる文字の高さは15ピクセル以上で、150dpiで8ポイントの文字に当たります。感熱紙のレシートを斜めから撮った写真は、この下限に近くなります。 文書の傾きには対応しています
5. 1枚に複数の領収書 … テーブルに並べて1枚で撮ったものは、ExpenseIndex で分けます
6. 日付の正規化 … 国ごとの表の書き方で年月日に直します。元の文字列は残します
7. 重複の検知 … 同じ支払先・日付・金額のものが、同じ出張または直近の精算にあれば印を付けます

6番目はAIに任せません。 「04/05/2026」を生成AIに読ませると、文脈から月と日を推測します。推測が外れても、もっともらしい日付が返ります。 書き方は国ごとの表で決め打ちし、出張の期間の外に出たら check にします。

AIに処理させる

させるのは、明細の行を費目に分け、根拠にした文字列を写すことだけです。 標準の項目の読み取りは Textract が行い、AIは行の意味を判断します。

私的な費用は「候補」として出させます。 ミニバーやランドリーが私的な費用かどうかは、長期の出張でランドリーを規程で認めている会社もあるように、会社の決まりによります。AIには行の意味だけを判断させ、精算から外すかは規則と人が決めます。

4行目と5行目は同じ失敗の裏表です。 フォリオの行の合計が TOTAL と合わないとき、AIに任せるとどこかの行の金額を直して辻褄を合わせます。 合わないこと自体が、読み違いか、明細の抜けの知らせです。

指示内容を固定する

あなたは経理部で、海外出張の領収書の明細を費目に分ける立場です。
渡すのは、OCRが返した標準の項目と明細の行です。そこに書かれたことだけを使ってください。

【書き出すこと】
1. receipt_type: hotel / taxi / rail / air / meal / other / unknown
2. 明細の行ごとの category:
   lodging（宿泊料） / tax_service（税・サービス料） / meal（食事） /
   transport（交通） / personal_candidate（私的な費用の候補） / unknown
3. 宿泊料の行は、行に書かれた日付と金額をそのまま写す
4. 食事の領収書は、人数の記載があれば写す

【厳守事項】
- 書かれていない項目は「不明」としてください。推測で埋めないでください。
- 金額は読み取り結果の文字列をそのまま写してください。
  円に換算しないでください。通貨を決めないでください。
- 行の金額の合計が TOTAL と合わなくても、どの行も直さないでください。
  合わないことを note に書いてください。
- ミニバー、ランドリー、映画、電話などは personal_candidate にしてください。
  精算から外すかどうかは書かないでください。
- 行の意味が取れないものは unknown にしてください。
  近そうな費目に寄せないでください。
- 日付の月と日の順を決めないでください。書かれた文字列のまま写してください。
- evidence には、根拠にした文字列をそのまま写してください。
- 領収書でない書類（予約の確認書、見積など）と判断した場合は、
  費目分けをせず document_type に種類を書いてください。

【標準の項目】{summary_fields}
【明細の行】{line_items}

「予約の確認書」を見分けさせるのは、よく混ざるからです。 ホテルの予約の確認メールやオンラインの予約画面の写しは、金額も日付も書かれていて領収書に見えます。支払った証拠ではないので、明細にしてはいけません。

「近そうな費目に寄せない」を書かないと、unknown がほとんど出ません。 何でもそれらしい費目に入れるので、人が見るべき行が一覧から消えます。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format にJSONスキーマを渡す）を使うと、スキーマどおりの形で返り、必須の項目が欠けません。

{
  "receipt_id": "",
  "trip_id": "",
  "document_type": "receipt",
  "receipt_type": "hotel",
  "vendor": "",
  "date_text": "",
  "total_text": "",
  "lines": [
    { "item": "", "amount_text": "", "date_text": "",
      "category": "lodging", "evidence": "" }
  ],
  "guests": "",
  "note": ""
}

この後に、Python が換算と照合を足します。

1つ目の理由は、換算を規則で行えることです。 法人税の通達では、外貨建取引の円換算は原則として取引日の電信売買相場の仲値（TTM）により、継続適用を条件に費用は電信売相場（TTS）も使え、前月末などの相場も使えるとされています。どれを使うかは自社で決め、決めた1つを規則に書きます。 AIに選ばせると、領収書ごとに違うレートが混ざります。

2つ目は、上限の差額を出せることです。 「上限を超えた」だけでなく「1泊あたり何円超えた」まで出るので、人は差額を見て、問い合わせるかを決められます。

システムへ連携する

明細の書き込みは、経理の担当者が確定した後だけです。 ok の明細も一覧で流し見てから確定します。出張者への問い合わせも、下書きまでにして人が送ります。

人が確認する

人が開くのは check の明細だけです。 理由ごとに見る順を決めます。

1. 通貨と期間外を先に見る … 多くは読み違いで、画像を見れば数秒で決まります
2. 重複を確かめる … 同じ食事を2人が別々に出していないか、同じ領収書を2回出していないか
3. 上限を超えたものの事情を見る … 出張報告に理由が書かれていれば認め、無ければ問い合わせます
4. 私的な費用の候補を分ける … 規程に照らして精算から外すか、認めるかを決めます
5. 判定を覆したら記録する … どの理由を、どう直したかを残します

1番目で読み違いが多い国は、国の表を直す材料です。 同じ国で日付の check が続くなら、その国の書き方の設定が足りていません。

3番目の問い合わせは、出張の単位でまとめて送ります。 1枚ごとに送ると、出張者は同じ出張について何通も返事を書くことになります。理由と差額を並べた1通にし、出張報告に足してもらう形にすると、返事が早く戻ります。

目標は、1,200件をならして1件2分です。 check が2割前後という想定で、それより多い月は、国の表かカードの明細の取り込みに抜けがあります。

例外に対処する

2行目がいちばん多くなります。 感熱紙のレシートは時間がたつと薄くなるので、出張中に撮って提出する運用にするほうが、読み取りの工夫より効きます。

下から3行目は、北米のレストランで毎回のように起きます。 印字されたレシートにチップと合計を手で書き足して署名する形式で、印字の TOTAL と、実際に払った金額が違います。 カードの利用明細の金額と照らせば、どちらが支払った額かが決まります。チップの割合が国の表の慣習から大きく外れていれば、それも理由に足します。

記録を残す

• 元の領収書の画像と、提出した日時・出張の番号・支払方法
• OCRが返したJSONの全文
• AIが返したJSONと、そのとき参照した規程の上限の表・国の表・為替のレート
• 換算に使ったレートと日付、カードの利用明細との対応
• 判定の結果（ok ／ check と理由）と、経理が判定を覆した記録
• 出張者への問い合わせと回答

「そのとき参照した規程の上限の表」を残すのは、上限が改定されるためです。 改定の前に行った出張を後から見直すとき、当時の上限で判定したかどうかを確かめられます。