G702抽出でよくあるエラー
ペイアプリ紛争の原因に

G702/G703フォームに関するほとんどのガイドは、計算の確認、期限厳守、ライエン放棄書の添付といった明白な点に焦点を当てています。これらは確かに重要です。しかし、手作業でフォームを記入する段階から、PDFやスプレッドシートからデータを抽出して1つの支払申請書にまとめる段階、あるいはゼネコンとして20の下請け業者の提出書類を1つの引出しスケジュールに統合する段階に移行すると、別の種類のエラーが支配的になります。これらは、計算結果がきれいに合っているにもかかわらず生き残るエラーです。なぜなら、合計を間違えることではなく、そもそも合計に間違った数字を入れてしまうことだからです。

数字は合っているのに支払申請が却下されるケース

建設業の請求業務を数サイクル以上経験したことのある人なら誰でも覚えのある特有のフラストレーションがあります。すべての合計を確認し、保留金の計算も問題なく、G703の総計がG702の4行目と一致しているのに、建築士や発注者側の担当者から数字の横に疑問符を付けられて送り返されてくるのです。問題は計算が間違っていることではありません。問題は、元の書類と最終的なフォームの間のどこかで、数字の値は変わらずにその意味が変わってしまっていることにあります。

これこそが、表面的なフォームのエラーと抽出エラーを分ける核心的な違いです。数字の桁違いや引き忘れといった表面的なエラーは、それ自体で明らかになります。抽出エラーは単独では正しく見えます。誰かがその数字の出所をたどり、フォームに記載されたものと元の情報が一致しないことが判明して初めて明らかになるのです。この6つの最も一般的な発生パターンを理解することは、支払申請が初回審査を通過するか、1請求サイクルを無駄にする紛争を引き起こすかの分かれ目となります。

1. 累計と当期分の抽出ミス

G703継続シートにおいて、D列とE列は根本的に異なる目的を持っています。D列は過去のすべての申請で承認された累計合計を繰り越します。E列は今回の請求期間に完了した作業のみを記録します。G列（本日までの完了・保管済み合計）は、D、E、および今回の期間にFに保管された資材の合計です。G702サマリーで重要な数値はG列です。

しかし、書類の山からデータを抽出する際（マークアップされたG703からの転記、下請け業者のスプレッドシートからの取得、またはAI抽出ツールを使用したスキャンされた支払い申請書の読み取り）に、最も一般的なエラーパターンは、E列（今回のみ）とG列（本日までの合計）を混同することです。下請け業者が今月45,000ドルの電気工事を完了したと報告した場合、その45,000ドルはE列に入ります。しかし、そのラインアイテムのG列は累計合計（プロジェクト開始以降に完了したすべての作業、例えば180,000ドル）を読み取るべきです。この45,000ドルを累計数値として抽出すると、G702のライン4は実際の完了作業を135,000ドル過小評価します。施主は現場での進捗観察と一致しない数値を目にし、申請全体にフラグを立てます。

逆のエラー（累計数値を今期の列に抽出する）は、今月の請求を膨らませ、過大請求レビューを引き起こします。どちらのエラーも単純なクロスフットチェックでは現れません。なぜなら、G702の内部計算は内部的に一貫しているからです。エラーは、誰かが提出された数値をプロジェクトの物理的進捗と比較した場合にのみ表面化します。これはAIA A201-2017 セクション9.4で要求されており、建築家に金額が実際の完了作業を反映していない場合、申請の一部のみを認証する権限を与えています。

修正の第一歩は、抽出対象の列がソースのどの概念に対応するかを理解することです。文書を構造化テーブルに変換する抽出ツールを使用している場合（列名抽出と呼ばれることもあり、必要なフィールドを指定するとAIが各ページの該当値を特定します）、列定義で「今期完了作業」と「累計完了作業」を明確に区別してください。ソース文書が期間数値のみを報告する場合は、G703に渡す前に請求サイクル全体で累積する別の仕組みが必要です。

2. 保留金のベース誤り

G702/G703ペアの保留金は、完了作業と保管材料の累計額に対して計算され、今期請求額に対してではありません。下請け業者が今月5万ドルの作業を完了し、累計完了額が20万ドルになったとします。契約上の保留率10%の場合、このラインアイテムの保留金は2万ドル（20万ドルの10%）であり、5,000ドルではありません。期間のみの5万ドルに10%を適用すると、保留金が1万5,000ドル不足します。

このエラーはデータ抽出時に意外と起こりやすいものです。なぜなら、保留金率は「Retainage: 10%」のように単一の契約フィールドに記載されている一方、その率が適用される金額は請求期間ごとに変わるからです。抽出ワークフローが契約書から「10%」を読み取り、ページ上で最も近い金額にかけるだけでは、どの金額を拾ったか保証できません。G703フォーム（契約総額を工事の各部分に細分化した明細書）では、保留金が明細項目ごとに異なる場合もあります。また、実質完了後に保留金を10%から5%に減額する契約もあり、同じG703の異なる行で異なる保留金率が適用される状況が生じます。

州法もさらに複雑にしています。ニューヨーク州では、15万ドルを超える民間建設契約の保留金は5%が上限となり、それを超える契約条項は無効かつ執行不能です。イリノイ州では、契約前半は10%を認めるものの、後半は5%への減額を義務付けています。ノースカロライナ州では、10万ドル未満のプロジェクトでは保留金が全面的に禁止されています。抽出ワークフローがこれらの法令の対象となるプロジェクトに一律10%を適用した場合、実際に差し控えた額と契約上合法的に認められる額との不一致が即座に紛争を引き起こし、管轄によっては法令違反となります。

建設財務管理協会（CFMA）は、誤報告や意思決定の遅れだけでも、エラーや調整問題によってプロジェクトコストが2～5%増加する可能性があると報告しています。500万ドルのプロジェクトでは、これは10万～25万ドルの完全に回避可能なコストであり、そのほとんどは支払いチェーンを流れるべき資金が紛争状態にあることに起因します。

3. G702とG703間で乖離する変更指示データ

G702には変更指示サマリー表が含まれており、そのデータは2行目（変更指示による正味変更額）、さらに3行目（現在までの契約総額）に反映されます。一方、承認済みの変更指示はG703上で個別の明細項目として表示され、それぞれに予定価格と進捗状況が設定されています。これら2つの表現は整合している必要があります。つまり、G703上のすべての変更指示明細の合計は、G702の変更指示サマリーから2行目に反映される金額と一致しなければなりません。

複数のソースから変更指示データを抽出する際、よくある2つの問題が発生します。1つ目は、未承認の変更指示を合計に含めてしまうことです。下請け業者が合計35,000ドルの5件の保留中の変更指示をG703の明細項目として含めるケースがありますが、これはAIAのG703指示書で「変更指示は別途、専用のG703フォームまたは基本スケジュールの末尾に記載する」と警告されている慣行に反します。ゼネコンや設計者が下請け業者のG703を確認し、承認していない作業に対する金額を発見した場合、申請全体が疑わしいものとなります。

2つ目のパターンはより微妙です。G703の明細行には変更指示の金額が正しく表示されているものの、G702の変更指示サマリーへの集計が欠落しているかゼロになっています。G703では承認された変更指示作業として35,000ドルが表示されていますが、G702の2行目は0ドルと読めます。詳細な内訳とサマリーの間のこの不一致は、AIA A201-2017第9.3条に基づく直接的な却下理由となります。同条項では、支払申請書に「現在までの契約金額の状況（現在までに完了し保管されている作業の総額、保留額（ある場合）、過去の支払総額、変更指示のサマリー、および今回請求する支払額を含む）」を表示することを要求しています。変更指示のサマリーが不完全な場合、申請自体が不完全となります。

変更指示が別々のシステム（Procoreでのコミットメント管理、サブコントラクターの変更記録用スプレッドシート、署名済み変更指示書のPDF）に記録され、誰かがこれらすべてを1つのG702エントリに調整する必要がある場合、抽出ワークフローはこの問題を悪化させます。1つの情報源が見落とされると、連鎖が始まります。これらのシステム間での手動データの受け渡しが支払いサイクル全体をどのように遅らせるかについての詳細は、AIA G702の手動データ入力が建設業の支払いサイクルを遅らせる理由に関する分析をご覧ください。

4. 保管資材の評価額が明細項目の上限を超える場合

G703の「Column F — 現在保管中の資材」は、購入済みで現場にある資材の価値（または特定の契約条項に基づき、現場外の保税倉庫に保管されている資材）を追跡します。手動レビューでは発見できるが、自動抽出では見逃されがちな構造上の制約があります。それは、単一のラインアイテムに対する保管資材が、そのラインアイテムの予定価額を超えてはならないという点です。ラインアイテムの総額が50,000ドルであれば、それに対して55,000ドルの保管資材を請求することはできません。それは、作業範囲全体よりも多くの資材価値を請求していることになるからです。

このエラーは、抽出ワークフローにおいて2つの経路で発生します。経路1：下請け業者の資材請求書に、SOV割り当てを超える価値の納入数量が記載されており、抽出ツールがSOVの上限を確認せずにその請求書の数値をそのまま転記する場合。経路2：前の期間に資材が1つのラインアイテムの下で保管されていたが、継続的な資材納入が、別の資材専用ラインではなく、同じラインアイテムに割り当てられている場合。累計値が上限を超え、G703にマイナスの残高が表示されます。これは、承認を停止させる即座の危険信号です。

G703は単なる数字の羅列ではありません。それは制約のシステムです。各ラインアイテムには最大値があり、累計合計は減少できず、保留額は契約上の率を超えられず、保管資材は予定価額を超えられず、残高はマイナスになってはなりません。抽出が各列を独立したフィールドとして扱い、制約システム内のリンクされた変数として扱わない場合、経験豊富なプロジェクト会計士が数秒で行うクロス制約の検証に失敗する一方で、列ごとのスキャンは通過するデータを確実に生成します。

5. 前回支払いの繰越問題

G702の7行目「前回までの支払証明書額」は、支払申請システム全体で最も複合的なエラーを引き起こす要因です。これはプロジェクトでこれまで承認されたすべての支払いの合計を表します。最初の支払申請ではゼロです。それ以降の申請では、最後に提出されたものや下書きではなく、最後に承認されたG702の6行目「今回支払期日額」と正確に一致しなければなりません。

実際の破綻例を示します。申請書#3で94,000ドルの支払いが請求されました。建築家は書類不備を理由に7,000ドルを差し引き、87,000ドルしか認証しませんでした。下請け業者のシステムには、提出された94,000ドルが繰越額として記録されます。申請書#4では7行目が94,000ドルで提出されます。しかし、発注者の記録と契約上、正しい繰越額は87,000ドルです。7行目以降のすべての数値（今回支払期日額、残工事代金）が7,000ドル膨らんでいます。申請は却下されます。

このエラーが拡大するのは、認証された金額が建築家の署名済みG702という一箇所にしか存在しない一方で、抽出元（通常は下請け業者やゼネコンの社内請求書スプレッドシート）が提出された金額を追跡しているからです。複数の下請け業者の支払申請を単一の支払スケジュールに統合する際（プロジェクト全体の支払申請を1つの統合支払スケジュールに統合する方法のガイドで解説）、各下請け業者の7行目は、前回サイクルの認証済みバージョンと個別に照合する必要があります。1社の繰越エラーがゼネコンの要約G702に波及し、追跡が指数関数的に困難になります。

6. 誰もレビュー時まで確認しないG702とG703の照合

G702サマリーの各数値はG703上の単一起源を持ちますが、1つだけ例外があります。第2行はG702自体にのみ存在する変更命令サマリーテーブルから導出されます。これにより照合の死角が生じます。G703の合計が完璧で、変更命令サマリーが正しくても、変更命令サマリーがG703の変更命令明細項目とは独立して入力された場合、両者は乖離する可能性があります。

手動ワークフローでは、この照合は面倒ですが少なくとも一元化されています。1人の担当者が両方のフォームに記入し、相互にチェックします。抽出ワークフローでは、G703の合計は下請け業者の継続シートを読み取るAIツールから得られる一方、変更命令サマリーはプロジェクトマネージャーが別の形式で管理する別のログから得られます。2つのデータストリームは同じG702に流れ込みますが、相互検証されることはありません。その結果、各セクションは個別に正しく検証されるものの、全体として調整不可能なギャップを含むフォームが生成されます。

これは抽出精度の失敗ではない。いわば抽出アーキテクチャの失敗だ。つまり、どのソースがどの出力フィールドに供給され、ワークフローのどこでクロスバリデーションが行われるかという設計の問題である。G702/G703処理において抽出ツールに最も求められるのは、99%のフィールド精度を達成することではない（それも重要だが）。それは、フォーム間のフィールド間の関係性を保持することだ。下請け業者のG703の3ページ目から抽出された数値が、元請けのG702の4行目に至るまでの系統を維持し、差異が生じた際に遡って追跡できるようにすることである。

実務上の帰結：建築家や発注者が数値を疑問視したとき、「スプレッドシートを確認して折り返します」ではなく、その数値がどのソース文書のどの明細行のどの列から来たのかを正確に答えられるべきだ。トレーサビリティのない抽出は、手動入力と大差ない。紛争を生むスピードが速くなっただけだ。

抽出ワークフローに検証レイヤーを組み込む

上記6つのエラーのいずれも、文字レベルの高い精度でデータを抽出するツールでは防止できない。これらは構造的なエラーである。つまり、ソースコンテキストにおけるデータの意味と、対象フォームにおけるデータの意味の不一致だ。これを防ぐには検証レイヤー、すなわち抽出後かつ提出前に実行される一連のクロスチェックが必要である。

最低限、このレイヤーでは以下を確認する必要があります。G703のG列合計がG702の4行目の値と一致していること、各G703行の保留額が契約上の率にその行のG列（E列ではない）を乗じた値と一致していること、G702の変更命令サマリー合計がG703の変更命令明細行の合計と一致していること、どの明細行の貯蔵材料もその予定値を超えていないこと、そして7行目が前回承認された申請の認定済み6行目と一致していること。これらは複雑な計算ではありません。実行に数秒しかかからない比較ですが、ワークフローに組み込まれている必要があり、請求サイクル最終日の午後11時に「送信」を押す担当者に任せてはいけません。

大量の申請を処理するチーム（ゼネコンが毎月15～20件の下請け業者支払申請を受け取る場合）にとって、AIA G702/G703データのスプレッドシートへの自動抽出は手動入力を排除しますが、検証レイヤーは依然として不可欠です。抽出によりデータは構造化された形式になります。検証レイヤーは、その構造が自己矛盾していないことを確認してから、申請書が建築家の机に届くようにします。

一部の抽出ツールでは、計算列（ドキュメントから直接読み取るのではなく、他の抽出データから値を導き出すフィールド）を定義できます。この機能は、組み込みの検証メカニズムとして機能します。「IF G703_ColumnG_Total ≠ G702_Line4 THEN '不一致' ELSE 'OK'」を計算する列を定義し、人間によるレビューに回る前に、調整エラーのあるすべての申請にフラグを立てることができます。このツールは、この比較を実行するために建設請求を理解する必要はありません。2つの抽出値が等しいはずであることと、等しくない場合に警告を発することだけを理解すればよいのです。

よくある質問

計算が合っているのに、なぜ支払申請が却下されるのですか？

正しい計算と正しいデータは同じではないからです。最も一般的な原因は、書類の内容と、建築主や所有者の代理人がプロジェクトの進捗状況について独自に把握している情報との間に不一致があることです。よくある原因：現場観察と一致しない累計額、承認なしに含まれた変更命令、誤った基準で計算された保留金、または7行目（前回支払額）が最後に認定された申請と一致しないこと。計算は完璧でも、データの系統が間違っている可能性があります。

G702とG703の違いは何ですか？また、それが抽出に重要な理由は何ですか？

G702は要約表紙です。総契約額、保留金、前回支払額、今回請求額を1ページに表示します。G703は継続シートで、契約をバリュー・スケジュールの個別明細項目に分解した、詳細な内訳です。G702のすべての数値（変更命令サマリーを除く）はG703に遡る必要があります。データ抽出において、G703は明細レベルの数値の信頼できる情報源であり、G702はそれらの数値を集計したものです。2つのフォームをリンクせずに独立して抽出すると、調整エラーが避けられません。

AI抽出ツールは、異なる明細項目間で変動する保留金率を処理できますか？

ツールによります。あるツールはページに印刷されているものだけを抽出し、G703のI列にある保留金の数値を忠実に取得しますが、その数値が契約に対して正しく計算されているかは検証できません。他のツールでは計算列を定義できます。例えば「保留金チェック（G列×0.10）」という列を作成し、累計額から期待される保留金を計算して差異をフラグ付けできます。この検証方法は、読み取っている文書の外部にある契約率を導入するため、純粋な抽出では見逃されるエラーを捕捉できます。

G702/G703の提出には、どのような補足書類を常に添付すべきですか？

AIA A201-2017のセクション9.3.1では、支払申請には権利放棄書と差押え放棄書を添付することが義務付けられています。法的な最低要件に加えて、ほとんどのプロジェクトでは、公的資金による作業のための認定給与報告書、進捗写真、保管資材の証拠（納品書、倉庫書類）、および元の範囲を超える作業に対する署名済み変更指示書も必要とします。書類の欠落は、支払いが却下される最も一般的な手続き上の理由であり、データエラーとは別の問題ですが、支払いスケジュールに同様に悪影響を及ぼします。

支払申請に未処理の変更指示書を含めても安全ですか？

いいえ。G703のラインアイテムやG702変更命令サマリーに未承認の変更命令を含めることは、申請が却下される最も早い方法の一つです。AIA A201-2017第7.3.9条では、建設変更指示書により正式に許可されたがまだ変更命令に含まれていない変更に対する支払い請求を申請に含めることが認められていますが、これは狭い例外であり、包括的な許可ではありません。最も安全な方法は、保留中の変更命令を別のログで追跡し、正式な承認後にのみG703に移すことです。署名された承認なしに作業の請求を行うことは、契約上の紛争を引き起こすだけでなく、多くの州では先取特権の問題にもなります。