건설 자재 발주서 50건을
단일 공사비 원가표로 일괄 처리하는 방법

건설 현장에서 PO가 한꺼번에 몰리는 이유 — 그리고 이는 계획 문제가 아닌 구조적 문제인 이유

대부분의 산업에서는 배치 처리를 언제 할지 선택합니다. 일주일간 인보이스를 모은 후 한꺼번에 처리하죠. 하지만 건설 현장에서는 배치 시점이 월별 드로우 사이클과 자재 리드 타임에 의해 정해집니다.

AIA A201 §9.3에 따라, 시공자는 매월 하나의 통합 지급 신청서를 발주자에게 제출합니다. 하지만 이 신청서가 발주자에게 도달하기 전에, GC는 모든 진행 중인 프로젝트에서 약정, 수령 또는 설치된 모든 자재 비용을 조정해야 합니다. 즉, 목재 공급업체, 콘크리트 공장, 철골 제작업체, MEP 유통업체의 모든 자재 PO가 드로우 패키지가 발송되기 전에 적절한 원가 코드와 프로젝트로 코딩되어 공사 원가 시스템에 입력되어야 합니다.

동시에 자재 주문은 월 전체에 걸쳐 고르게 분포되지 않습니다. 프로젝트 A의 골조 패키지는 1주차에 주문되고 PO는 2주차에 도착합니다. 프로젝트 B의 지붕 자재는 3주차에 주문되고 PO는 4주차에 나타납니다. 하지만 이 모든 것은 월말 마감 전에 조정되어야 하며, 이는 바로 같은 주입니다. 5~8개의 프로젝트를 운영하는 GC에게 이 수렴 기간은 가혹합니다: 매월 50~150개의 자재 PO가 동일한 10일 기간 내에 도착합니다.

이는 하청업체 인보이스 배치와는 다릅니다. 하청업체 인보이스 배치의 경우 30가지 다른 형식이 동일한 마감일에 맞춰 몰려드는 것이 문제입니다. 여기서 추가적인 계층은 원가 코딩입니다. 각 자재 구매 발주(PO)의 각 라인 항목은 공사 원가 원장에 반영되기 전에 CSI MasterFormat 부문, 섹션 및 원가 유형에 매핑되어야 합니다. 이 매핑은 단순 데이터 입력이 아닌 인지 작업이며, 이것이 건설 PO 처리를 일반 조달보다 훨씬 더 어렵게 만드는 이유입니다.

공급업체가 보내는 것 vs. 공사 원가 시스템이 요구하는 것

공급업체의 PO와 공사 원가 시스템 간의 차이는 대부분이 생각하는 것보다 훨씬 큽니다. 그 차이는 필드 자체에서 시작됩니다.

일반적인 자재 공급업체의 PO에는 공급업체명, PO 일자, PO 번호, 품목 코드(공급업체 SKU), 품목 설명("2×6 #2 SPF 16'"), 주문 수량, 단가, 라인 합계, 총 합계가 포함됩니다. 운이 좋다면 "참조" 필드에 공사명이 적혀 있을 수도 있습니다. 내부 공사 번호, 원가 코드 또는 원가 유형은 거의 없습니다. 공급업체의 ERP는 CSI MasterFormat을 지원하지 않고 회계 구조를 모르기 때문입니다.

Sage 100 Contractor, Sage Intacct, Viewpoint Vista, Foundation 또는 건설 애드온이 포함된 QuickBooks와 같은 공사 원가 시스템에는 공사 번호, 원가 코드(예: 목재 골조의 경우 06 11 00), 원가 유형(자재, 노무, 장비, 하청, 기타), 단계 또는 하위 공사, 공급업체명, PO 번호, 일자, 품목 설명, 수량, 단가, 라인 합계, 그리고 이 원가가 확정인지 실제인지가 필요합니다. 이는 공급업체의 PO에 없는 최소 5개의 필드이며, 이 필드들이 공사 원가 보고서의 정확성을 결정합니다.

프로젝트 회계사가 하는 일은 바로 이 간극을 메우는 작업입니다. 한 줄씩, 품목 설명을 읽고 → 해당하는 CSI 분류를 파악한 후 → 6자리 원가 코드를 찾거나 기억해내고 → 작업 번호를 할당하고 → 원가 유형을 입력한 다음 → 이미 페이지에 인쇄된 수량과 단가를 마지막으로 입력합니다. 발주서 한 장에 12개 품목이 있다면, 이 정신적 루프를 12번 반복해야 합니다. 평균 8개 품목의 발주서 50장이라면 400번의 반복입니다. 기성고 마감일이 이미 코앞으로 다가온 일주일 동안 말이죠.

원가 코드 문제: '2×6 방부처리재'가 06 11 00과 다른 이유

CSI MasterFormat은 건설 작업을 50개 부문으로 분류하며, 각 부문은 6자리 코드로 식별되는 섹션과 하위 섹션으로 세분화됩니다. Division 03은 콘크리트, Division 04는 조적, Division 06은 목재, 플라스틱 및 복합재입니다. Division 06 내에서 06 11 00은 목구조(Wood Framing)이고, 06 16 00은 덮개(Sheathing)입니다. 06 11 00과 06 16 00의 차이는 사소한 것이 아닙니다. 구조와 외피의 차이이며, 06 11 00에 대한 예산 초과 경고를 보는 프로젝트 관리자는 그 수치가 실제임을 알아야 합니다.

문제는 목재 공급업체의 발주서에 "06 11 00"이라고 적혀 있지 않다는 점입니다. "2×6 #2 SPF 16'"이라고 적혀 있고 자체 SKU가 있습니다. 철근 제조업체의 발주서에는 "#4 Grade 60 rebar — 20' lengths"라고 나열되어 있습니다. 석고보드 공급업체의 발주서에는 "5/8″ Type X Gypsum Board"라고 적혀 있습니다. 이 중 어느 것에도 CSI 코드가 포함되어 있지 않습니다. 누군가는 각 라인 항목을 읽고, 정신적으로 분류한 후, 올바른 코드를 할당해야 합니다. 그리고 다음 399개 라인 항목에 대해 다시 이 작업을 반복해야 합니다.

이 지점에서 수동 프로세스가 무너집니다. 누군가 업무를 잘못해서가 아니라, 컨텍스트 전환 비용이 크기 때문입니다. 세 개의 라인 항목 사이에서 골조용 목재 항목(06 11 00)에서 콘크리트 앵커 볼트(03 16 00), HVAC 덕트 행거(23 31 00)로 분류를 전환합니다. 200번째 항목쯤 되면 피로가 쌓이고, 석고보드(09 29 00)에 속하는 건식벽체 나사가 이전 발주서의 "목재" 모드에 갇힌 뇌 때문에 06 11 00으로 코딩됩니다. 이 오류는 월말이 되어서야 06 분야에 골조 활동과 일치하지 않는 비용이 나타나고, 누군가가 오후 내내 추적하며 발견할 때까지 표면화되지 않습니다.

건설 소프트웨어 플랫폼은 이 문제를 인지하고 있습니다. 이것이 Procore, CMiC, Viewpoint Vista가 약정 입력 시점에 원가 코드 선택을 강제하는 이유입니다. 하지만 이러한 강제 메커니즘은 데이터가 이미 시스템에 있을 때만 작동합니다. 공급업체의 PDF에서 데이터를 시스템으로 가져오는 문제는 해결하지 못합니다.

단일 발주서 추출 중 CSI MasterFormat 코드 매핑(원가 코드 열 설정 및 다단계 작업 단계 계층 구조 포함)에 대한 자세한 내용은 건설 발주서 원가 코드 추출 워크스루를 참조하세요.

일괄 워크플로우: 한 번 정의하고 모든 공급업체에서 추출

운영 대안은 워크플로우를 역전시키는 것입니다: 작업 원가 시스템이 요구하는 정확한 열(컬럼) — 즉 출력 스키마를 한 번 정의한 후, 모든 공급업체 PO를 동일한 추출 파이프라인에 통과시키는 것입니다. PO를 하나씩 처리하는 대신(추출, 다운로드, 마스터 시트에 복사-붙여넣기, 반복), 50개의 PO를 하나의 단위로 처리하여 통합된 출력 하나를 얻습니다.

먼저 열 헤더를 정의합니다 — 작업 원가 시스템이나 ERP 가져오기 템플릿이 예상하는 동일한 헤더입니다:

그런 다음 50개의 모든 PO — 제재소의 PDF, 석고보드 유통업체의 스캔본, 철근 제조업체의 시스템 출력물, MEP 공급업체의 QuickBooks 생성 주문서 — 를 단일 배치로 업로드합니다. 이것이 열 이름 추출입니다: 각 문서에서 각 필드가 어디에 있는지 도구에 알려주는 대신(50개의 템플릿이 필요함), 각 필드가 무엇을 의미하는지 알려줍니다. AI는 PO 번호가 무엇인지 이해함으로써 제재소 형식에서 "PO 번호"를 찾습니다. 특정 레이아웃의 모서리 위치가 아니라 개념을 이해하는 것입니다. "라인 합계"가 공급업체가 표의 가장 오른쪽 열에 배치하든, 품목 설명 바로 아래에 열 헤더 없이 배치하든 찾아냅니다.

실제로 가장 중요한 차이는 파일 하나만 다운로드하면 된다는 점입니다. 50개가 아니라요. 모든 구매요청서의 모든 라인 항목이 담긴 하나의 스프레드시트, 모든 열은 동일하고, 모든 행은 작업 번호별로 정렬하거나 비용 코드별로 필터링할 준비가 되어 있습니다. 통합 단계가 없습니다. 개별 내보내기 50개를 열고, 행을 마스터 시트에 복사하고, 아무것도 어긋나지 않기를 바라는 과정이 필요 없습니다. 병합은 추출 시점에 이루어지며, 이후에 하지 않습니다.

공급업체 수가 늘어날 때 확장성의 장점이 드러납니다. 41번째 공급업체가 또 다른 PO 형식을 사용해도 추가 설정 시간이 전혀 들지 않습니다. 템플릿을 만들거나, 경계 상자를 그리거나, 공급업체별 구성을 할 필요가 없습니다. 열 정의는 형식에 구애받지 않습니다. 41번째 공급업체의 PO는 처음 40개와 동일한 파이프라인으로 흘러들어가고, 출력은 동일한 열을 가진 동일한 통합 스프레드시트입니다. 이것이 규모가 커질수록 더 어려워지는 프로세스와 일정하게 유지되는 프로세스의 차이입니다.

PO에 내부 작업 번호가 인쇄되지 않는 경우

일반적인 PO 추출 가이드가 다루지 않는 건설 현장 특유의 문제가 있습니다. 대부분의 자재 공급업체 시스템에는 귀사의 내부 작업 번호가 없습니다. 공급업체는 자체 주문 번호를 가지고 있습니다. 참조 필드에 프로젝트 이름을 요청했다면 프로젝트 이름이 있을 수도 있습니다. 하지만 "작업 24-005" — 회계 시스템에서 모든 비용을 올바른 프로젝트에 연결하는 키 — 는 문서 자체에 없습니다.

수동 작업 흐름에서 프로젝트 회계 담당자는 공급업체 이름을 보고, 올바른 프로젝트에 정신적으로 매핑한 후("Builders FirstSource = 작업 24-005, Site Concrete Supply = 작업 24-003"), 해당 PO의 모든 라인 항목에 작업 번호를 수동으로 입력해야 합니다. 8개 프로젝트에 걸쳐 50개의 PO가 있다면, 50번의 수동 작업 번호 할당이 필요하며, 각각은 Site Concrete 자재를 잘못된 프로젝트에 넣을 기회가 됩니다.

이때 추론 열이 해법을 바꿉니다. 추론 열은 페이지에 있는 내용을 추출할 뿐만 아니라, 사용자가 정의한 규칙을 적용하여 문서 어디에도 인쇄되지 않은 값을 결정합니다. 작업 번호의 경우 "작업 #"이라는 열을 정의하고 다음과 같은 추론 규칙을 적용합니다:

AI가 Builders FirstSource의 PO를 처리할 때, 문서에서 공급업체명을 읽어 규칙과 대조한 후 작업 번호 열에 "24-005"를 자동으로 입력합니다. 이는 해당 PO의 모든 라인 항목에 적용됩니다. Site Concrete Supply의 PO는 "24-003"이 입력됩니다. 규칙 목록에 없는 새 공급업체가 나타나면 셀은 비워집니다. 잘못 추측하거나 조용히 오류가 발생하지 않으며, 검증 단계에서 이를 확인할 수 있습니다.

동일한 추론 패턴이 비용 코드에도 적용됩니다. Gerdau Rebar의 모든 주문이 03 21 00(철근)으로 분류된다면 해당 규칙을 추가하면 됩니다. Builders FirstSource가 골조용 목재(06 11 00)와 덮개용 합판(06 16 00)을 모두 납품하는 경우, 추론은 공급업체 기준이 아닌 품목 설명 기준으로 이루어집니다. AI가 "2×6 #2 SPF"를 읽으면 06 11 00으로 매핑하고, "7/16″ OSB"를 읽으면 06 16 00으로 매핑합니다. 매핑을 한 번 정의하면 배치 내 모든 PO에 자동으로 적용됩니다.

실질적인 효과: 50개 구매오더에 걸친 400건의 수동 분류 결정 중 상당 부분(일반적으로 일관된 공급업체 관계를 가진 계약자의 경우 70% 이상)이 추론 규칙으로 처리됩니다. 검증 단계에 남는 것은 30%입니다: 신규 공급업체, 특이한 자재 유형, 또는 사람의 판단이 필요한 모호한 설명입니다. 이는 400건 대신 120건의 결정이며, 남은 120건은 데이터에 잘못된 코드가 조용히 박혀 있는 대신 빈 셀로 표시되어 여러분이 확인할 수 있습니다.

일괄 출력에서 공사비 대사까지

다운로드하는 스프레드시트가 종착점이 아닙니다. 추출된 데이터를 신뢰할 수 있는 공사비 보고서로 전환하는 세 가지 검증 단계의 입력물입니다.

1. 공종 및 공사코드별 정렬 및 소계. 공종 번호와 공사코드 열이 채워지면 한 번의 정렬로 모든 PO 라인 항목이 프로젝트별로, 그리고 각 프로젝트 내에서 CSI 분류별로 그룹화됩니다. 라인 합계 열을 공종 번호별로 소계하면 프로젝트별 확정 자재비를 확인할 수 있습니다. 공사코드별로 소계하면 Division 03(콘크리트) 대비 Division 06(목재) 또는 Division 09(마감재)에 얼마나 확정되었는지 정확히 알 수 있습니다. 이전에는 50개의 개별 PO 파일을 합산해야 했던 작업이 이제는 한 시트의 피벗 테이블 하나로 해결됩니다.

2. 확정 비용과 프로젝트 예산 비교. 모든 공종에는 공사코드별로 세분화된 비용 예산이 있습니다(ERP(Sage, Viewpoint, Procore) 또는 PM이 관리하는 스프레드시트). 일괄 출력물이 공사코드별로 소계되면 예산에 대한 VLOOKUP으로 즉시 차이를 확인할 수 있습니다: Division 06은 목재 가격 급등으로 확정 예산 대비 12% 초과, Division 03은 콘크리트 타설이 예상보다 적어 5% 미만입니다. 이러한 논의는 기성 청구 패키지가 나가기 전에, 그리고 하도급 포기각서가 서명되기 전에 이루어져야 합니다.

3. 확정 비용과 실제 비용을 분리하세요. PO는 확정 비용, 즉 지출을 약속했지만 아직 지출하지 않은 금액을 나타냅니다. 자재가 인도될 때 도착하는 송장은 실제 비용을 나타냅니다. 이 둘을 구분하는 것은 건설 회계의 기본입니다. 확정 비용은 예산 대비 실적 예측에 영향을 미치고, 실제 비용은 현금 흐름에 영향을 미칩니다. 각 라인이 "확정"인지 "송장 발행"인지 추적하는 열이 있는 배치 출력은 동일한 시트에 두 숫자를 모두 제공합니다. 상태별로 정렬하여 분리하고, 둘 다 소계를 내어 프로젝트별 확정 비용과 실제 비용의 차이를 확인하세요.

PO 볼륨이 잘 설계된 배치 워크플로우조차도 주어진 시간 내에 처리할 수 있는 수준을 넘어선 계약자의 경우, 인력 증원 없이 문서 처리 확장하기 가이드의 확장 프레임워크가 프로세스 설계부터 다양한 볼륨 임계값에서의 팀 구조까지 조직적 측면을 다룹니다.

추출 오류 발생 시: 전체 재실행 대신 부분 재처리

50개의 PO 배치 중 적어도 2~3개는 문제가 있을 것입니다. AI가 $4,200를 $4,800로 읽는 번짐 스캔, AI가 하나의 테이블로 해석한 두 열 레이아웃을 사용한 공급업체 PO, 인쇄된 PO 배치에 섞인 부분적으로 읽기 어려운 손글씨 배송 메모 등이 그 예입니다. 문제는 오류가 발생하는지 여부가 아니라, 이를 수정하기 위해 전체 배치를 다시 처리해야 하는지입니다.

배치 출력은 각 행이 하나의 PO에 속한 하나의 라인 아이템에 해당하는 단일 스프레드시트입니다. Builders FirstSource의 목재 PO에서 5번째 항목인 37번 라인의 수량이 잘못된 경우, 1~36행이나 38~400행은 건드리지 않습니다. 해당 PO만 다시 처리하여 수정된 행을 잘못된 행 위에 붙여넣고 진행합니다. 시트 구조는 그대로 유지됩니다. 연쇄 작업은 없습니다. "PO #17을 다시 추출한 다음 모든 파일을 다시 병합하고 피벗 테이블을 다시 작성"할 필요가 없습니다. 오류는 해당 행에 국한되며, 수정도 동일한 행에 국한됩니다.

이것이 지급 요청 마감 전날 밤에 실행해도 믿을 만한 배치 프로세스와, 처음 사용했을 때 절약한 시간보다 더 많은 작업을 만들어내서 버리게 되는 배치 프로세스의 차이입니다. 배치 워크플로우가 완벽할 필요는 없습니다. 통제 가능해야 합니다. 즉, 하나의 잘못된 추출이 두 시간의 파일 재구성으로 이어지지 않아야 합니다. 오류율이 4~6%(혼합 형식과 다양한 스캔 품질의 건설 문서에서 일반적)인 경우, 부분 재처리 수정 시간은 5분(잘못된 PO 3개를 개별적으로 재추출하고 수정된 행을 붙여넣기)인 반면, 전체 배치를 다시 수행하는 데는 45분이 걸립니다. 이것이 워크플로우가 월말 압박 속에서도 살아남을 수 있는지를 결정하는 지표입니다.

자주 묻는 질문

자재 유형이 혼합된 PO(예: 단일 공급업체가 동일 주문에 목재와 패스너를 모두 보내는 경우)도 처리할 수 있나요?

네. PO의 각 라인 항목은 출력에서 자체 행을 가지며, 각 행은 항목 설명에 따라 자체 비용 코드를 받습니다. 건축 자재 공급업체의 PO에 2×6 골조재(06 11 00), OSB 덮개(06 16 00), 조이스트 행거(06 05 23)가 있는 경우, 동일한 문서에서 세 개의 서로 다른 비용 코드를 가진 세 개의 행이 생성되며, 모두 동일한 배치 출력에 포함됩니다. 추론 규칙이 항목별 분류를 처리하므로, 처리 전에 PO를 분할할 필요가 없습니다.

이메일 본문 텍스트나 휴대폰 사진으로 찍은 수기 주문서 형태로 PO를 받으면 어떻게 하나요?

추출 엔진은 PDF 및 스캔과 동일한 배치에서 둘 다 처리합니다. 이메일 본문 PO의 경우 스크린샷을 찍어 업로드하세요. 휴대폰 사진으로 찍은 수기 주문서의 경우, AI는 인쇄된 텍스트를 읽는 것과 동일한 방식으로 필기를 읽습니다. 가독성이 정확도에 영향을 미치는 주요 변수입니다. 공급업체 레터헤드에 적힌 선명한 수기 메모는 인쇄된 PO와 거의 동일한 정확도로 추출됩니다. 조명이 좋지 않은 상태에서 촬영한 번진 카본 사본은 정확도가 낮으므로 검증 단계에서 표시해야 합니다.

새로운 공급업체를 추가하거나 새 프로젝트를 시작할 때마다 추론 규칙을 업데이트해야 하나요?

새 공급업체의 경우: 처리 전에 추론 열에 "새 공급업체 이름 → 작업 #" 규칙 하나를 추가하면 됩니다. 이는 단일 텍스트 편집일 뿐, 템플릿 재구축이 아닙니다. 새 프로젝트의 경우: 해당 프로젝트에 할당된 공급업체를 새 작업 번호에 매핑하는 규칙을 추가합니다. Site Concrete Supply를 작업 24-003에서 작업 24-008로 이동하는 경우, 추론 규칙에서 한 줄을 업데이트합니다. 열 이름 추출 계층은 변경되지 않습니다. "공급업체 이름 / PO 번호 / 항목 설명 / 수량 / 단가"와 동일한 열이 활성 프로젝트에 관계없이 작동합니다.

배치 처리는 자재 PO의 유보금을 어떻게 처리하나요?

대부분의 자재 발주서(PO)에는 유보금이 포함되지 않습니다. 유보금은 일반적으로 자재 구매가 아닌 하도급 계약에 적용됩니다. 그러나 특별 주문 자재의 진행 지급이나 유보금 조항이 포함된 공급업체 계약과 같이 유보금이 적용되는 경우에는 계산 열을 추가할 수 있습니다. 계산 열은 페이지에서 값을 직접 읽어오는 대신 추출 중에 값을 계산하는 열입니다. "순 지급액"을 라인 합계 × (1 − 유보금 %) 로직으로 정의하면 AI가 PO별, 라인 항목별로 계산합니다. 유보금 비율은 PO에 인쇄되어 있으면 추출하거나, 열 정의에서 고정 매개변수로 지정할 수 있습니다. 문서 유형별 계산 열에 대한 자세한 내용은 문서 추출의 계산 열 소개를 참조하세요.

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

아니요. 이는 데이터 캡처 계층, 즉 공급업체 PDF에서 자재 PO 데이터를 가져와 구조화된 비용 코드 매핑 형식으로 변환하는 문제를 해결합니다. 회계 시스템의 승인 라우팅, 3방향 매칭(PO-입고-송장), 지급 처리, 유보금 면제 관리 또는 WIP 보고를 대체하지 않습니다. QuickBooks + 스프레드시트를 사용하는 계약자의 경우 배치 출력이 작업 원가 워크북에 직접 공급됩니다. Sage 100, Sage Intacct 또는 Viewpoint Vista를 사용하는 계약자의 경우 "공급업체 PO 수신"과 "ERP로 데이터 가져오기" 사이의 단계를 대체합니다. 많은 회사에서 이 단계는 여전히 사람이 PDF를 읽고 ERP 화면에 숫자를 입력하는 방식입니다. 개별 PO 처리, 즉 전체 배치 대신 단일 건설 PO에서 필드를 추출하는 방법은 단일 PO 추출 가이드에서 자세히 다룹니다.

여러 프로젝트의 PO를 한 배치로 처리할 수 있나요?

네 — 이것이 바로 Job #를 열로 포함하는 실무적 이점입니다. 진행 중인 8개 프로젝트의 PO를 한 번에 업로드하세요. 추론 규칙이 각 공급업체의 PO를 추출 시 올바른 작업 번호에 자동 할당합니다. 다운로드 후 Job # 기준으로 정렬하면 모든 라인 항목이 프로젝트별로 그룹화됩니다. Job #별 라인 합계 소계를 통해 몇 초 만에 프로젝트당 확정 자재비를 확인할 수 있습니다. 대안인 프로젝트별로 8개의 개별 배치를 실행한 후 통합하는 방식은, 바로 배치 워크플로가 제거하는 단편화의 전형입니다.