일반적인 G702 추출 오류
지급 청구서 분쟁을 유발하는

G702/G703 양식에 관한 대부분의 가이드는 명백한 것에 초점을 맞춥니다. 계산을 확인하고, 마감일을 놓치지 말고, 유치권 포기 각서를 포함하라는 것입니다. 그것들도 중요합니다. 하지만 PDF와 스프레드시트에서 데이터를 추출하여 단일 지급 청구서로 통합하는 단계로 넘어갈 때 — 또는 20개 하도급업체 제출물을 하나의 드로우 일정으로 통합하는 GC라면 — 다른 유형의 오류가 발생합니다. 이는 깨끗한 계산기 테이프에도 살아남는 오류입니다. 합계를 잘못 구하는 문제가 아니기 때문입니다. 처음부터 합계에 잘못된 숫자가 들어가는 문제입니다.

숫자는 맞는데 지급 청구서가 여전히 반려되는 경우

몇 차례 이상 건설 청구를 관리해 본 사람이라면 누구나 익숙한 특정한 답답함이 있습니다. 모든 합계를 검증하고, 보류금 산술이 맞고, G703 총합계가 G702의 4번 줄과 일치하는데도 — 건축가나 발주자 대표가 특정 수치 옆에 물음표를 남기고 다시 보내는 경우입니다. 문제는 계산이 틀린 것이 아닙니다. 문제는 원본 문서와 최종 양식 사이 어딘가에서 숫자가 값은 그대로인 채 의미가 바뀌었다는 것입니다.

이것이 표면적 양식 오류와 추출 오류를 구분하는 핵심 차이입니다. 표면 오류 — 숫자 전위, 누락된 뺄셈 — 는 스스로 드러납니다. 추출 오류는 단독으로는 정확해 보입니다. 누군가 그 숫자를 출처까지 추적하여 양식에 기재된 것과 원본이 일치하지 않는다는 것을 발견했을 때만 드러납니다. 이런 일이 발생하는 가장 흔한 여섯 가지 방식을 이해하는 것이 첫 검토를 통과하는 지급 청구서와 전체 청구 주기를 날리는 분쟁을 유발하는 청구서의 차이를 만듭니다.

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% 증가시킬 수 있다고 문서화했습니다. $5백만 프로젝트의 경우, 이는 $100,000~$250,000의 완전히 피할 수 있는 비용이며 — 대부분은 지급 체인을 통해 흐르지 않고 분쟁 상태로 묶여 있는 돈에 기인합니다.

3. G702와 G703 사이에서 달라지는 변경 명령 데이터

G702에는 변경 명령 요약표가 포함되어 있으며, 이는 2번 항목(변경 명령에 의한 순변경)과 최종적으로 3번 항목(현재까지의 계약 금액)으로 연결됩니다. 한편, 승인된 변경 명령은 G703에 추가 라인 항목으로 표시되며, 각각 고유한 예정 가치와 진행 상황 추적이 포함됩니다. 이 두 표현은 일치해야 합니다. G703의 모든 변경 명령 라인 항목의 합계는 G702 변경 명령 요약을 통해 2번 항목으로 흐르는 수치와 일치해야 합니다.

여러 출처에서 변경 명령 데이터를 추출할 때, 두 가지 문제가 예측 가능한 규칙성으로 발생합니다. 첫 번째는 승인되지 않은 변경 명령을 합계에 포함하는 것입니다. 하청업체가 총 $35,000에 달하는 5건의 보류 중인 변경 명령을 보유하고 있으며, 이를 G703에 라인 항목으로 포함하는 경우 — 이는 AIA의 G703 지침이 경고하는 관행으로, 변경 명령은 "자체 G703 양식에 별도로 나열하거나 기본 일정의 끝에 나열"하도록 명시하고 있습니다. GC나 건축가가 하청업체의 G703을 검토하고 승인하지 않은 작업에 대한 금액을 발견하면, 전체 지급 청구서가 의심을 받게 됩니다.

두 번째 패턴은 더 미묘합니다. 변경 명령 금액이 G703 라인 항목에 올바르게 표시되지만, G702 변경 명령 요약으로의 합산이 누락되거나 0으로 표시되는 경우입니다. G703에는 승인된 변경 명령 작업 $35,000가 표시됩니다. G702 2번 항목에는 $0으로 표시됩니다. 상세 백업과 요약 간의 불일치는 AIA A201-2017 섹션 9.3에 따른 직접적인 거부 사유이며, 이는 지급 청구서가 "현재까지의 계약 금액 상태, 현재까지 완료 및 보관된 작업의 총 금액, 보류금(있는 경우), 이전 지급 총액, 변경 명령 요약, 현재 요청된 지급 금액"을 표시해야 한다고 요구합니다. 변경 명령 요약이 불완전하면 지급 청구서도 불완전합니다.

변경 명령이 별도의 시스템에 기록될 때 추출 워크플로우는 더욱 악화됩니다 — Procore의 약정 관리, 하청업체 변경 로그용 스프레드시트, 서명된 변경 명령 양식의 PDF — 그리고 누군가 이 세 가지를 모두 단일 G702 항목으로 조정해야 합니다. 하나의 출처가 누락되면 연쇄 반응이 시작됩니다. 이러한 시스템 간 수동 데이터 전달이 전체 지급 주기를 지연시키는 방식에 대한 자세한 내용은 AIA G702 수동 데이터 입력이 건설 지급 주기를 지연시키는 이유에 대한 분석을 참조하십시오.

4. 라인 항목 상한을 초과하는 저장 자재 평가액

G703의 F열 — 현재 저장 자재 — 구매하여 현장에 보관 중인 자재(또는 특정 계약 조항에 따라 보세 창고에 오프사이트로 보관된 자재)의 가치를 추적합니다. 수동 검토는 잡아내지만 자동 추출은 종종 놓치는 구조적 제약이 있습니다: 단일 라인 항목의 저장 자재는 해당 라인 항목의 예정 가치를 초과할 수 없습니다. 라인 항목의 총 가치가 $50,000라면, 그 항목에 대해 $55,000의 저장 자재를 청구할 수 없습니다 — 이는 전체 작업 범위보다 더 많은 자재 가치를 청구하는 셈이기 때문입니다.

이 오류는 추출 워크플로우에서 두 가지 경로를 통해 발생합니다. 첫 번째 경로: 하도급업체의 자재 인보이스에 SOV 배정액을 초과하는 가치의 납품 수량이 표시되고, 추출 도구가 SOV 상한을 확인하지 않은 채 인보이스 수치를 그대로 전사하는 경우입니다. 두 번째 경로: 이전 기간에 자재가 한 라인 항목 아래에 저장되었지만, 계속되는 자재 납품이 별도의 자재 전용 라인 대신 동일한 라인 항목에 배정되는 경우입니다. 누적 수치가 상한을 돌파하고, G703에 음수 잔여 완료 금액이 표시됩니다 — 이는 인증을 중단시키는 즉각적인 경고 신호입니다.

G703은 단순한 숫자 목록이 아닙니다. 이는 제약 시스템입니다: 각 라인 항목에는 최대 가치가 있고, 누적 합계는 감소할 수 없으며, 보류금은 계약 비율을 초과할 수 없고, 저장 자재는 예정 가치를 초과할 수 없으며, 잔여 완료 금액은 음수가 될 수 없습니다. 추출이 각 열을 제약 시스템의 연결된 변수가 아닌 독립적인 필드로 취급하면, 경험 많은 프로젝트 회계사가 몇 초 만에 수행하는 교차 제약 검증을 통과하지 못하면서 열별 스캔만 통과하는 데이터를 일관되게 생성합니다.

5. 이전 지급 이월 문제

G702의 7행 — 이전 지급 증명서 차감 — 은 전체 지급 청구서 시스템에서 복합 오류의 가장 강력한 원천입니다. 이는 프로젝트에서 이전에 승인된 모든 지급의 합계를 나타냅니다. 첫 번째 지급 청구서의 경우 0입니다. 그 이후의 모든 청구서에 대해, 이는 마지막 승인된 G702의 6행(현재 지급 예정액)과 정확히 일치해야 합니다 — 마지막으로 제출된 것도, 마지막으로 초안이 작성된 것도 아닌, 마지막으로 인증된 것입니다.

실제로 이 문제가 어떻게 발생하는지 살펴보겠습니다. 3차 청구서가 $94,000 지급 요청으로 제출됩니다. 건축사는 불완전한 문서화로 $7,000를 보류하고 $87,000만 인증합니다. 하도급업체의 시스템은 제출된 $94,000를 이월 수치로 표시합니다. 4차 청구서가 7행에 $94,000로 도착합니다. 그러나 발주자의 기록 — 그리고 계약 — 에 따르면 올바른 이월 금액은 $87,000입니다. 7행 이후의 모든 숫자 — 현재 지급 예정액, 잔여 완료 금액 — 는 이제 $7,000만큼 부풀려집니다. 청구서는 거부됩니다.

이 오류는 인증된 수치가 한 곳(건축사가 서명한 G702)에 존재하는 반면, 추출 소스 — 일반적으로 하도급업체 또는 GC의 내부 청구 스프레드시트 — 는 제출된 수치를 추적하는 경우가 많기 때문에 전파됩니다. 여러 하도급업체의 지급 청구서를 단일 드로우 일정으로 통합할 때, 프로젝트 전체의 지급 청구서를 하나의 통합 드로우 일정으로 병합에 대한 가이드에서 다룬 것처럼, 각 하도급업체의 7행은 이전 주기의 인증된 버전과 개별적으로 검증되어야 합니다. 한 하도급업체의 이월 오류는 GC의 요약 G702로 연쇄적으로 전파되어 추적이 기하급수적으로 어려워집니다.

6. 검토 때까지 아무도 확인하지 않는 G702-G703 조정

G702 요약의 모든 수치는 G703에서 단일 출처를 갖습니다. 단 한 가지 예외가 있는데, 바로 G702 자체에만 존재하는 변경 명령 요약표에서 도출되는 2행입니다. 이로 인해 조정 사각지대가 발생합니다. G703 합계가 완벽하고 변경 명령 요약이 정확하더라도, 변경 명령 요약이 G703 변경 명령 라인 항목과 독립적으로 작성되었기 때문에 두 값이 여전히 어긋날 수 있습니다.

수동 워크플로에서 이 조정은 지루하지만 최소한 중앙 집중화되어 있습니다. 한 사람이 두 양식을 모두 작성하고 서로 대조합니다. 추출 워크플로에서는 G703 합계가 하도급업체 계속 시트를 읽는 AI 도구에서 나올 수 있는 반면, 변경 명령 요약은 프로젝트 관리자가 다른 형식으로 유지 관리하는 별도 로그에서 나옵니다. 두 데이터 스트림은 동일한 G702로 유입되지만 서로 교차 검증된 적이 없습니다. 그 결과 각 개별 섹션은 올바르게 검증되지만 전체적으로는 조정 불가능한 간극을 포함하는 양식이 됩니다.

이것은 추출 정확도의 실패가 아닙니다. 추출 아키텍처라고 부를 수 있는 것의 실패입니다. 즉, 어떤 소스가 어떤 출력 필드를 공급하고 워크플로의 어디에서 교차 검증이 발생하는지에 대한 설계입니다. 추출 도구가 G702/G703 처리에서 할 수 있는 가장 가치 있는 일은 99% 필드 수준 정확도를 달성하는 것이 아닙니다(물론 그것도 중요합니다). 양식 간 필드 간의 관계를 보존하여 하도급업체 G703의 3페이지에서 추출된 숫자가 GC G702의 4행까지 그 계보를 유지하고 불일치가 발생할 때 역추적될 수 있도록 하는 것입니다.

실질적인 결론: 건축가나 소유주가 수치에 대해 질문할 때, 해당 숫자가 어떤 소스 문서, 어떤 라인 항목, 어떤 열에서 왔는지 정확히 말할 수 있어야 합니다. "스프레드시트를 확인하고 다시 연락드리겠습니다"가 아니라요. 추적성 없는 추출은 수동 입력보다 크게 나을 것이 없습니다. 단지 동일한 분쟁을 더 빨리 만들어낼 뿐입니다.

추출 워크플로우에 검증 레이어 구축하기

위의 여섯 가지 오류 중 어느 것도 문자 수준에서 높은 정확도로 데이터를 추출하는 도구로는 방지할 수 없습니다. 이는 구조적 오류입니다 — 데이터가 원본 맥락에서 의미하는 바와 대상 양식에서 의미하는 바 사이의 불일치입니다. 이를 방지하려면 검증 레이어, 즉 추출 후 제출 전에 실행되는 일련의 교차 검증이 필요합니다.

최소한 이 레이어는 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'"를 계산하는 열을 정의하고 조정 오류가 있는 모든 청구서를 인간 검토에 도달하기 전에 플래그할 수 있습니다. 도구는 이 비교를 실행하기 위해 건설 청구를 이해할 필요가 없습니다 — 두 추출 값이 동일해야 한다는 것과 그렇지 않을 때 경고하는 것만 이해하면 됩니다.

자주 묻는 질문

계산이 맞는데도 지급 청구서가 거부되는 이유는 무엇인가요?

정확한 산술이 정확한 데이터와 같지 않기 때문입니다. 가장 흔한 원인은 문서에 명시된 내용과 건축가 또는 소유주 대리인이 프로젝트 진행 상황에 대한 독립적인 지식을 바탕으로 기대하는 내용 사이의 불일치입니다. 일반적인 원인으로는 현장 관찰과 일치하지 않는 누계 합계, 승인 없이 포함된 변경 명령, 잘못된 기준으로 계산된 보류금, 또는 7번 줄(이전 지급액)이 마지막 인증된 신청서와 일치하지 않는 경우가 있습니다. 수학은 완벽할 수 있지만 데이터 계보가 잘못될 수 있습니다.

G702와 G703의 차이점은 무엇이며, 추출에 왜 중요한가요?

G702는 요약 표지 시트로, 총 계약 금액, 보류금, 이전 지급액, 현재 지급 예정액을 단일 페이지 형식으로 보여줍니다. G703은 계약을 가치 명세서의 개별 라인 항목으로 나누는 계속 시트로, 비용에 대한 상세하고 항목별 세분화를 제공합니다. G702의 모든 숫자(변경 명령 요약 제외)는 G703으로 추적 가능해야 합니다. 데이터를 추출할 때 G703은 라인 항목 수준 수치의 진실 원천이고, G702는 해당 수치가 요약되는 곳입니다. 두 양식을 독립적으로 추출하고 연결하지 않으면 조정 오류가 불가피해집니다.

AI 추출 도구가 여러 라인 항목에 걸쳐 다양한 보류금 비율을 처리할 수 있나요?

도구에 따라 다릅니다. 일부 도구는 페이지에 인쇄된 내용만 추출하여 G703의 I열에 나타나는 보류금 수치를 충실히 캡처하지만, 해당 수치가 계약에 따라 올바르게 계산되었는지 검증할 수는 없습니다. 다른 도구는 계산 열을 정의할 수 있게 해줍니다. 예를 들어, "보류금 확인(G열 × 0.10)"이라는 열을 만들어 누계 합계에서 예상 보류금을 계산하고 불일치를 표시할 수 있습니다. 이 검증 접근 방식은 읽고 있는 문서 외부에 존재하는 계약상 비율을 도입하기 때문에 순수 추출로는 잡을 수 없는 오류를 포착합니다.

G702/G703 제출 시 항상 첨부해야 하는 지원 문서는 무엇인가요?

AIA A201-2017 섹션 9.3.1은 지급 청구서에 채권 포기 및 면제 문서를 첨부하도록 요구합니다. 법적 최소 요건 외에도 대부분의 프로젝트에서는 공인된 급여 보고서(정부 지원 사업의 경우), 진행 사진, 보관 자재 증빙(납품 영수증, 창고 문서), 그리고 원래 범위를 벗어난 작업에 대한 서명된 변경 명령이 필요합니다. 문서 누락은 데이터 오류와 별개로 지급 일정에 동일하게 치명적인 영향을 미치는, 거부의 가장 흔한 절차적 사유입니다.

지급 청구서에 보류 중인 변경 명령을 포함해도 안전한가요?

아니요. 승인되지 않은 변경 명령을 G703 라인 항목이나 G702 변경 명령 요약에 포함하는 것은 지급 청구서가 거부되는 가장 빠른 경로 중 하나입니다. AIA A201-2017 섹션 7.3.9에 따라 지급 청구서에는 건설 변경 지시에 따라 적절히 승인되었으나 아직 변경 명령에 포함되지 않은 변경 사항에 대한 지급 요청이 포함될 수 있습니다. 그러나 이는 제한적인 예외일 뿐, 포괄적인 허용이 아닙니다. 가장 안전한 방법은 보류 중인 변경 명령을 별도 로그에 기록하고 공식 승인 후에만 G703으로 이동하는 것입니다. 서명된 승인 없이 작업에 대해 청구하면 계약 분쟁이 발생할 뿐만 아니라 많은 주에서 유치권 권리 문제가 발생합니다.