여러 공급업체의 일본어 납품서를 일괄 처리하여 하나의 입고 로그로 만드는 방법

なぜ日本の入荷ドックは手動データ入力に依存しているのか

製造業、小売業、Eコマースなど、さまざまな業界の物流を支える日本の3PL市場は、2031年までに483億8000万米ドルに達すると予測されています。しかし、トラックに何が積まれていたかを証明する書類は、今も30年前と同じ方法で処理されています。誰かがそれを読み、データを入力し、数字を打ち間違えていないことを願うだけです。

日本の倉庫管理システムは、ほぼすべての物理的プロセスを自動化してきました。 ドックドアのバーコードスキャナーがパレットIDを取得します。RFIDタグが在庫の位置をリアルタイムで追跡します。無人搬送車が人の介入なしにゾーン間で商品を移動させます。国内最大の3PLである日本通運（NXグループ）は、入荷、保管、ピッキングをミリ秒単位で調整するWMSプラットフォームを運用しています。しかし、これらのシステムすべてに共通する依存関係があります。それは、動作を開始するために構造化データが必要だということです。WMSはデジタルトランザクションを受け取ると在庫レベルを更新できますが、そのトランザクションは、誰かが納品書を読み、データを入力した後にのみ作成できます。

これは日本の物流技術の失敗ではありません。これは、データ入力の問題を装った文書形式の問題です。納品書は、日本の商法上、法的に必須の書類ではありません。2023年10月から適格請求書等保存方式（インボイス制度）によって標準化が進められている請求書とは異なります。納品書には、必須の形式、必須の項目、PeppolやFactur-Xに相当するデジタル標準はありません。すべてのサプライヤーは、自社のバックオフィスが作成する方法で、納品書を印刷、タイプ、または手書きしています。

WMS가 팔레트는 인식하지만 납품서는 인식하지 못하는 이유

이러한 격차가 지속되는 이유를 이해하려면 화요일 아침 일본의 입고 현장에 실제로 무엇이 도착하는지 살펴보는 것이 도움이 됩니다.

간사이 소재 제조업체에서 보낸 화물이 사가와 익스프레스를 통해 배송됩니다. 납품서는 인쇄된 PDF로 도착합니다. 깔끔한 레이아웃, 다단 표, 품목 코드와 수량이 명확하게 표시되어 있습니다. 하지만 필드 이름은 일본어(品名/数量/単位)이고, 날짜는 일본 연호 형식(令和8年6月16日)이며, 공급업체 회사명은 헤더에 "공급업체"라는 명시적인 레이블 없이 표시됩니다.

야마토 운송이 홋카이도 식품 공급업체의 화물을 가져옵니다. 이 납품서는 야마토 물류 센터에서 생성된 감열지 출력물로, 레이아웃, 필드 레이블, 열 순서가 모두 다릅니다. 사이타마의 소규모 제조업체를 담당하는 지역 운송업체가 수기로 작성된 카본지 납품서와 함께 상자 세 개를 내려놓습니다. 글씨는 급하게 써졌고, 수량은 단위가 아닌 상자 개수로 표시되어 있으며, 공급업체명은 인쇄된 텍스트가 아닌 도장(印鑑)으로 찍혀 있습니다.

같은 30분 안에 도착한 이 세 문서는 완전히 다른 형식을 나타냅니다. 템플릿 기반 OCR 도구는 세 가지 다른 레이아웃에 대해 세 개의 개별 템플릿을 학습해야 합니다. 다음 주에 또 다른 형식의 네 번째 공급업체가 나타나면 시스템을 다시 학습시켜야 합니다. 사가와가 1월에 납품서 템플릿을 변경하면(실제로 발생하는 일입니다) 기존 템플릿은 작동을 멈춥니다. 이것이 대부분의 일본 물류 회사가 납품서 자동 추출을 시도하지 않는 이유입니다. 템플릿 유지보수 비용이 제거하려는 데이터 입력 비용을 초과하기 때문입니다.

병목 현상은 납품서 데이터가 복잡해서가 아닙니다. 동일한 필드(공급업체명, 납품일자, 구매처 참조번호, 품목 코드, 수량)가 문서마다 다른 위치에 다른 레이블로 나타나기 때문입니다. 전통적인 자동화 방식인 '형식당 하나의 템플릿'은 형식 다양성 앞에 무너집니다.

일본 납품서의 데이터 필드는 놀랍도록 일관적입니다. easymakedocs의 일본 납품서 가이드에 따르면 표준 요소는 문서 제목(納品書), 납품서 번호, 납품일자, 고객 정보, 공급업체 정보, 품목 세부 정보(명칭, 수량, 사양, 선택적 단가), 공급업체 도장입니다. 차이는 내용이 아닌 레이아웃에서 발생합니다. 야마토 납품서에는 지역 운송업체의 수기 납품서와 동일한 개념적 필드가 포함되어 있습니다. 차이는 해당 필드가 페이지의 어디에 위치하고 어떻게 레이블이 지정되는지에 있습니다. 추출의 어려움은 정보가 다르기 때문이 아닙니다. 다양한 형식에서 정보를 찾으려면 필드가 어디에 있는지가 아니라 무엇을 의미하는지 이해해야 하기 때문입니다.

일괄 처리: 30개의 문서를 하나의 구조화된 입고 기록으로

이것이 바로 의미 기반의 컬럼명 추출이 템플릿 OCR과 차별화되는 지점입니다. 공급업체 A의 레이아웃과 공급업체 B의 레이아웃에서 필드 위치를 인식하도록 도구를 훈련시키는 대신, 원하는 필드를 한 번만 정의하면 됩니다. 필드가 나타내는 의미를 기준으로 정의하면, 추출 엔진이 배치 내 모든 문서에서 각 값을 의미를 이해하여 찾아냅니다.

ImageToTable.ai는 사용자 정의 컬럼 추출을 사용합니다. 최종 입고 기록에 원하는 컬럼 헤더(예: "공급업체명", "납품일자", "발주번호", "품목코드", "품목설명", "납품수량", "단위")를 입력하면, AI가 배치 내 각 납품서를 읽고 페이지 내 위치와 관계없이 각 필드를 찾아 해당 컬럼에 값을 채웁니다. "공급업체명"이라는 컬럼은 헤더에 "株式会社〇〇"로 인쇄되었든, 인감 도장으로 찍혔든, "納入元"으로 표기되었든 관계없이 공급업체를 찾아냅니다. 추출이 위치 기반이 아닌 의미 기반이기 때문입니다.

일본 물류 입고팀을 위한 워크플로우:

효율성 향상은 측정 가능합니다. 단일 페이지 납품서는 추출을 통해 5~10초 만에 처리되며, 이는 평균 3분의 수동 입력보다 18배 개선된 것입니다. 그러나 더 중요한 이점은 오류 감소입니다. 하루 30건의 납품서에 각각 평균 5개의 라인 항목이 있는 경우, 수동 입력은 약 150개의 데이터 포인트를 생성합니다. 보수적인 1%의 전사 오류율에서도 하루에 1~2개의 오류(품번의 숫자 전위, 수량의 잘못된 소수점)가 발생합니다. 한 달이면 30~60개의 오류가 WMS, 3자 매칭 시스템, 미지급금 워크플로우로 전파됩니다. 배치 추출이 검증의 필요성을 없애는 것은 아니지만, 이를 전사 작업에서 확인 작업으로 전환시켜 훨씬 빠르고 오류 가능성이 훨씬 낮아집니다.

입고 기록에서 삼중 대사 및 전자장부법 준수까지

입고 기록은 최종 목적지가 아닙니다. 이는 일본 물류 회사가 정확하게 대금을 받고 감사 대비 상태를 유지하는지 결정하는 두 가지 중요한 다운스트림 프로세스의 상위 입력입니다.

일본의 전자장부보존법에 따라, 전자적으로 보관된 모든 거래 문서는 거래일자, 거래금액, 거래처의 세 가지 기준으로 검색 가능해야 합니다. 연간 매출이 5천만 엔을 초과하는 기업의 경우 이러한 검색 가능 요구 사항은 필수입니다.

공급업체가 임의로 명명한 30개의 PDF 납품서 폴더("納品書_20260616.pdf", "delivery_sagawa.pdf", "Scan001.pdf")는 검색 가능성 테스트를 통과하지 못합니다. 각 행에 공급업체명, 납품일자, 발주번호, 운송사, 품목코드, 납품수량이 포함된 구조화된 스프레드시트는 자동으로 통과합니다. 법에서 검색을 요구하는 모든 기준이 스프레드시트의 열입니다. 날짜 범위 필터링, 금액 필터링, 거래처 검색 모두 기본 스프레드시트 작업이 되며, 수동으로 파일 하나하나를 찾을 필요가 없습니다.

이는 대부분의 문서 자동화 논의에서 간과하는 일괄 추출의 부차적 이점입니다. 납품서에서 구조화된 데이터를 추출하는 행위는 동시에 일본의 전자 저장 규정 준수를 충족시킵니다. 원본 PDF는 법정 보존 기간(소비세법상 거래 문서 7년, 상법상 상업 장부 10년) 동안 계속 보관해야 하지만, 세무 조사 중 신속한 검색을 위해 추출된 스프레드시트가 팀이 실제로 사용하는 도구입니다.

입고 기록은 또한 공급업체 지급을 승인하는 삼중 대사 프로세스에 직접 입력됩니다. 표준 일본 조달 관행에 따라, 납품서의 수량과 품목이 발주서와 청구서 모두에 대해 확인될 때까지 어떤 청구서도 승인되어서는 안 됩니다. 이것이 발주서 → 납품서 → 청구서 검증 체인입니다. 그러나 삼중 대사는 세 문서 모두 구조화된 데이터인 경우에만 자동화될 수 있습니다:

バッチ抽出からExcelやCSVにエクスポートされた構造化された入庫記録は、三者照合のループを閉じる架け橋となります。抽出データはfreee、マネーフォワード クラウド、弥生、または自社のWMSに直接インポートできます。SAPジャパン、GLOVIA smart（富士通）、EXPLANNER（NEC）を利用する企業の場合、CSV出力は標準の入庫トランザクションインポート形式に対応しています。三者照合は、文書ごとの手動照合から、体系的な例外確認へと移行します。つまり、発注数量と納品数量が一致しない行のみ、人間の確認が必要になります。

자주 묻는 질문

주요 일본 운송회사와 소규모 지역 운송회사 모두의 배송장을 처리할 수 있나요?

네, 가능합니다. 의미 기반 추출은 각 필드의 의미를 이해하여 배송장을 읽습니다. 즉, 페이지 내 위치가 아닌 필드의 의미를 기준으로 합니다. "공급업체명"이라는 열은 사가와 PDF의 헤더에 인쇄되어 있든, 카본지 전표에 도장으로 찍혀 있든, 지역 운송회사 배송장에 손으로 쓰여 있든 관계없이 공급업체를 찾아냅니다. 이는 각 레이아웃마다 별도의 템플릿이 필요한 템플릿 기반 OCR과의 근본적인 차이점입니다. 입고 로그 열을 한 번만 정의하면 이전에 본 적 없는 새로운 서식까지 모든 공급업체 서식에서 작동합니다.

배송장에 서력 대신 일본 연호(令和)가 사용된 경우는 어떻게 하나요?

추출 결과는 원래 연호 형식을 유지하거나 내보내기 시 자동으로 변환할 수 있습니다. 하위 시스템(예: ERP 가져오기)에서 서력 날짜가 필요한 경우, 도구의 후처리 레이어에서 내보내기 시 令和8年6月16일을 2026-06-16으로 변환합니다. 열을 "배송일"로 정의하고 출력 형식을 제어하면 수동 날짜 변환이 필요하지 않습니다.

기존 WMS(SAP, GLOVIA, freee, MoneyForward)와 어떻게 통합하나요?

추출 결과(Excel 파일 또는 CSV)는 입고 거래에 대한 CSV 가져오기를 지원하는 모든 WMS 또는 ERP로 가져올 수 있습니다. Freee 및 MoneyForward Cloud는 CSV 기반 분개장 가져오기(仕訳インポート)를 지원합니다. SAP Japan 및 Oracle Japan은 CSV 기반 입고 거래 로드를 지원합니다. 추출 단계는 가져오기 단계와 분리되어 있어 데이터가 시스템에 입력되는 시기와 방법을 제어할 수 있습니다. 일본 배송장 추출 워크플로우에 대한 자세한 내용은 일본 배송장 데이터를 Excel로 추출하는 가이드를 참조하십시오.

손으로 쓴 일본어 배송장도 읽을 수 있나요?

네, 가능합니다. 비전 모델은 지역 운송회사의 카본지 배송장에 있는 일본어 문자를 포함한 필기 텍스트를 처리합니다. 필기 인식의 정확도는 인쇄된 텍스트보다 낮습니다. 특히 급하게 쓰거나, 번지거나, 대비가 낮은 필기의 경우 더욱 그렇습니다. 따라서 필기 필드는 검토 단계에서 빠른 육안 확인이 도움이 됩니다. 이 도구는 저품질 입력에 대해 잘못된 확신을 주지 않으며, 추측하기보다는 불확실성을 표면화합니다. 30개의 배송장 중 3~5개가 필기인 배치의 경우, 검토 단계는 해당 소수의 문서에 집중하고 25개 이상의 인쇄된 PDF는 거의 완벽한 정확도로 처리됩니다.

一括抽出は電子帳簿保存法に対応していますか？

一括抽出により、取引日・取引金額・取引先の3つの検索要件を満たす構造化されたスプレッドシートが生成されます。範囲指定や組み合わせ検索は、スプレッドシートのフィルタ機能でネイティブにサポートされます。ただし、法律では原本の納品書ファイル（PDF、スキャン、写真）を法定保存期間中保持することが依然として必要です。抽出されたスプレッドシートは検索可能なインデックス兼作業記録であり、原本ファイルは法的なアーカイブです。両方を保存する必要があります。検索要件の詳細については、国税庁の電子帳簿保存に関するガイドラインをご参照ください。

納品書兼請求書の場合はどうなりますか？

一部の日本のサプライヤー（特にB2B製造業）は、納品書兼請求書を発行します。これらの文書には、納品データ（品目説明、数量）と請求データ（単価、税内訳、支払条件）の両方が含まれます。複合文書を一括処理する場合、納品フィールドと請求フィールドの両方の列を定義することで、1回の処理で両方のデータセットを抽出できます。出力されるスプレッドシートでは、1文書あたり1行にすべてのデータが格納され、後続の入庫業務や買掛金処理ワークフローに応じて列を分割またはフィルタリングできます。