AIA G702 데이터 입력이
건설 대금 지급 주기를 지연시키는 이유
Rabbet의 2024 건설 대금 지급 보고서에 따르면, 건설 업계는 느린 지급 프로세스로 인해 매년 약 2,800억 달러의 손실을 보고 있습니다. 이 수치는 2020년 이후 두 배 이상 증가했습니다. 특히 주목할 점은 이러한 지급의 대부분에서 핵심 역할을 하는 서식인 AIA G702(지급 신청 및 증명서)가 미국 비즈니스에서 가장 표준화된 문서 중 하나라는 사실입니다. 모든 항목은 정의된 의미를 가지며, 모든 열은 정해진 목적이 있습니다. 이 서식은 1992년 이후 거의 변경되지 않았습니다. 그러나 서식의 데이터는 단 1달러가 이동하기 전에 수동으로 세 번, 네 번, 때로는 다섯 번이나 다시 입력됩니다. 형식의 표준화가 워크플로의 표준화로 이어지지 않았으며, 이 둘 사이의 간극이 바로 자금이 사라지는 지점입니다.
핵심 요약
- 미국 건설업계에서 가장 표준화된 문서인 AIA G702는 1992년 이후 변경되지 않았지만, 업계에서 가장 비표준화된 프로세스를 유발합니다. 300개 값을 수작업으로 3~5번 재입력해야 하며, 한 자리 숫자 오류가 30일 지급 주기를 초기화합니다.
- 하청업체는 56일을 기다려 대금을 받지만, 원청업체는 30일로 추정합니다. 또한 75%가 자체 현금으로 자재비를 지불하며, 아직 받지 못한 돈으로 주급을 충당합니다.
- ImageToTable.ai는 G702/G703 PDF를 읽을 때 열 제목의 의미를 이해합니다. 페이지 상의 위치가 아니라 의미를 파악하여 모든 라인 항목, 예정 값, 유보금 계산을 스프레드시트로 출력함으로써 오류와 지연을 유발하는 수동 재입력을 없앱니다.
양식은 표준입니다. 데이터 입력은 그렇지 않습니다.
AIA G702와 그 보충 양식인 G703 연속 시트는 미국 상업용 건설 프로젝트의 78%에서 사용됩니다. 미국 건축가 협회(American Institute of Architects)가 개발한 이 양식은 진행 청구를 위한 엄격한 구조를 제공합니다. G702는 계약 금액, 승인된 변경 명령, 이전 지급액, 보유된 유보금 및 현재 청구 금액을 요약하고, G703은 모든 금액을 가치 일정에 따라 구성된 라인 항목별로 세분화합니다. 이들의 목적은 수행된 작업과 지급해야 할 금액에 대한 단일하고 검증 가능한 기록을 만드는 것입니다. 그런 의미에서 이 양식은 성공적입니다. 양식 자체는 명확합니다.
양식이 표준화하지 않는 것은 데이터가 페이지에 입력된 후에 일어나는 일입니다. AIA 청구 프로젝트의 일반적인 지급 신청 워크플로는 익숙한 경로를 따릅니다. 하청업체가 G703을 작성하여 이번 기간에 완료된 작업 가치, 저장된 자재, 완료율 및 20~50개 라인 항목 각각의 누계 합계를 입력합니다. 그런 다음 G702 요약은 해당 G703 합계에서 채워집니다. 하청업체는 패키지(일반적으로 PDF)를 원청업체에 제출합니다. 원청업체의 프로젝트 관리자 또는 회계 담당자는 Procore, Sage 300 CRE, Viewpoint Vista 또는 공유 Excel 통합 문서 등 회사의 지급 추적 시스템에 해당 숫자를 다시 입력합니다. 프로젝트 소유자나 건축가가 인증 전에 독립적인 검토를 요구하는 경우(대부분의 AIA A201 일반 조건 계약에서와 같이) 데이터는 소유자 시스템에 세 번째로 전사됩니다. 경우에 따라 소유자의 대출 기관은 별도의 인출 요청 플랫폼에 네 번째 입력을 요구합니다.
G703 한 장에는 30개 라인 항목과 10개 재무 데이터 열이 포함되어 약 300개의 개별 숫자 값이 있습니다. 한 달에 12~15건의 기성 신청서를 처리하는 5개 활성 프로젝트에서, 원도급사의 프로젝트 관리팀은 청구 주기당 약 4,500개의 숫자를 처리합니다. 이 모든 숫자는 정확성을 검토해야 하며, 대부분은 도착한 시스템과 다른 시스템에 수동으로 입력해야 합니다. 이 양식은 숫자가 의미하는 바를 표준화할 뿐, 숫자가 이동하는 방식을 표준화하지는 않습니다.
AIA G702 및 G703은 수십 년 전에 표현 표준화 문제를 해결했습니다. 그러나 이 양식이 다루지 않았고, 업계가 그 이후로 계속 우회해 온 문제는 양식의 첫 번째 버전이 작성되는 순간 시작되는 데이터 재입력 체인입니다.
작은 데이터 입력 오류가 30일 지급 지연을 초래하는 경우
반려된 기성 신청서는 단순히 수정되어 다음 날 다시 제출되지 않습니다. 대부분의 건설 계약에서 청구 기간은 고정되어 있습니다. 신청서는 매월 특정 날짜(보통 20일 또는 25일)까지 제출되어야 합니다. 건축가나 발주자가 어떤 이유로든 기성 신청서를 반려하면(계산 오류, G703과 일치하지 않는 G702 합계, 잘못 적용된 유보금 비율 등), 시공사는 오류를 수정하고 재제출해야 합니다. 그러나 수정안이 준비되고 검토되어 승인 체인을 통해 다시 보내질 때쯤이면 청구 기간은 일반적으로 마감됩니다. 지급은 다음 달 주기로 이월됩니다. 단 한 번의 데이터 입력 실수(300개 값이 있는 스프레드시트에서 한 자리 숫자 오류)로 30일의 현금 흐름 공백이 발생할 수 있습니다.
일부 오류는 청구 기간을 넘나들며 누적되기 때문에 더욱 교묘합니다. G703은 누적 형식으로 구성되어 있습니다. G702의 6행("현재까지 완료 및 저장된 총계")은 G703의 총계와 일치해야 하며, 현재 기간의 각 항목별 누계는 이전 기간의 누계에 현재 기간의 완료된 작업을 더한 값과 같아야 합니다. 하청업체가 지난달 G703을 복사하여 이번 달 청구를 시작하고 "이번 기간" 열을 업데이트했지만, 지난달의 실제 승인된 수치를 이월하는 것을 잊었다면 모든 항목이 잘못됩니다. 건축가는 오류가 있는 항목뿐만 아니라 전체 신청서를 거부합니다. 시계는 다시 리셋됩니다. 그리고 오류가 이월 과정에 있기 때문에 하청업체의 내부 기록도 GC가 보유한 기록과 일치하지 않게 되어 다음 청구 주기까지 이어지는 조정 문제가 발생합니다.
이는 드문 예외 상황이 아닙니다. r/Construction의 한 하청업체는 정확히 이러한 조건에서 매월 지급 능력을 유지하기 위한 산술을 설명했습니다. 1월 15일에 첫 번째 기성 신청서를 제출하고, 3월 15일경에 첫 번째 지급을 기대합니다. 즉, 60일의 유예 기간입니다. 그 공백 기간 동안 자재는 net-30 조건으로 주문되며, 이는 하청업체가 들어오는 대금 없이 25일 동안 자체 자금으로 구매 자금을 조달해야 함을 의미합니다. 그들은 "현금 흐름을 앞서 나가는 데 어려움을 겪고 있으며, 결국 은행 잔고를 바닥내는 데 불편할 정도로 가까워지고 있습니다."라고 썼습니다.
거부된 기성 신청은 단순한 수정 사건이 아닙니다. 지급 주기의 리셋입니다. 그리고 거부가 바로 양식이 방지할 수 없는 것, 즉 데이터 입력 오류에 의해 촉발되기 때문에 양식 자체가 지연의 조용한 공범이 됩니다.
GC 측에서는 아무도 보지 못하는 56일의 격차
Billd의 2025년 전국 하도급업체 시장 보고서에 따르면, 하도급업체는 기성 청구서를 제출한 후 평균 56일이 지나서야 대금을 받습니다. 원도급업체에게 같은 질문을 하면 대기 기간을 30일로 추정합니다. 이 26일의 인식 격차는 사소하지 않습니다. 즉, 지급 일정을 통제하는 사람들이 실제로 대금을 기다리는 사람들이 얼마나 오래 기다리는지 진정으로 이해하지 못하고 있다는 뜻입니다. 파이프라인은 아래에서보다 위에서 볼 때 더 짧아 보입니다.
단일 지급 주기를 넘어서 보면 그 격차는 더 벌어집니다. Siteline의 2025년 하도급업체 청구 현황 보고서에 따르면, 하도급업체 중 단 5%만이 정시에 대금을 지급받습니다. 나머지 95%는 작업 완료 후 대금 수령까지 평균 96일(3개월 이상)을 기다립니다. 건설 재무 관리 협회(CFMA)는 건설사의 핵심 재무 건전성 KPI로 매출 채권 회수 기간(DSO)을 추적합니다. CreditPulse의 2025년 업계 벤치마크에 따르면 건설업계 평균 DSO는 83일로, 미국 전체 산업 평균인 약 60일과 비교됩니다. 건축 마감 공사 업체는 평균 77일, 엔지니어링 및 건설 회사는 100일에 달합니다. 참고로, 건설 재무 분석가들이 제시하는 건강한 목표 DSO 벤치마크는 45일로, 업계 평균의 약 절반 수준입니다.
이 숫자들을 데이터 입력 문제로 연결하는 것은 모든 청구 주기에 내재된 연쇄 반응입니다. 하청업체의 스프레드시트에서 GC의 Procore 인스턴스로, GC 시스템에서 발주처의 드로 요청으로, 발주처 검토에서 대출 기관 확인으로 이어지는 각각의 수동 재입력은 불일치가 발생할 새로운 기회를 만듭니다. 각 불일치는 확인 이메일을 필요로 하고, 각 확인 이메일은 검토 일정에 하루나 이틀을 추가합니다. 이 체인의 끝에서 56일 전에 원본 G703을 제출한 하청업체는 이러한 재입력 중 어떤 것이 지연을 초래했는지 전혀 알 수 없으며, 단지 지급이 도착하지 않았다는 사실만 알 수 있습니다.
PYMNTS와 아메리칸 익스프레스의 2025년 건설 지연 지급 보고서에 따르면 건설 회사의 69%가 여전히 수표로 지급합니다. 보고서는 수동 지급 시스템이 "건설 프로젝트 전반의 현금 흐름 문제를 증폭시킨다"고 지적합니다. 같은 설문조사에서 일반 계약자들은 대출 기관 관련 지연(38%)과 프로세스 관리 문제(27%)를 적시 지급의 가장 큰 두 가지 장애물로 꼽았으며, 두 범주 모두 여러 시스템 입력 간 데이터 조정에 소요되는 시간을 포함합니다.
이 모든 지연 비용을 실제로 부담하는 사람은 누구인가
느린 지급 주기를 업계 전반의 비효율성 — 즉, 업계 전체에 해당하는 추상적인 2800억 달러 규모의 숫자로 보는 것은 유혹적입니다. 그러나 건설업 지급의 비효율성은 고르게 분포하지 않습니다. 이는 지급 체인의 최하위에 집중됩니다. 하청업체는 GC로부터 단 한 푼도 받기 전에 자재를 구매하고, 인건비를 지급하며, 보험을 유지합니다. 사실상 그들은 자신이 참여하는 모든 프로젝트에 신용을 제공하고 있는 셈입니다. 이는 그들이 선택하여 제공한 신용도 아니고, 경쟁력을 잃지 않고 입찰가에 반영할 수도 없는 신용입니다.
Billd의 2025년 조사는 이것이 실제로 어떤 모습인지 정량화합니다: 하청업체의 75%는 지급을 기다리는 동안 자체 현금 보유액으로 자재비를 지불합니다. 하청업체 3곳 중 1곳은 지연 지급으로 인한 현금 흐름 공백을 메우기 위해 개인 저축이나 은퇴 자금을 인출한 경험이 있습니다. 자재비를 자비로 부담하는 하청업체의 비율은 2021년 66%에서 2023년 73%로 증가했으며, 이후 75% 이상을 유지하고 있습니다. 이는 더 넓은 경제가 안정화되었음에도 잘못된 방향을 가리키는 추세선입니다. 또한 하청업체의 86%는 56~96일 후에나 받을 수 있는 미수금을 기다리면서 인건비(팀의 주급)를 부담합니다. 하청업체는 사실상 이자도 없이 건설업계의 운전자본 대출 기관 역할을 하고 있는 셈입니다.
州法中的及时付款规定旨在解决这种不对称性。加利福尼亚州的《及时付款法案》要求私人项目业主在收到正确发票后30天内向总承包商付款,逾期未付则按月加收2%的利息罚款。自2026年1月起,加州还将私人项目的保留金上限设定为5%——这承认了多年来每笔进度款扣留10%的做法对分包商营运资金造成了巨大压力。德克萨斯州根据其《财产法》第28章,要求业主在35天内付款,并规定承包商在收到款项后7天内将款项转付给分包商。两个州都允许承包商在无争议款项未付的情况下暂停工作。但这些法律管辖的是在提交并批准正确的付款申请之后的付款行为。它们并未解决在申请被认定为正确之前所引入的数周延迟——即大多数承包商所经历的“计费周期”本身的数据录入和验证瓶颈。
法定保护措施在终点线生效,而非起跑线。而起跑线——分包商拿着上个月的G703表格、一份新电子表格和300个需要转录的数值坐下来开始工作的地方——在法律上完全不可见。
表格本身遗漏的提取层
当美国建筑师学会在20世纪90年代初设计G702和G703表格时——1992年版至今仍是最广泛使用的版本——这些表格需要解决的问题是一致性。标准格式意味着项目中的每一方都使用相同的计费语言,从而减少关于何种构成正确付款请求的争议。设计背后的假设是,这些表格本身一旦标准化,将成为唯一的权威记录——一次性填写、一次性审核、一次性认证。
디자이너들이 예상하지 못한 것은, 동일한 데이터를 각각 필요로 하는 소프트웨어 시스템이 폭발적으로 늘어난 점입니다. G702/G703 양식은 프레젠테이션 레이어 — 당사자 간에 전달되는 PDF — 가 되었지만, 모든 당사자는 여전히 해당 PDF 내 데이터를 자신의 시스템에 저장해야 했습니다: 하청업체의 QuickBooks나 Jonas Premier, GC의 Procore나 Viewpoint Vista, 발주자의 Acumatica Construction Edition, 대출 기관의 드로우 관리 플랫폼 등. 표준 양식은 표면을 표준화했지만, 기반은 그렇지 못했습니다. 그리고 이 둘 사이의 간극 — 양식을 읽고 데이터를 다른 시스템에 입력하는 작업 — 은 여전히 완전히 수동으로 이루어졌습니다.
바로 이 지점에서, 또 다른 프로젝트 관리 플랫폼이 아닌 AI 기반 문서 추출이 빠진 조각이 됩니다. 지불 체인의 모든 당사자에게 동일한 소프트웨어를 채택하도록 요구하는 대신 — 30년간 해결되지 않은 조정 문제 — 추출 도구는 양식과 시스템 사이에 가벼운 데이터 레이어를 삽입합니다. 캡처하려는 열 이름("항목 설명", "예정 금액", "이번 기간 완료 작업", "현재까지 완료 및 보관된 총액", "유보금")을 지정하면, 도구가 PDF를 읽고, 열 머리글이 페이지상의 위치가 아닌 의미를 이해하여 각 값을 찾은 후 구조화된 테이블을 출력합니다. 열 이름 추출이라고 하는 이 접근 방식은 템플릿 기반 OCR과 다릅니다. 모든 양식의 각 필드 주위에 상자를 그려야 하는 대신, 필요한 필드 이름을 입력하면 AI가 양식 레이아웃에 대한 의미론적 이해를 바탕으로 문서 내 어디에서든 해당 값을 찾습니다. 출력물은 각 당사자가 이미 사용 중인 시스템에 바로 드롭할 수 있는 스프레드시트(Excel 또는 CSV)입니다.
양식은 바뀌지 않습니다. 제출 워크플로도 바뀌지 않습니다. 하청업체는 여전히 G703을 작성해 PDF로 제출하고, GC는 이를 검토합니다. 달라지는 점은 누구도 한 화면에서 다른 화면으로 300개의 숫자를 직접 입력할 필요가 없다는 것입니다. 추출 레이어가 PDF를 읽고 데이터를 구조화된 열로 제공하여 오류와 지연을 유발하는 수동 재입력 단계를 없앱니다. G702 및 G703 양식(계약 금액, 유보금 계산, 라인 항목 추출 포함)에서 이 기능이 어떻게 작동하는지 자세히 알아보려면 AIA G702 지급 신청 데이터를 스프레드시트로 추출하는 단계별 가이드를 참조하세요. 문서 데이터 입력을 더 광범위하게 자동화하려는 경우 자동화된 데이터 입력 페이지에서 문서 유형별 열 이름 추출 방식을 확인할 수 있습니다.
AIA 양식은 데이터의 내용을 표준화합니다. 추출 레이어는 데이터의 이동 방식을 표준화합니다. 이 둘을 결합하면 지급 신청서를 다시 입력해야 하는 문서에서 읽을 수 있는 데이터 소스로 바꿀 수 있습니다. 이것이 바로 56일 지급 주기와 며칠(몇 주가 아닌) 단위로 측정되는 지급 주기의 차이입니다.
자주 묻는 질문
반려된 G702/G703 지급 신청서가 왜 이렇게 오랜 지연을 초래하나요?
대부분의 건설 계약은 고정된 월별 청구 기간을 명시합니다. 마감일 이후에 제출되거나 반려 후 재제출된 신청서는 일반적으로 다음 달 주기까지 기다려야 합니다. 수학 오류나 G702와 G703 합계 불일치로 인한 반려는 단순한 수정만 필요한 것이 아니라 30~45일의 승인 시계를 사실상 초기화합니다. 수정된 신청서가 재제출, 검토, 인증 및 지급될 때쯤이면 원래 작업이 완료된 지 90일 이상 지났을 수 있습니다.
원청업체가 의도적으로 이러한 지연을 초래하나요?
대부분의 지연은 의도적이지 않으며 절차상의 문제입니다. 원청 프로젝트 관리자와 회계 담당자는 매월 여러 하도급업체와 여러 프로젝트에 걸친 기성 청구서를 처리합니다. 각 청구서는 검증이 필요합니다: G703 라인 항목이 G702 총액과 일치하는지, 이월 금액이 이전 기간과 일치하는지, 계약에 따라 정확한 비율로 유보금이 적용되었는지, 그리고 증빙 서류(포기각서, 변경 명령서, 보험 증명서)가 완전한지 확인하는 것입니다. 검증 자체는 필요합니다. 느려지는 이유는 검증할 데이터가 PDF에 있고 검증 도구는 스프레드시트에 있어서 그 간극을 메우기 위해 수동 입력이 필요하기 때문입니다.
문서 추출은 Procore와 같은 건설 프로젝트 관리 소프트웨어와 어떻게 다른가요?
Procore, Viewpoint Vista, Sage 300 CRE 및 유사한 플랫폼은 견적, 일정 관리, 문서 관리, 현장 커뮤니케이션, 청구를 모두 하나의 시스템에서 처리하는 종합 프로젝트 관리 생태계입니다. 문서 추출은 더 좁고 가벼운 도구로, PDF(G702/G703 패키지 등)를 읽고 구조화된 데이터를 추출하여 스프레드시트로 출력합니다. PM 플랫폼을 대체하지 않으며, PDF와 기존 시스템 사이에 위치하여 수동 데이터 재입력 단계를 없애줍니다. 이는 동일 프로젝트의 다른 당사자가 다른 PM 플랫폼을 사용할 때 특히 유용합니다. 추출 도구는 궁극적으로 어떤 시스템이 데이터를 수신하든 PDF 자체와 함께 작동합니다.
신속 지급 법률이 실제로 하도급업체가 더 빨리 대금을 받는 데 도움이 되나요?
주 정부의 신속 지급법은 지연 지급에 대한 법정 기한과 이자 패널티를 규정합니다. 예를 들어, 캘리포니아의 신속 지급법은 민간 프로젝트 소유주가 30일 이내에 지급하도록 요구하며, 지연 시 월 2%의 이자를 부과합니다. 텍사스는 소유주의 35일 내 지급과 하위 업체로의 7일 내 전달을 요구합니다. 이러한 법률은 적절히 제출된 신청서가 인증된 후 중요한 구제 수단을 제공합니다. 하지만 인증 전 지연 — 데이터 입력 오류 수정, 이월 차액 조정, 여러 단계의 검토 대기 등에 소요되는 수 주 — 은 다루지 않습니다. 이러한 지연은 신속 지급법의 적용 범위 밖, 즉 서류 제출과 서류 인증 사이의 간극에 존재합니다.
건설 계약에서 'pay-if-paid' 조항과 'pay-when-paid' 조항의 차이점은 무엇인가요?
'Pay-when-paid' 조항은 시기를 정합니다: 원청은 소유주로부터 지급을 받은 후 합리적인 기간 내에 하청업체에 지급해야 하며, 이는 지급이 언제 이루어지는지를 규율합니다. 'Pay-if-paid' 조항은 더 나아가, 소유주로부터의 지급 수령을 하청업체에 대한 지급 의무의 선결 조건으로 만들어, 소유주의 미지급 위험을 전적으로 하청업체에 전가합니다. 주마다 'pay-if-paid' 조항을 다르게 취급합니다: 캘리포니아 법원은 이 조항이 사실상 공사 유치권을 포기하게 하므로 집행 불가능하다고 판결한 반면, 텍사스는 명시적이고 모호함이 없으면 허용합니다. 실제로 두 조항 유형 모두 하청업체의 지급 대기 기간을 연장하며, 상위 승인 프로세스에 며칠 또는 몇 주를 추가하는 데이터 입력 오류의 비용을 증폭시킵니다.
이 문제는 대규모 상업 건설업체만의 문제인가요, 아니면 소규모 하청업체에도 영향을 미치나요?
영세 하도급업체가 불균형적으로 큰 타격을 입습니다. 전담 회계 인력을 둔 대형 건설사(GS)와 전문 하도급업체는 신용 한도, 현금 보유액, 또는 연장 조건을 허용하는 공급업체 관계를 통해 56~96일의 결제 주기를 감당할 수 있습니다. 하지만 3개 팀, 주급 지급 체계, 신용 한도가 없는 소규모 하도급업체에게는 그런 완충 장치가 없습니다. Billd의 2025년 전국 하도급업체 시장 보고서에 따르면, 하도급업체의 75%가 결제를 기다리는 동안 자재비를 자비로 부담하며, 업체 규모가 작을수록 개인 저축이나 퇴직금으로 그 격차를 메울 가능성이 높습니다. 여러 프로젝트에 걸쳐 총 40만 달러 계약을 체결한 하도급업체의 경우, 기성 신청서(G702) 반려로 인한 단 한 번의 30일 결제 지연이 임금 체불로 이어질 수 있습니다.
기성(off-the-shelf) AI 추출 도구로 G702 요약과 G703 내역 항목을 모두 처리할 수 있나요?
G702와 G703은 각기 다른 추출 과제를 제시합니다. G702는 약 10개의 개별 필드(계약 금액, 변경 명령, 유보금, 기존 지급액, 현재 청구 금액)가 포함된 단일 페이지 요약서로, 비교적 추출이 간단합니다. G703은 여러 페이지에 걸친 계속 시트로, 수백 개의 라인 항목 행이 포함될 수 있으며 각 행은 여러 열에 걸쳐 값을 가지므로 행 무결성을 유지해야 합니다. 즉, 12행의 D열 값은 12행의 B열 항목 설명과 정확히 연결되어야 합니다. 범용 AI 추출 도구는 G702 필드를 처리할 수 있지만 G703에서는 행 정렬을 잃을 수 있습니다. ImageToTable.ai의 열 이름 추출과 같은 구조화된 문서 추출용 도구는 각 열을 모든 행에 걸쳐 명명된 필드로 처리하여 행 무결성을 유지합니다. 예를 들어 "이 기간 완료된 작업"은 각 라인 항목당 하나의 값이 있는 단일 열로 추출됩니다. 전체 과정을 보려면 AIA G702/G703 지급 신청 데이터 자동 추출 가이드를 참조하세요.