거래명세서를 Excel로
추출하는 방법
한국에서는 매년 6억 건 이상의 전자세금계산서가 국세청(NTS) 전자세금계산서 시스템을 통해 처리됩니다. 하지만 모든 물리적 배송에 동봉되는 문서 — 거래명세서 — 는 디지털 사각지대에 놓여 있습니다. 법적으로 규정된 형식이 없고, 어떤 정부 시스템에도 전송되지 않습니다. 그리고 주당 40장의 거래명세서를 20개 다른 공급업체로부터 받는 구매팀에게 각 문서는 PDF, 출력물, 또는 모바일 사진으로 도착하며, 모두 다른 레이아웃을 가지고 있고, 모두 동일한 품목별 데이터를 동일한 수령 스프레드시트에 추출해야 합니다.
이 가이드에서는 한국 거래명세서에 실제로 포함된 내용, 기존 OCR 도구가 이를 처리하기 어려운 이유, 그리고 공급업체별 설정 없이 한 번에 모든 공급업체의 거래명세서에서 라인 항목 데이터를 Excel로 추출하는 방법을 다룹니다.
핵심 요약
- 매년 6억 건의 전자세금계산서가 한국 국세청(NTS) 시스템을 통해 유통됩니다. 하지만 모든 배송에 동봉되는 거래명세서는 법적 형식 규정도, 디지털 전송 경로도 없이 그 시스템 밖에 완전히 존재합니다.
- 병목 현상의 원인은 한국어 문자 인식이 아닙니다. 법적으로 규정된 형식이 없기 때문에 모든 공급업체가 자신만의 레이아웃을 설계합니다. 템플릿 기반 추출은 일관된 형식을 전제로 하는데, 두 번째 공급업체가 문서를 보내는 순간 그 전제는 무너집니다.
- 단일 열 정의 — 공급자명, 품목명, 수량, 단가 — 는 위치가 아닌 의미로 모든 거래명세서를 읽습니다. ImageToTable.ai는 공급업체가 항목을 배치한 위치에 의존하지 않고 문서의 내용을 해독하여 필드를 찾아냅니다.
한국 거래명세서에 실제로 포함된 내용
거래명세서는 한국 기업 간 배송과 함께 이동하는 문서입니다. 법적으로 규제되는 문서인 세금계산서와 달리, 거래명세서는 필수 형식이 없습니다. 이는 사적 증빙 문서로, 매입세액 공제 대상이 아니며, 정부 기관에 제출되지도 않고, 법적으로 요구되지도 않습니다. 법적 규제를 받는 한국 문서의 경우, 한국 세금 문서 추출 허브에서 필수 필드가 있는 형식을 다룹니다.
이러한 규제 공백이 추출 문제를 만듭니다. 표준 형식이 없기 때문에 모든 공급자가 자신만의 레이아웃을 설계합니다. 인천의 포장재 공급업체가 보내는 거래명세서는 구매자 정보를 왼쪽 상단에, 품목 표를 중앙 하단에 배치합니다. 포항의 철강 유통업체가 보내는 거래명세서는 회사 직인을 헤더에 걸치고 품목 행을 가로 방향으로 배치합니다. 둘 다 틀린 것이 아닙니다 — 대조할 템플릿 자체가 없기 때문입니다.
일반적인 거래명세서에는 다음 필드가 포함됩니다:
| 필드 | 한글 명칭 | 용도 |
|---|---|---|
| 공급자 정보 | 공급자 | 업체명, 사업자등록번호, 주소, 연락처 |
| 공급받는자 정보 | 공급받는자 | 수령 업체명, 사업자등록번호, 주소 |
| 거래일자 | 거래일자 | 상품이 인도된 날짜 |
| 품목명 | 품목명 | 인도된 각 품목의 이름 또는 코드 |
| 규격 | 규격 | 치수, 모델 번호, 등급 |
| 수량 | 수량 | 인도된 단위 수 |
| 단가 | 단가 | 단위당 가격 |
| 금액 | 금액 | 라인 합계 |
| 공급가액 | 공급가액 | 부가세 제외 모든 라인 금액의 합계 |
| 세액 | 세액 | 부가가치세 |
| 비고 | 비고 | 추가 메모 — 배송 조건, 부분 배송 표시, 발주서 참조 |
이 문서는 일반적으로 이중으로 발행됩니다: 공급자용 빨간색 사본과 공급받는자용 파란색 사본입니다. 조달 워크플로우에서 물리적 배송과 함께 도착합니다. 수령 팀은 발주서 및 실제 상품과 대조 확인하는데, 이를 3자 일치 (3-way matching)라고 하며, 이후 도착하는 세금계산서에 대한 지불을 승인하기 전에 수행합니다.
한국 ERP 시스템인 ECOUNT, Douzone (더존), iQuest 얼마에요에서는 거래명세서가 일반적으로 판매 기록에서 자동으로 생성됩니다. 이는 매출 측면에서는 이미 해결된 문제입니다. 문제는 매입 측면에서 발생합니다. 이러한 시스템에는 공급업체로부터 받은 거래명세서의 데이터를 불러올 수 있는 기본 기능이 없습니다.
템플릿 기반 도구가 거래명세서를 처리할 수 없는 이유
대부분의 문서 추출 도구는 좌표 기반 템플릿 또는 학습된 모델이라는 두 가지 원리 중 하나로 작동합니다. 좌표 기반 시스템에서는 필드 주변에 사각형을 그립니다. 예를 들어 "공급자 이름은 (120, 340)에 있습니다"라고 지정하면 도구는 해당 영역에 나타나는 텍스트를 읽습니다. 학습된 모델 시스템에서는 10~50개의 샘플 문서에 주석을 달아 모델이 각 필드가 일반적으로 나타나는 위치를 학습하도록 합니다.
두 접근 방식 모두 거래명세서에서는 동일한 이유로 실패합니다. "일반적인" 위치가 없기 때문입니다. 문서에 표준 레이아웃이 없으므로 좌표와 필드 위치가 공급업체마다 다릅니다. 공급업체 A의 거래명세서로 모델을 학습시키면 공급업체 B의 형식에서는 실패합니다. 공급업체 B의 형식을 학습 세트에 추가하면 공급업체 C의 레이아웃이 새로운 실패 모드를 만듭니다. 이는 학습 데이터 문제가 아니라 템플릿 기반 추출과 템플릿 기반으로 설계된 적이 없는 문서 유형 간의 구조적 불일치입니다.
대안은 의미 기반 추출입니다. 도구에 어디를 볼지 알려주는 대신 무엇을 찾을지 알려주는 방식입니다. "품목명", "수량", "단가", "공급가액" 등 원하는 열 이름을 입력하면 AI가 문서를 시각적으로 읽고 페이지에서의 위치가 아니라 의미를 이해하여 각 필드를 찾습니다. 열 이름 추출이라고 하는 이 방식은 하나의 열 정의로 공급업체의 레이아웃, 방향, 공급자 이름의 위치와 관계없이 모든 공급업체의 거래명세서를 처리합니다.
이 차이가 중요한 이유는 대안인 공급업체별 개별 템플릿 유지 관리가 확장 가능하지 않기 때문입니다. 공급업체 3곳을 온보딩하면 잘 작동합니다. 30곳이 되면 템플릿 라이브러리 유지 관리가 그 자체로 행정 업무가 됩니다. 열 이름 추출은 이러한 유지 관리를 완전히 건너뜁니다. 동일한 열 정의가 첫 번째 공급업체의 문서와 30번째 공급업체의 문서 모두에서 작동합니다.
템플릿 기반 OCR은 문서 레이아웃이 일관적이라고 가정합니다. 열 이름 추출은 그렇지 않다고 가정하며, 법적으로 표준 형식이 없는 한국 B2B 문서에는 이것이 올바른 가정입니다.
단계별 가이드: 거래명세서 데이터를 Excel로 추출하기
거래명세서 PDF를 받아 스프레드시트에 구조화된 데이터로 만드는 전체 워크플로우입니다. 각 단계는 하나의 동작으로 구성되며, 좌표 그리기, 모델 학습, 공급자별 설정이 필요 없습니다.
추출 엔진은 각 필드를 의미적으로 읽습니다. 사업자등록번호는 하이픈이 포함된 10자리 패턴으로, 공급가액은 수량 및 단가 열과의 상대적 위치로, 품목명은 품목 테이블 내의 맥락으로 인식합니다. 이것이 광학 문자 인식과 시각적 언어 이해의 차이입니다. 하나는 텍스트를 읽고, 다른 하나는 문서를 읽습니다.
이 접근 방식의 메커니즘을 더 자세히 알아보려면 열 이름으로 특정 필드 추출하기 가이드를 참조하세요.
파일은 안전하게 처리되며 저장되지 않습니다.
3자 일치(3-Way Matching): 발주서(PO) vs 거래명세서 vs 세금계산서
거래명세서에서 데이터를 단독으로 추출하는 것도 유용하지만, 구매 정산 주기(procurement reconciliation cycle)의 일부로 추출할 때 진정한 운영상의 이점이 있습니다. 한국의 표준 구매 워크플로우는 예측 가능한 순서로 진행됩니다: 공급자에게 발주서(PO) 발송 → 거래명세서와 함께 상품 인도 → 검수 수행 → 세금계산서 발행 및 국세청(NTS) 전송 → 대금 지불.
검수 단계에서의 핵심 작업은 3자 일치(3-way matching)입니다: 주문한 것, 인도된 것, 청구된 것을 비교하는 것입니다. 검수 시점에 발견된 불일치는 전화 한 통이면 해결되지만, 월말 정산 중에 발견된 불일치는 납품 기록, 공급자 이메일, ERP 화면을 뒤지는 데 몇 시간이 걸립니다.
각 문서 유형이 일치 작업에 제공하는 데이터는 다음과 같습니다:
| 문서 | 출처 | 일치를 위한 주요 필드 |
|---|---|---|
| 발주서(PO) | 귀사의 ERP | 주문 수량, 합의된 단가, 요청 납기일 |
| 거래명세서 | 공급자 | 인도 수량, 품목명, 명세서상 단가 |
| 세금계산서 | 공급자 | 청구 수량, 청구 단가, 공급가액, 세액, 국세청 승인번호 |
병목 지점은 중간 열입니다. 거래명세서 데이터는 거의 디지털화되어 있지 않습니다. 박스에 클립으로 고정된 종이로 도착하거나 납품 알림 이메일에 첨부된 PDF로 묻혀 있습니다. 이 데이터가 ERP의 발주서 데이터 및 국세청 시스템의 세금계산서 데이터와 동일한 형식인 스프레드시트 형태가 되기 전까지는 3자 일치를 자동화할 수 없습니다.
거래명세서 데이터가 Excel로 추출되면 계산 열(computed columns)을 사용하여 출력물에서 직접 일치 작업을 수행할 수 있습니다. 차이: 주문 수량 vs 인도 수량과 같은 열을 정의하면 AI가 추출 중에 모든 라인 항목의 차이를 계산합니다. 0이 아닌 차이가 있는 행은 스프레드시트를 열기 전에 플래그가 지정됩니다. 동일한 추출 파이프라인으로 발주서를 처리하는 경우 발주서 데이터를 Excel로 추출하여 두 문서 유형을 동일한 구조화된 형식으로 가져와 직접 비교할 수 있습니다.
세금계산서 데이터 추출에 대한 유사한 시나리오는 한국 세금계산서 데이터를 Excel로 추출 가이드를 참조하세요. 이 가이드에서는 7가지 필수 항목과 분기별 부가가치세 신고 워크플로우를 다룹니다. 대량의 세금계산서를 부가가치세 신고용으로 처리하는 경우 세금계산서 일괄 처리 가이드에서 처리량 측면을 다룹니다.
일괄 처리: 일일 거래명세서 처리
개별 추출은 문서별 문제를 해결합니다. 일괄 처리는 일일 처리량 문제를 해결하며, 설정 작업을 반복할 필요 없이 처리할 수 있습니다.
위 2단계에서 만든 열 정의는 특정 문서에 국한되지 않습니다. 원하는 필드를 설명할 뿐, 해당 필드가 어디에 있는지는 설명하지 않습니다. 즉, 서로 다른 레이아웃을 가진 15개 공급업체의 거래명세서 20장을 단일 배치로 업로드할 수 있습니다. 동일한 열 정의가 모든 문서에 적용됩니다. 출력은 하나의 통합 스프레드시트로, 각 거래명세서의 모든 라인 항목이 한 행씩 차지하며, 동일한 문서의 모든 행에 공급업체 이름과 날짜가 채워집니다.
주당 30장의 거래명세서를 받는 조달 팀은 수작업 데이터 입력 시간을 약 3~4시간 절약합니다. 조달 담당자의 시간당 비용을 원(KRW) 18,000~25,000으로 가정하면, 단일 워크플로우 변경만으로 월 220,000~400,000원을 절약할 수 있습니다. 이 수치에는 오류 수정 시간이 포함되지 않았으며, 실제로는 입력 시간과 같거나 그 이상일 수 있습니다.
배송과 함께 종이 거래명세서를 지속적으로 보내는 공급업체의 경우, 수집 링크를 통해 디지털화 단계를 앞당길 수 있습니다. 공급업체가 로그인할 필요 없는 공유 가능한 URL을 생성하여 공급업체 온보딩 지침에 포함하세요. 공급업체는 휴대폰에서 링크를 열고 짧은 인증 코드를 입력한 후 거래명세서 사진이나 PDF를 처리 대기열에 직접 업로드합니다. 문서는 이미 디지털화된 상태로 도착하며, 팀은 재입력 대신 데이터를 추출합니다. 이는 한국 영수증 추출 가이드에 설명된 것과 동일한 메커니즘으로, B2B 조달 상황에 맞게 조정된 것입니다.
거래명세서를 다른 배송 문서와 함께 일괄 처리할 때 추출 워크플로우는 동일합니다. 열을 한 번 정의하고, 모든 것을 업로드하고, 하나의 스프레드시트를 다운로드하면 됩니다. 배송 명세서 추출 도구는 동일한 배송에서 거래명세서와 함께 자주 제공되는 운송업체 발행 배송 명세서에 대해 동일한 패턴을 다룹니다.
FAQ
공급업체마다 거래명세서 형식이 달라서 별도 설정이 필요한가요?
아닙니다. 열 이름 추출은 위치가 아닌 의미를 기준으로 필드를 찾습니다. 동일한 열 정의가 모든 공급업체의 레이아웃에서 작동합니다. AI가 문서를 시각적으로 읽고 각 필드가 무엇을 나타내는지 이해하기 때문입니다. 공급업체가 페이지의 어디에 배치했든 상관없습니다.
손으로 작성된 거래명세서도 처리할 수 있나요?
네, 가능합니다. 인쇄된 양식에 손으로 기입하는 경우는 처리할 수 있습니다. 인쇄된 구조 없이 완전히 손으로 작성된 문서는 더 까다로우며 정확도가 낮아집니다. 시스템은 직인과 서명을 시각적 요소로 감지합니다. 존재 여부는 확인할 수 있지만, 텍스트는 추출하지 않습니다.
공급가액과 세액을 어떻게 구분하나요?
AI는 문서의 의미론적 계층 구조를 이해합니다. 공급가액은 부가세(VAT)가 포함되지 않은 총액입니다. 세액은 일반적으로 해당 금액의 10%입니다. 두 열을 모두 정의하면 AI는 이 관계를 사용하여 추출을 검증합니다. 공급가액으로 감지된 값이 세액과의 예상 관계와 일치하지 않으면 시스템이 플래그를 표시합니다. 부가세 검증과 같은 계산 열을 정의하여 모든 행의 비율을 출력할 수도 있습니다.
Excel 대신 ECOUNT나 Douzone으로 데이터를 추출할 수 있나요?
직접 출력 형식은 Excel(XLSX), CSV 또는 JSON입니다. ECOUNT와 Douzone 모두 거래 데이터에 대해 Excel 가져오기를 지원합니다. XLSX로 내보낸 후 ERP의 가져오기 기능을 사용하여 데이터를 로드하면 됩니다. Excel 출력의 열 이름을 ERP의 가져오기 필드 이름과 일치하도록 구성할 수 있어 매핑 단계가 필요 없습니다.
한국어와 영어 필드가 혼합된 문서는 어떻게 처리하나요?
AI는 두 언어를 모두 읽습니다. 많은 한국 거래명세서에는 수입품이나 다국적 공급망의 경우 특히 영어 품목명이 한국어 설명과 함께 포함되어 있습니다. 출력에 필요한 언어로 열을 정의하기만 하면 됩니다. AI는 소스 문서의 언어와 관계없이 해당 값을 찾습니다.
다음 단계
한국의 B2B 문서 인프라에서 공백은 발행 측면이 아닙니다. ECOUNT, Douzone, 국세청(NTS) 전자세금계산서 시스템이 이미 세금계산서를 완전히 디지털화했습니다. 공백은 수취 측면에 있습니다. 즉, 공급업체가 보내는 문서 중 기계가 읽도록 설계된 적이 없는 문서들입니다. 거래명세서는 조달 대사, 입고 관리, 지급 승인 — 하위 재무 팀이 의존하는 세 가지 워크플로우와 연결되기 때문에 그 공백의 중심에 있습니다.
이 공백을 해소하기 위해 공급업체가 문서를 발행하는 방식을 바꿀 필요는 없습니다. 팀이 도착하는 문서를 처리하는 방식을 바꾸면 됩니다. 입고 로그에 다시 입력하는 데 8분이 걸리던 동일한 거래명세서를 몇 초 만에 추출할 수 있습니다. 동일한 열 정의가 내일 다른 공급업체가 다른 형식으로 보내는 명세서에도 그대로 적용됩니다.