G702 추출 오류
페이앱 분쟁을 유발하는 흔한 실수들

G702/G703 양식에 관한 대부분의 가이드는 당연한 것에 초점을 맞춥니다: 계산 확인, 마감일 준수, 하도급 포기각서 포함. 물론 중요합니다. 하지만 수기로 양식을 작성하는 단계에서 PDF와 스프레드시트에서 데이터를 추출하여 하나의 기성청구서로 만드는 단계로 넘어가거나, 원도급자가 20개 하도급사의 제출물을 하나의 기성 공정표로 통합할 때는 다른 종류의 오류가 지배적입니다. 계산기 결과는 깔끔해도 살아남는 오류들입니다. 합계 자체를 잘못 내는 문제가 아니라, 애초에 합계에 잘못된 숫자가 들어가는 문제이기 때문입니다.

숫자는 맞는데 기성청구가 반려될 때

건설 청구 관리를 여러 번 해본 사람이라면 누구나 겪는 특별한 좌절감이 있습니다: 모든 합계를 확인하고, 유보금 계산도 맞고, G703 총계가 G702의 4번 항목과 일치하는데 — 건축가나 발주처 담당자가 특정 숫자에 물음표를 표시하며 다시 보내는 경우입니다. 문제는 계산이 틀린 것이 아닙니다. 문제는 원본 문서와 최종 양식 사이 어딘가에서 숫자가 값은 그대로인 채 의미가 바뀌어 버렸다는 데 있습니다.

이것이 표면적인 양식 오류와 추출 오류를 구분하는 핵심입니다. 표면 오류(숫자 전위, 뺄셈 누락)는 스스로 드러납니다. 추출 오류는 단독으로 보면 정확해 보입니다. 누군가가 그 숫자를 출처까지 추적하여 양식에 기재된 내용과 원본이 일치하지 않는다는 것을 발견해야만 비로소 드러납니다. 이 여섯 가지 가장 흔한 발생 방식을 이해하는 것이 1차 검토를 통과하는 기성청구서와 한 번의 청구 주기를 날리는 분쟁을 초래하는 기성청구서의 차이를 만듭니다.

1. 누계 vs. 당기 추출 함정

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의 다른 행에 서로 다른 유보율이 적용되는 상황이 발생합니다.

주법(州法)이 또 다른 복잡성을 더합니다. 뉴욕주는 이제 15만 달러를 초과하는 민간 건설 계약의 유보금을 5%로 제한하며, 이를 초과하는 계약 조항은 무효입니다. 일리노이주는 계약 전반기에는 10%를 허용하지만, 이후에는 5%로 낮추도록 규정합니다. 노스캐롤라이나주는 10만 달러 미만 프로젝트의 유보금을 전면 금지합니다. 추출 워크플로가 이러한 법률이 적용되는 프로젝트에 일괄적으로 10%를 적용하면, 실제 원천징수 금액과 계약상 법적 허용 금액 간의 불일치로 즉시 분쟁이 발생하며, 일부 관할권에서는 법적 위반이 됩니다.

CFMA(건설 재무 관리 협회)는 오류와 조정 문제로 인해 잘못된 보고와 의사 결정 지연만으로도 프로젝트 비용이 2~5% 증가할 수 있다고 문서화했습니다. 500만 달러 규모의 프로젝트의 경우 이는 10만~25만 달러의 완전히 피할 수 있는 비용이며, 대부분은 지급 흐름을 따라 흘러가지 못하고 분쟁 상태에 묶여 있는 자금에서 비롯됩니다.

3. G702와 G703 간에 차이가 발생하는 변경명령 데이터

G702에는 변경명령 요약표가 포함되어 있으며, 이는 2행(변경명령에 의한 순변경액)과 최종적으로 3행(현재까지 계약금액)에 반영됩니다. 한편, 승인된 변경명령은 G703에 추가 라인 항목으로 표시되며, 각각 고유한 기성금액과 진행률 추적이 있습니다. 이 두 표현은 일치해야 합니다. 즉, G703의 모든 변경명령 라인 항목 합계는 G702 변경명령 요약표를 통해 2행으로 유입되는 금액과 일치해야 합니다.

여러 출처에서 변경명령 데이터를 추출할 때, 두 가지 문제가 자주 발생합니다. 첫째는 미승인 변경명령을 합계에 포함하는 것입니다. 하청업체가 총 $35,000에 달하는 5건의 보류 중인 변경명령을 G703에 라인 항목으로 포함하는 경우가 있는데, 이는 AIA의 G703 지침에서 변경명령은 "별도의 G703 양식에 따로 기재하거나 기본 공정표 끝에 나열"하도록 경고하는 방식입니다. 원도급업체나 건축가가 하청업체의 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)에 존재하는 반면, 추출 출처(일반적으로 하청업체나 원도급업체의 내부 청구 스프레드시트)는 제출된 금액을 추적하기 때문에 전파됩니다. 전체 프로젝트의 기성 청구를 하나의 통합 지급 일정으로 병합하는 방법에 대한 가이드에서 다루듯이, 여러 하청업체의 기성 청구를 단일 지급 일정으로 통합할 때 각 하청업체의 7번 항목은 이전 주기의 인증된 버전과 개별적으로 확인되어야 합니다. 한 하청업체의 이월 오류는 원도급업체의 요약 G702로 전파되어 추적이 기하급수적으로 어려워집니다.

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

G702 요약의 모든 수치는 G703에서 단일 출처를 가집니다. 단, 한 가지 예외는 2행으로, 이는 G702 자체에만 존재하는 변경 명령 요약표에서 파생됩니다. 이로 인해 조정 사각지대가 발생합니다. G703 합계가 완벽하고 변경 명령 요약이 정확하더라도, 변경 명령 요약이 G703 변경 명령 라인 항목과 독립적으로 채워졌다면 두 값은 여전히 차이를 보일 수 있습니다.

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

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

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

추출 워크플로에 검증 계층 구축하기

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

최소한 이 단계에서는 G703의 G열 합계가 G702의 4행 값과 일치하는지, 각 G703 행의 retainage가 해당 행의 G열( E열이 아님)에 계약 비율을 곱한 값과 일치하는지, G702의 변경 주문 요약 합계가 G703의 변경 주문 라인 항목 합계와 일치하는지, 저장 자재가 예정 값을 초과하는 라인 항목이 없는지, 7행이 이전 승인 신청서의 인증된 6행과 일치하는지 확인해야 합니다. 이는 복잡한 계산이 아닙니다. 수행하는 데 몇 초밖에 걸리지 않는 비교일 뿐입니다. 하지만 청구 주기 마지막 날 오후 11시에 "제출" 버튼을 누르는 사람에게 맡겨서는 안 되며, 워크플로우에 내장되어야 합니다.

많은 신청서를 처리하는 팀(매달 15~20개의 하청업체 지급 신청서를 받는 일반 계약자)의 경우 AIA G702/G703 데이터를 스프레드시트로 자동 추출하면 수동 입력 단계가 사라지지만 검증 단계는 여전히 필수적입니다. 추출은 데이터를 구조화된 형태로 만듭니다. 검증 단계는 신청서가 건축가의 책상에 도착하기 전에 그 구조가 자체적으로 일관성이 있는지 확인합니다.

일부 추출 도구를 사용하면 계산된 열(문서에서 직접 읽는 것이 아니라 추출된 다른 데이터에서 파생된 값이 있는 필드)을 정의할 수 있습니다. 이 기능은 내장된 검증 메커니즘 역할을 할 수 있습니다. "IF G703_ColumnG_Total ≠ G702_Line4 THEN '불일치' ELSE '정상'"을 계산하는 열을 정의하고, 사람이 검토하기 전에 조정 오류가 있는 모든 신청서에 플래그를 지정할 수 있습니다. 도구가 이 비교를 실행하기 위해 건설 청구를 이해할 필요는 없습니다. 두 추출 값이 같아야 한다는 것만 이해하고, 그렇지 않을 때 경고하면 됩니다.

자주 묻는 질문

계산이 맞는데도 기성 신청이 거절되는 이유는 무엇인가요?

올바른 산술이 올바른 데이터와 같은 것은 아니기 때문입니다. 가장 흔한 원인은 문서에 명시된 내용과 건축가 또는 발주처 담당자가 프로젝트 진행 상황에 대한 독립적인 지식을 바탕으로 기대하는 내용 간의 불일치입니다. 일반적인 원인으로는 현장 관찰과 일치하지 않는 누적 합계, 승인 없이 포함된 변경 명령, 잘못된 기준으로 계산된 유보금, 또는 7항(기지급액)이 마지막으로 인증된 신청서와 일치하지 않는 경우 등이 있습니다. 계산은 완벽하더라도 데이터 계보가 잘못될 수 있습니다.

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

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

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

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

G702/G703 제출 시 항상 함께 제출해야 하는 증빙 서류는 무엇인가요?

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

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

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