거래명세서 50장, 스프레드시트 하나로: 타이핑 없는 일괄 처리

모든 국내 ERP는 판매 기록에서 거래명세서를 한 번의 클릭으로 생성할 수 있습니다. 하지만 그 누구도 거래명세서를 다시 읽어 들일 수는 없습니다. 국내 기업 간 모든 물리적 배송에 동봉되는 이 문서는 키보드를 통해 한 필드씩 조달 워크플로에 입력됩니다. 월말에 15개 공급업체로부터 50장의 거래명세서를 받는다면, 이러한 비대칭성은 더 이상 호기심의 대상이 아니라 접수팀이 오후 10시까지 사무실에 남아 있어야 하는 이유가 됩니다.

한국 거래명세서가 처음이라면, 한국 거래명세서 데이터를 엑셀로 추출하는 가이드부터 시작해 보세요. 필드 구조, 3자 매칭, 템플릿 오류 문제를 다룹니다. 이 글은 한 건에서 쉰 건으로, 한 공급업체 형식에서 열다섯 개 형식으로 확장될 때 무엇이 달라지는지에 초점을 맞춥니다.

한국 조달에서 배치 처리가 실제로 의미하는 것

거래명세서 한 건과 쉰 건을 처리하는 차이는 단순히 시간 문제가 아닙니다. 완전히 다른 종류의 문제입니다.

거래명세서 한 장을 처리하는 작업 흐름은 간단합니다. PDF를 열고, 공급자, 거래일자, 품목표를 읽습니다. 각 행의 품목명, 수량, 단가, 금액을 입고 스프레드시트에 입력합니다. 공급가액과 세액을 조정 파일에 복사합니다. 끝. 문서당 3분, 공급업체 레이아웃이 복잡하거나 스캔 품질이 나쁘면 5분 정도 걸립니다.

이제 쉰 건을 해보세요. 각각 다른 레이아웃, 다른 품목 코드 체계, 다른 인쇄 품질을 가진 열다섯 개의 공급업체에서 온 문서들입니다. 대규모에서 나타나는 문제는 단건 처리에서는 보이지 않습니다:

형식 탐색. A사의 거래명세서는 더존 iCUBE에서 생성된 깔끔한 PDF로, 품목표가 표준 그리드 레이아웃입니다. B사는 손글씨 양식을 모바일로 찍은 사진으로, 수량이 여백에 휘갈겨져 있습니다. C사는 셀이 병합된 엑셀 출력 문서입니다. 문서 1에 적용된 추출 방식은 문서 2에서 실패합니다. 문서 50에 이르면 한국 B2B 공급망이 제공하는 모든 형식 변형을 마주하게 되고, 모두 수동으로 입력하게 됩니다.
명명 규칙. 어떤 행이 어떤 파일에서 왔는지 알아야 합니다. "거래명세서_20260430.pdf"는 공급업체에 대해 아무것도 알려주지 않습니다. 같은 공급업체에서 한 달에 세 장의 세금계산서를 받으면, 각 품목을 원본 문서까지 추적해야 합니다. 파일 이름만으로는 추적이 불가능합니다.
예외 처리. 문서 50장 중에는 빈 필드가 나타납니다. 한 공급업체가 단가 인쇄를 잊었습니다. 다른 업체는 VAT 셀을 비워두었습니다. 휴대폰 사진이 품목표 하단 행을 잘라냈습니다. 단건 처리에서는 즉시 발견하고 해결하지만, 배치 처리에서는 예외가 문서 더미 속에 묻혀 있습니다. 찾으려면 완료된 모든 행을 검사해야 합니다.
출력 병합. 각 문서를 완벽하게 추출하더라도 쉰 개의 개별 스프레드시트가 생깁니다. 실제 필요한 결과물은 모든 공급업체의 모든 품목을 담은 단일 테이블로, 날짜, 공급업체, 발주번호별로 정렬 및 필터링이 가능해야 합니다.

단건 처리는 타이핑 속도를 테스트합니다. 배치 처리는 시스템 설계를 테스트합니다. 병목이 "얼마나 빨리 입력할 수 있는가"에서 "모든 문서를 한 번에 처리하면서 각각의 출처를 놓치지 않는 방법"으로 바뀝니다. 이는 근본적으로 다른 질문입니다.

더존·이카운트·아이퀘스트가 인바운드 추출을 해결하지 못하는 이유

한국 ERP 시장은 수십 년간 아웃바운드 문서 생성에 투자해 왔으며, 그 결과는 실로 인상적입니다. 더존비즈온 — 2025년 스웨덴 사모펀드 EQT에 1.3조 원에 인수된 국내 최대 ERP 공급사 — 은 WEHAGO와 iCUBE를 통해 약 2만 개의 기업 고객이 판매 기록에서 거래명세서를 한 번에 생성하고, 고객 DB에서 공급자와 구매자 정보를 자동 입력하며, 수백 장의 명세서를 일괄 인쇄·이메일 발송할 수 있도록 지원합니다.

이카운트는 8만 개 이상의 기업 고객에게 월 4만 원 정액제로 동일한 모델을 제공합니다: 매출 입력 → 자동 거래명세서 생성 → 멀티 채널 발송. 구매 모듈에서 매입 데이터를 기록할 수는 있지만, 데이터 입력은 수동입니다. 수신한 문서에 대해 '문서 업로드 → 필드 자동 추출' 경로는 존재하지 않습니다.

아이퀘스트의 얼마에요 ERP는 OCR 기반 거래명세서 데이터 추출을 제공하는 유일한 주요 국내 ERP 벤더입니다. 모바일 앱으로 수신한 거래명세서를 촬영하면 AI가 공급자 정보와 품목 목록을 추출하여 ERP에 입력합니다. 이는 분명한 진전이며, 어떤 면에서는 ImageToTable.ai가 단일 문서에 대해 수행하는 작업과 가장 유사한 국내 사례입니다. 하지만 설계 가정은 '문서 한 건씩'입니다: 촬영 → 화면에서 AI 추출 결과 검토 → 오류 수정 → 확인 → 반복. 점심 미팅 후 영업사원이 영수증 한 장을 캡처하는 경우에는 적합합니다. 그러나 월말에 15개 공급업체로부터 50장의 거래명세서를 받는 구매팀에게는 적합하지 않습니다. 병목 현상이 문서별 추출 정확도가 아니라, 진정한 일괄 처리를 막는 문서별 인간 검토 루프이기 때문입니다.

경리나라와 경영이지는 간편함으로 중소기업에 인기가 많으며, 거래명세서 발행은 능숙하게 처리하지만 인바운드 추출 기능은 전혀 없습니다. 주요 ASP 플랫폼인 팝빌과 바로빌도 마찬가지입니다. 이들은 대량 발행과 홈택스 연동 API를 제공하지만, 조회 기능은 자사가 발행한 문서의 데이터를 가져올 뿐, PDF·스캔·사진 형태로 수신한 공급업체 문서에서 구조화된 데이터를 추출하지는 않습니다.

모든 한국 ERP 및 회계 플랫폼에서 일관된 패턴이 나타납니다: 아웃바운드 자동화는 해결된 문제입니다. 인바운드 데이터 추출은 제품 로드맵조차 오르지 않았습니다. 암묵적이지만 일관된 가정은 '구매자가 직접 데이터를 입력할 것'이라는 점입니다.

월말 결산의 현실: 이 문제에 마감이 있는 이유

한국 B2B 결제 주기는 일괄 처리 압박을 가중시킵니다. 두 가지 정산 패턴이 주를 이룹니다: 월말결제와 익월결제. 두 경우 모두, 한 달 동안 수신된 거래명세서는 결제 승인 전에 대사가 완료되어야 하는 더미로 쌓입니다.

10~30개 협력사를 둔 중견 제조업체나 유통업체의 경우, 한 달에 보통 50~200건의 거래명세서가 유입됩니다. 이 명세서들은 한 달 내내 하루에 몇 건씩 도착하지만, 대사 작업은 결제 승인 전 마지막 3~5영업일이라는 짧은 기간에 집중됩니다. 수령 부서는 모든 거래명세서의 모든 라인 항목을 시스템에 입력하여 구매 발주서와 대조하고 재무팀에 지급 일정을 준비해야 합니다.

보수적으로 50건의 문서를 기준으로 한 해당 기간의 작업량은 다음과 같습니다:

작업	문서당	× 50건
공급자/구매자 헤더 필드 열람 및 확인	1분	50분
라인 항목 추출	3분	2.5시간
공급가액을 구매 발주서와 대조	1분	50분
세금계산서와 대조	1분	50분
수동 처리 합계		약 5.5시간

5시간 30분은 거의 하루 종일 근무하는 시간입니다. 그리고 이는 모든 문서가 깨끗하고 읽기 쉬운 PDF로 도착한다는 가정하에 계산된 것입니다. 실제로는 ERP에서 생성되어 A4 용지에 인쇄된 PDF, 송장 소프트웨어를 사용해 본 적 없는 소규모 가족 운영 협력사의 수기 양식, 배송 기사가 카카오톡으로 보낸 모바일 사진, 기울어져 스캔된 복사본 등 다양한 형식이 섞여 있습니다. 각 형식 변형은 마찰을 더하고, 마감 시간에 쫓기면 그 마찰은 더욱 커집니다.

이것이 바로 "더 빨리 입력하면 된다"는 답변이 대략 20번째 문서쯤에서 더 이상 통하지 않는 이유입니다. 진짜 질문은 개별 필드를 얼마나 빨리 입력할 수 있느냐가 아니라, 모든 문서를 하나의 워크플로우에서 한 번에 처리하고, 하나의 출력물로 만들고, 각 원본 파일까지 명확한 감사 추적을 유지하는 방법입니다.

일괄 추출 작동 방식: 하나의 열 정의로 모든 공급업체 처리

일괄 거래명세서 처리를 가능하게 하는 핵심 메커니즘은 열 이름 기반 추출입니다. 문서에서 각 필드의 위치를 알려주거나, 원하는 필드 이름을 입력하여 무엇을 찾을지 알려주는 방식입니다. AI가 문서를 시각적으로 읽고, 필드 이름의 의미를 이해하여 각 값을 찾아내고, 공급업체가 페이지에서 필드를 어디에 배치했든 관계없이 출력 테이블을 채웁니다.

좌표 기반 추출과 의미 기반 추출의 이러한 차이점이 일괄 처리를 실현 가능하게 만듭니다. 좌표 기반 도구는 각 공급업체의 레이아웃에 대해 별도의 템플릿이 필요합니다. 공급업체 A의 "수량" 필드는 픽셀 위치 (400, 320)에 있지만 공급업체 B의 경우 (380, 450)에 있기 때문입니다. 15개 공급업체의 문서 50개가 있다면 15개의 템플릿이 필요하며, 공급업체가 양식 레이아웃을 변경하면 템플릿이 작동하지 않습니다. 의미 기반 추출 도구는 "공급자명", "거래일자", "품목명", "수량", "단가", "공급가액"과 같은 필드 이름 목록인 하나의 열 정의만 필요하며, 레이아웃에 관계없이 배치의 모든 문서에 동일한 정의를 적용합니다.

ImageToTable.ai의 일괄 처리는 이 원칙에 따라 작동합니다. 50개의 거래명세서 파일을 한 번에 업로드합니다. 출력 스프레드시트에서 추출하려는 열을 정의합니다. AI가 모든 문서를 읽고, 위치가 아닌 의미로 각 필드를 찾아 모든 결과를 하나의 병합된 Excel 테이블로 컴파일합니다. 각 문서는 하나의 행이 되고, 요청된 각 필드는 열이 되며, 50개의 개별 파일이 아닌 하나의 스프레드시트를 다운로드합니다.

JPG/PNG/PDF AI 추출

파일은 안전하게 처리되며 저장되지 않습니다.

효율성 배수는 문서별 설정을 제거함으로써 발생합니다. 공급업체별로 아무것도 구성할 필요가 없습니다. 템플릿을 만들 필요가 없습니다. 모델을 학습시킬 필요가 없습니다. "공급자명", "사업자등록번호", "거래일자", "품목명", "규격", "수량", "단가", "금액", "공급가액", "세액", "PO 참조 번호"와 같은 열을 한 번만 정의하면 동일한 열 세트가 모든 공급업체의 모든 거래명세서를 처리합니다. 50개 파일, 15개 공급업체, 하나의 출력.

페이지당 5~10초면 처리되는 반면, 문서 한 건당 수동 입력에 3분이 소요되는 점을 고려하면, 일괄 워크플로는 5.5시간 분량의 타이핑 작업을 약 15분의 처리 시간으로 압축하여 18배의 효율성 향상을 가져옵니다. 하지만 진정한 이점은 절약된 시간이 아닙니다. 출력물이 하나의 병합된 스프레드시트로 제공되며, 모든 라인 항목을 원본 문서까지 추적할 수 있어 발주서(PO) 및 세금계산서와의 3자 일치(3-way matching)에 즉시 사용할 수 있다는 점입니다.

대규모 3자 일치: 발주서(PO) → 거래명세서 → 세금계산서

한국 조달팀의 경우, 거래명세서 데이터를 스프레드시트로 추출하는 것이 최종 목표가 아니라 중간 단계입니다. 실제 결과물은 발주서 → 거래명세서 → 세금계산서로 이어지는 3자 일치입니다.

한국의 부가가치세(VAT) 체계에서 세금계산서는 법적으로 규제되는 문서로, 부가가치세법 제32조의 적용을 받으며 공급자 및 공급받는자의 사업자등록번호, 공급가액, 부가가치세액, 작성일자 등 필수 기재사항을 포함합니다. 이는 구매자가 매입세액 공제를 받을 수 있는 자격을 부여하는 문서이며, 분기별 부가가치세 신고에 정확히 반영되어야 합니다. 거래명세서는 그러한 법적 효력이 없으며, 세액 공제 대상이 아닌 사적 증빙 문서에 불과하지만, 실제로 상품과 함께 도착하고 세금계산서에서 종종 생략되는 품목 수준의 세부 정보를 담고 있는 문서입니다.

대규모 3자 일치 워크플로는 다음과 같습니다:

발주서 → 거래명세서: 주문한 대로 납품되었는지 확인

각 공급업체의 거래명세서에 기재된 품목, 수량, 단가를 원래 발주서와 비교합니다. 수량 불일치, 승인되지 않은 대체 품목, 잘못된 단가 등의 차이는 세금계산서 처리를 시작하기 전에 반드시 식별되어 해결되어야 합니다. 거래명세서 데이터를 각 라인별 발주서 참조 번호가 포함된 열 구조로 추출합니다.

거래명세서 → 세금계산서: 청구 금액이 납품 금액과 일치하는지 확인

세금계산서는 별도로 도착합니다. 보통 상품 인수 후 며칠이 지나서, 때로는 월별 통합 청구 주기에 맞춰 첨부되어 옵니다. 세금계산서의 공급가액과 세액은 거래명세서의 합계와 일치해야 합니다. 이때 통합 스프레드시트의 진가가 발휘됩니다. 거래명세서 추출 결과의 한 열과 세금계산서 추출 결과의 한 열을 나란히 비교함으로써, 여러 문서를 수동으로 대조하던 작업을 간단히 대체할 수 있습니다.

세금계산서 → 국세청 신고: 부가가치세 신고 정확성 확인

거래명세서와 대조 검증된 세금계산서 데이터는 분기별 부가가치세 신고에 활용됩니다. 국세청에 공급업체의 전자 세금계산서로 등록된 내용과 귀하가 신고한 내용 간에 차이가 발생하면 교차 검증 플래그가 트리거됩니다. 3자 일치는 바로 귀하의 감사 추적 자료입니다. 지불한 금액이 수령한 물품 및 공급업체가 신고한 내용과 일치함을 증명합니다.

거래명세서 추출과 세금계산서 추출의 결합이 바로 완벽한 구매 대사 시스템을 만드는 핵심입니다. 각 문서 유형은 서로 다른 필드를 포함하고, 다른 목적을 가지며, 다른 경로를 통해 도착합니다. 그러나 둘 다 동일한 스프레드시트에 입력되며, 둘 다 일치해야 합니다.

수동 데이터 입력은 그만, AI가 대신 읽어드립니다

이미지나 PDF를 업로드하면 10초 안에 구조화된 스프레드시트 데이터로 변환

지금 사용해보기 →

회원가입 불필요 · 신용카드 불필요 · 10초 내 결과 확인

파일명 문제: 배치 처리에 출처 추적이 필요한 이유

단일 문서 처리에서는 존재하지 않지만 배치 워크플로우에서 중요해지는 문제가 있습니다. 바로 추출된 각 행이 어떤 파일에서 왔는지 아는 것입니다.

전형적인 월말 배치에는 다음과 같은 파일들이 포함될 수 있습니다:

거래명세서_20260430.pdf — 동해철강, ERP 생성
거래명세서_20260430.pdf — 다른 공급업체, 동일 파일명, 다른 폴더
KakaoTalk_20260502_143021.jpg — 수기 거래명세서 사진, 파일명만으로 공급업체 식별 불가
scan001.pdf — 스캔된 종이 양식, 이미지에 공급업체명 포함되어 있으나 파일명에는 없음
2026-04-30_거래명세표_대한포장.pdf — 식별 가능한 깔끔한 파일명, 예외적인 경우

추출된 50개의 행이 출력 스프레드시트에 들어오면, 각 행이 어떤 공급업체의 원본 문서에 해당하는지 알아야 합니다. 이러한 추적성 없이는 수량 불일치를 해결할 수 없습니다. 즉, 추출이 올바른지 또는 공급업체가 오류를 범했는지 확인하기 위해 원본 문서로 돌아갈 수 없습니다.

ImageToTable.ai의 배치 추출 워크플로우는 출력에 원본 파일명을 열로 포함시켜 이러한 추적성을 유지합니다. 추출된 모든 행은 원본 파일명을 가지고 있어, 어떤 데이터 포인트든 즉시 원본 문서로 추적할 수 있습니다. KakaoTalk_20260502_143021.jpg처럼 모호한 파일명의 문서는 업로드 전에 이름을 바꾸십시오. DonghaeSteel_20260430.pdf와 같은 간단한 접두사만으로도 필요한 추적성을 제공합니다.

이것은 단일 문서 튜토리얼에서는 언급되지 않는 배치 특유의 과제 중 하나입니다. 하나의 문서를 처리할 때는 방금 본 문서이므로 데이터 출처를 알 수 있습니다. 하지만 50개를 처리할 때는 시스템이 기억하도록 해야 하며, 그렇지 않으면 직접 기억해야 합니다.

업로드 전에 설정하는 파일명 규칙이 곧 감사 추적입니다. 일관된 패턴 — [공급업체코드]_[날짜]_[문서유형].pdf — 은 파일당 10초가 소요되며, 대사 과정에서 불일치가 발생했을 때 파일명을 추적하는 데 몇 시간을 절약해 줍니다.

형식 다양성 처리: 수기 작성부터 ERP 생성까지

한국 B2B 조달에서 형식 다양성 문제는 공급업체 규모와 업종에 따라 달라집니다. 울산의 대형 화학 공급업체는 두존 iCUBE로 생성된 PDF로 상품을 발송합니다 — 레이저 용지에 인쇄되고, 전문적으로 포맷팅되며, 모든 필드가 예측 가능한 그리드에 있습니다. 인천의 소형 포장 공급업체는 미리 인쇄된 카본지 양식에 거래명세서를 손으로 작성하고, 파란색 구매자 사본을 떼어 배송 기사에게 건넵니다. 중간 규모의 식품 유통업체는 화면에서는 전문적으로 보이지만 인쇄 시 병합된 셀이 필드 경계를 겹치게 하는 Excel 템플릿을 사용합니다.

기존 OCR — 텍스트가 예측 가능한 위치에 있을 것으로 가정 — 은 두 번째와 세 번째 범주에서 실패합니다. 카본지 양식에 손으로 쓴 한글 문자는 기사의 필체를 고려하기 전에도 이미 대비가 낮습니다. 병합된 셀이 있는 Excel 인쇄 양식은 필드 레이블과 값이 서로 섞이는 텍스트 블록을 생성합니다. 템플릿 기반 시스템은 각 형식에 대해 별도의 템플릿을 구축해야 하며 — 15개 공급업체가 5가지 다른 형식 유형을 사용하는 경우, 템플릿 유지 관리만으로도 반복적인 작업이 됩니다.

열 이름 추출은 설계상 형식 다양성을 처리합니다 — 레이아웃에 의존하지 않기 때문입니다. "수량"이 PDF의 그리드 테이블 세 번째 열에 있든, 수기 양식 여백에 휘갈겨 쓰여 있든, 병합된 Excel 셀에 포함되어 있든, AI는 사람이 읽는 방식으로 문서를 읽어 위치를 찾습니다: 픽셀 좌표가 아닌 의미적 의미를 스캔합니다. 두존 PDF에서 작동하는 동일한 열 정의가 수기 카본지와 Excel 출력물에서도 작동합니다.

실질적인 한계는 있습니다: 사람이 텍스트를 읽을 수 없을 정도로 흐릿한 사진은 AI도 실패합니다. 그러나 "읽을 수 있는" 기준은 템플릿 기반 OCR이 요구하는 것보다 훨씬 낮습니다 — 흐릿하지만 읽을 수 있는 텍스트는 픽셀 좌표가 템플릿이 일치시키기에는 너무 부정확하더라도 여전히 의미적으로 읽을 수 있기 때문입니다.

50건 문서 배치에서 예외 처리하기

50건의 문서 배치 중 일부는 문제가 있습니다. 간이과세자인 공급업체가 VAT 필드를 비워두거나, 다른 업체가 공급가액을 잘못된 셀에 입력하여 예상치 못한 값이 추출됩니다. 휴대폰 사진으로 촬영된 문서는 10개 항목 테이블의 마지막 두 행이 잘릴 수 있습니다.

단일 문서 처리에서는 문서와 데이터를 동시에 보기 때문에 문제를 즉시 발견할 수 있습니다. 하지만 배치 처리에서는 추출 단계로 인해 문서와 데이터가 분리되어, 400행의 병합된 테이블 속에 예외가 숨을 수 있습니다.

배치 모드에서 예외를 처리하는 워크플로우:

필수 열의 빈칸 스캔

추출 후 출력 스프레드시트에서 공급업체명, 공급가액, 수량 등 중요 열의 빈 셀을 필터링합니다. 수량이 비어 있으면 항목 행이 누락되었거나 문서에 수량 필드가 없는 경우입니다. 어느 쪽이든 확인이 필요합니다.

문서 합계와 총액 대조 확인

거래명세서의 공급가액은 모든 라인 금액의 합계입니다. 추출된 라인 금액의 합이 추출된 공급가액과 일치하지 않으면 라인이 누락되었거나 공급가액이 잘못 읽힌 것입니다. 이 교차 검증은 모든 문서를 다시 읽지 않고도 추출 누락을 찾아냅니다.

개별 문제 문서 재처리

필수 필드 누락이나 합계 불일치로 신뢰할 수 없는 결과가 나온 문서는 개별적으로 다시 업로드하여 두 번째 추출을 수행합니다. 배치 워크플로우는 한 문서의 오류를 수정하기 위해 전체 배치를 다시 처리할 필요가 없습니다.

핵심 통찰: 배치 처리는 예외를 없애는 것이 아니라 예외를 찾는 방식을 바꿉니다. 입력하면서 한 번에 하나씩 오류를 발견하는 대신, 완성된 출력물에 대해 구조화된 검사를 실행하고 문제 문서를 분리합니다. 반응적 오류 발견에서 능동적 오류 탐지로의 전환이 배치 처리를 더 빠르고 신뢰성 있게 만듭니다.

기존 구매 워크플로우에 일괄 추출 통합하기

일괄 거래명세서 추출은 ERP를 대체하지 않습니다. 그렇게 시도해서도 안 됩니다. ERP는 판매 기록, 매출 송장 생성, 국세청 전송, 재무 보고를 처리합니다. 일괄 추출은 ERP가 키보드 입력에 맡겨두었던 데이터 수집 단계를 처리합니다.

통합 지점은 Excel 출력물입니다. 모든 수신 거래명세서 데이터를 하나의 스프레드시트로 추출하고, 발주서 및 세금계산서와 대사한 후, 검증된 데이터를 ERP의 표준 Excel 가져오기 기능을 통해 가져옵니다. 주요 한국 ERP는 모두 이를 지원합니다. 더존의 Smart A와 iCUBE는 구매 기록에 대한 Excel 일괄 가져오기를 제공합니다. 이카운트는 거래명세서 및 기타 거래 문서에 대한 Excel 대량 가져오기를 제공합니다. 아이퀘스트 얼마에요는 매입거래명세표 데이터에 대한 Excel 업로드를 지원합니다. 추출된 스프레드시트는 ERP에 입력되기 전에 깨끗하고, 구조화되어 있으며, 검증된 가져오기 소스가 됩니다.

해외 공급업체의 문서도 처리하는 팀의 경우 동일한 워크플로우가 적용됩니다. 중국 부품 공급업체의 납품서나 유럽 장비 공급업체의 패킹 리스트도 동일한 추출 로직을 따릅니다. 문서 언어와 형식은 바뀌지만, 열 이름 추출 원칙은 바뀌지 않습니다.

이는 올인원 ERP 약속과 근본적으로 다릅니다. 재무 시스템을 대체하는 것이 아닙니다. 모든 한국 ERP가 남겨둔 유일한 격차, 즉 공급업체의 문서가 어떤 형식으로 도착하든 ERP의 레코드가 되기 전에 먼저 스프레드시트의 행이 되어야 하는 그 순간을 메우는 것입니다.

FAQ

일괄 처리가 동일한 업로드에서 수기 및 인쇄된 거래명세서를 모두 처리할 수 있습니까?

가능합니다. AI는 각 문서를 독립적으로 읽으며, 동일한 의미 추출 로직을 사용하여 수기 한글 문자와 인쇄된 텍스트를 인식합니다. 동일한 열 정의가 두 형식을 모두 처리합니다. 실질적인 한계는 가독성입니다. 사람이 손글씨를 읽을 수 없다면 AI도 읽지 못할 가능성이 높습니다.

공급자의 거래명세서에 비표준 필드명이 사용되면 어떻게 처리되나요?

열 이름 추출은 텍스트 문자열을 일치시키는 방식이 아니라 의미론적 이해를 통해 값을 찾습니다. 수량 필드의 라벨이 "수량" 대신 "출하수량"으로 표시된 공급자의 문서라도 AI가 두 라벨이 동일한 개념을 가리킨다는 것을 이해하므로 올바르게 추출됩니다. 이것이 템플릿 매칭과 의미론적 추출의 근본적인 차이점입니다.

항목 테이블이 여러 페이지에 걸쳐 있는 다중 페이지 거래명세서는 시스템이 어떻게 처리하나요?

다중 페이지 PDF는 하나의 문서로 처리됩니다. AI가 모든 페이지를 읽고 페이지 나누기와 관계없이 항목 테이블에서 모든 라인 항목을 추출합니다. 출력물은 모든 페이지의 모든 행을 동일한 문서의 스프레드시트 레코드로 통합합니다.

특정 라인 항목만 추출할 수 있나요? 예를 들어, 특정 PO 번호와 일치하는 항목만 추출하는 경우는요?

추출 단계에서는 모든 문서의 모든 데이터를 추출합니다. PO 번호, 공급자, 날짜 범위 또는 기타 기준에 따른 필터링은 추출 후 출력 스프레드시트에서 수행됩니다. 이렇게 하면 추출을 처음부터 하위 집합으로 제한하는 대신 필요에 따라 작업하고 필터링할 수 있는 완전한 데이터 세트를 얻을 수 있습니다.

거래명세서 데이터 추출은 한국의 세무 기록 보관 요건을 준수하나요?

거래명세서 자체는 사적 증빙 문서입니다. 법적으로 정해진 형식이 없으며 정부 기관에 제출되지 않습니다. 데이터를 추출하거나 저장하는 방식에 관한 특정 규정 준수 요건은 없습니다. 법적 규정 준수 의무가 있는 문서는 부가가치세법 제32조에 따른 세금계산서이며, 이는 별도로 처리됩니다. 세금계산서 추출에 대해서는 세금계산서 일괄 처리 가이드를 참조하십시오. 실무적으로 국세기본법 제85조의3은 거래 기록을 5년간 보관할 것을 권장하며, 출처 파일명 추적이 가능한 구조화된 Excel 파일은 종이 서류 더미보다 이 목적에 더 적합합니다.

한국어 세금계산서도 배치 처리되나요?

네 — 동일한 배치 추출 방식이 적용됩니다. 세금계산서 배치 처리 시 사업자등록번호, 공급가액, 세액, 승인번호 등의 열을 정의하고 한 번에 100~200장의 세금계산서를 업로드하면 됩니다. 추출 원리는 동일하며, 필드명만 달라집니다.

모든 한국형 ERP는 판매 기록에서 거래명세서를 생성할 수 있습니다. 차이와 기회는 수신 측에 있습니다. 배치 추출은 하나의 열 정의, 한 번의 업로드, 하나의 스프레드시트로 그 격차를 메웁니다. 다음 월말 배치 작업에서 직접 사용해보세요. 5시간 30분의 타이핑이 15분의 검증으로 바뀌는 경험을 해보십시오.

거래명세서 50장,스프레드시트 하나로: 타이핑 없는 일괄 처리

핵심 요약