하청업체 30곳의 서로 다른 형식의 청구서를
하나의 프로젝트 원가 시트로 일괄 처리하는 방법

드로우 사이클이 배치를 만든다 — 준비가 되었든 아니든

대부분의 업종에서 배치는 선택적으로 생성하는 것이다. 일주일 동안 인보이스를 모아두었다가 효율성을 위해 한꺼번에 처리한다. 그러나 건설업에서는 선택의 여지가 없다. 하도급 계약서는 단일 월별 마감일(보통 20일 또는 25일)을 지정하며, 모든 하도급업체가 동일한 날짜에 응답한다. 그 결과 매월 모든 진행 중인 프로젝트에서 48시간 안에 서류가 쏟아져 들어온다.

이것은 해결해야 할 기술 문제가 아니다. 이는 업계가 공사 대금을 지급하는 방식의 구조적 특징이다. AIA A201 §9.3에 따라, 시공사는 매월 하나의 통합 지급 신청서를 발주자에게 제출한다. 이 통합 신청서의 정확성은 입력되는 데이터에 달려 있다. 즉, GC 자체 드로우 마감일 전에 30개의 개별 하도급업체 인보이스가 정확하게 하나의 숫자 집합으로 변환되어야 한다는 뜻이다.

3개의 프로젝트를 운영하는 GC의 경우, 90개의 인보이스가 동일한 3일 기간에 집중된다. 프로젝트 회계사가 직면한 것은 데이터 입력 문제가 아니다. 처리량 문제다: 90개의 데이터 세트를 평소 15개를 처리하는 시간 안에 PDF에서 스프레드시트로 옮겨야 한다.

단일 인보이스 추출이 25일을 버티지 못하는 이유

송장을 하나씩 처리한다면 — 업로드, 추출, 다운로드, 반복 — AI 도움을 받아도 각각 3~5분이 걸립니다. 송장 30개면 2.5시간의 화면 앞 시간입니다. 하지만 진짜 비용은 2.5시간이 아닙니다. 송장별 접근 방식이 만들어내는 후속 작업입니다:

서른 번의 개별 다운로드. 각 추출마다 자체 Excel 파일이 생성됩니다. 마지막 송장을 처리한 후에는 동일한 열 구조와 다른 데이터를 가진 30개의 파일이 생깁니다. 누군가는 각 파일을 열고 데이터 행을 복사해 마스터 시트에 붙여넣거나, 통합을 위한 수식을 작성해야 합니다. 이 통합 단계는 추출 자체만큼 시간이 걸리며, 병합 오류가 발생하기 쉬운 지점입니다: 잘못된 프로젝트 탭에 붙여넣어진 행, 한 칸씩 밀린 열, 완전히 누락된 파일.

파일별 설정 불일치. 송장 하나씩 추출 열을 정의하면, 23번째 송장은 필연적으로 5번째와 약간 다른 열 세트를 갖게 됩니다 — 마음이 바뀌어서가 아니라, 피곤하고 건식벽체 하청업체의 송장 형식 때문에 "보관 자재"를 별도 열로 할지 혼란스러웠기 때문입니다. 배치가 끝날 무렵에는 파일 간 열이 일치하지 않아 통합이 수동 조정 작업이 됩니다.

송장 간 패턴을 발견할 수 없습니다. 송장을 개별적으로 처리하면 통합이 완료될 때까지 전체 그림을 볼 수 없습니다. 오후 6시에 작업을 마치고 마스터 시트를 열어서야 두 하청업체가 일치하지 않는 요율로 동일한 원가 코드에 청구했거나, 세 개의 송장에 나타난 변경 주문 금액이 승인된 CO 총액과 맞지 않는다는 것을 알게 됩니다. 이를 발견했을 때는 이미 인출 마감일이 내일 아침입니다.

열을 한 번 정의하고 모든 하청업체에서 추출

대안은 워크플로를 역전시키는 것입니다. 먼저 출력 스키마를 정의한 다음, 모든 하청업체 인보이스를 동일한 추출 파이프라인에 통과시키는 것입니다. 필드 추출 자체 설정에 대한 단계별 가이드(특히 열 이름 추출이 페이지 위치가 아닌 의미로 값을 찾는 방법 포함)는 하청업체 인보이스 데이터 추출 워크스루를 참조하세요. 여기서는 입력을 30배로 늘릴 때 무엇이 달라지는지에 초점을 맞춥니다.

열 헤더를 한 번 입력합니다:

그런 다음 30개의 인보이스를 한 번에 업로드합니다. 콘크리트 하청업체의 AIA 스타일 PDF, HVAC 하청업체의 회사 레터헤드, 전기 기사의 QuickBooks 생성 인보이스, 도장공의 수기 청구서 등입니다. 추출 엔진은 이를 병렬로 처리하여 각 문서에서 각 열의 값이 어디에 나타나든 찾아냅니다. 하나의 파일을 다운로드합니다: 각각 하나의 하청업체 인보이스를 나타내는 30개의 행과 동일한 열로 구성된 스프레드시트입니다.

일괄 처리 방식의 차이는 통합 단계를 완전히 생략한다는 점입니다. 30개의 파일을 병합할 필요 없이, 하나의 파일만 확인하면 됩니다. 그리고 30개 행 모두 동일한 열 정의로 추출되었기 때문에, Job #로 정렬하거나, Cost Code로 필터링하거나, 하청업체별로 소계를 바로 계산할 수 있습니다 — 재구성, 열 정렬, "어느 파일에 배관 품목이 있었지?" 같은 고민이 필요 없습니다.

하청업체 송장 물량이 일괄 처리만으로 감당하기 어려울 정도로 증가하고 있다면, 인력 증원 없이 송장 처리 규모를 확장하는 가이드의 확장 프레임워크에서 프로세스 설계부터 물량 임계치별 팀 구조까지 조직적인 측면을 다루고 있습니다.

유보금 차이: 하도급업체마다 다른 원천징수율

30장의 하도급업체 인보이스 일괄 처리에서, 유보금은 모든 경우에 일괄 적용할 수 있는 단일 숫자가 아닙니다. 어떤 하도급업체는 계약에 따라 10%를 원천징수합니다. 다른 업체는 5%를 원천징수합니다. 세 번째 업체는 공사 범위를 완료하여 유보금 0%로 청구 중입니다. 이미 원천징수된 금액을 되찾은 것입니다. 네 번째 업체는 주법이 GC의 표준 하도급 계약과 다르게 유보금 상한선을 정하는 공공 공사 프로젝트에 참여 중입니다.

인보이스를 개별적으로 처리한다면, 유보금 계산은 머릿속에서 이루어지거나 — 추출 후 각 행의 셀에 입력하는 수식에서 이루어질 가능성이 높습니다. 인보이스 30장에 대해 수동 수식 입력이 30번 필요합니다. 하나라도 잘못되면 하도급업체의 순 지급액이 $4,200만큼 차이가 나며, 이는 수표가 적게 왔다고 항의 전화를 할 때 알게 됩니다.

일괄 접근 방식은 계산된 열로 이를 처리합니다. 문서에서 값을 추출할 뿐만 아니라 추출 중에 계산을 수행하는 열입니다. "순 지급액"이라는 열을 총 청구액 × (1 − 유보금 %) 논리로 정의합니다. AI가 각 인보이스에서 총 청구액과 유보금 %를 읽고, 계산을 수행하며, 순 지급액을 자동으로 채웁니다 — 인보이스별, 하도급업체별, 페이지의 실제 숫자에 따라.

결과는 모든 행의 순 지급액이 해당 특정 하도급 계약의 유보금 조건을 반영하는 열입니다 — 일괄 처리 전체에 적용되는 10%의 막연한 추정치가 아닙니다. 계산된 열이 다양한 문서 유형에서 다단계 계산을 처리하는 방법에 대한 자세한 내용은 문서 추출의 계산된 열 소개를 참조하세요.

일괄 출력에서 기성 요청 패키지로

다운로드하는 스프레드시트는 최종 납품본이 아닙니다. 이는 기성 청구 패키지(소유주, 대출 기관 또는 건축가의 승인을 위해 제출하는 통합 지급 신청서)의 입력 자료입니다. 추출된 데이터에서 제출 준비가 완료된 패키지를 만드는 데는 일괄 출력이 더 빠르게 해주는 세 단계가 있습니다:

1. 공사별로 정렬 및 소계 계산. 일괄 처리에 여러 프로젝트의 인보이스가 포함된 경우, PM 또는 소유주 대리인이 가장 먼저 확인해야 하는 것은 공사별 요약입니다. 모든 행에 공사 번호 열이 있으므로 한 번의 정렬로 모든 인보이스가 프로젝트별로 그룹화됩니다. 공사별 청구 총액과 순 지급액에 대한 소계를 계산하면 각 프로젝트의 지급 신청에 필요한 기성 총액을 얻을 수 있습니다. 이전에는 30개의 개별 파일을 합산해야 했던 숫자입니다.

2. 기성 내역서와 대조 확인. 각 하청업체의 청구 금액은 프로젝트 기성 내역서의 해당 항목과 일치해야 합니다. 모든 하청업체 데이터가 하나의 시트에 있으면 VLOOKUP을 사용하여 기성 내역서 항목 금액을 추출된 인보이스 총액과 비교할 수 있습니다. 불일치 사항이 즉시 드러납니다. 예를 들어, 기성 내역서에는 40%인데 하청업체가 45% 완료로 청구했거나, 이전 지급액을 현재 기성에서 공제하는 것을 잊은 경우 등입니다.

3. 권리 포기 각서 체크리스트 작성. 모든 기성 청구 패키지에는 지급을 받는 각 하청업체의 조건부 권리 포기 각서가 필요합니다. 추출된 순 지급액 열은 이번 기간에 각 하청업체에 지급해야 할 정확한 금액을 알려줍니다. 이는 조건부 권리 포기 각서에 반영되어야 하는 금액과 정확히 일치합니다. 권리 포기 각서 금액 불일치는 기성 청구 패키지가 거부되는 가장 흔한 이유입니다. 검증된 순 지급액 수치가 한 곳에 있으면 권리 포기 각서 조정 작업이 하루 종일 걸리던 일에서 나란히 열을 비교하는 작업으로 바뀝니다.

일괄 처리에서 하나의 인보이스가 실패할 경우

30개 중 한 장은 문제가 생깁니다. AI가 $3,800를 $5,800로 읽는 필기 항목, 유보금 줄이 일부 가려진 스캔 문서, 지난달 청구서를 잘못 보내 현재 기성과 숫자가 맞지 않는 하도급업체. 이런 일이 발생하느냐가 아니라, 배치 워크플로가 전체 프로세스를 중단시키지 않고 처리할 수 있느냐가 관건입니다.

실용적인 접근 방식은 부분 재처리이지, 전체 재시작이 아닙니다. 배치 출력은 30행짜리 스프레드시트를 제공합니다. 총 청구액, 순 지급액 등 달러 필드를 원본 문서와 대조하여 점검합니다. 한 행에서 불일치가 발견되면 해당 청구서만 재처리하고(전체 배치가 아님), 수정된 행을 잘못된 행 위에 복사한 후 계속 진행합니다. 나머지 29개 행은 그대로 유지됩니다.

이것이 병합 출력 배치 워크플로의 운영상 이점입니다. 오류가 개별 행으로 격리되어 다른 항목에 영향을 주지 않고 수정될 수 있습니다. 청구서 #17을 다시 추출하기 위해 파일을 다시 병합하고 마스터 시트를 재구축해야 하는 도미노 효과가 없습니다. 구조는 그대로 유지되고, 한 행만 수정됩니다.

자주 묻는 질문

이미 배치를 실행한 후 하도급업체가 수정된 청구서를 제출하면 어떻게 됩니까?

수정된 청구서를 동일한 열 세트로 별도 처리하면 추출 시 동일한 필드가 일치됩니다. 단일 청구서 결과를 다운로드하여 마스터 배치 스프레드시트에서 해당 하청업체 행을 교체하고 다시 정렬하세요. 배치 출력 구조를 다시 구축할 필요는 없습니다. 이는 위에서 설명한 부분 재처리 워크플로우와 동일하며, 추출 오류가 아닌 늦은 수정에 적용됩니다.

여러 프로젝트에 걸친 청구서를 일괄 처리할 수 있나요?

네. 추출 스키마에 작업 번호(Job #) 열을 포함하세요. 각 청구서는 해당 문서에 있는 작업 번호가 할당됩니다. 추출 후 배치 출력을 작업 번호별로 정렬하여 프로젝트별로 청구서를 그룹화한 다음, 드로우 패키지용으로 프로젝트별 소계를 계산하세요. 청구서가 몇 개의 프로젝트를 나타내든 열 정의는 동일하게 유지됩니다. 이것이 프로젝트당 하나의 배치 대신 전체 활성 프로젝트 포트폴리오에 걸쳐 하나의 배치를 실행하는 핵심입니다.

일괄 처리는 PDF, 스캔본, 휴대폰 사진 등 혼합 파일 형식을 어떻게 처리하나요?

추출 엔진은 이 모든 형식을 동일한 배치에서 처리합니다. 하청업체가 이메일로 보낸 PDF, 현장 사무실에서 스캔한 종이 청구서, 수기 명세서의 휴대폰 사진을 모두 함께 업로드할 수 있습니다. AI는 각 문서 유형을 동일한 열 이름 일치 로직으로 처리합니다. 유일한 실질적 고려 사항은 이미지 품질입니다. 흐릿한 휴대폰 사진은 선명한 PDF만큼 깔끔하게 추출되지 않으므로, 검증 단계에서는 모든 셀을 확인하는 대신 신뢰도가 낮은 문서에 집중합니다.

배치에서 AIA G702 양식과 일반 하청업체 청구서를 분리해야 하나요?

아니요. AIA G702 지급청구서는 표준 청구서와 다른 필드 라벨을 사용합니다. 예를 들어 "총 청구 금액" 대신 "현재까지 완료 및 보관된 총액", "이전 지급액" 대신 "이전 증명서 차감"과 같은 표현을 쓰지만, AI는 라벨 텍스트가 아닌 의미를 매칭합니다. G702와 표준 청구서를 함께 업로드하세요. 컬럼명 추출 기능은 문서에서 해당 필드를 어떻게 부르든 관계없이 각 컬럼에 해당하는 값을 찾아냅니다. G702 특화 추출 세부사항은 AIA G702 데이터 추출 가이드를 참조하세요.

이것이 건설 ERP를 대체하나요?

아니요, 대체하려는 목적도 아닙니다. 이 도구는 데이터 캡처 계층, 즉 하도급업체 청구서 데이터를 문서에서 추출하여 구조화된 스프레드시트로 만드는 작업을 해결합니다. 회계 시스템의 승인 라우팅, 삼자 매칭, 지급 처리, 프로젝트 단위 WIP 보고를 대체하지 않습니다. QuickBooks나 Sage 100을 사용하는 중소 규모 종합건설업체의 경우, 스프레드시트 우선 일괄 처리 방식이 해당 시스템에 데이터를 공급하는 수동 데이터 입력을 대체합니다. Viewpoint Vista나 CMiC를 사용하는 대규모 종합건설업체의 경우, "청구서 수신" 단계와 "데이터 가져오기" 단계 사이의 과정을 대체합니다. 많은 업체에서 이 과정은 여전히 사람이 PDF를 읽고 ERP 화면에 숫자를 입력하는 방식으로 이루어집니다.