한국 거래명세서를
엑셀로 추출하는 방법
한국은 국세청(NTS) 전자세금계산서 시스템을 통해 연간 6억 건 이상의 전자세금계산서를 처리합니다. 하지만 실제로 모든 물리적 배송에 동봉되는 문서인 거래명세서는 디지털 사각지대에 놓여 있습니다. 법적으로 정해진 형식이 없으며, 어떤 정부 시스템에도 전송되지 않습니다. 그리고 주당 20개 공급업체로부터 40장의 거래명세서를 받는 조달팀에게 각 문서는 PDF, 출력물, 또는 모바일 사진으로 도착하며, 모두 다른 레이아웃을 가지고 있지만 동일한 품목 수준 데이터를 동일한 수령 스프레드시트에 추출해야 합니다.
이 가이드에서는 한국 거래명세서에 실제로 포함된 내용, 기존 OCR 도구가 이를 처리하기 어려운 이유, 그리고 공급업체별 설정 없이 한 번에 모든 공급업체의 거래명세서에서 라인 항목 데이터를 엑셀로 추출하는 방법을 다룹니다.
핵심 요약
- 매년 6억 건의 전자세금계산서가 한국 국세청(NTS) 시스템을 통해 유통되지만, 실제로 모든 배송과 함께 받는 거래명세서는 그 시스템 밖에 완전히 존재하며 법적으로 정해진 형식이나 디지털 전송 경로가 없습니다.
- 병목 현상은 한글 인식 문제가 아닙니다. 법적으로 정해진 형식이 없기 때문에 모든 공급업체가 자신만의 레이아웃을 설계합니다. 템플릿 기반 추출은 일관된 형식을 가정하는데, 두 번째 공급업체가 문서를 보내는 순간 그 가정은 깨집니다.
- 공급업체명, 품목명, 수량, 단가라는 단일 열 정의는 위치가 아닌 의미를 기준으로 모든 거래명세서를 읽습니다. ImageToTable.ai는 공급업체가 항목을 배치한 위치에 의존하지 않고 문서가 말하는 내용을 해독하여 필드를 찾습니다.
한국 거래명세서의 실제 구성
거래명세서는 한국 기업 간에 화물과 함께 이동하는 문서입니다. 세금계산서가 부가가치세법 제32조에 따라 법적으로 규제되어 국세청에 전송되는 반면, 거래명세서는 강제 양식이 없습니다. 이는 사적 증빙에 해당하며 — 매입세액 공제 대상이 아니고, 정부 기관에 제출되지 않으며, 법적 요구 사항도 없습니다.
이러한 규제 공백이 데이터 추출 문제를 만듭니다. 표준 양식이 없기 때문에 모든 공급업체가 각자 방식대로 문서를 설계합니다. 인천의 포장재 공급업체가 보내는 거래명세서는 구매자 정보를 왼쪽 상단에, 품목 표를 중앙 하단에 배치합니다. 포항의 철강 유통업체가 보내는 문서는 회사 직인을 헤더에 걸쳐 찍고 품목 행을 가로 방향으로 배열합니다. 어느 쪽도 틀리지 않았습니다 — 기준이 되는 템플릿 자체가 없기 때문입니다.
일반적인 거래명세서에는 다음 항목이 포함됩니다:
| 항목 | 한글 명칭 | 용도 |
|---|---|---|
| 공급자 정보 | 공급자 | 상호, 사업자등록번호, 주소, 연락처 |
| 구매자 정보 | 공급받는자 | 수취 업체명, 사업자등록번호, 주소 |
| 거래일자 | 거래일자 | 상품 인도일 |
| 품목명 | 품목명 | 인도된 각 품목의 명칭 또는 코드 |
| 규격 | 규격 | 치수, 모델 번호, 등급 |
| 수량 | 수량 | 인도된 단위 수량 |
| 단가 | 단가 | 단위당 가격 |
| 금액 | 금액 | 라인 합계 |
| 공급가액 | 공급가액 | 부가세를 제외한 모든 라인 금액의 합계 |
| 세액 | 세액 | 부가가치세 |
| 비고 | 비고 | 추가 기재사항 — 납품 조건, 부분 납품 여부, 발주번호 참조 |
문서는 보통 2부로 발행됩니다: 공급자용과 공급받는자용입니다. 조달 업무 흐름에서 거래명세서는 실제 화물과 함께 도착합니다. 수령팀은 발주서 및 실제 상품과 대조하는 3-Way 매칭 과정을 거친 후, 이후 발행되는 세금계산서에 대한 지급을 승인합니다.
이카운트, 더존, 아이퀘스트의 얼마에요 같은 한국 ERP 시스템에서는 거래명세서가 일반적으로 판매 기록에서 자동 생성됩니다 — 이는 출력 측면에서 해결된 문제입니다. 문제는 입력 측면에서 발생합니다: 이들 시스템은 자사 공급업체로부터 받은 거래명세서의 데이터를 가져오는 자체 기능을 제공하지 않습니다.
템플릿 기반 도구가 거래명세서를 처리할 수 없는 이유
대부분의 문서 추출 도구는 좌표 기반 템플릿 또는 학습된 모델이라는 두 가지 원리 중 하나로 작동합니다. 좌표 기반 시스템에서는 필드 주위에 사각형을 그립니다. 예를 들어 "공급자 이름은 (120, 340)에 있습니다"와 같이 지정하면 도구가 해당 영역에 나타나는 텍스트를 읽습니다. 학습된 모델 시스템에서는 10~50개의 샘플 문서에 주석을 달아 모델이 각 필드가 일반적으로 나타나는 위치를 학습하도록 합니다.
두 접근 방식 모두 거래명세서에서 동일한 이유로 실패합니다. 바로 "일반적인" 위치가 없기 때문입니다. 문서에 표준 레이아웃이 없기 때문에 좌표와 필드 위치는 공급자마다 다릅니다. 공급자 A의 거래명세서로 모델을 학습시키면 공급자 B의 형식에서는 실패합니다. 공급자 B의 형식을 학습 세트에 추가하면 공급자 C의 레이아웃이 새로운 실패 모드를 초래합니다. 이것은 학습 데이터의 문제가 아니라, 템플릿에 고정된 추출 방식과 템플릿에 고정될 수 없도록 설계된 문서 유형 간의 구조적 불일치입니다.
대안은 의미 기반 추출입니다. 도구에 어디를 볼지 알려주는 대신 무엇을 찾을지 알려주는 것입니다. 원하는 열 이름을 입력하면 AI가 문서를 시각적으로 읽고, 페이지에서의 위치가 아닌 의미를 이해하여 각 필드를 찾습니다. 열 이름 추출이라고 하는 이 접근 방식은 하나의 열 정의로 공급자의 레이아웃, 방향, 또는 공급자 이름이 왼쪽 상단, 중앙 또는 헤더 블록에 포함되어 있는지 여부에 관계없이 모든 공급자의 거래명세서를 처리합니다.
이 차이가 중요한 이유는 대안인 공급자별로 별도의 템플릿을 유지 관리하는 방식이 확장 불가능하기 때문입니다. 공급자 3곳을 온보딩할 때는 잘 작동합니다. 하지만 30곳이 되면 템플릿 라이브러리를 유지 관리하는 것이 그 자체로 하나의 관리 작업이 됩니다. 열 이름 추출은 이러한 유지 관리를 완전히 없애줍니다. 동일한 열 정의가 첫 번째 공급자의 문서와 30번째 공급자의 문서에서 모두 작동합니다.
템플릿 기반 OCR은 문서 레이아웃이 일관적이라고 가정합니다. 열 이름 추출은 그렇지 않다고 가정하며, 이것이 법적으로 강제된 형식이 없는 한국 B2B 문서에 대한 올바른 가정입니다.
단계별 가이드: 거래명세서 데이터를 Excel로 추출하기
거래명세서 PDF를 받은 후 스프레드시트에 정형화된 데이터를 얻기까지의 전체 워크플로우입니다. 각 단계는 하나의 동작으로 구성되며, 좌표를 그리거나, 모델을 학습시키거나, 공급업체별로 설정을 구성할 필요가 없습니다.
추출 엔진은 각 필드를 의미별로 읽습니다. 사업자등록번호는 하이픈이 포함된 10자리 패턴으로 인식하고, 공급가액은 수량 및 단가 열과의 상대적 위치로 인식하며, 품목명은 품목표 내의 맥락으로 인식합니다. 이것이 광학 문자 인식(OCR)과 시각적 언어 이해의 차이입니다. 하나는 텍스트를 읽고, 다른 하나는 문서를 읽습니다.
이 접근 방식의 메커니즘에 대한 자세한 내용은 열 이름으로 특정 필드 추출하기 가이드를 참조하세요.
파일은 안전하게 처리되며 저장되지 않습니다.
3자 일치(3-Way Matching): 발주서(PO) vs 거래명세서 vs 세금계산서
거래명세서에서 데이터를 추출하는 것만으로도 유용합니다. 하지만 이를 조달 정산 주기의 일부로 추출할 때 진정한 운영 효율성이 발휘됩니다. 한국의 표준 조달 워크플로우는 예측 가능한 순서를 따릅니다: 공급자에게 발주서(PO) 발송 → 거래명세서와 함께 상품 입고 → 입고 검사 수행 → 세금계산서 발행 및 국세청(NTS) 전송 → 대금 지급.
입고 현장에서의 핵심 작업은 3자 일치(3-way matching)입니다: 주문한 내용(PO), 실제로 배송된 내용, 그리고 청구된 내용을 비교하는 것입니다. 입고 현장에서 발견된 불일치는 전화 한 통이면 해결됩니다. 하지만 월말 정산 중에 발견된 불일치는 입고 기록, 공급자 이메일, ERP 화면을 뒤져야 하는 몇 시간의 작업이 필요합니다.
다음은 각 문서 유형이 일치 작업에 제공하는 데이터입니다:
| 문서 | 출처 | 일치를 위한 주요 필드 |
|---|---|---|
| 발주서(PO) | 귀사 ERP | 주문 수량, 합의된 단가, 요청 납기일 |
| 거래명세서 | 공급자 | 납품 수량, 품목명, 명세서상 단가 |
| 세금계산서 | 공급자 | 청구 수량, 청구 단가, 공급가액, 부가세, 국세청 승인번호 |
병목 현상은 중간 열에 있습니다: 거래명세서 데이터는 거의 디지털화되어 있지 않습니다. 박스에 동봉된 종이로 도착하거나, 배송 알림 이메일에 첨부된 PDF 파일로 묻혀 있습니다. 이 데이터가 스프레드시트 형태, 즉 ERP의 발주서 데이터 및 국세청 시스템의 세금계산서 데이터와 동일한 형식이 되기 전까지는 3자 일치를 자동화할 수 없습니다.
거래명세서 데이터가 Excel로 추출되면, 계산 열(Computed Columns)을 사용하여 출력물에서 직접 일치 작업을 수행할 수 있습니다. 차이: 주문 수량 vs 납품 수량과 같은 열을 정의하면 AI가 추출 중에 모든 라인 항목에 대한 차이를 계산합니다. 0이 아닌 차이가 있는 행은 스프레드시트를 열기도 전에 표시됩니다. 동일한 추출 파이프라인을 통해 발주서를 처리하는 경우, 발주서 데이터를 Excel로 추출하여 두 문서 유형을 동일한 구조화된 형식으로 가져와 직접 비교할 수 있습니다.
유사한 시나리오로, 특히 세금계산서 데이터 추출에 대해서는 한국 세금계산서 데이터를 Excel로 추출하는 가이드를 참조하십시오. 이 가이드는 7가지 필수 항목과 분기별 부가가치세 신고 워크플로우를 다룹니다. 부가세 신고를 위해 대량의 세금계산서를 처리하는 경우, 일괄 세금계산서 처리 가이드에서 처리량 측면을 다루고 있습니다.
일괄 처리: 일일 거래명세서 처리
개별 추출은 문서 단위 문제를 해결합니다. 일괄 처리는 일일 볼륨 문제를 해결하며, 설정 작업을 반복할 필요가 없습니다.
위 2단계에서 생성한 열 정의는 특정 문서에 국한되지 않습니다. 이는 필드가 어디에 있는지가 아니라, 원하는 필드를 설명합니다. 따라서 15개 공급업체의 서로 다른 레이아웃을 가진 20장의 거래명세서를 단일 배치로 업로드할 수 있습니다. 동일한 열 정의가 모든 문서에 적용됩니다. 출력은 하나의 통합 스프레드시트로, 각 명세서의 모든 라인 항목이 한 행을 차지하며, 동일 문서의 모든 행에 공급업체명과 날짜가 입력됩니다.
주당 30장의 거래명세서를 접수하는 조달팀은 수동 데이터 입력 시간을 약 3~4시간 절약합니다. 조달 담당자의 시간당 인건비를 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, 더존, NTS 전자세금계산서 시스템은 이미 세금계산서를 완전히 디지털화했습니다. 문제는 수취 측면, 즉 공급업체가 보내는 문서 중 기계 판독이 불가능하도록 설계된 문서들입니다. 거래 명세서는 조달 정산, 입고 확인, 지불 승인이라는 세 가지 업무 흐름에 모두 관여하기 때문에 그 간극의 중심에 있습니다. 이는 하위 재무팀이 의존하는 프로세스입니다.
이 간극을 해소하기 위해 공급업체가 문서를 발행하는 방식을 바꿀 필요는 없습니다. 필요한 것은 도착하는 문서를 팀이 처리하는 방식을 바꾸는 것입니다. 수신 로그에 다시 입력하는 데 8분이 걸리던 동일한 거래 명세서를 몇 초 만에 추출할 수 있습니다. 오늘의 명세서에 적용한 열 정의가 내일 다른 공급업체의 다른 형식 명세서에도 동일하게 작동합니다.