종이 거래명세서 OCR 자동 입력 — 매입채무와 실제원가를 망치지 않는 Document AI 설계

식품공장의 매입 데이터는 의외로 생산현장보다 더 늦게 확정되는 경우가 많다. 원료는 오전에 입고됐고 창고에서는 실제 중량까지 확인했지만, 거래명세서는 사진으로 전달되고 경리담당자가 며칠 뒤 ERP에 다시 입력한다.

이 과정에서 185.6kg이 158.6kg으로 입력되고, kg당 단가가 Box 단가로 들어가며, 면세 원료에 부가세가 붙는 오류가 발생한다. 문제는 단순 타자 실수가 아니다. 잘못 입력된 매입 데이터는 재고수불·매입채무(AP)·원재료 단가·제조원가를 동시에 왜곡한다.

Document AI의 목적은 종이를 없애는 게 아니라 이미 현장에서 발생한 구매·입고 사실을 다시 타이핑하지 않는 구조를 만드는 것이다.

식품 매입은 ’문서에 적힌 수량’과 ’실제 받은 수량’이 다를 수 있다

가변중량 원료에서는 발주수량·공급업체 출고수량·실제 입고중량이 서로 다를 수 있다.

PO는 돼지고기 200kg
공급업체 거래명세서는 198.4kg
현장 계근 결과는 197.9kg
검수에서 2.0kg 부적합 → 최종 승인수량 195.9kg

이때 거래명세서의 198.4kg을 OCR로 정확하게 읽었다고 해서 ERP 재고를 198.4kg 증가시키면 안 된다. OCR은 문서의 사실을 추출하는 기술이고, 실제 재고수량은 GRN 또는 입고검수 실적이 결정해야 한다. 이 구분이 없으면 자동화가 수기 오류를 줄이는 대신 잘못된 데이터를 더 빠르게 확정하게 된다.

OCR보다 먼저 필요한 것은 문서의 역할 구분이다

거래명세서·세금계산서·납품서·계근표는 서로 다른 증빙이다. 거래명세서는 공급업체가 주장하는 납품수량과 금액을 담을 수 있고, GRN은 실제 수령한 수량을 기록한다. 세금계산서는 세금증빙과 청구자료 역할을 하지만 그것만으로 실제 입고수량을 확정하지는 않는다.

따라서 시스템에서는 문서별 Source Type을 구분한다.

PO = 주문 사실
GRN = 실제 입고 사실
Invoice/거래명세서 = 공급업체 청구 사실

이 세 가지를 하나의 숫자로 덮어쓰지 않아야 3-Way Matching이 가능하다.

AI OCR은 문자를 읽는 게 아니라 필드를 구조화해야 한다

종이 거래명세서를 이미지에서 텍스트로 변환하는 것만으로는 ERP 자동입력이 어렵다. 필요한 것은 Key-Value Extraction이다. 공급자 사업자번호·거래일자·품목명·규격·수량·단위·단가·공급가액·세액·합계금액 같은 항목을 각각 구조화된 Field로 추출해야 한다.

여기서 Vision AI의 장점은 공급업체마다 서식 위치가 달라도 문맥을 이용해 항목을 추정할 수 있다는 데 있다. 다만 추정값은 어디까지나 후보값이다. ERP Transaction으로 확정되기 전에 Master Mapping과 검증 단계를 거쳐야 한다.

사업자번호는 Vendor Master Mapping의 가장 강한 Key가 된다

공급업체 명칭은 동일업체라도 여러 방식으로 표시될 수 있다. 농업회사법인 ○○ · (주)○○ · ○○푸드처럼 서류마다 표기가 달라질 수 있다. 따라서 OCR에서 추출한 사업자등록번호를 Vendor Master의 Primary Matching Key로 사용하고, 상호명은 보조 검증값으로 쓰는 편이 안정적이다. 사업자번호가 인식되지 않거나 Master와 불일치하면 자동확정하지 않고 Exception Queue로 보내야 한다.

계좌번호처럼 지급과 연결되는 정보는 OCR로 읽었다고 기존 Vendor Master를 자동 변경해서는 안 된다. 거래처 계좌변경은 별도의 검증·승인 절차를 두는 것이 내부통제상 안전하다.

가장 어려운 것은 품목명 Mapping이다

공급업체 문서의 품목명과 ERP Item Master는 거의 항상 다르다. 공급업체는 국산 삼겹 냉장이라고 적고 ERP는 RM-PORK-BELLY-CHILLED 또는 돼지고기_삼겹살_냉장으로 관리할 수 있다. 따라서 Mapping Engine은 단순 문자열 일치만 써서는 안 된다.

Vendor별 Alias Dictionary를 두고 Vendor + Supplier Item Name + Specification + Unit → Internal Item Code 관계를 축적하는 편이 좋다. 한 번 승인된 Mapping은 다음 문서에서 재사용하고, 신규 품목이나 낮은 Confidence Score는 사람이 승인하게 한다. Master Data가 정제되지 않은 상태에서는 OCR 정확도가 아무리 높아도 ERP Mapping 정확도는 올라가지 않는다.

단위 변환은 숫자 인식보다 중요하다

식품 원료에서는 kg·g·EA·Box·포대·Roll 등 여러 단위가 혼재한다. 거래명세서에 수량 10, 단가 45,000원이 적혀 있을 때 이것이 10kg인지 10Box인지 시스템이 모르면 매입금액만 맞고 재고수량은 틀릴 수 있다.

따라서 Item Master에는 구매단위와 재고관리단위를 분리해야 한다.

Purchase UOM = BOX
Inventory UOM = KG
Conversion = 1 BOX = 20 KG

같은 환산규칙이 필요하다. 가변중량 품목은 고정 환산계수 대신 실제 Net Weight를 GRN에서 받아야 한다. OCR는 거래명세서 단위를 읽고, ERP는 그 단위가 해당 공급업체·품목에 허용된 단위인지 검증한다.

3-Way Matching은 ’숫자가 같은가’보다 차이의 이유를 찾는 절차다

매입 자동화의 핵심은 PO-GRN-Invoice 비교다.

PO는 1,000kg × 3,000원
GRN은 실제 985kg
Invoice는 985kg × 3,050원

이 경우 수량은 입고와 일치하지만 단가는 PO와 다르다. 시스템은 이를 오류로 단순 거부하기보다 Price Variance로 분류해야 한다. 반대로 Invoice가 1,000kg인데 실제 GRN이 985kg이라면 Quantity Variance다. 회사에서 정한 Tolerance 안의 차이는 자동 승인할 수 있고, 초과 건은 AP Hold로 보낼 수 있다. Tolerance는 품목군·거래처·계약조건에 따라 다르게 설정할 수 있으며 법정 고정수치가 아니라 내부 통제정책이다.

OCR 자동화의 목적은 AP 자동생성이 아니라 AP 오기 차단이다

문서를 읽었다고 곧바로 매입채무를 확정하면 위험하다. 더 안전한 구조는 다음이다.

Document Capture → OCR Extraction → Vendor/Item Mapping → PO Match → GRN Match → Tax/Price Validation → Approval → AP Posting

이 흐름에서 OCR는 입력을 대체하고, Matching Engine은 검증을 담당하며, 최종 회계 Transaction은 승인규칙을 통과한 데이터만 생성한다. OCR Confidence가 낮거나 PO가 없거나 수량·단가 차이가 Tolerance를 넘으면 자동분개 대신 검토대상으로 보내야 한다.

세금계산서와 거래명세서는 같은 문서가 아니다

전자세금계산서는 부가가치세 증빙과 세무처리에 중요한 자료이지만, 실제 물류수량을 입증하는 문서와는 역할이 다르다. 공급가액과 세액이 맞더라도 입고수량이나 품목 Mapping이 틀릴 수 있다.

특히 식품 제조업은 면세 농수산물과 과세 가공원료가 혼재할 수 있으므로, 문서의 세율을 그대로 회계계정에 매핑하지 말고 Item Tax Master와 교차검증하는 편이 좋다. OCR가 세액을 읽는 기능과 회계가 세무처리를 결정하는 로직은 분리해야 한다.

종이 오염과 손글씨는 Confidence Score로 관리해야 한다

식품공장의 거래명세서는 깨끗한 PDF만 들어오지 않는다. 냉장차에서 젖거나 접히고, 도장이 겹치거나 볼펜으로 실제 중량을 수정하기도 한다. 이런 문서를 100% 자동처리하려고 하면 오류가 숨어 들어간다.

따라서 Field별 Confidence Score를 저장한다. 예를 들어 사업자번호 99% · 총액 98% · 품목명 82% · 실중량 61%라면, 전체 문서를 자동승인하지 않고 낮은 신뢰도 Field만 사람에게 보여줄 수 있다. 사람은 전체 문서를 다시 타이핑하는 게 아니라 AI가 의심한 부분만 확인한다. 이것이 OCR 자동화와 단순 문자인식의 차이다.

수기 입력과 Document AI의 차이는 검증 시점에 있다

구분	수기 매입 입력	OCR·ERP 연동
문서 입력	전체 재타이핑	Key-Value 자동 추출
거래처 확인	상호명 육안	Vendor Master Mapping
품목 Mapping	담당자 기억	Vendor Alias Mapping
단위 변환	수기 계산	UOM Master 검증
입고수량	문서값 재입력 가능	GRN 기준
단가 검증	월말 대조	PO Price Match
세금 검증	문서 기준 입력	Tax Master 교차검증
AP 생성	담당자 입력	Matching 승인 후 Posting
오류 발견	결산·지급 후	Exception Queue
이력	수정자 추적 어려움	Audit Trail

GRN은 Raw Material Inspection과 연결돼야 한다

입고수량이 확인됐다고 곧바로 정상재고가 되는 것은 아니다. 원재료는 입고검사 결과에 따라 QC HOLD · RELEASED · REJECTED 상태로 나뉠 수 있다. 따라서 OCR 거래명세서가 500kg을 읽고 GRN이 498kg을 확인했더라도 실제 생산에 쓸 수 있는 수량은 품질승인 후 495kg일 수 있다. 이 부분은 원료 입고검사와 연결된다. ERP는 매입과 재고수불을 관리하고, MES는 승인된 원료 LOT가 실제 어느 Batch에 투입됐는지를 기록한다.

실제원가는 OCR 금액만으로 결정되지 않는다

매입단가는 Actual Costing의 중요한 입력값이지만 그것만으로 Batch 실제원가가 확정되지는 않는다. 원료 단가가 ERP에 정확하게 들어와도 MES 실제투입량이 틀리면 제조원가는 여전히 틀린다. 따라서 Approved Purchase Cost × MES Actual Consumption이 연결돼야 한다. 거래명세서 OCR 자동화는 ERP 원가의 금액 Source를 정제하고, MES는 실제 소비수량 Source를 제공한다. 두 데이터가 만나야 제품별 실제 재료비가 계산된다.

Document AI의 완성도는 자동처리율보다 예외를 얼마나 안전하게 남기는가에서 결정된다

OCR 시스템에서 가장 위험한 상태는 “자동처리 성공”으로 표시됐지만 실제로는 잘못 Mapping된 경우다. 그래서 신규 거래처 · 신규 품목 · 단위 불일치 · 사업자번호 불일치 · PO 미존재 · GRN 미존재 · 가격차이 · 세금차이 · 낮은 Confidence 같은 사건은 Exception Type으로 남겨야 한다. 그리고 누가 어떤 값을 수정했고 어떤 근거로 승인했는지를 Audit Trail로 기록한다.

최종 구조는 단순하다.

Vendor EDI/PO → Physical Receipt/GRN → Raw Material Inspection → Document AI/OCR → 3-Way Matching → AP Posting → ERP Costing → MES Actual Consumption

종이 거래명세서를 자동으로 읽는 기술 자체는 이 구조의 시작점에 불과하다. 구매 EDI로 확정된 주문과, 실제 입고·검사, 그리고 문서에 적힌 청구가 서로 맞는지 확인되는 지점이 진짜 통제다.

식품 제조업의 매입 자동화는 문서를 잘 읽는 시스템이 아니라, 문서에 적힌 주장과 실제 주문·입고·검사 사실이 일치하는지를 확인한 뒤 회계와 원가에 반영하는 시스템이어야 한다.