協力会社から毎月届く出来高の請求書を読み取り、注文書の契約金額と現場の出来高査定に照らして、出来高率の食い違いと請求の重複を支払い前に見つける

処理の起点を決める

受付フォルダにファイルが保存されたことを起点にします。 締め日の直後に集中して届くため、1日1回の定時実行にはしません。 届いた順に照合を進めると、差のある請求の問い合わせを早く始められ、協力会社が出し直す時間が残ります。

受付フォルダは Azure Blob Storage のコンテナーにし、Azure Functions の Blob Storage トリガーで動かします。 トリガーには、遅延の小さいイベントベースの実装が推奨されています。同じファイルの同じ版で関数が二度呼ばれないよう、ランタイムが処理済みの記録（blob receipt）を持ちます。 失敗したファイルは既定で計5回まで再試行され、すべて失敗すると専用のキューに記録されます。そのキューを毎朝見る作業を、運用に入れておきます。

フォルダは1つにし、現場ごとに分けません。 現場ごとに分けると、保存先を間違えた請求書がどこにも照合されずに残ります。現場は、読み取った注文番号から原価管理システムで引きます。

処理が終わったファイルは、処理済みのフォルダへ移します。 移すのは成功したときだけにします。受付フォルダに残っている数が、そのまま未処理の数になります。 締め日の5日後の朝に、受付フォルダに残っている件数と、注文があるのに請求が届いていない協力会社を一覧にします。

入力データを集める

質を決めるのは、いちばん下の表です。 「前回迄」「既払」「前月累計」のように、同じ意味の列に協力会社ごとに違う名前が付いています。 取引の多い協力会社から順に、列の名前と意味を1行ずつ書いておくと、並べ直しの迷いが減ります。

支払実績は、請求書の「前回までの累計」と照らす相手です。 ここが無いと、協力会社が自分で書いた累計を、そのまま正しいものとして扱うことになります。

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

明細の表は、合計の行と工種の行を分けて扱います。 合計の行だけを見ると、工種ごとの出来高率の差が相殺されて見えなくなります。工種ごとに査定がある注文では、工種ごとに照らします。

表が複数ページにまたがる請求書は、ページをつないでから扱います。 レイアウトモデルの案内でも、表がページをまたぐ場合は分析の後に1つの表にまとめる処理を勧めています。ページの区切りで工種の行が2つに割れたまま照合すると、同じ工種が2回請求されているように見えます。

原価管理システムの注文と査定は、毎朝書き出したファイルを読みます。 照合に要るのは、注文番号、変更契約を反映した契約金額、査定の出来高率と査定した日です。

AIへ渡す前に整形する

1. 形式の確認 … PDFと画像（JPEG・PNG・BMP・TIFF・HEIF）であることを確かめます。Excelのまま届いたものは、レイアウトモデルで扱えますが、XLSXの表の分析には対応していないため、PDFに印刷して入れます
2. パスワードの確認 … パスワードでロックされたPDFは、提出前に解除する必要があります。協力会社に解除したものを出し直してもらいます
3. ページ数とサイズの確認 … PDFとTIFFは最大2,000ページ、有料（S0）レベルで500MBまでです
4. 画像の寸法と文字の大きさの確認 … 画像は50×50から10,000×10,000ピクセルの間、文字の最小高さは1024×768の画像で12ピクセル（150dpiで約8ポイント）です。明細の小さな数字は、この下限に近づきます
5. 1ファイルに複数の請求書がないかの確認 … 現場事務所でまとめてスキャンされたものは、請求書ごとに分けます
6. 同じ請求書の検知 … 同じ注文番号・同じ請求月のものが二度保存されたら、二重の請求の候補として印を付けます

6番目は、この構成の目的そのものです。 郵送とメールの両方で同じ請求書が届くことがあり、それを別の請求として照合すると、支払も2回になります。 同じ注文・同じ月の請求は、内容が違っても必ず人へ回します。

AIに処理させる

させるのは、書式の違う請求書の読み取り結果を、同じ項目へ並べ直すことだけです。

1行目がいちばん起きやすい失敗です。 前回累計が書かれていない請求書を渡すと、累計から今回を引いて埋めます。埋めた値は計算として正しくても、「前回累計を書いていない」という事実が消え、支払実績と照らす相手が無くなります。

指示内容を固定する

あなたは建設会社の経理部で、協力会社から届いた出来高の請求書を
照合の形にそろえる立場です。
渡すのは Azure AI Document Intelligence のレイアウトモデルが返した
読み取り結果（表・キーと値の組・信頼度）と、この協力会社の書式の対応表です。
読み取り結果に書かれていることだけを使ってください。推測で埋めないでください。

【やること】
- 注文番号、請求月、契約金額、工種ごとの前回累計・今回・累計・出来高率、
  相殺の項目と額、請求額を、下の形にそろえてください。
- 明細の表の列は、書式の対応表に従って当ててください。対応表に無い
  列名は column_raw にそのまま入れ、当てはめずに status を ambiguous に
  してください。
- 金額と出来高率は、書かれた数字をそのまま入れてください。

【厳守事項】
- 計算をしないでください。前回累計・累計・出来高率が書かれていない
  ときに、他の値から計算して埋めないでください。not_stated にしてください。
- 注文番号が書かれていなければ not_stated にしてください。工事名や
  金額から推定しないでください。
- 相殺が差し引き前の額で書かれているか、差し引き後の額で書かれているかが
  決められなければ unknown にしてください。
- 合計の行と工種の行を混ぜないでください。合計の行は row_type を total に
  してください。
- 査定や支払実績との比較、どちらが正しいかの判断は書かないでください。
- confidence は読み取り結果の値をそのまま入れてください。
- 出来高の請求書でない書類と判断した場合は、並べ直しをせず
  document_type に種類を書いてください。

【読み取り結果】{layout_result}
【書式の対応表】{format_map}

「計算をしない」を最初に書かないと、ほぼ必ず埋めます。 出来高の請求書は数字どうしの関係がはっきりしているため、欠けた値を埋めることがAIにとって自然な仕事に見えるからです。 禁じるのは計算そのものです。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "file_id": "",
  "document_type": "progress_invoice",
  "order_no": "",
  "billing_month": "",
  "contract_amount": "",
  "rows": [
    {
      "row_type": "item | total",
      "work_type": "",
      "column_raw": "",
      "prev_cumulative": "",
      "this_month": "",
      "cumulative": "",
      "progress_rate": "",
      "status": "ok | not_stated | ambiguous | low_confidence",
      "handwritten": false,
      "confidence": 0
    }
  ],
  "offsets": [ { "name": "", "amount": "" } ],
  "offset_basis": "before | after | unknown",
  "billed_amount_excl_tax": "",
  "billed_amount_incl_tax": ""
}

1つ目の理由は、差の計算をプログラムに渡せることです。 次の4つの照合は、AIではなく Azure Functions が数字を引いて決めます。

2つ目は、status と照合の結果を別の層に置けることです。 読み取りが not_stated の項目は照合に回さず、「書かれていない」として先に人へ渡します。 読み取りの欠けと、数字の食い違いを混ぜません。

金額は文字列で受け取り、数値への変換と桁の確認はプログラムで行います。 構造化出力ではすべてのフィールドを必須にし、オブジェクトに additionalProperties: false を付けます。minimum や maximum のような数値の制約はスキーマで書けないため、金額の範囲の確認は後段で行います。

システムへ連携する

原価管理システムへは書き込みません。 査定が遅れていても、この構成から査定を直すことはしません。査定を直すのは現場の所長です。

会計システムへも、人が確かめた後のファイルだけを渡します。 書き込みを自動にすると、照合の誤りがそのまま支払まで進みます。

人が確認する

担当者が開くのは、差のある請求と、not_stated ／ ambiguous ／ low_confidence のある請求だけです。

1. 重複の候補を先に見る … 同じ注文・同じ月の請求が2件ある、cumulative_mismatch がある。支払が二重になる危険のあるものから見ます
2. 出来高率の差を所長に確かめる … over_assessed は、査定が遅れているのか、請求が先走っているのかを現場に聞きます
3. 契約金額の差を確かめる … 変更契約が原価管理システムに反映されていないことが多い理由です
4. 手書きの行を原本で見る … 手書きの判定が付いた行の数字は、信頼度にかかわらず原本を見ます
5. 支払う額を決めて書き出す … 査定どおりに直して支払うか、出し直しを頼むかを決めます

2番目を担当者だけで決めないでください。 出来高の判断は現場の仕事です。経理が査定に合わせて減額すると、協力会社との関係を現場の知らないところで損ねます。

目標は、240件をならして1件5分です。 差の無い請求は一覧で流し見て終わり、差のある請求だけに時間を使います。差のある請求が2割を超える月は、査定の入力が遅れているか、書式の対応表が古くなっています。

例外に対処する

4行目が、締め日の直後にいちばん多く出ます。 所長の査定の入力が請求の到着より遅れることは珍しくなく、査定の無いまま照合すると、すべての請求が over_assessed に見えます。 保留にして、査定が入った時点で照合し直します。

記録を残す

• 元の請求書ファイルと、受け取った日時・経路（紙／PDF）
• レイアウトモデルが返した読み取り結果の全文
• 並べ直したJSONと、そのとき使った書式の対応表の版
• 照合の結果と、そのとき照らした契約金額・査定・支払実績の値
• 担当者と所長が決めた支払額と、その理由
• 協力会社へ出し直しを頼んだ日と、出し直された請求書との対応
• 協力会社ごとの、差のある請求の割合

4つ目で「照らした値」を残すのは、査定と変更契約が後から動くためです。 照合し直すと過去の差が消え、なぜその月に減額して支払ったのかを協力会社に説明できなくなります。

最後の行は、協力会社との話し合いの材料になります。 毎月同じ会社で cumulative_mismatch が出るなら、その会社の書式の累計の書き方が自社の考え方と違っています。 1件ずつ差し戻すより、書式を相談したほうが早く終わります。