AIA G702 & G703 데이터 추출 완벽 가이드

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 양식 자체는 새 프로젝트가 시작될 때마다 비용이 발생합니다. 개별적으로는 이러한 비용이 작습니다. 그러나 함께 합산되면 많은 중견 일반 도급자(GC)에게 풀타임 급여에 해당하는 금액이 됩니다.

월간 지급 주기. 상업 건설 지급 청구서는 고정된 월간 리듬을 따릅니다. 하도급자는 일반적으로 매월 20일 또는 25일인 마감일까지 지급 청구서를 제출합니다. 일반 도급자(GC)는 이를 검토, 확인하고 월말까지 소유자 지급 요청으로 통합합니다. 승인된 경우 소유자의 지급은 30~45일 후에 도착합니다. 마감일을 놓치면 하도급자의 지급이 전체 청구 주기만큼 지연되어 30일 대신 60일을 기다려야 합니다. 프로젝트 회계 담당자가 4일 동안 40개의 지급 청구서를 수동으로 처리할 때, 하나 또는 두 개의 마감일을 놓칠 위험은 이론적이지 않습니다. 우리는 재입력 체인에 대한 별도의 분석에서 느린 G702 데이터 입력이 지급 주기를 어떻게 늘리는지 정확히 분석했습니다. Construction Financial Management Association의 2025 Financial Benchmarker는 1,558개 기업의 2024 회계연도 데이터를 기반으로, 일반적인 건설 기업이 세전 순이익 마진 6.7%로 운영된다고 보고합니다. 모든 지연된 청구서, 모든 수정 주기, 모든 재제출은 그 마진을 직접적으로 잠식합니다.

보증금 계산 오류. 보증금 — 프로젝트 완료까지 각 지급에서 보류되는 비율 — 은 지급 청구서 분쟁의 가장 흔한 원인입니다. 대부분의 계약은 완료된 작업 및 보관된 자재의 총 가치에 적용되는 고정 비율을 명시합니다. 그러나 계산은 "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의 누적 합계를 잘못된 G702 항목에 입력하는 것입니다. 즉, 완료 합계를 보증금 필드에 입력하거나, 이전 인증서를 현재 지급 금액으로 입력하는 경우입니다. 양식 자체에는 산술 계산이 내장되어 있습니다. 6번 항목에서 7번 항목을 빼면 8번 항목이 되고, 3번 항목에서 6번 항목을 빼면 9번 항목이 됩니다. 단일 필드의 입력 오류는 모든 파생 항목에 연쇄적으로 영향을 미쳐 내부적으로 산술이 일치하지 않는 G702를 생성합니다. 신청서를 검토하는 건축가는 몇 초 만에 불일치를 발견하고 전체 패키지를 거부합니다. 이 실패 모드는 지급 청구 분쟁을 유발하는 일반적인 G702 추출 오류에서 자세히 다룹니다.

AIA 양식 비용. 일반적인 구매 주문서나 배송 명세서와 달리 AIA 양식은 저작권이 있는 문서입니다. AIA Contract Documents를 통해 일회용으로 구매하는 단일 G702/G703 세트는 약 $49.99이며, 연간 약 $500부터 시작하는 AIA 소프트웨어 구독을 통해 대량 구매 시 세트당 약 $15~$25입니다. 5개 프로젝트에서 50개의 활성 하도급자를 관리하는 일반 도급자(GC)의 경우 연간 양식 비용은 $750~$2,500입니다. 이는 큰 금액은 아니지만, GC가 이미 처리해야 하는 청구 데이터의 형식을 표준화하는 것 외에는 가치를 더하지 않는 지속적인 운영 비용입니다.

G702/G703 상위-하위 구조: 요약 페이지와 계속 시트

이 양식들에서 데이터 추출이 각 페이지를 독립적으로 읽는 것 이상을 요구하는 이유를 이해하려면 먼저 이들의 구조적 관계를 이해해야 합니다. G702와 G703은 함께 제출되는 두 개의 양식이 아닙니다. 이들은 동일한 재무 데이터의 두 가지 관점으로, 신뢰할 수 있는 추출 도구가 읽고 검증해야 하는 일련의 산술적 제약 조건으로 연결되어 있습니다.

G702는 상위 양식입니다: 전체 계약을 포괄하는 9개 항목의 재무 요약입니다. 해당 항목은 다음과 같습니다:

이 9개 항목 중 3개는 G703에서 이월됩니다. 4개는 산술적 파생 값입니다. 2개는 계약의 고정 입력 값입니다. G702 표지 시트만 읽는 추출 도구는 요약 수치를 포착하지만 이를 원본과 대조하여 검증할 수 없습니다. 또한 데이터를 세분화할 수 있는 유일한 곳인 G703을 놓치게 됩니다.

G703은 하위 양식입니다: 각 행이 가치 일람표 세부 항목이고, 각 열이 청구 기간에 따른 해당 세부 항목의 재무 진행 상황을 추적하는 가변 길이 테이블입니다. 표준 G703 계속 시트는 데이터를 다음 열로 구성합니다:

G703의 각 행은 해당 특정 작업 범위에 대한 미니 재무 명세서입니다. G열의 총 합계는 G702의 항목 4와 일치해야 합니다. I열의 합계는 항목 5와 일치해야 합니다. 이러한 양식 간 제약 조건이 지급 청구서 추출을 인보이스 추출과 다르게 만드는 이유입니다: 단일 문서에서 필드를 읽는 것만이 아니라 두 부분으로 구성된 데이터 구조를 읽고 두 부분 간의 산술적 일관성을 검증하는 것입니다. 이 추출이 실제로 어떻게 작동하는지 단계별로 알아보려면 AIA G702 지급 청구서 데이터를 스프레드시트로 추출하는 방법에 대한 상세 가이드를 참조하십시오.

지급 청구서 데이터 추출의 숨은 과제

양식이 올바르게 작성된 경우에도 G702/G703 패키지에서 데이터를 추출하는 작업은 다른 건설 문서 유형에는 없는 과제를 제시합니다. 이러한 과제는 지급 청구서를 대규모로 처리해 본 적이 없는 사람에게는 즉시 명확하게 드러나지 않습니다.

손으로 작성된 변경 명령 및 수량. 디지털 AIA 양식이 널리 보급되었음에도 불구하고, 상당수의 하도급자 지급 청구서에는 손으로 작성된 항목이 포함되어 있습니다. 현장에서 주석이 추가된 G703은 흔합니다. 하도급자의 프로젝트 관리자가 가치 일람표(SOV)를 출력하고, 당기 수량을 손으로 기입하고, 여백에 완공률을 계산하여 기록한 뒤, 주석이 추가된 시트를 스캔하여 PDF로 변환합니다. 여러 프로젝트에서 작업하는 하도급자는 AIA 변경 명령 요약표를 사용하는 대신, 손으로 주석을 단 단일 변경 명령 로그를 작성하여 지급 청구서에 첨부할 수 있습니다. 페이지의 픽셀 위치로 데이터 필드를 찾는 기존 OCR 및 템플릿 기반 추출 도구는 손으로 작성된 값이 레이아웃을 변경하기 때문에 이러한 문서에서 오류가 발생합니다. 수량 열에 손으로 쓴 "1,247"이 인접한 금액을 한 셀 오른쪽으로 밀어내면, 템플릿 추출은 문제가 발생했다는 신호 없이 잘못된 값을 반환합니다. 반면, 비전 기반 AI 추출은 각 값을 의미론적 맥락에서 읽습니다. "이번 기간 완료 작업" 열의 숫자를 식별할 때 페이지 상단에서 픽셀 오프셋을 측정하는 것이 아니라, 해당 숫자가 "이번 기간 완료 작업"이라는 헤더가 있는 열에 있다는 것을 이해하여 식별합니다.

CSI MasterFormat 코드. 대부분의 G703 계속 시트는 Construction Specifications Institute(CSI)가 관리하는 표준 분류 체계인 CSI MasterFormat 구분 번호를 사용하여 세부 항목을 구성합니다. 일반적인 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열을 뺀 값과 일치해야 합니다. 하도급자가 프로젝트 중간에 가치 일람표를 변경하는 경우 — 세부 항목을 둘로 나누거나 범위 간 가치를 재배분하는 경우 — 이 이월 값이 깨지며, 일반 도급자(GC)가 불일치를 수동으로 조정해야 합니다. 각 지급 청구서를 독립적인 문서로 취급하는 추출 도구는 이러한 불일치를 감지하지 못합니다. 그러나 연속된 지급 청구서를 읽고 이월 값을 비교하는 도구는 이를 감지할 수 있습니다.

전통적 방식 vs. AI: 지급 청구서 추출의 두 가지 접근법

전통적 지급 청구서 추출과 AI 기반 추출의 차이는 속도의 문제가 아닙니다 — 둘 다 페이지를 몇 초 안에 처리할 수 있습니다. 차이는 변형, 오류, 그리고 양식 간 관계를 처리하는 방식에 있습니다.

스프레드시트 조회를 통한 수동 복사-붙여넣기. 전통적 접근법: 하도급자의 G702 PDF를 열고 4번 줄을 읽은 후, 프로젝트 추적 스프레드시트의 해당 하도급자 행에 입력합니다. G703을 열고 첫 번째 세부 항목부터 항목 번호, 설명, 예정 가치, 이전 완료, 이번 기간, 보관, 합계, 백분율, 잔액, 보증금 — 30개 행에 대해 행당 10개 필드를 입력합니다. 이번 주기에 지급 청구서를 제출하는 40개 하도급자 각각에 대해 이 과정을 반복합니다. 이 과정은 간단하며 소프트웨어 투자가 필요 없습니다. 그러나 매 청구 주기마다 최소한 몇 건의 전사 오류가 발생하는 것은 보장됩니다 — Journal of Construction Engineering and Management에 게재된 건설 산업 데이터 입력 정확도 연구에 따르면, 수치 건설 데이터의 수동 전사는 필드당 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가 "보증금"이 무엇인지 알기 때문이며, 일반적으로 어디에 위치하는지에 의존하지 않기 때문입니다.

AI G702 양식과 기타 건설 문서 유형을 다양한 추출 도구가 어떻게 처리하는지 실질적으로 비교하려면, 2026년 건설 분야 최고의 문서 추출 소프트웨어 기사에서 8개 플랫폼을 공통 테스트 세트인 건설 문서 35건으로 평가했으며, 지급 청구서에 특화된 필드 수준 정확도 벤치마크를 제공합니다.

계산된 열: 산술 검증의 완성

G702/G703 추출에서 가장 유용한 기능 중 하나는 추출 과정 중 파생 값을 계산하는 열을 정의할 수 있다는 점입니다. 이는 추출 후 스프레드시트 수식이 필요하지 않습니다. 이것이 바로 계산된 열의 영역입니다. AI가 다른 추출 값에 대해 지정된 계산을 수행하고 결과를 데이터 행의 일부로 출력하는 열입니다.

지급 청구서 추출에서 특히 유용한 세 가지 계산된 열은 다음과 같습니다:

• 보증금 검증 — 추출된 "현재까지 기성 및 보관 합계"에 계약상 보증금 비율을 곱하는 계산된 열을 정의합니다. G702에 명시된 보증금 금액이 이 계산 값과 소정의 허용 오차 이상 차이가 나면, 추출 과정에서 불일치를 표시하여 검토자가 지급 청구서 승인 전에 조사할 수 있습니다.
• 양식 간 검증 — G703의 G열을 모든 세부 항목에 걸쳐 합산하고 그 결과를 G702의 4번 항목과 비교하는 계산된 열을 정의합니다. 이는 지급 청구서에서 가장 중요한 산술 검증이며, 이를 자동화하면 재제출의 가장 흔한 원인이 제거됩니다.
• 잔여 공사 합산 — 누적 완료 금액과 보유 보증금을 계약 금액에서 차감하여 현재까지의 잔여 계약 가치를 계산합니다. 이를 통해 프로젝트 팀은 하도급자가 다음 지급 청구서를 제출할 때까지 기다리지 않고 각 공종별 잔여 예산을 실시간으로 확인할 수 있습니다.

이러한 계산된 열은 추출 후 사용자가 수식을 입력할 필요가 없습니다. 추출 설정에서 지정됩니다. 열 이름의 일부(예: "보증금 검증") 또는 다단계 로직을 위한 도구의 규칙 형식의 JSON 규칙으로 지정되며, AI는 추출 과정 중 계산을 수행합니다. 그 결과 검토자가 파일을 열기 전에 지급 청구서의 정확성을 검증하는 열이 채워진 출력 스프레드시트가 생성됩니다.

일괄 처리: 지급 청구서 30건에서 통합 스프레드시트 1개로

단일 G702/G703 패키지를 추출하는 것은 개념 증명에 불과합니다. 한 번에 30~50개 패키지를 추출하는 작업에서 운영상의 가치가 드러납니다. 지급 청구서의 일괄 워크플로는 송장이나 영수증의 일괄 처리와 다른 논리를 따릅니다. 출력이 단순한 세부 항목의 평면 목록이 아니라 프로젝트-하도급자-공종 계층 구조를 보존하는 구조화된 통합이기 때문입니다.

일반 도급자(GC)의 통합 지급 일정표 — 모든 진행 중인 프로젝트의 모든 하도급자에 대한 지급 상태를 추적하는 마스터 스프레드시트 — 는 일반적으로 프로젝트, 하도급자, 세부 항목의 세 가지 수준으로 데이터를 구성합니다. 서로 다른 7개 프로젝트에서 G702/G703 패키지 40건을 일괄 추출할 때는 단일 스프레드시트를 출력해야 하며, 첫 번째 열은 프로젝트를 식별하고, 두 번째 열은 하도급자를 식별하며, 나머지 열은 각 세부 항목의 지급 청구 데이터를 캡처해야 합니다. 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행의 고정 비율로 계산됩니다. G703에서는 변동 유보율이 적용되는 경우 항목별로 유보금을 계산하거나, 프로젝트 전체에 고정 비율이 사용되는 경우 공란으로 둡니다. 추출 도구의 계산 열은 추출된 총액에서 예상 유보금을 계산하고 불일치를 표시하여 이 검증을 자동화할 수 있습니다.

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 양식에 대한 저작권을 보유하고 있습니다. 1회용 G702/G703 세트는 AIA 웹사이트를 통해 약 $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 구분 코드로 식별합니다. 이 체계는 6자리 숫자로 구성됩니다. 이러한 코드를 사용하는 프로젝트 회계 및 작업 원가 계산 워크플로우의 경우 추출 도구는 인접 필드를 자르거나 병합하지 않고 전체 코드와 설명을 보존해야 합니다. 현재 버전인 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와 Sage 300 CRE는 모두 시스템 내에서 생성된 기성 청구서에 대한 AIA 청구 생성 모듈을 제공하지만, 외부에서 수신한 G702/G703 PDF의 구조화된 데이터를 직접 가져오지는 않습니다. 표준 통합 방법은 추출 결과를 Excel 또는 CSV로 내보낸 후, 플랫폼의 내장 가져오기 기능을 사용하여 해당 플랫폼의 미수금 또는 작업 원가 모듈로 가져오는 것입니다. 일부 GC는 Acumatica 또는 RabbitMQ와 같은 미들웨어 도구를 사용하여 전송을 자동화하지만, 대부분의 기업에서는 플랫폼의 가져오기 템플릿에 맞게 열이 매핑된 잘 구성된 Excel 내보내기가 가장 실용적인 솔루션입니다.

G702와 G703은 건설 문서 중 가장 표준화된 양식으로, AIA가 업계 전반의 기성 청구를 위한 일관된 형식을 만들기 위해 설계했습니다. 하지만 양식의 표준화가 이후의 데이터 입력 과정까지 표준화하지는 않습니다. 모든 기성 청구 패키지는 특정 시점의 프로젝트 재정 상태를 보여주는 스냅샷이며, 이 스냅샷에는 예산 추적, 진행 상황 확인, 대금 지급에 필요한 정보가 담겨 있습니다. 스냅샷을 추적 시스템에 연결하는 추출 계층은 매달 수십 건의 청구를 처리하는 GC에게 사치가 아니라, 수작업 입력이 보장하는 오류율을 감수하지 않고 물량을 처리할 수 있는 유일한 신뢰할 수 있는 방법입니다.

단일 기성 청구를 업로드하여 시맨틱 추출이 하청업체 양식을 어떻게 처리하는지 확인하거나, 30건의 청구 전체 배치를 실행하여 통합 스프레드시트가 몇 초 만에 채워지는 것을 지켜보십시오. 양식은 표준화되어 있습니다. 추출도 그래야 합니다.