하도급사 청구서 데이터를 Excel로 추출하는 방법
템플릿 없이, 재입력 없이
콘크리트 하도급사가 보류금 10%로 계산되고 세 개의 원가 코드에 걸쳐 공사 내역이 나뉜 AIA 스타일 지급 신청서를 보내옵니다. 전기 하도급사는 인건비와 자재비를 별도 줄로 기재한 한 페이지 PDF를 이메일로 보내고, HVAC 하도급사는 변경 명령을 여백에 휘갈겨 적은 손으로 쓴 청구서를 팩스로 보냅니다. 매달 팀원 중 한 명이 각 문서를 열어 동일한 여섯 개 필드를 찾아 현장 원가 스프레드시트에 직접 입력합니다 — 하도급사마다 청구서 형식이 제각각이기 때문입니다.
대부분의 추출 도구가 하도급 청구서에서 포기하는 이유
표준 PDF-to-Excel 도구나 일반적인 청구서 OCR을 하도급 지급 신청서에 사용해 본 적이 있다면 이미 결과를 아실 것입니다. 공급업체 이름과 총액은 정확히 추출하지만, 나머지 모든 항목에서는 실패합니다. 보류금 항목은 음수 비용으로 읽힙니다. 기성 금액표는 라벨 없는 숫자 격자가 됩니다. 현장 번호는 — 페이지에 나타나더라도 — 도구가 관련성 있는 것으로 인식하지 못한 헤더 블록에서 사라집니다.
이것은 OCR의 실패가 아닙니다. 가정의 실패입니다. 일반적인 추출 도구는 표준 상업 청구서를 위해 설계되었습니다: 상단에 공급업체, 중간에 품목, 하단에 합계. 하나의 문서 구조와 하나의 필드 집합을 기대합니다. 하도급 청구서는 이러한 모든 가정을 깨뜨립니다:
- 한 페이지에 여러 비용 내역. 콘크리트 공사를 청구하는 하도급업체는 단일 청구서에 인건비, 자재비, 장비비, 보류금을 각각 자체 소계가 있는 별도의 항목 그룹으로 나열할 수 있습니다. 일반적인 도구는 이를 "열이 너무 많은 표"로 읽고 왜곡된 출력을 생성합니다.
- 표준 OCR이 인식하도록 학습된 적이 없는 건설 특화 필드. "이번 기간 완료 공사액", "보관 자재", "보류금 공제액", "보류금 공제 후 총 수입" — 이러한 항목은 일반적인 청구서 도구의 필드 사전에 없습니다. 도구는 이를 건너뛰거나 "기타 비용"으로 잘못 분류합니다.
- 여백에 있는 현장 번호와 원가 코드. 현장 참조 번호는 오른쪽 상단의 작은 상자, 하도급업체 커버 이메일의 제목 줄, 또는 프로젝트 이름에 포함되어 나타날 수 있습니다 — 라벨이 있는 필드가 아닙니다. 표준 추출은 찾아야 한다는 것을 모르기 때문에 이를 찾지 않습니다.
하도급 청구서의 추출 문제는 페이지를 읽는 것이 아닙니다. 어떤 필드를 찾아야 하는지 알고, 일반적인 청구서 파서가 절대 확인하지 않을 위치에 나타날 때 이를 인식하는 것입니다.
건설 분야에서 중요한 필드 (그리고 일반 추출이 이를 놓치는 이유)
하도급업체 청구서는 단순한 청구서가 아닙니다. 공사 원가 문서이자, 규정 준수 기록이며, 지급 승인서가 하나로 합쳐진 것입니다. 추출해야 할 필드는 사무용품 공급업체 청구서에서 추출하는 필드와 동일하지 않습니다. 모든 하도급업체 청구서에 있는 항목과 각 항목이 단순히 수표를 발행하는 것 이상으로 중요한 이유는 다음과 같습니다:
| 필드 | 지급 외에 중요한 이유 |
|---|---|
| 현장 번호 / 프로젝트 코드 | 이것이 없으면 원가가 잘못된 프로젝트의 손익계산서에 반영됩니다. $12,000 규모의 콘크리트 청구서가 잘못된 현장에 게시되면 해당 현장은 예산 초과로 보이고 실제 현장은 예산 미만으로 보입니다. 둘 다 잘못된 것이며, 월말이 되어서야 이를 발견하게 됩니다. |
| 원가 코드 (CSI 디비전) | 견적은 CSI 디비전별로 작성되었습니다. 디비전 03 콘크리트, 디비전 08 개구부, 디비전 22 배관. 청구서 데이터에 원가 코드가 없으면 누군가가 라인 항목 설명을 읽고 어떤 예산 항목에 속하는지 추측하여 수동으로 할당해야 합니다. 그 작업을 하는 사람은 보통 시간당 $75–120의 PM으로, 분류 작업에 청구서당 15분을 소비하며 의사 결정 대신 분류에 시간을 쓰고 있습니다. |
| 완료 공사액 + 보관 자재 | 이들은 AIA G702 지급 신청서와 대부분의 하도급업체 청구 양식에서 별도의 라인 항목입니다. 완료 공사액은 즉시 유치권이 설정됩니다. 보관 자재(현장 내 vs. 현장 외)는 유치권 권리와 현금 흐름 영향이 다릅니다. 이를 단일 "청구 총액" 열로 합치면 소유자에게 언제 청구할 수 있는지를 결정하는 구분이 사라집니다. |
| 보류금 | 일반적으로 각 진행 지급액의 5–10%로, AIA A201 §9.3.1에 따라 실질 완공 시까지 보류됩니다. 청구서별로 보류금을 추적하지 않으면 소유자가 모든 하도급업체에 대해 보유하고 있는 현금이 얼마인지 알 수 없으며, GC가 소유자가 그들에게 보류하는 금액보다 더 많이 보류하고 있지 않은지 확인할 수 없습니다. |
| 변경 명령 요약 | 승인된 변경 명령은 원래 계약 금액을 수정합니다. 하도급업체 청구서에 변경 명령 작업이 포함되어 있지만 스프레드시트에 "청구 총액"만 추적하는 경우, 이번 달 청구서가 지난달보다 $8,000 더 높은 이유를 설명하는 문서 기록을 잃게 됩니다. |
이러한 필드 중 어느 것도 표준 상업용 청구서 템플릿에는 나타나지 않습니다. 그렇기 때문에 "청구서 번호, 날짜, 공급업체, 총액"으로 학습된 도구는 공사 원가 보고를 실제로 좌우하는 열에 대해 빈 셀을 반환합니다.
열 이름 추출이 형식에 관계없이 필요한 것을 찾는 방법
이 작업을 가능하게 하는 기술은 열 이름 추출입니다. 템플릿 기반 OCR처럼 각 필드 주위에 사각형을 그려 도구에 페이지에서 어디를 봐야 하는지 알려주는 대신, 찾고자 하는 것이 무엇인지 알려주면 AI가 의미를 이해하여 해당 값을 찾아냅니다. 이 접근 방식이 청구서 데이터에 특히 어떻게 적용되는지 자세히 알아보려면 모든 청구서 형식에서 특정 필드를 추출하는 방법에 대한 가이드를 참조하세요.
입력은 직접 입력하는 열 이름 목록입니다. 출력 스프레드시트에 원하는 헤더와 정확히 일치합니다:
하도급사명 | 청구서 번호 | 날짜 | 현장 번호 | 원가 코드 | 완료 공사액 | 보관 자재 | 보류금 | 지급 잔액 | 변경 명령 합계
AI는 각 문서를 읽고 각 열 이름에 해당하는 값을 찾아 행을 채웁니다. 한 청구서의 "하도급사명"은 헤더의 "계약자:" 라벨에 있을 수 있고, 다른 청구서에서는 라벨 없이 페이지 상단 중앙에 굵은 텍스트로 표시될 수 있습니다. AI는 의미를 매칭하기 때문에 위치가 아니라 두 경우 모두 인식합니다. 마치 숙련된 AP 담당자가 페이지를 훑어보고 위치에 관계없이 0.5초 만에 하도급업체 이름을 찾는 것과 같습니다.
이것은 픽셀 좌표를 기록하는 템플릿 기반 도구와 근본적으로 다릅니다("공급업체 이름은 상단에서 2.3인치, 왼쪽에서 1.1인치"). 템플릿은 하도급업체가 청구서 소프트웨어를 변경하거나 새 필드를 추가하는 순간 깨집니다. 열 이름 추출은 깨지지 않습니다. 픽셀이 아니라 정보를 찾는 것이기 때문입니다.
출력 스키마를 정의하는 것입니다. AI는 각 문서의 입력 형식에 적응합니다. 이러한 역전 — 출력 우선, 형식 비의존 — 이 다양한 업종의 하도급업체 청구서에서 작동하는 이유입니다.
단계별 안내: 하도급업체 청구서에서 현장 원가 스프레드시트까지
다음은 하도급업체 청구서 배치를 수령한 후 현장 원가 스프레드시트를 작성하기까지의 실제 워크플로우입니다. 각 단계는 이전 단계 없이는 병목 현상이 발생하기 때문에 존재합니다.
1. 열을 한 번 정의하고, 매 기성 기간마다 재사용하세요
문서를 처리하기 전에 스프레드시트에 필요한 열을 결정하세요. 현장별 하도급업체 비용을 추적하는 GC 또는 전문 하도급업체의 경우, 실용적인 열 구성은 다음과 같습니다:
- 하도급사명 — 청구하는 업체
- 청구서 번호 — 업체의 참조 번호(감사 추적에 필수)
- 날짜 — 청구서 또는 기간 종료일
- 현장 번호 — 이 비용이 속한 프로젝트
- 원가 코드 — CSI 디비전 또는 내부 코드(예: 현장 타설 콘크리트의 경우 03-3100)
- 완료 공사액 — 이 기간의 노무 및 설치 자재의 달러 가치
- 보관 자재 — 현장에 있지만 아직 설치되지 않은 자재
- 청구 총액 — 완료 공사액 + 보관 자재(총 기성액)
- 보류금 — 보류된 금액(일반적으로 5~10%)
- 지급 잔액 — 이 기간에 실제로 지급하는 금액
- 변경 명령 번호 — 이 기성에 포함된 CO 참조
이 열들을 사전 설정으로 저장하여 매월 다시 입력하지 마세요. 동일한 열 구성이 모든 하도급업체에 적용됩니다 — AI가 입력 측의 형식 변동을 처리합니다.
2. 업로드 — 한 장이든 스무 장이든, 동일한 흐름
PDF를 업로드 영역에 놓으세요. 하도급업체 청구서는 이메일 첨부 파일(PDF), 현장 사무소에서 스캔한 종이, 또는 손으로 쓴 청구서의 휴대폰 사진으로 도착합니다. 추출 엔진은 PDF, JPG, PNG, WebP를 처리합니다 — 사전 처리, 300 DPI 요구 사항, "콘크리트 하도급업체에 청구서 형식을 바꿔 달라고 요청"할 필요가 없습니다.
한 달치 기성을 처리하는 경우 모든 청구서를 한 번에 업로드할 수 있습니다. 도구는 이를 병렬로 처리합니다 — 단일 페이지 추출은 일반적으로 5~10초가 소요됩니다 — 그리고 모든 결과를 하나의 스프레드시트로 병합합니다.
3. 추출된 스프레드시트 검토 — 개별 문서가 아닌
각 PDF를 열어 필드를 하나씩 입력하는 대신, 각 행이 하도급사 청구서이고 각 열이 정의한 필드인 스프레드시트 하나를 엽니다. 실제로 사용할 형식의 데이터를 검토하는 것이지, 한 형식에서 다른 형식으로 옮겨 적는 것이 아닙니다. 처음 몇 장의 청구서에 대해 고가치 필드(청구 총액, 지급 잔액)를 원본 문서와 대조하여 점검합니다. 검증 과정은 아래에서 자세히 설명합니다.
파일은 안전하게 처리되며 저장되지 않습니다.
4. 내보내고 원가 시스템에 공급하기
Excel(XLSX) 또는 CSV로 다운로드하세요. 스프레드시트는 열 머리글을 기준으로 구성되며, 청구서마다 한 행씩 기록됩니다. 이 데이터는 기존 워크플로우로 흘러 들어갑니다 — QuickBooks 가져오기, Sage 300 원가 모듈, Procore 원가 원장, 또는 예산 대비 프로젝트 지출을 추적하는 공유 Excel 통합 문서 등이 그것입니다. 핵심은 이제 종이에서 숫자를 다시 입력하는 것이 아니라, 시스템 간에 구조화된 데이터를 이동한다는 점입니다.
추출 단계는 첫 입력 병목 — 데이터를 페이지에서 구조화된 형식으로 옮기는 작업 — 을 대체합니다. 회계 시스템, 승인 워크플로우, 또는 프로젝트 관리자의 판단을 대체하지는 않습니다. 단지 모든 청구서에서 동일한 여섯 개 필드를 스프레드시트에 입력하던 작업만 없앨 뿐입니다.
보류금, 변경 명령, 그리고 유치권 포기 각서 문서 처리
하도급업체 청구의 세 가지 측면은 표준 추출이 무시하는 데이터를 생성합니다 — 그러나 건설 현장에서는 깔끔한 기성 신청서와 분쟁이 있는 지급 신청서를 가르는 차이입니다.
보류금. 대부분의 하도급 계약은 각 기성 지급에서 5~10%를 보류합니다. 열 세트에 보류금 필드를 포함하여 스프레드시트가 총 청구 금액과 순 지급 금액을 모두 반영하도록 하세요. 하도급업체가 계약서에 명시된 것과 다르게 보류금을 계산하는 경우(예: 보관 자재가 아닌 노무비에만 보류), 이 열은 승인 전에 스프레드시트에서 불일치를 드러냅니다 — 소유주 회계사가 발견한 후가 아니라요.
변경 명령. 변경 명령 작업을 포함하는 하도급업체 청구서는 CO 번호와 승인된 금액을 참조해야 합니다. 스프레드시트에 이러한 참조가 없으면, 여섯 달 후 원래 하도급 계약 가치와 대조할 수 없는 청구서 합계를 마주하게 됩니다. 변경 명령 번호 열을 포함하세요. 청구서가 여러 CO를 참조하는 경우, AI는 모든 CO를 쉼표로 구분된 목록으로 캡처합니다 — 이번 기성이 기본 계약 작업인지 승인된 추가 작업인지 한눈에 확인할 수 있습니다.
유치권 포기 각서. 많은 GC는 각 지급 신청서와 함께 조건부 유치권 포기 각서를 요구합니다. 추출 도구가 유치권 포기 각서를 생성하지는 않지만, 지급 잔액 금액이 추출되고 검증되면 포기 각서 금액이 실제 지급과 일치합니다 — 유치권 포기 각서 거부의 가장 흔한 원인을 제거합니다. 프로젝트당 20명 이상의 하도급업체를 관리하는 경우, 포기 각서 금액을 지급 금액과 수동으로 대조하는 것은 하루 종일 걸리는 작업입니다. 추출된 스프레드시트는 이를 VLOOKUP으로 바꿔줍니다.
놓칠 수 없는 단계: 검증 패스
AI 추출은 첫 번째 데이터 입력, 즉 페이지의 필드를 읽고 셀에 입력하는 작업을 대체합니다. 검증을 대체하지는 않으며, 어떤 가격대의 추출 도구도 이를 대체할 수 없습니다. 깨끗한 문서의 인쇄 데이터의 경우 추출 정확도는 99% 이상에 달합니다. 하지만 200장의 청구서에서 "99% 정확도"라면 두 장의 청구서에 오류가 있을 수 있습니다. 바로 그 두 장이 조정 문제와 지급 분쟁을 일으키는 원인입니다.
실용적인 접근 방식은 계층형 검증 패스입니다. 모든 청구서의 모든 셀을 확인하는 것이 아니라, 오류가 재정적 영향을 미치는 필드를 대상으로 합니다:
- 1단계: 모든 청구서의 모든 금액 필드를 표본 점검합니다. 청구 총액, 보류금, 지급 잔액. 이 필드들이 지급 금액을 결정합니다. 각 행을 원본 문서와 대조해 보십시오. $48,700 청구서에서 숫자 하나가 빠지면 $4,870이 됩니다. 2초간 육안으로 비교하면 바로 발견할 수 있습니다.
- 2단계: 각 하도급업체의 첫 번째 청구서에서 현장 번호를 확인합니다. AI가 특정 하도급업체의 형식에 대해 현장 번호를 일관되게 정확히 추출한다면, 해당 업체의 이후 청구서도 정확할 가능성이 높습니다. 첫 번째 청구서에서 오류가 있으면 추출을 조정하고 다시 처리하십시오.
- 3단계: 원가 코드를 합리성 차원에서 훑어봅니다. 배관 하도급업체의 청구서가 Division 03 콘크리트로 분류되면 업종과 일치하지 않아 눈에 띌 것입니다. 대부분의 잘못된 분류는 맥락상 명확합니다.
이 계층형 접근 방식은 청구서 20장 배치에 2~3분이 소요됩니다. 수동 입력에 필요한 청구서당 15~20분과 비교하면 말이죠. 병목 현상이 "스프레드시트에 데이터 입력하기"에서 "이미 있는 데이터 검증하기"로 이동합니다. 이는 훨씬 더 작은 시간 투자입니다.
목표는 인간의 검토를 완전히 없애는 것이 아닙니다. 인간의 검토를 "모든 키 입력"에서 "실제로 중요한 키 입력"으로 줄이는 것입니다.
자주 묻는 질문
손으로 쓴 하도급업체 청구서도 처리할 수 있나요?
가능하지만 조건이 있습니다. AI는 손글씨를 읽습니다 — 인쇄체는 필기체보다, 또박또박 쓴 글씨는 급하게 휘갈긴 글씨보다 더 정확하게 읽습니다. 배관공이 또박또박 쓴 숫자와 금액이 있는 손글씨 청구서는 잘 추출됩니다. 번지고 연필로 흐릿하게 겹쳐 쓴 카본 사본은 정확도가 낮아집니다. 손글씨 청구서가 접수량의 상당 부분을 차지한다면 앞서 설명한 검증 단계가 더 중요해집니다 — 하지만 어려운 손글씨에서도 85–90%의 정확도라면 전체 문서를 다시 입력하는 대신 수정만 하면 됩니다.
AIA G702 지급 신청서는 특별히 어떻게 처리되나요?
열 이름 방식은 AIA G702 양식에서도 작동합니다. 필요한 필드 — 현재까지 계약 금액, 현재까지 완료 및 보관 총액, 보류금, 보류금 차감 후 총 수령액, 기존 지급 증명서 차감액, 현재 지급 예정액 — 가 양식에 텍스트로 표시되어 있기 때문입니다. AI는 이러한 라벨을 읽고 인접한 값을 추출하며, 다른 문서와 동일한 방식으로 처리합니다. AIA 양식 전용 가이드는 AIA G702 데이터 추출 가이드를 참조하세요.
총 청구액과 보류금에서 지급 잔액을 계산할 수 있나요?
가능합니다. 계산 열을 사용하여 "지급 잔액(청구 총액 − 보류금)"과 같은 열을 정의하면 AI가 추출 중에 뺄셈을 수행합니다. 스프레드시트에서 계산 결과를 바로 얻을 수 있으며 추출 후 수식이 필요 없습니다. 하도급업체가 보류금을 백분율로 표시하지만 청구서에 지급 예정액을 명시하지 않는 경우에 유용합니다.
Sage 300 / Viewpoint / QuickBooks와 연동되나요?
이 도구는 Excel(XLSX) 및 CSV로 내보내기를 지원하며, 두 형식 모두 파일 기반 데이터 가져오기를 지원하는 모든 건설 회계 시스템에 가져올 수 있습니다. 특정 ERP 플랫폼과의 직접 API 연동은 없습니다. 작업 흐름은 다음과 같습니다: 스프레드시트로 추출 → 검토 → 회계 시스템으로 가져오기. 대부분의 중소 규모 건설업체에게 이는 ERP 통합 프로젝트 없이 수동 입력 단계를 대체합니다. Procore 또는 Viewpoint Vista를 사용하는 대형 업체는 원가 원장에 직접 데이터를 공급하는 도구를 원할 수 있습니다 — 하지만 이러한 플랫폼은 일반적으로 연간 $15,000 이상의 비용이 들고 전담 구현이 필요합니다. 병목 현상이 "페이지에서 데이터를 가져올 수 없는 것"이라면 스프레드시트 우선 접근 방식이 부담 없이 문제를 해결합니다.
하도급업체가 청구서 형식을 변경하면 어떻게 되나요?
귀하 측에서 변경할 사항은 없습니다. 추출이 페이지 위치가 아닌 필드 의미로 매칭되므로, 기존 하도급업체의 새로운 청구서 레이아웃도 신규 하도급업체의 청구서와 동일한 방식으로 처리됩니다. 템플릿 업데이트, 재학습, 구성 변경이 필요 없습니다. 이는 템플릿 기반 OCR과 열 이름 AI 추출 간의 가장 큰 운영상 차이점이며, 수십 개의 하도급업체에 걸쳐 유지보수 없이 확장할 수 있는 이유입니다.
하도급업체 청구서를 대량으로 처리 중이거나 곧 처리할 예정이라면, 규모에 따른 형식 변동 관리가 실제 문제입니다. 열 이름 접근 방식을 증가하는 물량에 적용하는 프레임워크는 인력 증원 없이 청구서 처리 확장 가이드를 참조하세요.