다른 형식의 하도급업체 청구서 30장을 일괄 처리하여
하나의 프로젝트 원가 시트로 만드는 방법

지급 주기가 배치를 만든다 — 준비가 되었든 아니든

대부분의 산업에서 배치는 직접 선택하여 생성하는 것입니다. 일주일간 인보이스를 모아 두었다가 효율성을 위해 함께 처리합니다. 그러나 건설업에서는 선택의 여지가 없습니다. 하도급 계약 조건은 월 1회의 단일 마감일 — 일반적으로 20일 또는 25일 — 을 설정하며, 모든 하도급업체가 동일한 날짜에 맞춰 응답합니다. 그 결과 모든 진행 중인 프로젝트에서 매월 48시간의 창구 기간 동안 서류가 쏟아져 들어옵니다.

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

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

단일 인보이스 추출이 25일을 견디지 못하는 이유

인보이스를 한 번에 하나씩 처리하는 경우 — 업로드, 추출, 다운로드, 반복 — AI 지원이 있더라도 각각 3~5분이 소요됩니다. 30개의 인보이스라면 2.5시간의 화면 작업 시간입니다. 그러나 실제 비용은 2.5시간이 아닙니다. 인보이스별 접근 방식이 만들어내는 후속 작업이 진짜 비용입니다:

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

파일별 구성 편차. 추출 열을 인보이스별로 하나씩 정의하면 23번째 인보이스는 필연적으로 5번째 인보이스와 약간 다른 열 집합을 갖게 됩니다 — 의도를 바꿔서가 아니라, 피곤하고 건식벽체 하도급업체의 인보이스 형식 때문에 "보관 자재"를 별도 열로 처리해야 하는지 혼란스러웠기 때문입니다. 배치가 끝날 무렵에는 파일 간 열이 일치하지 않게 되고, 통합은 수동 대사 작업이 됩니다.

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

열을 한 번 정의하면 모든 하도급업체에서 추출합니다

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

열 머리글을 한 번만 입력하면 됩니다:

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

운영상의 차이는 일괄 접근 방식이 통합 단계를 완전히 제거한다는 점입니다. 30개의 파일을 병합할 필요가 없습니다. 파일 하나만 검증하면 됩니다. 그리고 30개 행 모두 동일한 열 정의로 추출되었기 때문에 작업 번호로 정렬하고, 비용 코드로 필터링하고, 하도급업체별로 소계를 즉시 계산할 수 있습니다 — 재구성, 열 정렬, "잠깐, 배관 라인 항목이 어느 파일에 있었지?"와 같은 작업이 필요 없습니다.

하도급업체 인보이스 규모가 일괄 처리만으로 감당할 수 없을 정도로 커지고 있다면, 인력 증원 없이 인보이스 처리 확장 가이드의 확장 프레임워크가 문제의 조직적 측면을 다룹니다 — 프로세스 설계부터 다양한 규모 임계값에서의 팀 구조까지.

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

하도급업체 청구서 30건을 처리할 때, 보류금은 모든 건에 일괄 적용할 수 있는 단일 숫자가 아닙니다. 한 하도급업체의 계약은 10%를 보류합니다. 다른 업체는 5%를 보류합니다. 세 번째 업체는 공사 범위를 완료하여 보류금 0%로 청구하고 있습니다 — 이미 보류된 금액을 돌려받았기 때문입니다. 네 번째 업체는 주(state) 법이 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 # 열을 포함하십시오. 각 청구서는 해당 문서에서 찾은 작업 번호가 할당됩니다. 추출 후 배치 출력을 Job #별로 정렬하여 프로젝트별로 청구서를 그룹화한 다음, 지급 요청 패키지용으로 프로젝트별 소계를 계산하십시오. 청구서가 나타내는 프로젝트 수와 관계없이 열 정의는 동일하게 유지됩니다 — 이것이 프로젝트별 배치 하나가 아닌 전체 활성 프로젝트 포트폴리오에 걸쳐 하나의 배치를 실행하는 핵심입니다.

배치 처리는 혼합 파일 유형( PDF, 스캔, 휴대폰 사진)을 어떻게 처리합니까?

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

배치에서 AIA G702 양식을 일반 하도급업체 청구서와 분리해야 합니까?

아니요. AIA G702 지급 신청은 일반 청구서와 다른 필드 라벨을 사용합니다 — "Total Completed & Stored to Date" 대신 "Total Billed," "Less Previous Certificates" 대신 "Previous Payments" — 하지만 AI는 라벨 텍스트가 아닌 의미를 매칭합니다. G702와 일반 청구서를 함께 업로드하십시오. 열 이름 추출은 문서가 해당 필드를 무엇이라고 부르든 각 열에 해당하는 값을 찾습니다. G702 특정 추출 세부 사항은 AIA G702 데이터 추출 가이드를 참조하십시오.

이것이 건설 ERP의 필요성을 대체하나요?

아니요, 대체하려 하지도 않습니다. 이 도구는 데이터 캡처 계층을 해결합니다 — 하도급업체 청구서 데이터를 문서에서 구조화된 스프레드시트로 옮기는 작업입니다. 회계 시스템의 승인 라우팅, 3자 매칭, 지급 처리 또는 프로젝트 수준 WIP 보고를 대체하지 않습니다. QuickBooks 또는 Sage 100을 사용하는 중소 규모 GC의 경우, 스프레드시트 우선 일괄 접근 방식은 해당 시스템에 데이터를 공급하는 수동 데이터 입력을 대체합니다. Viewpoint Vista 또는 CMiC을 사용하는 대형 GC의 경우, "청구서 수신"과 "데이터 가져오기" 사이의 단계를 대체합니다 — 많은 기업에서 이 단계는 여전히 사람이 PDF를 읽고 ERP 화면에 숫자를 입력하는 방식입니다.