한국 거래명세서를 엑셀로
추출하는 방법

한국 거래명세서의 실제 구성 요소

거래명세서는 한국 기업 간에 화물과 함께 이동하는 문서입니다. 세금계산서가 부가가치세법 제32조에 따라 법적으로 규제되어 국세청에 전송되는 반면, 거래명세서는 강제 형식이 없습니다. 이는 사적 증빙에 해당하며 — 매입세액 공제 대상이 아니고, 정부 기관에 제출되지 않으며, 법적 요구 사항도 없습니다.

이러한 규제 공백이 추출 문제를 만듭니다. 표준 형식이 없기 때문에 모든 공급업체가 자신만의 레이아웃을 설계합니다. 인천의 포장재 공급업체가 보낸 거래명세서는 구매자 정보를 왼쪽 상단에, 품목 표를 중앙 하단에 배치합니다. 포항의 철강 유통업체가 보낸 것은 회사 직인을 헤더에 걸쳐 찍고 품목 행을 가로 방향으로 배열합니다. 둘 다 틀리지 않았습니다 — 기준이 될 템플릿 자체가 없기 때문입니다.

일반적인 거래명세서에는 다음 필드가 포함됩니다:

문서는 일반적으로 공급자용(빨간색)과 공급받는자용(파란색)의 2부로 발행됩니다. 조달 워크플로에서는 실제 화물과 함께 도착합니다. 수령팀은 구매 주문서와 실제 상품을 대조 확인하는 3-Way 매칭 과정을 거친 후, 이후 도착하는 세금계산서에 대한 지급을 승인합니다.

이카운트, 더존, 아이퀘스트의 얼마에요 같은 한국 ERP 시스템에서는 거래명세서가 일반적으로 판매 기록에서 자동으로 생성됩니다 — 이는 출력 측면에서 해결된 문제입니다. 문제는 입력 측면에서 발생합니다: 이 동일한 시스템들은 자사 공급업체로부터 수신한 거래명세서의 데이터를 가져오는 기본 기능을 제공하지 않습니다.

템플릿 기반 도구가 거래명세서를 처리할 수 없는 이유

대부분의 문서 추출 도구는 좌표 기반 템플릿 또는 학습된 모델이라는 두 가지 원리 중 하나로 작동합니다. 좌표 기반 시스템에서는 필드 주위에 사각형을 그립니다. 예를 들어 "공급자명은 (120, 340)에 있습니다"와 같이 지정하면 도구가 해당 영역에 있는 텍스트를 읽습니다. 학습된 모델 시스템에서는 10~50개의 샘플 문서에 주석을 달아 모델이 각 필드가 일반적으로 나타나는 위치를 학습하도록 합니다.

두 접근 방식 모두 거래명세서에서 동일한 이유로 실패합니다. 바로 "일반적인" 위치가 없기 때문입니다. 문서에 표준 레이아웃이 없으므로 좌표와 필드 위치는 공급자마다 다릅니다. 공급자 A의 거래명세서로 모델을 학습시키면 공급자 B의 형식에서는 실패합니다. 공급자 B의 형식을 학습 세트에 추가하면 공급자 C의 레이아웃이 새로운 실패 모드를 초래합니다. 이것은 학습 데이터의 문제가 아니라 템플릿 기반 추출과 템플릿 기반으로 설계되지 않은 문서 유형 간의 구조적 불일치입니다.

대안은 의미 기반 추출입니다. 도구에 어디를 볼지 알려주는 대신 무엇을 찾을지 알려줍니다. 원하는 열 이름(예: "품목명", "수량", "단가", "공급가액")을 입력하면 AI가 문서를 시각적으로 읽고 페이지에서의 위치가 아닌 의미를 이해하여 각 필드를 찾습니다. 열 이름 추출이라고 하는 이 접근 방식은 하나의 열 정의로 공급자의 레이아웃, 방향, 또는 공급자명이 왼쪽 상단, 중앙 또는 헤더 블록에 포함되어 있는지 여부에 관계없이 모든 공급자의 거래명세서를 처리합니다.

이 차이가 중요한 이유는 공급자별로 별도의 템플릿을 유지 관리하는 대안이 확장 불가능하기 때문입니다. 공급자 3곳을 온보딩하면 잘 작동합니다. 30곳이 되면 템플릿 라이브러리 유지 관리가 그 자체로 관리 작업이 됩니다. 열 이름 추출은 이러한 유지 관리를 완전히 우회합니다. 동일한 열 정의가 첫 번째 공급자의 문서와 30번째 공급자의 문서에서 모두 작동합니다.

단계별 가이드: 거래명세서 데이터를 엑셀로 추출하기

거래명세서 PDF를 받아 스프레드시트에 정형 데이터로 만드는 전체 워크플로우입니다. 각 단계는 하나의 동작으로 구성되며, 좌표 그리기, 모델 학습, 공급업체별 설정이 필요하지 않습니다.

추출 엔진은 각 필드를 의미로 읽습니다. 사업자등록번호는 하이픈이 포함된 10자리 패턴으로, 공급가액은 수량 및 단가 컬럼과의 상대적 위치로, 품목명은 품목표 내 문맥으로 인식합니다. 이것이 광학 문자 인식과 시각적 언어 이해의 차이입니다. 하나는 텍스트를 읽고, 다른 하나는 문서를 읽습니다.

이 접근 방식의 메커니즘에 대한 자세한 내용은 컬럼명으로 특정 필드 추출하기 가이드를 참조하세요.

3-Way 매칭: 발주서 vs 거래명세서 vs 세금계산서

거래명세서에서 데이터를 추출하는 것만으로도 유용합니다. 하지만 이를 구매 정산 주기의 일부로 활용할 때 진정한 운영 효율이 발휘됩니다. 표준적인 국내 구매 프로세스는 예측 가능한 순서로 진행됩니다: 발주서 발행 → 공급처 납품 및 거래명세서 동봉 → 입고 검수 → 세금계산서 발행 및 국세청 전송 → 대금 지급.

입고 현장에서의 핵심 업무는 3-Way 매칭입니다: 주문한 내역(발주서), 실제 납품된 내역(거래명세서), 청구된 내역(세금계산서)을 비교하는 것입니다. 입고 시 발견된 차이는 전화 한 통이면 해결됩니다. 하지만 월말 정산 시 발견된 차이는 납품 기록, 공급처 이메일, ERP 화면을 샅샅이 뒤져야 하므로 몇 시간이 소요됩니다.

매칭에 사용되는 각 문서 유형별 데이터는 다음과 같습니다:

병목 구간은 바로 중간 열입니다. 거래명세서 데이터는 거의 항상 디지털화되어 있지 않습니다. 박스에 클립으로 고정된 종이 형태로 도착하거나, 납품 알림 이메일에 첨부된 PDF 파일로 묻혀 있습니다. 이 데이터가 ERP의 발주서 데이터, 국세청 시스템의 세금계산서 데이터와 동일한 형식의 스프레드시트로 변환되기 전까지는 3-Way 매칭 자동화가 불가능합니다.

거래명세서 데이터를 엑셀로 추출한 후 계산 열을 사용하여 출력물에서 직접 대조할 수 있습니다. 차이: 주문 수량 vs 납품 수량 (PO 수량 - 수량)과 같은 열을 정의하면 AI가 추출 과정에서 모든 라인 항목의 차이를 계산합니다. 0이 아닌 차이가 있는 행은 스프레드시트를 열기 전에 표시됩니다. 동일한 추출 파이프라인을 통해 구매 주문서를 처리하는 경우 PO 데이터를 엑셀로 추출하여 두 문서 유형을 동일한 구조화된 형식으로 가져와 직접 비교할 수 있습니다.

병렬 시나리오, 즉 세금 계산서 데이터 추출에 대한 자세한 내용은 한국 세금 계산서 데이터를 엑셀로 추출하는 방법 가이드를 참조하세요. 이 가이드는 7가지 필수 항목과 분기별 부가가치세 신고 워크플로우를 다룹니다. 부가가치세 신고를 위해 대량의 세금 계산서를 처리하는 경우 일괄 세금 계산서 처리 가이드에서 처리량 측면을 다룹니다.

일괄 처리: 일일 거래명세서 처리

개별 추출은 문서별 문제를 해결합니다. 일괄 처리는 일일 볼륨 문제를 해결하며, 설정 작업을 반복할 필요가 없습니다.

위 2단계에서 생성한 열 정의는 문서에 국한되지 않습니다. 이는 필드의 위치가 아닌 원하는 필드를 설명합니다. 즉, 15개 공급업체의 20개 거래명세서를 모두 다른 레이아웃으로 단일 배치에 업로드할 수 있습니다. 동일한 열 정의가 모든 문서에 적용됩니다. 출력은 하나의 통합 스프레드시트로, 각 명세서의 모든 라인 항목이 한 행을 차지하며, 동일한 문서의 모든 행에 공급업체 이름과 날짜가 채워집니다.

일관되게 종이 명세서와 납품서를 보내는 공급업체의 경우 수집 링크를 사용하여 디지털화 단계를 상류로 이동할 수 있습니다. 공급업체 로그인이 필요 없는 공유 가능한 URL을 생성하여 공급업체 온보딩 지침에 포함시키세요. 공급업체는 휴대폰에서 링크를 열고, 짧은 확인 코드를 입력한 후, 거래명세서 사진이나 PDF를 처리 대기열에 직접 업로드합니다. 문서는 이미 디지털화되어 도착하며, 팀은 데이터를 다시 입력하는 대신 추출합니다. 이는 한국 영수증 추출 가이드에 설명된 동일한 메커니즘을 B2B 조달 상황에 맞게 조정한 것입니다.

다른 납품 문서와 함께 거래명세서를 일괄 처리할 때 추출 워크플로우는 동일합니다. 열을 한 번 정의하고, 모든 것을 업로드하고, 하나의 스프레드시트를 다운로드하면 됩니다. 납품서 추출 도구는 동일한 화물에 거래명세서와 함께 제공되는 경우가 많은 운송업체 발행 납품서에 대한 동일한 패턴을 다룹니다.

자주 묻는 질문

다음 단계

한국의 B2B 문서 인프라에서 부족한 점은 발행 측면이 아닙니다. ECOUNT, 더존, 국세청 전자세금계산서 시스템은 이미 세금계산서를 완전히 디지털화했습니다. 문제는 수취 측면, 즉 공급업체가 보내는 문서 중 기계 판독이 불가능하도록 설계된 문서들입니다. 거래명세서는 조달 정산, 입고 확인, 지급 승인이라는 세 가지 업무 흐름과 맞닿아 있기 때문에 그 부족의 중심에 있습니다. 이 세 가지는 하위 재무팀이 의존하는 프로세스입니다.

이 격차를 해소하기 위해 공급업체가 문서를 발행하는 방식을 바꿀 필요는 없습니다. 필요한 것은 팀이 도착하는 문서를 처리하는 방식을 바꾸는 것입니다. 입고 기록에 다시 입력하는 데 8분이 걸리던 동일한 거래명세서를 몇 초 만에 추출할 수 있습니다. 오늘의 명세서에 사용한 열 정의가 내일 다른 공급업체의 다른 형식 명세서에도 동일하게 적용됩니다.