受領請求書のPDFを読み取って支払データを作成する

処理の起点を決める

SharePointの受領フォルダにファイルが作成されたことを起点にします。Power Automate の SharePoint コネクタには「ファイルが作成されたとき」トリガーが標準で用意されています。

メール添付を自動でこのフォルダへ保存する部分は、Office 365 Outlook コネクタの「新しいメールが届いたとき」トリガーと組み合わせます。ただし、請求書以外の添付ファイルも大量に届くため、送信元アドレスまたは件名での絞り込みが必要です。専用のメールアドレス（invoice@ 等）を用意して、仕入先にそこへ送ってもらうのがもっとも確実です。

入力データを集める

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

OCR： Azure AI Document Intelligence の prebuilt-invoice モデルにPDFを渡します。このモデルは請求書、公共料金明細、発注書を対象に、取引先名、請求先住所、支払期日、合計金額などの主要項目と明細行を抽出し、構造化されたJSONで返します。対応言語は27言語です。スキャン画像、スマートフォンで撮影した画像、デジタルPDFのいずれも扱えます。

仕入先マスタ： ERPのAPI、または日次でエクスポートしたマスタファイルを参照します。リアルタイム連携は必須ではありません。

過去の仕訳実績： 会計システムから直近12か月の仕訳をエクスポートし、「仕入先コード × 勘定科目 × 部門コード」の出現回数を集計したテーブルを持ちます。これは月1回の更新で足ります。

AIへ渡す前に整形する

1. 複数請求書の分割 … 1つのPDFに複数の請求書が入っていることがあります。ページ単位で請求書番号を検出し、分割します
2. 向きの補正 … スキャンした紙は上下逆や横向きのことがあります。OCRサービス側で自動補正されるか確認し、されない場合は前段で回転させます
3. 重複の検出 … 同じ請求書が再送されることがあります。「仕入先コード＋請求書番号＋金額」で既存データと照合し、重複なら処理を止めます。これを入れないと二重支払いが起きます
4. 請求書以外の除外 … 見積書、納品書、督促状が混ざります。書類種別を判定して振り分けます

AIに処理させる

OCRとLLMで役割を分けます。

OCR（Document Intelligence）にさせること： 文字と項目の読み取り。金額、日付、明細行の抽出。ここはLLMにさせません。専用モデルのほうが精度が高く、費用も安いためです。

LLMにさせること：

指示内容を固定する

あなたは経理の買掛金担当を支援する担当者です。
OCRで抽出された請求書の内容と、仕入先マスタ・過去仕訳実績をもとに、
仕入先コードと勘定科目の候補を付けてください。

【厳守事項】
- 金額、日付、請求書番号を書き換えないでください。
  OCRの抽出結果をそのまま引き継いでください。
- 仕入先マスタに一致する候補がない場合は、新しいコードを作らず
  supplier_code を null にし、reason に理由を書いてください。
- 勘定科目は、過去仕訳実績に存在する組み合わせからのみ選んでください。
  実績にない科目を提案する場合は confidence を low にしてください。
- 税率区分（10% / 8%軽減 / 対象外）は、請求書に明記された表示に従ってください。
  品目名から推測しないでください。
- 判断に迷った項目は needs_review に列挙してください。

【OCR抽出結果】
{ocr_result}

【仕入先マスタの候補（名称の近い上位5件）】
{supplier_candidates}

【この仕入先の過去仕訳実績（直近12か月）】
{past_entries}

「税率区分を品目名から推測しない」の1行が重要です。 軽減税率の判定は、AIが品目名から推測すると誤ります。請求書に書かれた表示に従わせ、書かれていなければ人に回します。税額の誤りは、後から修正申告の対象になります。

出力形式を固定する

{
  "supplier_code": "",
  "supplier_name_matched": "",
  "invoice_no": "",
  "invoice_date": "",
  "due_date": "",
  "amount_excluding_tax": 0,
  "tax_amount": 0,
  "tax_rate_breakdown": [
    { "rate": "10", "base": 0, "tax": 0 }
  ],
  "total_amount": 0,
  "line_items": [
    {
      "description": "",
      "amount": 0,
      "account_code": "",
      "department_code": "",
      "confidence": "high | medium | low"
    }
  ],
  "po_match": "matched | mismatched | not_found",
  "duplicate_check": "ok | duplicate",
  "needs_review": [],
  "reason": ""
}

金額は文字列でなく数値で返させます。文字列にすると「1,200,000」のようにカンマ入りで返り、後段の計算で壊れます。

システムへ連携する

承認後、会計システムへ登録します。連携方法は会計システムによって3通りあります。

多くの国産ERPでは、CSV取込がもっとも確実です。 APIの有無と仕様は、自社の会計システムのベンダーに確認してください。この部分は利用環境に応じた個別確認が必要です。

PDFの保管は、電子帳簿保存法の要件（取引年月日・取引金額・取引先での検索が可能であること）を満たす形にします。ファイル名に「日付_取引先_金額」を含める、または検索項目をメタデータとして持たせます。

人が確認する

全件、人が承認します。段階的な自動化もしません。

理由は、支払という金銭の移動を伴うためです。誤った金額が登録されれば、そのまま振り込まれます。この構成で減らしているのは「読んで打ち込む時間」であって、「確認の責任」ではありません。

確認を速くするための設計が重要です。

• 確認画面で、PDFの原本と抽出結果を左右に並べて表示する
• OCRが抽出した箇所を、PDF上でハイライトする
• confidence が低い項目、needs_review に入った項目を色分けする
• 発注データと金額が一致した請求書は、その旨を大きく表示する（確認の負荷が下がる）

これらがないと、確認に4分かかり、削減効果が出ません。

例外に対処する

記録を残す

この業務では、ログの保存が法令上の要件になります。

• 請求書PDFの原本（電子帳簿保存法の保存要件に従う）
• OCRの抽出結果（生の状態）
• LLMが付けた候補と confidence
• 承認者、承認日時
• 人が修正した項目と、修正前後の値

最後の項目は、精度の実測値になります。「金額は毎回そのまま通るが、勘定科目は3割修正されている」と分かれば、どこを改善すべきかが決まります。