一般的なG702抽出エラー
支払申請書の紛争を引き起こす

G702/G703フォームに関するガイドの大半は、当然のことに焦点を当てています。計算の確認、期限の厳守、債権放棄書の同封です。これらは重要です。しかし、手書きのフォーム記入から、PDFやスプレッドシートからデータを抽出して単一の支払申請書にまとめる段階に移行したとき、あるいは、20社の下請け業者の提出書類を1つの支払スケジュールに統合するゼネコンの立場であるとき、別の種類のエラーが支配的になります。これらは、電卓テープがきれいに合うにもかかわらず残るエラーです。なぜなら、合計を間違えることではなく、そもそも間違った数値を合計に含めてしまうことに関するエラーだからです。

数字は合っているのに支払申請書が却下される場合

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

これこそが、表面的なフォームエラーと抽出エラーを区別する中核的な違いです。表面的なエラー（数字の桁の入れ替え、引き忘れ）は、それ自体で明らかになります。抽出エラーは、単独で見ると正しく見えます。それは、誰かがその数字を遡って出所を辿り、フォームに記載されたものと元の情報源が一致しないことに気づいたときにのみ、明らかになります。この6つの最も一般的な発生パターンを理解することは、支払申請書が最初の審査を通過するか、請求サイクル全体を失う紛争を引き起こすかの違いを生みます。

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ペアの保留金は、完了した作業と保管材料の累計合計に対して計算され、今期の請求額に対してではありません。下請け業者が今月$50,000の作業を完了し、累計完了額が$200,000になったとします。契約上の保留金率が10%の場合、このライン項目の保留金は$20,000 — $200,000の10% — であり、$5,000ではありません。期間のみの$50,000に10%を適用すると、保留金が$15,000不足します。

このエラーはデータ抽出時に陥りやすいものです。保留金率は多くの場合、契約書の単一フィールド（「保留金：10%」）に記載されている一方、その率が適用される金額は請求期間ごとに変わるからです。抽出ワークフローが契約書から「10%」を読み取り、ページ上で最も近い金額に掛け合わせる場合、どの金額を取得したかを保証できません。G703フォーム（契約金額を作業の各部分に分解する詳細な価値明細表）では、保留金はライン項目ごとに異なる場合もあります。一部の契約では、実質完了後に保留金を10%から5%に引き下げるため、同じG703の異なる行に異なる保留金率が適用される状況が生じます。

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

建設財務管理協会（CFMA）は、誤報告と意思決定の遅延だけでも、エラーと調整問題によりプロジェクトコストが2〜5%増加する可能性があると文書化しています。$500万のプロジェクトでは、これは$100,000〜$250,000の完全に回避可能なコストであり、その大部分は支払いチェーンを流れるのではなく紛争状態にある資金に起因します。

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の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のColumn G合計がG702のLine 4の値と一致すること、各G703ラインの保留金が契約上の率にそのラインのColumn G（Column Eではない）を乗じたものと一致すること、G702の変更命令サマリー合計がG703の変更命令ライン項目の合計と一致すること、いずれのライン項目の保管材料もその予定価額を超えないこと、そしてLine 7が前回承認済み申請書の認定済みLine 6と一致すること。これらは複雑な計算ではありません。数秒で実行できる比較ですが、ワークフローに組み込まれていなければなりません。請求サイクル最終日の午後11時に「提出」を押す担当者任せにしてはいけません。

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

一部の抽出ツールでは、計算列を定義できます。これは、文書から直接読み取るのではなく、他の抽出データから導出される値を持つフィールドです。この機能は組み込みの検証メカニズムとして機能します。「IF G703_ColumnG_Total ≠ G702_Line4 THEN 'MISMATCH' 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に移行することです。署名済みの承認なしに作業に対する請求を行うと、契約上の紛争が生じるだけでなく、多くの州ではリーエン権の問題も発生します。