송장 20개, 보고서 1개:
원자재를 수동 입력 없이 처리하세요
APQC의 업계 간 벤치마킹 데이터에 따르면, 공급업체 송장 1건을 처리하는 중간 비용은 $6.00입니다. 하지만 이 수치는 서비스 및 완제품에 대한 비용 송장을 중심으로 구축된 표준화된 미지급금 워크플로를 가정합니다. 원자재는 이 공식을 뒤집습니다. 모든 송장은 일반 비용 라인이 아닌 다른 재고 원장 계정(원자재(일반적으로 코드 13xx), 재공품(14xx) 또는 특정 작업 주문)에 매핑됩니다. Ryerson의 304 스테인리스 스틸 500파운드에 대한 송장은 MSC Industrial Supply의 절삭유 송장과 다른 계정에 기록됩니다. 하나씩 처리하면 데이터를 추출하는 것보다 GL 계정을 코딩하는 데 더 많은 시간을 소비하게 됩니다.
핵심 요약
- 월 20건의 원자재 송장은 5개의 재고 계정에 분산된 200건의 GL 코딩 결정을 의미하며, 데이터 입력은 결코 어려운 부분이 아니었습니다.
- 공급업체별 OCR 템플릿은 설정 작업을 공급업체 수만큼 증가시킵니다. 40개 업체에서 40개의 구성을 구축해야 하며, 그 후에도 수기로 작성된 납품서는 여전히 실패합니다.
- ImageToTable.ai는 위치가 아닌 의미로 모든 공급업체 송장을 읽습니다. 하나의 템플릿이 추출 중에 200개의 라인 항목을 5개의 GL 계정으로 코딩하고, SOX 감사를 위해 모든 행을 원본 PDF에 연결합니다.
원자재 인보이스 20장이 일반 AP 인보이스 20장과 다른 문제를 만드는 이유
표준 미지급금(AP) 처리 프로세스는 예측 가능한 문서를 기반으로 설계되었습니다. 인보이스에는 공급업체명, 날짜, 총액, 비용 계정에 매핑되는 라인 항목이 있습니다. 원자재 인보이스는 세 가지 방식으로 이 모델을 깨뜨리며, 이러한 차이는 대량 처리 시 더욱 두드러집니다.
첫째, 공급업체 환경은 극심한 형식 다양성을 만듭니다. 중견 제조업체의 AP 담당자는 MRO 자재용 Grainger, 절삭 공구용 MSC Industrial Supply, 체결구용 Fastenal, 단발성 하드웨어용 McMaster-Carr, 지역 철강 유통업체의 판재, 공정 자재용 화학 공급업체, 아웃소싱 가공을 위한 여러 지역 기계 공장 등 각기 다른 PDF 레이아웃의 인보이스를 받을 수 있습니다. r/Accounting의 한 Reddit 사용자는 자신들의 현실을 이렇게 설명했습니다. 팀은 공급업체로부터 매월 1,500~2,000장의 인보이스를 처리하는데, "NetSuite에 내장된 OCR 기능은 모든 기계 공장과 원자재 공급업체가 각자 다른 형식으로 인보이스를 작성하기 때문에 절반은 제대로 읽지 못합니다." 템플릿 기반 OCR은 공급업체별로 별도 설정이 필요하며, 원자재 제조업체는 일반적으로 15~40개의 활성 공급업체를 두고 각자 고유한 문서 스키마를 사용합니다. 설정 비용은 공급업체 수에 비례하여 증가합니다.
둘째, 원자재 인보이스는 비용 계정이 아닌 재고 계정으로 연결됩니다. 제조업의 표준 계정과목표에서 직접 원자재 구매는 원자재 재고(대부분 번호 체계에서 계정 코드 13xx)로 차변에 기입되고, 이후 재공품 재고(14xx)를 거쳐 완제품 재고(15xx)로 이동하며, 최종적으로 제품 출하 시 매출 원가로 계상됩니다. 304 스테인리스강 인보이스는 단순한 비용 기록이 아니라 재고 평가 이벤트입니다. 동일한 인보이스 배치에 MSC의 절삭유나 Grainger의 안전 장갑과 같은 간접 자재가 포함된 경우, 이는 제조 간접비(계정 코드 43xx) 또는 소모품 비용 계정으로 매핑됩니다. 각 인보이스를 개별적으로 코딩한다는 것은 배치 전체에서 5~6개의 서로 다른 GL 계정을 전환해야 함을 의미하며, 이는 단일 문서 추출 도구로는 해결할 수 없는 인지적 부담입니다.
셋째, 부분 납품은 산업 조달에서 표준 관행입니다. 알루미늄 봉재 2,000파운드에 대한 구매 주문이 4주에 걸쳐 3번의 개별 선적으로 도착할 수 있으며, 각 선적마다 자체 공급업체 인보이스와 포장 명세서가 발행됩니다. 첫 번째 인보이스는 800파운드, 두 번째는 700파운드, 세 번째는 500파운드에 대해 청구됩니다. 단일 인보이스 추출 워크플로우는 각 문서를 개별적으로 처리하고, 3개의 부분 인보이스를 하나의 PO 및 누적 수령 보고서와 일치시키는 통합 작업은 수동 스프레드시트 작업으로 남습니다. 20개 이상의 공급업체에 걸친 대량 처리에서 부분 납품 조정은 몇 시간의 상호 참조 작업으로 이어집니다. 모든 인보이스 지불이 수령 보고서에 의해 뒷받침되어야 한다고 규정하는 FAR 32.905의 적용을 받는 정부 계약자의 경우, 이 조정은 선택 사항이 아니라 규정 준수 요구 사항입니다.
제조 맥락에서 3방향 매칭(PO, 수령 보고서, 인보이스 조정)이 어떻게 작동하는지에 대한 기본 내용은 제조업에서 공급업체 인보이스를 PO와 매칭하는 방법을 참조하십시오. 해당 문서는 매칭 프레임워크를 다루고, 이 문서는 해당 프레임워크에 입력되는 추출 단계를 일괄 처리할 때 발생하는 상황에 초점을 맞춥니다.
한 번에 20장의 인보이스를 처리할 때만 나타나는 세 가지 문제
단일 인보이스 처리는 배치를 처리하는 순간 구조적으로 불가피해지는 복잡성을 숨깁니다. 세 가지 문제가 표면화됩니다. 이는 단일 인보이스 문제의 과장된 버전이 아니라 배치 규모에 특화된 문제입니다.
1. 출력 행 귀속 — 어떤 품목이 어떤 공급업체에서 왔는가?
단일 인보이스에서 데이터를 추출하면 출처를 알 수 있습니다. 12개 공급업체의 인보이스 20장을 배치 처리하면 출력은 단일 스프레드시트이며, 어떤 행이 어떤 공급업체와 인보이스에 속하는지 즉시 알아야 합니다. 잘 설계된 배치 추출 도구는 모든 출력 행에 소스 파일 열을 포함합니다. 해당 데이터를 생성한 원본 인보이스의 파일명입니다. 이 열이 없으면 각 행을 원본 문서에 수동으로 매칭해야 하며, 이는 배치 처리의 목적을 무색하게 합니다. 열에 포함되어야 할 내용은 명명 규칙에 따라 다릅니다: "Ryerson_052024.pdf", "MSC_PO4472_052024.pdf", "Fastenal_weekly_052024.pdf". 파일명 자체가 데이터 필드가 되며, 배치 전체에 걸친 일관된 명명 규칙이 다운스트림 정렬 및 필터링을 가능하게 합니다.
2. 형식 혼합 — PDF, 스캔본, 수기 배송 명세서가 동일한 추출 작업에 포함될 때
원자재 배치에는 깨끗한 PDF만 있는 경우가 거의 없습니다. 제철소는 포맷된 전자 인보이스를 보냅니다. 지역 주조소는 하단에 수기로 작성된 합계가 있는 종이 문서를 스캔하여 이메일로 보냅니다. 트럭 기사는 부두에서 누군가 휴대폰으로 촬영한 카본 카피 패킹 슬립을 건넵니다. 템플릿 기반 OCR 도구는 각 형식 유형에 대해 별도의 구성이 필요하며, 일반적으로 수기 문서나 비스듬히 촬영된 휴대폰 사진에서는 완전히 실패합니다.
이것이 기본 추출 메커니즘이 중요한 이유입니다. 기존 OCR은 위치를 기준으로 데이터를 찾습니다. 인보이스 번호는 항상 1페이지의 오른쪽 상단 모서리에 있습니다. 비전 모델(의미론적 문서 추출을 구동하는 AI 유형)은 의미를 기준으로 데이터를 찾습니다. "Invoice No."라는 단어 옆에 있는 숫자가 페이지의 어디에 나타나든 인보이스 번호임을 이해합니다. 동일한 열 이름 템플릿("자재 설명", "수량", "단가", "라인 합계")은 포맷된 Ryerson PDF, 스캔된 Fastenal 인보이스, 동일한 배치의 수기 배송 명세서 휴대폰 사진에서 데이터를 추출하여 동일한 출력 스프레드시트에 행을 생성합니다. 특정 문서에 필드가 적으면 일부 셀이 비어 있을 수 있지만, 열 구조는 모든 행에서 그대로 유지됩니다.
단일 형식 처리와 혼합 형식 처리의 차이는 성능 업그레이드가 아닙니다. 이는 배치를 처리하는 도구와 사용하기 전에 인보이스를 형식 호환 그룹으로 미리 분류해야 하는 도구의 차이입니다.
3. 배치 규모의 예외 처리 — 하나의 잘못된 청구서가 전체 대기열을 차단하는 경우
단일 청구서 워크플로에서는 예외(손상된 PDF, 읽을 수 없는 스캔, 도구가 지원하지 않는 언어의 문서)가 하나의 작업을 중단시킵니다. 배치 워크플로에서는 하나의 잘못된 문서가 전체 배치를 중단시키는지, 아니면 나머지 배치가 독립적으로 계속 처리되는지가 문제입니다. 잘못된 동작은 최악의 경우입니다. 19개의 청구서가 성공적으로 추출되었지만, 20번째 청구서에 읽을 수 없는 페이지가 있어 전체 배치가 출력을 생성하지 못하는 경우입니다. 올바른 동작은 문서별 오류 격리입니다. 배치의 각 문서는 독립적으로 성공하거나 실패하며, 최종 출력에는 성공적으로 추출된 모든 행과 실패한 문서에 대한 빈 항목 또는 오류 플래그가 포함됩니다. 배치를 처리하기 전에 도구에 물어보세요. 12번째 청구서가 팩스로 전송된 납품서의 손상된 스캔본이라면, 19개 청구서 분량의 데이터를 얻을 수 있습니까, 아니면 0개를 얻을 수 있습니까?
20개의 PDF에서 하나의 비용 보고서로: 배치 워크플로, 단계별
다음은 월별 원자재 청구서 배치를 처리하는 제조 원가 회계사를 위한 종단 간 워크플로입니다. 수동 입력에 3~4시간이 소요되던 작업을 약 15분의 업로드 및 검토로 단축합니다.
1단계 — 추출 템플릿을 한 번 정의합니다. 템플릿은 스프레드시트의 구조가 되는 열 이름 목록입니다. 원자재 비용 보고를 위한 실용적인 템플릿에는 공급업체명, 청구서 번호, 청구서 날짜, 발주 번호, 자재 설명, 자재 등급/사양, 수량, 측정 단위, 단가, 라인 합계 및 GL 계정이 포함됩니다. GL 계정 열은 추론 추출을 사용할 수 있습니다. "원자재 재고 / WIP / MRO 소모품 / 제조 간접비"와 같은 옵션으로 열을 정의하면 AI가 자재 설명 및 공급업체 컨텍스트를 기반으로 각 라인 항목을 올바른 GL 계정으로 분류합니다. 청구서에 GL 코드가 명시적으로 인쇄되어 있지 않더라도 말이죠. 이 분류는 추출 중에 이루어지며, 이후가 아니므로 비용 보고서를 다운로드할 때 이미 코딩되어 있습니다.
도구의 사용자 정의 열 추출 메커니즘은 템플릿 기반 OCR과 다르게 작동합니다. 각 공급업체의 청구서 형식에 필드 주위에 상자를 그리는 대신, 원하는 데이터 포인트("자재 설명", "단가")를 입력하면 AI가 각 값을 위치가 아닌 의미를 이해하여 찾습니다. AI가 위치가 아닌 의미론적으로 읽기 때문에 하나의 템플릿이 모든 공급업체의 형식에서 작동합니다.
2단계 — 청구서 파일을 수집하고 이름을 지정합니다. 일주일 또는 한 달 동안 모든 공급업체 청구서(이메일의 PDF, 스캔한 종이 청구서, 납품서의 휴대폰 사진)를 단일 폴더에 저장합니다. 일관된 파일 이름 규칙은 출력 스프레드시트를 즉시 정렬 가능하게 만듭니다. [공급업체]_[청구서번호]_[날짜].pdf — 예: "Ryerson_INV88241_052024.pdf", "MSC_4472_052024.pdf", "Fastenal_WK21_052024.pdf". AI는 추출을 위해 파일 이름이 아닌 문서 내용을 읽습니다. 그러나 출력에 소스 파일 열이 포함되면 깔끔한 명명 규칙을 통해 원본 PDF를 열지 않고도 공급업체별로 필터링, 정렬 및 감사할 수 있습니다.
3단계 — 전체 배치를 업로드합니다. PDF, 스캔본, 휴대폰 사진 등 20~50개의 모든 문서를 업로드 영역으로 드래그합니다. 시스템은 이를 하나의 작업으로 처리하며, 배치의 모든 문서에 동일한 열 이름 템플릿을 적용합니다. 공급업체별 구성이 필요 없습니다. 문서별 업로드 주기가 필요 없습니다. 청구서당 평균 2페이지인 20개 청구서 배치의 처리 시간은 약 40페이지이며, 이는 단일 처리 패스로 완료됩니다.
4단계 — 모든 셀이 아닌 결과를 검토하세요. 결과는 모든 송장의 모든 행이 포함된 단일 스프레드시트입니다. 공급업체명으로 정렬하여 각 업체의 행이 모두 표시되는지 확인하세요. 공급업체당 한두 개의 라인 항목을 샘플 점검합니다: Ryerson의 304 스테인리스 스틸 라인이 올바른 수량과 단가를 표시하는지, 현지 주물 공장의 수기 메모가 올바르게 읽혔는지, GL 계정 분류가 계정과목표와 일치하는지 확인하세요. 20개 송장(100~200개 라인 항목) 배치의 검토 시간은 약 3분입니다 — 목표는 셀별 확인이 아닌 이상 징후 탐지입니다.
5단계 — ERP로 가져오거나 전기하세요. 출력 파일(Excel 또는 CSV)은 가져오기 준비가 완료된 구조입니다. ERP가 대량 분개장 가져오기를 지원하는 경우(SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365, Epicor, Infor CloudSuite 모두 지원), 원가 데이터가 적절한 재고 GL 계정으로 직접 흐릅니다. Microsoft Dynamics를 사용하는 제조업체의 경우 열 구조가 일반 분개장 가져오기 템플릿에 깔끔하게 매핑됩니다. Oracle NetSuite의 경우 CSV 가져오기 도우미가 동일한 열 레이아웃을 허용합니다.
파일은 안전하게 처리되며 저장되지 않습니다.
배치 규모의 원가 배분: 제조업에서 추출 후가 아닌 추출 중 GL 코딩이 필요한 이유
원자재 배치의 원가는 모든 라인 합계의 합이 아닙니다. 이는 해당하는 총계정원장 계정별로 그룹화된 라인 합계의 합이며, 이러한 그룹화는 누가 판매했는지가 아니라 무엇을 구매했는지에 따라 결정됩니다. 동일한 공급업체인 Ryerson이 직접 생산 자재(304 스테인리스 환봉 — 원자재 재고, 13xx)에 대한 송장 하나와 공장 소모품(용접 가스 — 제조 간접비, 43xx)에 대한 다른 송장을 보낼 수 있습니다. 수동 GL 코딩을 위해서는 AP 담당자가 모든 라인 항목을 평가하고 올바른 계정을 할당해야 합니다. 이는 송장 20개에 각각 8~12개의 라인 항목이 있을 경우 200개의 개별 코딩 판단을 의미합니다.
추론 기반 추출이 이를 변화시킵니다. GL 계정 (옵션: 원자재 / 재공품 / MRO 소모품 / 제조 간접비 / 운임)과 같은 열을 정의함으로써 AI는 라인 항목 설명("304 SS 환봉 2인치 직경" 또는 "절삭유 5갤런")을 읽고 자재 맥락에서 올바른 GL 분류를 추론합니다. 분류는 추출 중에 배치 내 모든 문서의 모든 라인 항목에 대해 실행됩니다. 출력 스프레드시트는 이미 계정별로 코딩되고 그룹화되어 전기 준비가 완료된 상태로 도착합니다.
운임이 포함된 원자재 구매의 경우, 운임 (추론: 송장 하단 또는 라인 항목의 배송비)이라는 별도 열이 비용 처리되지 않고 재고 가치로 자본화되어야 하는 배송 비용을 포착합니다. 표준 원가 회계에서 원자재 운임은 재고 원가의 구성 요소이지 기간 비용이 아닙니다. 이를 자재 단가와 별도로 추출하면 원가 배분 추적이 보존됩니다.
200개의 라인 항목이 있는 20개 송장 배치가 추출 중에 각각 올바른 재고 GL 계정으로 자동 분류되면, 2시간 수동 코딩 작업이 AI 분류에 대한 3분 간단 확인으로 단축됩니다.
SOX 규정 준수 — 특히 재무 보고에 대한 문서화된 내부 통제를 요구하는 섹션 302 및 404 — 의 적용을 받는 제조업체의 경우, 소스 파일 속성이 포함된 배치 추출의 감사 추적 이점은 상당합니다. 출력 스프레드시트의 모든 추출된 행은 특정 송장 파일 및 해당 파일 내의 특정 페이지로 연결됩니다. 추출 이벤트 자체가 감사 체인의 기본 링크가 되어 원시 소스 문서와 총계정원장으로 흘러가는 구조화된 데이터 간의 검증 가능한 연결을 설정합니다. 감사자는 데이터 경로를 수동으로 재구성하지 않고도 모든 분개를 원래 공급업체 송장까지 추적할 수 있습니다.
전체 배치를 처리하는 대신 하나의 공급업체 문서에서 특정 필드를 추출해야 하는 단일 송장 추출 워크플로의 경우, 대상 송장 필드 추출 도구는 개별 문서 처리에 최적화된 집중 워크플로를 제공합니다. 더 높은 볼륨의 대량 송장-Excel 처리를 위해서는 배치 송장을 Excel로 도구가 동일한 템플릿 시스템으로 대규모 업로드 대기열을 처리합니다.
자주 묻는 질문
한 번에 처리할 수 있는 원자재 인보이스는 몇 개인가요?
파일 개수에 엄격한 제한은 없습니다. 실질적인 제약은 총 페이지 수입니다. 평균 2페이지짜리 인보이스 20개(총 40페이지)는 한 번의 처리 작업으로 완료됩니다. 50개 이상의 다중 페이지 인보이스처럼 매우 큰 배치의 경우, 금속 및 원자재는 한 묶음으로, MRO 및 공구 자재는 다른 묶음으로 공급업체 카테고리별로 나누어 업로드하면 처리 시간을 관리 가능한 수준으로 유지하고 검토가 더 쉬워집니다.
공급업체가 동일한 자재에 대해 다른 이름을 사용하면 어떻게 되나요?
AI는 정확한 문자 일치가 아닌 의미를 기준으로 자재 설명을 읽습니다. "304 SS Round Bar 2", "Stainless Steel Rod 2in 304", "SS Bar Rnd 304 2.000"은 모두 동일한 품목을 설명한다고 모델이 이해하기 때문에 동일한 자재 설명 열로 매핑됩니다. 정확한 재고 매칭을 위해서는 자재 설명 열과 공급업체 부품 번호 열을 모두 포함하세요. 설명은 정규화된 품목을 제공하고, 공급업체 번호는 필요할 때 정확한 조정을 위한 공급업체별 식별자를 제공합니다.
AI가 동일한 인보이스에서 직접 자재와 MRO 소모품을 구분할 수 있나요?
네, 분류 옵션이 포함된 GL 계정 열과 함께 추론 추출을 사용할 때 가능합니다. AI는 라인 항목 컨텍스트를 읽습니다. "304 SS Round Bar"는 직접 생산 자재이고, "Cutting Fluid 5-Gal"은 MRO 소모품입니다. 두 라인 항목이 동일한 공급업체 인보이스에 나타나더라도 각 행에 올바른 GL 계정을 독립적으로 할당합니다. 이 행 수준 분류는 배치 내 모든 문서의 모든 라인 항목에 대해 실행됩니다.
각 공급업체에 대해 별도의 추출 템플릿을 만들어야 하나요?
아니요. 단일 열 이름 템플릿으로 Grainger, Fastenal, McMaster-Carr, MSC, Ryerson, 지역 기계 공장 및 철강 유통업체 등 배치 내 모든 공급업체에 적용됩니다. AI는 페이지의 고정된 위치가 아닌 의미적 의미를 기준으로 데이터를 찾습니다. "자재 설명"이라는 열은 공급업체가 "설명", "품목", "제품"으로 표시하거나 테이블 헤더에 레이블 없이 나열하더라도 자재 설명을 찾습니다. 이것이 새로운 공급업체가 추가될 때마다 설정 비용이 배가되지 않으면서 배치 처리를 가능하게 하는 구조적 이점입니다.
일괄 추출은 하나의 구매 주문서가 여러 개의 인보이스로 분할 납품될 때 어떻게 처리하나요?
각 분할 납품 인보이스는 일괄 출력에서 고유한 행을 생성하며, 모두 해당 열에 동일한 PO 번호를 갖습니다. PO 번호별로 출력을 정렬하면 각 구매 주문에 대한 모든 분할 납품이 함께 나타납니다. 각 인보이스의 수량이 원래 PO 수량과 나란히 표시됩니다. 수령 누계로 통합하려면 Excel에서 SUMIF 함수를 빠르게 사용하면 됩니다: =SUMIF(PO_Number_Column, [your_PO], Quantity_Column). 전체 매칭 프레임워크(누적 수령액을 PO와 비교하고 불일치를 표시)는 제조업에서 공급업체 인보이스를 PO에 매칭하는 방법을 참조하세요.
일괄 처리된 인보이스 중 일부가 다른 언어로 되어 있으면 어떻게 하나요?
AI의 기본 비전 모델은 다국어를 지원합니다. 영어, 독일어, 프랑스어, 스페인어, 일본어 등 다양한 언어의 인보이스 데이터를 동등하게 읽습니다. 영어 열 머리글을 사용하는 열 이름 템플릿은 유럽 철강 공급업체의 독일어 인보이스에서도 데이터를 추출합니다. AI가 키워드 일치가 아닌 의미를 기준으로 "Invoice Date"를 "Rechnungsdatum"에 매핑하기 때문입니다. 추출된 값은 원본 문서의 언어와 관계없이 영어 열 이름 아래 출력에 나타납니다.
일괄 추출의 정확도는 인보이스를 하나씩 처리하는 것과 비교하여 어떤가요?
문서당 정확도는 동일합니다. AI는 일괄 처리의 각 문서에 단일 업로드와 동일한 추출 로직을 적용합니다. 주요 공급업체의 인쇄된 표 데이터의 경우 인식 정확도는 최대 99%에 이릅니다. 손으로 쓴 납품서나 저품질 휴대폰 사진의 경우 정확도는 가독성에 따라 달라집니다. 실질적인 차이는 검토 단계에 있습니다. 모든 셀을 재확인하는 대신 공급업체당 2~3개의 라인 항목을 점검하면 됩니다. 또한 이 도구는 Precision+ 모드를 제공합니다. 이는 수동 토글 기능으로, 어려운 문서의 필드 인식을 개선하기 위해 AI에 추가 추론 패스를 제공하지만 페이지당 2~3초가 더 소요됩니다. 깨끗한 PDF에서는 끄고, 조명이 좋지 않은 상태에서 촬영한 카본 카피 포장 명세서에서는 활성화하세요.