AIA G702 & G703 데이터 추출 완벽 가이드
모든 것을 한 번에
모든 G702 지급 신청서는 동일한 이야기를 담고 있습니다: 시공사가 일정 비율의 공사를 완료했고, 일정 금액을 벌었으며, 특정 금액의 지급을 요청합니다. 이 이야기는 표준화되어 있습니다. 문제는 이 동일한 이야기가 세 명의 다른 사람에 의해 세 개의 다른 시스템에 입력된 후에야 지급이 이루어진다는 점입니다. 5개의 활성 상업 프로젝트를 관리하는 일반 시공사는 매 청구 주기마다 10~50개의 G702/G703 패키지를 받습니다. 각 패키지에는 요약 페이지, 20~50개 라인 항목이 있는 계속 시트, 그리고 프로젝트 예산과 대조하여 확인, 전사, 조정해야 하는 약 300개의 개별 숫자 값이 포함되어 있습니다. 이 가이드는 한 번에 해당 데이터를 추출하는 데 필요한 모든 것을 다룹니다: 중요한 양식 구조, 모든 추출이 반드시 캡처해야 하는 필드, 지급 지연을 방지하는 양식 간 검증, 그리고 픽셀 위치가 아닌 의미를 기준으로 G702/G703 패키지를 읽는 도구에 대해 설명합니다.
핵심 요약
- 매 청구 주기마다 일반 시공사는 약 12,000개의 지급 신청 값을 수동으로 스프레드시트에 전사하며, 일반적인 건설 업계 오류율을 감안하면 검토가 시작되기도 전에 60~300개의 값이 잘못 입력됩니다.
- G702와 G703은 함께 제출되는 두 개의 독립적인 양식이 아니라 동일한 데이터의 두 가지 보기입니다. 모든 G703 열 합계는 특정 G702 요약 라인과 일치해야 하지만, 각 페이지를 개별적으로 읽는 템플릿 기반 추출 도구는 이러한 산술적 불일치를 감지할 수 없습니다.
- 추출이 두 양식을 연결된 부모-자식 데이터 구조로 읽을 때, 30일 지급 재제출 주기를 유발하는 양식 간 검증이 검토자가 스프레드시트를 열기 전에 자동으로 실행됩니다.
AIA G702 및 G703 양식이란?
AIA G702(공식 명칭: 지급 신청 및 인증서)는 미국의 사실상 모든 상업 건설 프로젝트에서 사용되는 표준 진행 청구 양식입니다. 그와 함께 사용되는 G703 연속 시트는 요약 금액을 뒷받침하는 항목별 내역을 제공합니다. 이 두 양식은 업계에서 지급 신청 패키지라고 부르는 것을 구성합니다. 미국 건축가 협회(AIA)가 개발하고 저작권을 소유한 이 양식은 진행 지급을 요청하기 위한 통일된 구조를 만듭니다. 20만 달러 규모의 소규모 임대 공간 인테리어 공사든 2억 달러 규모의 대형 병원 프로젝트든 동일한 형식이 사용됩니다.
G702는 프로젝트 수준의 재무 현황을 한 장에 요약한 단일 페이지 양식입니다. 최초 계약 금액, 승인된 변경 명령으로 인한 조정, 현재까지 완료된 공사 및 현장 반입 자재의 총 가치, 원청 공제액, 기 수령한 지급액, 그리고 현재 지급해야 할 순 금액을 기록합니다. 건축가나 발주자가 이 양식을 인증하면 지급이 이루어집니다. 이론상으로는 30일 이내이지만, 실제로는 오류로 인해 재제출이 발생하는 경우 더 오래 걸리는 경우가 많습니다.
G703 연속 시트는 세부 내역이 기록되는 곳입니다. 각 행은 프로젝트의 공사비 내역서(SOV)에 있는 하나의 항목을 나타내며, 각 열은 해당 항목의 재무 진행 상황(계획 금액, 이전 기간 완료 공사, 당기 완료 공사, 현장 반입 자재, 누계, 완료율, 잔여 공사 금액, 원청 공제액)의 다양한 측면을 추적합니다. 30개 항목이 있는 G703에는 약 270개의 개별 데이터 포인트가 포함되며, 이 모든 숫자는 G702 요약에 반영됩니다. 두 양식은 독립적인 문서가 아니라 부모-자식 데이터 구조로, G702의 합계는 G703의 총합계와 일치해야 합니다. 일치하지 않으면 지급 신청은 반려되어 지급되지 않습니다.
G702/G703 데이터 추출은 최근 몇 년 동안 세 가지 상호 연관된 이유로 주목을 받고 있습니다. 첫째, GC(원청업체)가 처리하는 지급 신청 건수는 프로젝트가 진행됨에 따라 증가하며, 전문화가 심화됨에 따라 일반적인 상업 프로젝트에 참여하는 하청업체의 수도 늘어났습니다. 둘째, Procore, Viewpoint, Sage 300 CRE, CMiC와 같은 건설 회계 및 프로젝트 관리 플랫폼은 구조화된 데이터를 필요로 합니다. 이 플랫폼들은 작성된 PDF 양식을 그대로 가져와서 작업 원가 원장에 자동으로 입력할 수 없습니다. 셋째, 템플릿 위치를 일치시키는 대신 양식의 의미를 이해하여 이러한 양식을 읽을 수 있는 AI 도구는 불과 지난 18~24개월 사이에야 신뢰할 수 있는 정확도 수준에 도달했습니다. 양식 자체는 변하지 않았습니다. 데이터를 추출하는 능력이 발전한 것입니다.
G702/G703 처리 비용이 생각보다 더 많이 드는 이유
기성 청구서 처리의 눈에 보이는 비용은 PDF를 열고, 숫자를 읽고, 스프레드시트에 입력하는 데 걸리는 시간입니다. 30개 라인 항목의 G703이 포함된 단일 청구서의 경우, 유능한 프로젝트 회계사는 이 작업을 완료하는 데 약 30~45분이 소요됩니다. 숨겨진 비용은 이 작업 주변에서 발생합니다. 월별 기성 마감일로 인해 모든 청구서가 3일 창구로 압축되고, 유보금 오류로 인해 30일 지급 시계가 초기화되는 재제출 주기가 발생하며, 양식 간 불일치로 인해 하도급업체와의 조정 전화가 필요하고, AIA 양식 자체도 새 프로젝트를 시작할 때마다 비용이 발생합니다. 개별적으로는 이러한 비용이 적습니다. 하지만 합산하면 많은 중견 건설사의 정규직 직원 한 명의 연봉에 맞먹습니다.
월별 기성 주기. 상업용 건설 기성 청구서는 고정된 월별 주기를 따릅니다. 하도급업체는 마감일(보통 매월 20일 또는 25일)까지 기성 청구서를 제출합니다. 원도급사는 이를 검토, 확인하고 월말까지 통합하여 발주처에 기성 요청서를 제출합니다. 승인되면 발주처의 지급은 30~45일 후에 이루어집니다. 마감일을 놓치면 하도급업체의 지급은 한 번의 청구 주기(30일 대기에서 60일 대기)만큼 지연됩니다. 프로젝트 회계사가 4일 동안 40개의 기성 청구서를 수동으로 처리할 때, 한두 개의 마감일을 놓칠 위험은 이론적인 것이 아닙니다. 1,558개 기업의 2024 회계연도 데이터를 기반으로 한 건설 재무 관리 협회의 2025 재무 벤치마커에 따르면, 일반적인 건설 회사의 세전 순이익 마진은 6.7%입니다. 모든 지연된 청구서, 모든 수정 주기, 모든 재제출은 이 마진을 직접적으로 잠식합니다.
유보금 계산 오류. 유보금(프로젝트 완료 시까지 각 지급액의 일정 비율을 보류하는 것)은 기성 청구서 분쟁의 가장 흔한 원인입니다. 대부분의 계약은 완료된 작업 및 저장된 자재의 총 가치에 적용되는 고정 비율(일반적으로 5% 또는 10%)을 명시합니다. 그러나 계산이 "G702의 4번 라인에서 10%를 가져간다"처럼 단순한 경우는 드뭅니다. 많은 계약에서 가변 유보금을 사용합니다. 작업이 50% 완료되면 비율이 10%에서 5%로 줄어들거나, 저장된 자재에 대한 유보금이 설치된 작업에 대한 유보금과 다른 비율로 계산됩니다. 일부 주에서는 법정 유보금 한도를 부과합니다. 캘리포니아는 민간 프로젝트에서 50% 완료 후 유보금을 5%로 제한하여 계약 비율을 무효화합니다. 계약이 5%를 명시했는데 하도급업체가 유보금을 10%로 계산하면 기성 청구서가 과다 청구된 것이며, 전체 패키지가 수정을 위해 반송됩니다. 오류는 대개 소액(수천 달러)이지만, 재제출 지연으로 인해 프로젝트의 모든 이해관계자에게 2~4주의 시간이 소요됩니다.
G702-G703 교차 검증. G702 요약은 G703 라인 항목 합계에서 숫자를 가져옵니다. G702 4행의 "현재까지 완료 및 보관된 총액"은 G703 G열의 총합계와 일치해야 합니다. G702 5행의 유보금은 G703 I열의 총합계(또는 G703 합계에 적용된 고정 비율 계산)와 일치해야 합니다. 프로젝트 회계사가 이 숫자를 수동으로 옮겨 적을 때 가장 흔한 오류는 G703의 누적 합계를 잘못된 G702 행에 입력하는 것입니다 — 완료된 총액을 유보금 필드에 입력하거나, 이전 인증서를 현재 지불 예정액으로 입력하는 경우입니다. 양식 자체에는 산술이 내장되어 있습니다: 6행에서 7행을 빼면 8행이 되고, 3행에서 6행을 빼면 9행이 됩니다. 단일 필드의 전사 오류는 모든 파생 행에 연쇄적으로 영향을 미쳐 내부적으로 산술이 일관되지 않은 G702를 생성합니다. 신청서를 검토하는 건축가는 몇 초 만에 불일치를 발견하고 전체 패키지를 거부합니다.
AIA 양식 비용. 일반 구매 주문서나 납품서와 달리 AIA 양식은 저작권이 있는 문서입니다. AIA 계약 문서를 통해 일회용으로 구매하는 단일 G702/G703 세트의 가격은 약 $49.99이며, 연간 약 $500부터 시작하는 AIA 소프트웨어 구독을 통해 대량 구매 시 세트당 약 $15~$25입니다. 5개 프로젝트에서 50명의 활성 하청업체를 관리하는 GC의 경우 연간 양식 비용은 $750~$2,500입니다. 이는 큰 금액은 아니지만, GC가 이미 처리해야 하는 청구 데이터 형식을 표준화하는 것 외에는 가치를 더하지 않는 지속적인 운영 비용입니다.
G702/G703 처리의 실제 비용은 입력 시간이 아닙니다. 오류 주기로 인한 지연의 누적입니다: 단 한 번의 유보금 비율 계산 실수로 하청업체의 지불이 30일 지연될 수 있으며, 청구 주기당 3~4건의 신청에서 이런 일이 발생하면 총 유동성 손실은 자동 추출 도구의 연간 비용을 초과합니다.
G702/G703 상위-하위 구조: 요약 페이지와 연속 시트의 관계
이 양식들에서 데이터를 추출할 때 각 페이지를 독립적으로 읽는 것만으로는 충분하지 않은 이유를 이해하려면 먼저 이들의 구조적 관계를 이해해야 합니다. G702와 G703은 함께 제출되는 두 개의 개별 양식이 아닙니다. 이는 동일한 재무 데이터를 두 가지 관점에서 보여주며, 신뢰할 수 있는 추출 도구가 반드시 읽고 검증해야 하는 일련의 산술적 제약 조건으로 연결되어 있습니다.
G702는 상위 양식으로, 전체 계약에 대한 9개 항목의 재무 요약을 제공합니다. 각 항목은 다음과 같습니다:
항목 1: 최초 계약 금액
항목 2: 변경 명령에 의한 순 변경액
항목 3: 현재까지의 계약 금액 (항목 1 + 항목 2)
항목 4: 현재까지 완료 및 저장된 총액 (G703 합계에서 가져옴)
항목 5: 유보금 (일반적으로 항목 4의 5-10%)
항목 6: 유보금 차감 후 총 기성액 (항목 4 − 항목 5)
항목 7: 기 지급 증서 차감
항목 8: 현재 지급 예정액 (항목 6 − 항목 7)
항목 9: 유보금 포함 잔여 금액 (항목 3 − 항목 6)이 9개 항목 중 3개는 G703에서 가져옵니다(항목 4, 그리고 연장선상에서 항목 5~9). 4개는 산술적으로 파생됩니다(항목 3, 6, 8, 9). 2개는 계약서의 고정 입력값입니다(항목 1, 2). G702 표지 시트만 읽는 추출 도구는 요약 수치를 얻을 수 있지만, 이를 원천 데이터와 대조하여 검증할 수 없습니다. 또한 데이터를 세분화하여 볼 수 있는 유일한 장소인 G703을 놓치게 됩니다.
G703은 하위 양식으로, 각 행이 공사비 내역 항목이고 각 열이 해당 항목의 청구 기간별 재무 진행 상황을 추적하는 가변 길이 테이블입니다. 표준 G703 연속 시트는 데이터를 다음 열로 구성합니다:
A: 항목 번호
B: 공사 내용
C: 공사비 배정액
D: 이전 기성 신청까지 완료된 공사
E: 이번 기간에 완료된 공사
F: 현재 현장 보관 자재
G: 현재까지 완료 및 저장된 총액 (D + E + F)
G%: 공정률 (G ÷ C)
H: 잔여 금액 (C − G)
I: 유보금 (변동 비율, 또는 고정 비율 프로젝트의 경우 공란)G703의 각 행은 해당 특정 공사 범위에 대한 소규모 재무제표입니다. G열의 총합은 G702의 항목 4와 일치해야 합니다. I열의 총합은 항목 5와 일치해야 합니다. 이러한 양식 간 제약 조건이 기성 신청 데이터 추출을 일반 청구서 추출과 다르게 만드는 이유입니다. 단일 문서에서 필드를 읽는 것이 아니라 두 부분으로 구성된 데이터 구조를 읽고 두 부분 간의 산술적 일관성을 검증하는 것입니다. 실제로 이 추출이 어떻게 작동하는지 단계별로 알아보려면 AIA G702 기성 신청 데이터를 스프레드시트로 추출하는 방법에 대한 상세 가이드를 참조하십시오.
기성청구 데이터 추출의 숨은 과제
양식이 올바르게 작성된 경우에도 G702/G703 패키지에서 데이터를 추출하는 것은 다른 건설 문서 유형에는 없는 과제를 제시합니다. 이러한 과제는 기성청구를 대규모로 처리해 본 사람이 아니라면 바로 인식하기 어렵습니다.
수기 작성된 변경 주문 및 수량. 디지털 AIA 양식이 널리 보급되었음에도 불구하고, 상당수의 하도급업체 기성청구는 수기로 작성된 항목이 포함되어 도착합니다. 현장에서 주석이 추가된 G703은 흔합니다. 하도급업체의 프로젝트 관리자가 기성금액 내역서를 출력하고, 당기 수량을 손으로 기입하며, 여백에 완료율을 계산하고, 주석이 추가된 시트를 스캔하여 PDF로 만듭니다. 여러 프로젝트에 걸쳐 작업하는 하도급업체는 AIA 변경 주문 요약표를 사용하는 대신, 단일 수기 주석 변경 주문 로그를 준비하여 기성청구에 첨부할 수 있습니다. 전통적인 OCR 및 템플릿 기반 추출 도구(페이지의 픽셀 위치로 데이터 필드를 찾는 도구)는 수기 값이 레이아웃을 변경하기 때문에 이러한 문서에서 제대로 작동하지 않습니다. 수량 열에 수기로 "1,247"이라고 쓰여 있으면 인접한 금액이 한 셀 오른쪽으로 밀리고, 템플릿 추출은 문제가 발생했다는 신호 없이 잘못된 값을 반환합니다. 반면, 비전 기반 AI 추출은 각 값을 의미론적 맥락에서 읽습니다. "이 기간 완료된 작업" 열의 숫자를 페이지 상단의 픽셀 오프셋을 측정하여 식별하는 것이 아니라, 해당 숫자가 "이 기간 완료된 작업"이라는 헤더가 있는 열에 있다는 것을 이해하여 식별합니다.
CSI MasterFormat 코드. 대부분의 G703 계속 시트는 CSI MasterFormat 구분 번호(Construction Specifications Institute에서 유지 관리하는 표준화된 분류 시스템)를 사용하여 라인 항목을 구성합니다. 일반적인 G703은 "03 30 00 — 현장 타설 콘크리트", "08 11 00 — 금속 문 및 프레임", "23 31 00 — HVAC 덕트", "26 10 00 — 중전압 전기"와 같은 라인 항목을 나열할 수 있습니다. 이러한 코드는 작업 원가 계산에 의미가 있습니다. 프로젝트 회계사는 콘크리트 작업에 47,000달러가 일반 범주인 "콘크리트"가 아닌 원가 코드 03 30 00에 속한다는 것을 알아야 합니다. 라인 항목 설명을 구조화되지 않은 텍스트로 캡처하는 추출 도구는 구조화된 원가 코드를 잃게 됩니다. MasterFormat 계층 구조를 인식하는 도구는 구분 번호를 별도의 열로 출력하여 라인 항목 청구와 작업 원가 할당 간의 매핑을 보존할 수 있습니다. CSI가 Construction Specifications Canada와 협력하여 발표한 현재 MasterFormat 2026판은 건설 사양을 Division 00(조달 및 계약 요구 사항)부터 Division 49까지 50개 구분으로 구성하며, 2026년 업데이트에서 약 2,185개의 새로운 목록이 추가되었습니다.
변경 주문에 따른 계약 금액 추적. 건설 프로젝트가 원래 계약 금액으로 완료되는 경우는 거의 없습니다. 변경 주문은 프로젝트가 진행됨에 따라 작업을 추가하거나, 공제하거나, 가격을 조정합니다. G702는 라인 1, 2, 3을 통해 이를 추적합니다. 원래 금액, 순 변경액, 조정된 총액입니다. 그러나 G702의 변경 주문 요약은 단일 숫자에 불과합니다. 개별 변경 주문이나 그 상태(승인됨, 보류 중, 분쟁 중)를 나열하지 않습니다. 하도급업체는 종종 별도의 변경 주문 로그 또는 CO 전달 시트를 기성청구 패키지에 첨부합니다. G702 필드만 캡처하는 추출 워크플로우는 프로젝트 회계사가 순 변경액이 올바른지 확인하는 데 필요한 뒷받침 세부 정보를 놓칩니다. 계약 데이터 추출에 대한 더 넓은 교훈이 여기에 적용됩니다. 구조화된 추출은 요약 문서뿐만 아니라 이를 구성하는 뒷받침 문서도 읽을 때 가장 잘 작동합니다.
교차 양식 검증의 복잡성. G702와 G703 간의 산술적 제약 조건은 단순한 열 합계 일치를 넘어섭니다. 현재 기성 청구서의 G703 D열(이전 기성 완료 작업)은 이전 기성 청구서의 G703 G열(현재까지 완료 및 저장된 총계)에서 이전 기간의 F열(저장 자재)을 뺀 값과 일치해야 합니다. 하청업체가 프로젝트 중간에 기성 가치 일정을 변경하여 단일 라인 항목을 분할하거나 작업 범위 간 가치를 재배분하는 경우, 이 이월 값이 깨지며 원도급업체는 수동으로 불일치를 조정해야 합니다. 각 기성 청구서를 독립적인 문서로 처리하는 추출 도구는 이러한 불일치를 감지하지 못합니다. 연속적인 기성 청구서를 읽고 이월 값을 비교하는 도구만이 이를 감지할 수 있습니다.
전통적 방식 vs. AI: 기성 청구서 추출의 두 가지 접근법
전통적 기성 청구서 추출과 AI 기반 추출의 차이는 속도의 문제가 아닙니다. 두 방식 모두 페이지를 몇 초 안에 처리할 수 있습니다. 차이는 변형, 오류, 그리고 교차 양식 관계를 처리하는 방식에 있습니다.
스프레드시트 조회를 통한 수동 복사-붙여넣기. 전통적인 접근법: 하청업체의 G702 PDF를 열고 4행(완료 및 저장된 총계)을 읽어 프로젝트 추적 스프레드시트의 해당 하청업체 행에 입력합니다. G703을 열고 첫 번째 라인 항목부터 시작하여 항목 번호, 설명, 예정 가치, 이전 기성 완료, 당기, 저장, 합계, 백분율, 잔액, 유보금 등 30개 행에 대해 행당 10개 필드를 입력합니다. 이번 회기에 기성 청구서를 제출하는 40개 하청업체 각각에 대해 이 과정을 반복합니다. 이 과정은 간단하며 소프트웨어 투자가 필요 없습니다. 그러나 청구 주기마다 최소한 몇 건의 전사 오류가 발생합니다. 건설 공학 및 관리 저널에 발표된 건설 산업 데이터 입력 정확도 연구에 따르면, 수치 건설 데이터의 수동 전사는 필드당 0.5~2.5%의 오류율을 발생시킵니다. 애플리케이션당 300개 값, 40개 애플리케이션 기준으로 청구 주기당 60~300개의 오류가 발생합니다. 대부분은 작은 오류지만, 일부는 그렇지 않습니다.
템플릿 기반 OCR. Docparser와 같은 템플릿 기반 추출 도구와 전통적인 OCR 플랫폼은 전사 문제를 해결하지만 유지 관리 문제를 야기합니다. G702 요약 페이지용 템플릿을 생성합니다: 위치(x=200, y=150)에 원래 계약 금액을 캡처하는 영역을 정의하고, 위치(x=200, y=180)에 순 변경 명령을 위한 또 다른 영역을 정의하는 식으로 9개 라인 모두에 대해 설정합니다. G703 테이블용 두 번째 템플릿을 생성합니다: 테이블 테두리를 기준으로 픽셀 좌표로 테이블 셀을 캡처하는 열 영역을 정의합니다. 템플릿은 첫 번째 하청업체가 디지털로 제출한 양식에 완벽하게 작동합니다. 두 번째 하청업체가 인쇄 중 테이블이 왼쪽으로 3밀리미터 이동한 스캔된 G703을 제출하면 실패합니다. 세 번째 하청업체가 양식 필드 위치를 약간 다르게 지정하는 다른 PDF 편집기를 사용하면 실패합니다. 손으로 작성된 G703이 도착하여 테이블 구조가 불규칙하면 완전히 실패합니다. 각 실패는 새 템플릿이나 기존 템플릿 조정을 필요로 하며, 조정은 이전에 작동하던 양식에 대한 적용 범위를 깨뜨립니다.
의미 기반 AI를 활용한 사용자 정의 열 추출. 최신 비전 기반 추출은 G702/G703 양식에서 각 필드가 페이지 상의 위치가 아닌 의미를 이해하여 데이터를 읽습니다. 이것이 바로 사용자 정의 열 추출입니다: 출력 스프레드시트에 원하는 열 — "원 계약 금액", "완료 및 기성 총액", "유보금 비율", "항목 번호", "설명", "계획 금액", "이번 기간 완료 작업", "현재까지 완료 누계", "잔여 금액" — 을 정의하면, AI가 전체 문서를 읽고 양식 내 각 열의 의미적 역할에 따라 해당 값을 식별하여 구조화된 행으로 출력합니다. 첫 번째 하청업체의 디지털 G702와 두 번째 하청업체의 수기 스캔본 모두 동일한 출력 열을 생성합니다. AI가 "유보금"이 무엇인지 알기 때문이지, 그것이 일반적으로 어디에 나타나는지를 알기 때문이 아닙니다.
다양한 추출 도구가 AIA G702 양식과 다른 건설 문서 유형을 어떻게 처리하는지 실질적으로 비교하려면, 2026년 건설 분야 최고의 문서 추출 소프트웨어 기사에서 8개 플랫폼을 35개의 공통 건설 문서 테스트 세트로 테스트하고 기성 청구서에 특화된 필드 수준 정확도 벤치마크를 제공합니다.
근본적인 아키텍처 차이: 템플릿 기반 추출은 모든 양식이 학습된 템플릿과 동일할 때만 작동합니다. 의미 기반 추출은 모든 양식이 동일한 정보를 포함하지만 다른 레이아웃, 다른 인쇄 품질 또는 다른 완성 상태로 제시될 때 작동합니다. 기성 청구 패키지는 동일하지 않습니다 — 그러나 그 안에 포함된 데이터는 동일합니다.
계산 열: 산술 루프 닫기
G702/G703 추출에서 가장 유용한 기능 중 하나는 추출 후 스프레드시트 수식이 아닌 추출 과정 중에 파생 값을 계산하는 열을 정의하는 기능입니다. 이것이 계산 열의 영역입니다 — AI가 추출된 다른 값에 대해 지정된 계산을 수행하고 결과를 데이터 행의 일부로 출력하는 열입니다.
기성 청구 추출에 특히 유용한 세 가지 계산 열은 다음과 같습니다:
- 유보금 검증 — 추출된 "현재까지 완료 및 기성 총액"에 계약상 유보금 비율을 곱하는 계산 열을 정의합니다. G702에 명시된 유보금 금액이 이 계산 값과 작은 허용 오차(예: $1.00) 이상 차이가 나면, 추출 시 불일치를 플래그 지정하여 검토자가 청구서 승인 전에 조사할 수 있습니다.
- 양식 간 검증 — 모든 라인 항목에 걸쳐 G703 G열(현재까지 완료 및 기성 총액)을 합산하고 그 결과를 G702 4행과 비교하는 계산 열을 정의합니다. 이는 기성 청구서에서 가장 중요한 산술 검사이며, 이를 자동화하면 재제출의 가장 일반적인 원인이 제거됩니다.
- 잔여 금액 집계 — 누적 기성 금액과 보유 유보금을 계약 금액에서 차감하여 남은 계약 가치를 계산합니다. 이를 통해 프로젝트 팀은 하청업체가 다음 기성 청구서를 제출할 때까지 기다리지 않고 각 작업 범위에 남은 예산을 실시간으로 확인할 수 있습니다.
이러한 계산 열은 추출 후 사용자가 수식을 입력할 필요가 없습니다. 추출 설정에서 열 이름의 일부(예: "유보금 확인 (기성 총액 x 10%)") 또는 다단계 로직을 위한 도구의 규칙 형식 내 JSON 규칙으로 지정되며, AI가 추출 과정 중에 계산을 수행합니다. 결과적으로 검토자가 파일을 열기 전에 기성 청구서의 정확성을 검증하는 열이 채워진 출력 스프레드시트가 생성됩니다.
일괄 처리: 30개의 기성청구서를 하나의 통합 스프레드시트로
단일 G702/G703 패키지를 추출하는 것은 개념 증명에 불과합니다. 한 번에 30~50개의 패키지를 추출하는 것이 실제 운영 가치가 나타나는 지점입니다. 기성청구서의 일괄 처리 워크플로는 송장이나 영수증의 일괄 처리와 다른 로직을 따릅니다. 출력이 단순한 품목 목록이 아니라 프로젝트-하도급업체-공종 계층 구조를 유지하는 구조화된 통합 데이터이기 때문입니다.
원도급업체의 통합 기성 공정표(모든 활성 프로젝트의 모든 하도급업체에 대한 지급 상태를 추적하는 마스터 스프레드시트)는 일반적으로 프로젝트, 하도급업체, 품목의 세 가지 수준으로 데이터를 구성합니다. 7개 프로젝트의 40개 G702/G703 패키지를 일괄 추출할 때는 첫 번째 열에 프로젝트, 두 번째 열에 하도급업체를 식별하고 나머지 열에 각 품목의 기성청구 데이터를 담은 단일 스프레드시트를 출력해야 합니다. 40개의 기성청구서에 디지털 양식과 필기 스캔본이 섞여 있는 경우, 일괄 추출은 파일별로 별도 설정 없이 동일한 워크플로를 통해 두 가지를 모두 처리해야 합니다.
일괄 접근 방식은 양식 간 검증을 더욱 강력하게 만듭니다. 하도급업체 A의 G703 합계가 G702 합계와 일치하는지 개별적으로 확인하는 대신, 통합 스프레드시트를 통해 동일한 프로젝트에서 유사한 공종을 수행하는 하도급업체 간의 지급 금액을 비교할 수 있습니다. 예를 들어, 건식벽체 하도급업체가 80% 완료로 청구하는 반면, 건식벽체가 완료되어야 작업을 시작할 수 있는 도장 하도급업체가 90% 완료로 청구하는 상황을 플래그할 수 있습니다. 이러한 패턴 수준의 이상 징후는 각 기성청구서를 개별적으로 처리할 때는 보이지 않습니다. 일괄 처리에 대한 자세한 워크플로는 전용 가이드인 전체 프로젝트 포트폴리오에 걸친 AIA G702 기성청구서 일괄 처리를 참조하십시오.
내보내기 및 연동: 데이터를 필요한 곳으로 전달하기
기성 신청 데이터를 추출하는 것은, 추출된 데이터가 지급 처리가 이루어지는 시스템에 도달하지 않으면 의미가 없습니다. 대부분의 GC(일반 건설사)에게 그 시스템은 프로젝트 관리 플랫폼(Procore, Viewpoint, CMiC), 건설 회계 시스템(Sage 300 CRE, Foundation), 또는 이 중 하나에 데이터를 공급하는 스프레드시트 모음 중 하나입니다.
Excel 내보내기. 가장 일반적인 출력 경로이자 가장 유연한 방법입니다. 잘 구성된 G702/G703 추출은 G702 요약 필드와 G703 라인 항목을 위한 별도 시트 또는 명확히 레이블이 지정된 열이 있는 Excel 파일을 생성합니다. G702 시트에는 프로젝트별 하청업체당 한 행이 있으며, 원래 계약 금액, 순 변경 명령, 현재까지 계약 금액, 완료 및 보관된 총액, 유보금, 이전 지급액, 현재 지급액, 잔여 완료 금액 열이 있습니다. G703 시트에는 라인 항목당 한 행이 있으며, 프로젝트 및 하청업체 식별자 열과 10개의 모든 라인 항목 열이 있습니다. 프로젝트 회계 담당자는 피벗 테이블, SUMIF 수식 또는 Power Query를 사용하여 특정 보고 및 지급 처리 워크플로에 필요한 형식으로 데이터를 집계할 수 있습니다.
Google Sheets 연동. Google Sheets에서 기성 일정을 관리하는 팀의 경우, Google Sheets 애드온을 통해 추출 결과를 활성 스프레드시트에 직접 넣을 수 있습니다. 이렇게 하면 내보내기-가져오기 단계가 완전히 제거됩니다. 업로드된 기성 신청 PDF가 처리되고, 결과 구조화된 데이터가 사용자의 기존 추적 템플릿과 일치하는 열 머리글과 함께 지정된 시트에 실시간으로 추가됩니다. 의미론적 추출이 템플릿 기반 접근 방식과 근본적으로 어떻게 다른지 더 깊이 이해하려면 COI 추출 완벽 가이드에서 보험 증명서 데이터에 적용된 동일한 패러다임 전환을 다루고 있습니다.
Procore 및 Viewpoint 연동. Datagrid 인수를 기반으로 한 Procore의 AI 기능은 제출물, RFI, 계약 검토에 중점을 두고 있으며, 외부 문서 데이터를 지급 처리 모듈로 가져오는 데는 중점을 두지 않습니다. Viewpoint(Trimble)는 Vista 및 Spectrum ERP 플랫폼 내에서 AIA 청구 기능을 제공하지만, 기성 신청이 하청업체로부터 작성된 PDF로 수신되는 것이 아니라 시스템 내에서 생성되어야 합니다. 실제로 외부에서 수신된 G702/G703 패키지에 가장 안정적인 연동 경로는 Excel 또는 CSV 내보내기 후 프로젝트 관리 또는 회계 플랫폼으로 가져오는 것이며, 해당 연동의 품질은 추출 도구가 출력을 얼마나 깔끔하게 구성하는지에 전적으로 달려 있습니다.
기성청구 추출 도구 평가 방법
모든 문서 추출 도구가 G702/G703 데이터의 특정 요구사항에 적합한 것은 아닙니다. 다음 기준은 기성청구를 처리할 수 있는 도구와 완벽하게 포맷된 디지털 PDF가 아니면 사용할 수 없는 출력을 생성하는 도구를 구분합니다.
교차 양식 검증 기능. 가장 중요한 기준: 도구가 G702와 G703이 관련 문서임을 이해합니까? 각 페이지를 독립적으로 처리하는 도구는 G702 요약 수치와 G703 라인 항목을 별개의 관련 없는 데이터 행으로 추출합니다. 기성청구를 인식하는 도구는 G702 데이터를 G703 데이터에 연결하여 출력하거나, 추출 과정에서 두 양식 간의 불일치를 플래그 지정합니다. 이 기능이 없으면 추출 결과 두 개의 데이터 세트가 생성되어 사용자가 수동으로 조정해야 하며, 이는 추출이 제거하려고 했던 작업입니다.
유보금 계산 검증. 도구는 유보금 비율과 금액을 구조화된 필드로 추출하거나 사용자가 추출된 합계에서 예상 유보금을 계산하는 계산 열을 정의할 수 있어야 합니다. "5%"를 Notes 열에 텍스트 문자열로 반환하는 도구는 실제로 데이터를 추출한 것이 아닙니다. 해석 책임을 사용자에게 다시 전가한 것입니다.
필기 인식. 도구가 G703 계속 시트의 필기 항목을 읽을 수 없으면 프로젝트 유형과 관련 하청업체에 따라 실제 하청업체 제출물의 약 30~50%에서 실패합니다. 이를 테스트하는 유일한 신뢰할 수 있는 방법은 공급업체가 제공한 데모 양식이 아닌 최소 3개의 필기 또는 수동 주석이 추가된 기성청구를 포함한 샘플 세트를 제출하고 테스트 세트에서 디지털 문서와 필기 문서 간의 필드 수준 정확도를 비교하는 것입니다.
가변 길이 G703의 테이블 추출. G703 테이블의 행 수는 10개에서 100개 이상의 라인 항목까지 다양합니다. 고정 테이블 레이아웃을 처리하지만 라인 항목이 두 줄로 래핑되거나 하청업체가 인쇄된 행 사이에 손으로 그린 행을 삽입한 테이블에서 중단되는 도구는 불완전한 출력을 생성합니다. 최소 40개의 행을 포함하고 여러 줄 설명이 있는 라인 항목이 하나 이상 포함된 G703으로 테스트하십시오.
CSI MasterFormat 코드 보존. 프로젝트에서 원가 계산에 CSI 부서 코드를 사용하는 경우 추출 도구는 코드와 설명을 별도의 열로 출력하거나 최소한 인접 필드를 자르거나 연결하지 않고 전체 라인 항목 설명을 보존해야 합니다. "03 30 00 — 현장 타설 콘크리트"를 "03 30 00"으로 자르는 도구는 원가 코딩 시스템에 필요한 정보를 이미 손실한 것입니다.
템플릿 불필요 설정. 도구는 사용자가 영역을 그리거나, 모델을 훈련시키거나, 템플릿을 생성할 필요 없이 G702/G703 패키지를 추출해야 합니다. 설정 과정에서 공급업체가 샘플 문서를 요청하는 경우 도구는 템플릿 기반 또는 훈련 기반 아키텍처를 사용하는 것이며, 양식이 변경되거나 새로운 하청업체가 다른 형식으로 기성청구를 제출할 때 유지보수가 필요합니다.
자주 묻는 질문
AIA G702와 G703의 차이점은 무엇인가요?
G702는 지급 신청 및 증명서로, 계약 수준의 재무 현황(최초 계약 금액, 변경 명령, 현재까지 완료된 총액, 유보금, 기지급액, 현재 청구 금액)을 한 페이지에 요약합니다. G703 계속 시트는 내역서의 항목별 세부 내역을 제공하며, 항목별 예정 금액, 기간별 완료 작업, 기성 자재, 유보금을 추적합니다. G703의 합계는 G702 요약 항목에 직접 반영됩니다.
AIA G702 및 G703 양식에서 유보금은 어떻게 계산되나요?
G702의 유보금은 일반적으로 4행(현재까지 완료 및 기성 총액)의 고정 비율(보통 5% 또는 10%)로 계산됩니다. G703에서는 변동 유보율이 적용되는 경우 항목별(열 I)로 유보금을 계산하거나, 프로젝트 전체에 고정 비율이 사용되는 경우 공란으로 둡니다. 추출 도구의 계산 열은 추출된 총액에서 예상 유보금을 계산하고 불일치를 표시하여 이 검증을 자동화할 수 있습니다.
AI가 G703 계속 시트의 필기 입력 내용을 추출할 수 있나요?
네, 가능하지만 정확도는 필기 가독성과 추출 도구의 아키텍처에 따라 달라집니다. "이 기간에 완료된 작업" 열의 값이 날짜나 항목 번호가 아닌 금액임을 이해하는 등 의미적 맥락에서 문자를 읽는 비전 기반 AI는 템플릿 기반 OCR보다 필기 G703에서 훨씬 높은 정확도를 달성합니다. 읽기 쉬운 필기 항목의 경우 최신 비전 AI는 필드 수준 정확도가 약 85~92%에 달하지만, 필체가 좋지 않거나 주석이 많은 양식의 경우 정확도가 70~80% 범위로 떨어집니다. 실용적인 해결 방법은 신뢰도 점수 열이 있는 추출 결과를 설계하고 임계값 미만으로 표시된 값만 검토하는 것입니다.
여러 하도급업체의 G702 패키지를 한 번에 일괄 처리할 수 있나요?
네. 일괄 처리는 AI 추출이 GC에게 가장 큰 효과를 제공하는 시나리오입니다. 모든 지급 신청 PDF(디지털 또는 수기, 모든 하도급업체, 모든 프로젝트)를 한 번에 업로드하세요. AI가 각 양식을 독립적으로 읽고 G702 및 G703 데이터를 추출한 후, 소스 파일을 식별하는 열이 포함된 하나의 통합 스프레드시트를 출력합니다. 일괄 워크플로는 혼합 형식을 자동으로 처리합니다. 일부 파일은 디지털 AIA 양식이고, 다른 파일은 스캔한 종이 양식이며, 또 다른 파일은 PDF로 저장된 Excel 내보내기일 수 있습니다. 이 워크플로에 대한 전체 안내는 프로젝트 포트폴리오 전반에 걸친 AIA G702 지급 신청 일괄 처리를 참조하세요.
AIA G702 양식을 사용하는 데 비용이 드나요?
네. AIA Contract Documents는 공식 G702 및 G703 양식에 대한 저작권을 보유하고 있습니다. AIA 웹사이트를 통한 G702/G703 세트 1회 사용 비용은 약 $49.99입니다. 모든 AIA 문서에 대한 무제한 액세스 연간 구독료는 약 $500입니다. 많은 계약업체가 저작권이 있는 양식을 사용하지 않고 G702/G703 레이아웃을 복제하는 스프레드시트 기반 버전을 만들지만, 수동 데이터 입력이 필요하고 건축가와 소유주의 동의를 얻지 못할 수 있습니다. 데이터 추출은 양식 자체의 필요성을 대체하지 않으며, 완성된 양식의 데이터를 추적 시스템으로 전송하는 작업을 자동화합니다.
Procore는 G702/G703 데이터 추출을 지원하나요?
Procore의 AI 기능(Datagrid 인수를 통해 도입)은 계약 문서, 제출물, RFI 분석에 중점을 두고 있으며, 수신된 지급 신청 PDF에서 구조화된 데이터를 추출하는 기능은 아닙니다. Procore는 플랫폼 내에서 G702/G703 양식을 생성하기 위한 AIA 청구 기능을 제공하지만, 이는 문서 생성 도구일 뿐 하도급업체로부터 받은 양식을 위한 추출 도구는 아닙니다. 가장 일반적인 통합 경로는 전용 추출 도구를 사용하여 G702/G703 데이터를 추출하고, Excel 또는 CSV 업로드를 통해 구조화된 출력을 Procore로 가져오는 것입니다.
CSI MasterFormat 코드가 G702/G703 추출에 어떤 영향을 미치나요?
대부분의 G703 연속 시트는 라인 항목을 CSI MasterFormat 구분 코드(Construction Specifications Institute에서 관리하는 표준 번호 체계)로 식별합니다. 이 체계는 6자리 숫자(예: 현장 타설 콘크리트의 경우 03 30 00, 금속 문 및 프레임의 경우 08 11 00, HVAC 덕트 작업의 경우 23 31 00)로 구성됩니다. 이러한 코드를 사용하는 프로젝트 회계 및 작업 원가 계산 워크플로우의 경우 추출 도구는 인접 필드를 자르거나 병합하지 않고 전체 코드와 설명을 보존해야 합니다. 현재 버전인 MasterFormat 2026은 50개 구분 프레임워크에 약 2,185개의 새 목록을 추가합니다.
변경 주문 추적은 G702/G703 추출에서 어떻게 작동하나요?
G702는 변경 주문을 2행에 단일 순액으로 캡처합니다. 이는 원래 계약 금액에 대한 승인된 모든 추가 및 차감의 총액입니다. 개별 변경 주문, 상태 또는 관련 문서는 나열하지 않습니다. 포괄적인 추출 워크플로우는 G702의 순 변경 금액뿐만 아니라 하청업체가 지급 신청 패키지에 포함하는 첨부된 변경 주문 로그 또는 변경 주문 전달 시트도 캡처해야 합니다. 이를 통해 프로젝트 회계 담당자는 순 금액이 프로젝트의 변경 주문 등록부와 비교하여 정확한지 확인하는 데 필요한 세부 정보를 얻을 수 있습니다.
G702/G703 추출에서 어느 정도의 정확도를 기대할 수 있나요?
인쇄된 텍스트가 있는 깨끗한 디지털 양식의 경우, 비전 기반 AI 추출의 필드 수준 정확도는 일반적으로 모든 G702 및 G703 필드에서 92~98%입니다. 필기 항목이 있는 양식의 경우 정확도는 필기 가독성과 양식 상태에 따라 80~92%입니다. 가장 중요한 운영 지표는 원시 정확도가 아니라 오류 감지율입니다. 계산된 열과 교차 양식 유효성 검사가 있는 잘 설계된 추출 워크플로우는 예상 범위를 벗어나는 값을 플래그 지정하므로 검토자는 모든 숫자를 수동으로 다시 확인하는 대신 검사해야 할 필드를 정확히 알 수 있습니다.
G702/G703 추출 데이터를 Viewpoint 또는 Sage 300 CRE와 통합하는 가장 좋은 방법은 무엇인가요?
Viewpoint(Trimble의 Vista 및 Spectrum)와 Sage 300 CRE는 모두 시스템 내에서 생성된 기성 청구서에 대한 AIA 청구 생성 모듈을 제공하지만, 외부에서 수신한 G702/G703 PDF의 구조화된 데이터를 직접 가져오지는 않습니다. 표준 통합 방법은 추출 결과를 Excel 또는 CSV로 내보낸 후, 플랫폼의 내장 가져오기 기능을 사용하여 해당 플랫폼의 미수금 또는 작업 원가 모듈로 가져오는 것입니다. 일부 GC는 Acumatica 또는 RabbitMQ와 같은 미들웨어 도구를 사용하여 전송을 자동화하지만, 대부분의 기업에서는 플랫폼의 가져오기 템플릿에 맞게 열이 매핑된 잘 구성된 Excel 내보내기가 가장 실용적인 솔루션입니다.
G702와 G703은 건설 문서 중 가장 표준화된 양식으로, AIA가 업계 전반의 기성 청구를 위한 일관된 형식을 만들기 위해 설계했습니다. 하지만 양식의 표준화가 이후의 데이터 입력 과정까지 표준화하지는 않습니다. 모든 기성 청구 패키지는 특정 시점의 프로젝트 재정 상태를 보여주는 스냅샷이며, 이 스냅샷에는 예산 추적, 진행 상황 확인, 대금 지급에 필요한 정보가 담겨 있습니다. 스냅샷을 추적 시스템에 연결하는 추출 계층은 매달 수십 건의 청구를 처리하는 GC에게 사치가 아니라, 수작업 입력이 보장하는 오류율을 감수하지 않고 물량을 처리할 수 있는 유일한 신뢰할 수 있는 방법입니다.
단일 기성 청구를 업로드하여 시맨틱 추출이 하청업체 양식을 어떻게 처리하는지 확인하거나, 30건의 청구 전체 배치를 실행하여 통합 스프레드시트가 몇 초 만에 채워지는 것을 지켜보십시오. 양식은 표준화되어 있습니다. 추출도 그래야 합니다.