한국어 납품명세서 50장, 스프레드시트 하나로: 타이핑 없이 일괄 처리

모든 한국 ERP는 판매 기록에서 거래명세서를 한 번의 클릭으로 생성할 수 있습니다. 하지만 그 명세서를 다시 읽을 수 있는 ERP는 단 하나도 없습니다. 한국 기업 간 모든 물리적 배송에 동봉되는 이 문서 — 품목, 수량, 단가, 공급가액을 나열하는 — 는 키보드를 통해 조달 워크플로우에 한 필드씩 입력됩니다. 월말에 15개 공급업체로부터 50장의 명세서를 받을 때, 그 비대칭성은 더 이상 호기심에 그치지 않고, 입고팀이 밤 10시까지 사무실에 남아 있는 이유가 됩니다.

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

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

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

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

이제 이 작업을 50번 반복해 보세요. 각각 다른 레이아웃, 다른 품목 코드 체계, 다른 인쇄 품질을 가진 15곳의 공급사에서 말입니다. 대규모에서 발생하는 문제는 단건 처리에서는 보이지 않습니다:

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

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

더존·이카운트·아이퀘스트가 매입 전자문서 추출을 해결하지 못하는 이유

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

이카운트는 8만여 기업 고객에게 월 4만 원 정액제로 동일한 모델을 제공합니다: 매출 입력 → 자동 거래명세서 생성 → 멀티 채널 발송(이메일, 카카오톡, SMS, 팩스). 구매 모듈에서 매입 데이터를 기록할 수는 있지만, 데이터 입력은 수동입니다. 수취한 문서를 업로드하면 필드를 자동 추출하는 기능은 없습니다.

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

경리나라와 경영이지는 간편함으로 중소기업에 인기가 많지만, 거래명세서 발행은 잘 처리하나 매입 문서 추출 기능은 전혀 없습니다. 주요 ASP 플랫폼들도 마찬가지입니다. 팝빌은 37만 3천여 개 등록 사업자, 3억 2천 4백만 건 이상의 누적 문서를 보유하고, 바로빌은 대량 발행 API와 홈택스 연동을 제공하지만, 조회 기능은 자사가 발행한 문서 데이터를 가져오는 것일 뿐, PDF·스캔·사진 형태로 수취한 공급자 문서에서 구조화된 데이터를 추출하는 기능은 아닙니다.

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

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

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

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

보수적으로 50건의 문서를 기준으로 한 작업 시간 산출:

작업	문서당	× 50건
공급자/구매자 헤더 필드 열람 및 확인	1분	50분
라인 항목 추출 (문서당 평균 8행)	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의 일괄 처리는 이 원칙에 따라 작동합니다. 모든 거래명세서 파일(PDF, JPG 스캔본, PNG 스크린샷, WebP 사진)을 한 번에 업로드합니다. 출력 스프레드시트에서 추출하려는 열을 정의합니다. AI가 모든 문서를 읽고, 위치가 아닌 의미로 각 필드를 찾아 모든 결과를 하나의 병합된 Excel 테이블로 컴파일합니다. 각 문서는 하나의 행(또는 여러 줄 항목 테이블이 포함된 경우 여러 행)이 되고, 요청된 각 필드는 열이 되며, 50개의 개별 파일이 아닌 하나의 스프레드시트를 다운로드합니다.

JPG/PNG/PDF AI 추출

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

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

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

대규모 3-Way 매칭: 발주서 → 거래명세서 → 세금계산서

한국 조달팀에게 거래명세서 데이터를 스프레드시트로 추출하는 것은 최종 목표가 아니라 중간 단계입니다. 실제 결과물은 3-Way 매칭, 즉 발주서 → 거래명세서 → 세금계산서입니다.

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

대규모 3-Way 매칭 워크플로우:

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

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

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

세금계산서는 별도로 도착합니다. 보통 물품 수령 후 며칠 뒤, 또는 월별 통합 청구 주기에 맞춰 발행됩니다. 공급가액과 세액은 거래명세서의 총액과 일치해야 합니다. 이때 통합 스프레드시트가 유용합니다. 거래명세서 추출 데이터의 한 열과 세금계산서 추출 데이터의 한 열을 나란히 비교하면, 여러 문서를 일일이 대조할 필요가 없습니다.

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

거래명세서와 대조하여 확인된 세금계산서 데이터는 분기별 부가세 신고에 사용됩니다. 국세청에 공급업체가 전자신고한 내용과 귀하가 신고한 내용이 일치하지 않으면 교차 검증 플래그가 발생합니다. 3자 매칭은 감사 추적 역할을 합니다. 지불한 금액이 수령한 물품 및 공급업체가 신고한 내용과 일치함을 입증합니다.

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

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

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

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

거래명세서_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는 사람이 문서를 읽는 방식, 즉 픽셀 좌표가 아닌 의미적 의미를 스캔하여 이를 찾습니다. Douzone PDF에서 작동하는 동일한 열 정의가 수기 카본지와 Excel 출력물에서도 작동합니다.

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

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

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

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

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

필수 열의 빈칸 스캔

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

문서 합계와 추출 합계 대조

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

개별 문제 문서 재처리

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

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

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

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

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

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

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

FAQ

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

예. AI는 각 문서를 독립적으로 읽으며, 동일한 의미 추출 로직을 사용하여 필기 한글 문자(다양한 필기체 품질 포함)와 인쇄된 텍스트를 인식합니다. 동일한 열 정의가 두 형식을 모두 처리합니다. 실질적인 한계는 가독성입니다: 사람이 필체를 읽을 수 없다면 AI도 읽을 가능성이 낮습니다.

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

열 이름 추출은 텍스트 문자열을 일치시키는 방식이 아니라 의미적 이해를 통해 값을 찾습니다. 수량 필드가 "수량" 대신 "출하수량"으로 표시된 공급자의 서식에서도 AI가 두 레이블이 동일한 개념을 나타냄을 이해하기 때문에 정확하게 추출됩니다. 이것이 템플릿 매칭(실패함)과 의미적 추출(적응함)의 근본적인 차이점입니다.

여러 페이지에 걸친 품목 테이블이 있는 거래명세서는 어떻게 처리되나요?

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

특정 라인 항목만(예: 특정 PO 번호와 일치하는 항목만) 추출할 수 있나요?

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

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

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

한국어 세금계산서도 일괄 처리되나요?

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

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