AIで請求書と発注書を照合する方法

発注書、請求書、受領記録、税情報、承認メモが別々のファイルにあると、照合作業は遅くなります。AIは読み取りと分類の手間を減らせますが、支払いの可否を決めるべきではありません。安全な方法は、AIによる抽出、決定論的な計算、文書化された許容差、明確な人間の承認者を組み合わせることです。

このガイドでは、混在する文書を確認可能な照合表へ変換し、例外を見つけ、優先順位を付け、仕入先への質問を準備します。最終出力は、証拠不足を隠したり承認権限を変更したりせず、買掛金担当者の作業を速めるものでなければなりません。

照合結果を先に定義する

モデルではなく、必要な出力から始めます。実用的な照合記録には、請求書番号、発注書、仕入先、通貨、明細、発注数量、受領数量、請求数量、単価、税、合計、照合状態、例外理由、証拠の場所、レビュー担当者を含めます。

必要な状態も決めます。たとえば、一致、承認済み許容差内、不一致、文書不足、重複、手動確認です。各状態を誰が承認できるかを明記します。AIは分類を提案できますが、差異を許容するかは財務方針が決めます。

元文書を準備する

発注書、請求書、物品受領またはサービス確認、仕入先マスター、許容差を定義する方針を集めます。原本は変更せず、コピーで作業します。安定したファイル名とページ番号を付け、抽出値を追跡できるようにします。

利用するAIツールで処理を許可されていない情報は除きます。銀行情報、個人データ、税務識別子、契約条件、社内価格は、承認された専用環境が必要な場合があります。安全基準を満たせないツールでは、管理されたシステムで最小限の項目だけを抽出し、匿名化したデータをAIへ渡します。

ステップ1：文書を正規化する

最初のAI作業は判断ではなく抽出です。一貫した構造を求め、値がない場合はnullを返させます。もっともらしい推測が会計データになることを防げます。

### Prompt：請求書レコードを正規化する

~~~text You are an accounts payable data normalization assistant. Convert the supplied purchase orders, invoices, and receipt records into a JSON array. Use only values that appear in the documents. Never infer a missing identifier or amount. Return these fields for each line: document_type, document_id, vendor_name, currency, line_item, quantity, unit_price, tax, total, purchase_order_id, receipt_id, and document_date. Use null for missing values and add a source_reference field with the file name and page number. Do not approve a payment or decide that a discrepancy is acceptable. ~~~

大きなバッチへ進む前にサンプルを確認します。小数点、通貨記号、負数、税込価格、明細名、分割納品、複数ページの請求書を点検します。OCRを使う場合は、合計と識別番号を元画像と照合してください。

ステップ2：明示的な照合ルールを適用する

計算はコードやスプレッドシートの数式で行います。まず仕入先と通貨を合わせ、次に請求書、発注書、受領記録を明細単位で比較します。許容する丸め差、承認済み送料、受領責任者の確認が必要な数量差などを、レビュー前に定義します。

モデルにルールを作らせてはいけません。正確な方針を与え、各結果に使用ルールを関連付けます。三点照合は通常、発注書、請求書、受領記録を比較します。サービス請求では、倉庫の受領票ではなく担当者のサービス完了確認が必要になる場合があります。

ステップ3：証拠に基づいて例外を分類する

計算後、AIは価格差、数量差、発注書不足、受領記録不足、重複請求、税差、通貨不一致、不明な手数料などへ整理できます。

### Prompt：照合例外を分析する

~~~text Compare the normalized invoice, purchase order, and receipt records below. Apply only the matching rules and tolerance limits I provide. For every mismatch, return: exception_type, affected_document, expected_value, actual_value, difference, evidence, business_risk, and recommended_reviewer. Separate confirmed mismatches from records that cannot be evaluated because data is missing. Do not invent policy, tax treatment, delivery status, or approval authority. ~~~

確認済みの差異と、情報不足で判定できないものを分けます。受領記録がないことは未納品の証明ではなく、合計が違うことも過請求とは限りません。レビュー記録には、判明した事実、不足情報、解決できる担当者を示します。

ステップ4：優先度付きレビューキューを作る

リスク金額、支払期限、二重払いの可能性、仕入先の重要度、経過日数、月次締めへの影響など、説明可能なルールで優先順位を付けます。根拠を示せない単一のAIリスクスコアは避けます。

買掛金、購買、受領、予算責任者、仕入先確認ごとの表示を作り、すべての未解決項目に担当者と次の行動を設定します。モデル出力は下書きとして残し、確認後の状態と解決内容を正式な記録にします。

ステップ5：仕入先と社内への確認文を作る

AIは構造化された例外から短い質問文を作れます。確認済み事実、不足証拠、求める対応、期限を入力します。レビュー前に相手の誤りを断定したり非難したりしないでください。

有効な連絡には、請求書と発注書、具体的な差異と明細、修正版または証拠の依頼、次の手順を含めます。送信前に、人が宛先、添付、金額、表現を確認します。

品質確認チェックリスト

• すべての金額と識別子を元ファイルとページへ追跡できる。
• 通貨、税、単位、正負記号が一貫している。
• 計算はモデルの推定ではなく決定論的な方法で行う。
• 許容差は承認済み方針に基づき、記録から確認できる。
• 証拠不足を事実の結論へ変換しない。
• 仕入先、請求書番号、金額、日付の組み合わせで重複を確認する。
• 支払承認は権限を持つ担当者と会計システムに残す。
• 修正と判断を監査用に記録する。

避けるべき一般的な失敗

最も多い失敗は、項目やルールを定義せず、文書をアップロードして一致するかだけを尋ねることです。読みやすい説明は得られても、監査証跡は弱くなります。合計だけを比較すると、明細差が相殺されることもあります。生成した仕入先メールを未確認で送信したり、未承認ツールへ機密文書を置いたりすることも危険です。

小さく代表的なバッチから始め、抽出精度、例外分類の精度、レビュー時間、未解決件数を測ります。不確実性を明示し証拠を保持できることを確認してから拡張します。目的は自動支払いではなく、財務統制を担当者に残したまま、照合を速く一貫させることです。