韓国納品書50枚を、
1つのスプレッドシートに：手入力不要の一括処理

韓国の取引明細書が初めての方は、韓国取引明細書データのExcel抽出ガイド（フィールド構造、3ウェイマッチング、テンプレート破綻問題を解説）をご覧ください。本記事では、1枚の書類から50枚へ、1社のフォーマットから15社へと規模が拡大した際に生じる変化に焦点を当てます。

バッチ処理が韓国調達にもたらすもの

1件の取引明細書（거래명세서）を処理することと、50件を処理することの違いは、単なる時間の問題ではありません。それは全く異なるクラスの問題です。

1件の거래명세서（1社、1出荷、1書類）を処理する場合、ワークフローは単純です。PDFを開き、供給者名（공급자）、取引日（거래일자）、品目表を確認します。各行の品目名（품목명）、数量（수량）、単価（단가）、金額（금액）を受入スプレッドシートに入力します。供給価額（공급가액）と税額（세액）を照合ファイルにコピーします。完了です。1枚あたり3分、レイアウトが複雑だったりスキャン品質が悪ければ5分ほどです。

では、これを15社の異なるサプライヤー（それぞれ独自のレイアウト、品目コード体系、印刷品質）から50回行うとします。規模が拡大したときに現れる問題は、単一書類処理では見えません。

• フォーマットの多様性。 サプライヤーAの거래명세서は、Douzone iCUBEで生成された鮮明なPDFで、品目表は標準的なグリッドレイアウトです。サプライヤーBは、手書き伝票をスマートフォンで撮影したもので、数量は余白に走り書きされています。サプライヤーCは、セル結合のあるExcel印刷文書です。書類1で機能した抽出方法が書類2では失敗します。50枚目までには、韓国B2Bサプライチェーンが提供するあらゆるフォーマットのバリエーションに遭遇し、それらすべてを手動で入力していることになります。
• 命名規則。 どの行がどのファイルから来たのかを把握する必要があります。"거래명세서_20260430.pdf"というファイル名からは、サプライヤーに関する情報は何も得られません。同じサプライヤーから月内に3枚の請求書を受け取った場合、各明細行を元の文書に遡って追跡する必要がありますが、ファイル名だけではそのトレーサビリティを維持できません。
• 例外処理。 50枚の書類の中には、空白フィールドに遭遇します。あるサプライヤーは単価の印刷を忘れています。別のサプライヤーはVATセルを空欄のままにしています。スマートフォン写真では、品目表の下部の行が切れています。単一書類処理では、これらにすぐ気づき解決できます。バッチ処理では、例外は書類の山の中に埋もれており、それらを見つけるには、すべての完了行をスキャンする必要があります。
• 出力の統合。 各書類を完全に抽出できたとしても、50個の個別のスプレッドシートができるだけです。実際に必要な成果物（受入チームが求めるもの）は、すべてのサプライヤーの全明細行を含み、日付、サプライヤー、発注番号で並べ替え・フィルタリング可能な単一のテーブルです。

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

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

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

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

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

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

月末の現実：なぜこの問題に期限があるのか

韓国のB2B支払いサイクルは、バッチ処理のプレッシャーを増幅させます。2つの決済パターンが主流です。월말결제（当月月末決済）は、商品が納品された月の末日に支払いが行われ、익월결제（翌月月末決済）は、翌月末に支払いが行われます。どちらの場合も、月内に受け取った거래명세서（取引明細書）が積み重なり、支払い承認前に照合する必要があります。

10～30の取引先と取引のある中規模の韓国メーカーや販売代理店の場合、通常、月に50～200件の取引明細書が届きます。これらは月を通じて（1日あたり数件）到着しますが、照合作業は支払い承認前の最後の3～5営業日という限られた期間に集中します。受入部門は、すべての거래명세서の全明細行をシステムに入力し、発注書と照合し、財務チーム向けの支払いスケジュールを作成する必要があります。

控えめに見積もって50件の書類を処理する場合、その期間の計算は次のようになります。

5.5時間はほぼ丸一日の労働時間に相当します。しかも、これはすべての書類が鮮明で読みやすいPDFで届くことを前提としています。実際には、標準的なA4用紙に印刷されたERP生成のPDF、請求書ソフトを使ったことのない零細な家族経営の仕入先からの手書きの書類、配送ドライバーがKakaoTalkで送信したスマートフォン写真、傾いた状態でスキャンされたコピーなど、さまざまな形式が混在します。形式が異なるたびに作業に手間がかかり、期限に追われる中でその負担はさらに大きくなります。

これこそが、「単に入力を速くする」という対策が20件目あたりで通用しなくなる理由です。本当に問われるのは、個々のフィールドをどれだけ速く入力できるかではなく、すべての書類を一度に、一つのワークフローで、一つの出力にまとめ、各ソースファイルへの明確な監査証跡を残しながら処理できるかどうかです。

一括抽出の仕組み：1つの列定義で全仕入先に対応

一括の거래명세서処理を可能にする核となる仕組みは列名抽出です。つまり、ツールに各フィールドの位置（座標に矩形を描いたり、サンプルレイアウトでモデルを学習させるなど）を指示するのではなく、抽出したいフィールド名を入力して何を探すかを指示します。AIは文書を視覚的に読み取り、フィールド名の意味を理解して各値を特定し、出力テーブルに格納します。仕入先がフィールドをページ上のどこに配置しても関係ありません。

座標ベースの抽出と意味ベースの抽出のこの違いこそが、一括処理を実現可能にします。座標ベースのツールでは、仕入先ごとに個別のテンプレートが必要です。仕入先Aの「数量」フィールドはピクセル位置(400, 320)にあり、仕入先Bでは(380, 450)にあるからです。15社の50件の書類があれば15個のテンプレートが必要で、仕入先が帳票レイアウトを変更するとテンプレートは使えなくなります。意味ベースの抽出ツールに必要なのは1つの列定義だけです。「仕入先名」「取引日付」「品名」「数量」「単価」「供給額」などのフィールド名のリストで、レイアウトに関係なくバッチ内のすべての文書に同じ定義を適用します。

ImageToTable.aiでの一括処理はこの原理に基づいています。50件すべての거래명세서ファイル（PDF、JPGスキャン、PNGスクリーンショット、WebP写真）を一度にアップロードします。出力スプレッドシートに抽出したい列を定義します。AIがすべての文書を読み取り、位置ではなく意味で各フィールドを見つけ、すべての結果を1つの結合されたExcelテーブルにまとめます。各文書が1行（複数行の明細テーブルを含む場合は複数行）になり、要求した各フィールドが列になり、1つのスプレッドシートをダウンロードできます。50個の個別ファイルではありません。

効率の向上は、書類ごとの設定を排除することから生まれます。仕入先ごとに何かを設定する必要はありません。テンプレートを作成する必要も、モデルを学習させる必要もありません。列を一度定義するだけです。「仕入先名（공급자）」「仕入先登録番号（사업자등록번호）」「取引日付（거래일자）」「品名（품목명）」「規格（규격）」「数量（수량）」「単価（단가）」「金額（금액）」「供給額（공급가액）」「税額（세액）」「PO参照番号」— 同じ列セットですべての仕入先のすべての거래명세서を処理します。50ファイル、15社、1つの出力です。

スケール対応の3者照合：発注書 → 거래명세서 → 税額計算書

韓国の調達チームにとって、거래명세서データをスプレッドシートに抽出することは最終目標ではなく、中間ステップです。実際の成果物は3者照合、すなわち発注書（발주서）→取引明細書（거래명세서）→税額計算書（세금계산서）です。

韓国の付加価値税（VAT）制度において、税額計算書（세금계산서）は法的に規制された文書であり、付加価値税法第32条に基づき、供給者および購入者の登録番号、供給価額、VAT額、作成日などの必須項目が定められています。これは購入者が仕入税額控除（매입세액 공제）を受ける権利を付与する文書であり、四半期ごとのVAT申告（1月25日、4月25日、7月25日、10月25日締切）に正確に反映される必要があります。一方、取引明細書にはそのような法的効力はなく、私的な確認文書（사적 증빙）であり、税額控除の対象とはなりません。しかし、実際に商品とともに届き、税額計算書では省略されることの多い品目レベルの詳細情報を記載している文書です。

スケール対応の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のような単純なプレフィックスでも、必要なトレーサビリティが得られます。

これは、単一ドキュメントのチュートリアルでは決して言及されない、バッチ特有の課題の一つです。1つの文書を処理するときは、データの出所がわかります。50を処理するときは、システムが覚えていてくれる必要があります。

多様なフォーマットへの対応：手書きからERP生成まで

韓国のB2B調達におけるフォーマットの多様性問題は、サプライヤーの規模と業種に起因します。蔚山の大手化学サプライヤーは、Douzone iCUBEで生成されたPDFで出荷します。レーザー用紙に印刷され、プロフェッショナルな書式で、すべてのフィールドが予測可能なグリッドに配置されています。一方、仁川の小さな包装資材サプライヤーは、所定のカーボン複写伝票に手書きで거래명세서（取引明細書）を作成し、青い買い手控え（공급받는자용）を切り取って配送ドライバーに渡します。中規模の食品流通業者は、画面上ではプロフェッショナルに見えるExcelテンプレートを使用しますが、印刷するとセル結合によりフィールド境界が重なってしまいます。

従来のOCRは、テキストが予測可能な位置にあることを前提としているため、2番目と3番目のカテゴリでは機能しません。カーボン複写伝票に手書きされた韓国語の文字は、ドライバーの筆跡を考慮する前から低コントラストです。セル結合されたExcel印刷フォームでは、フィールドラベルと値が互いににじみ込むテキストブロックが生成されます。テンプレートベースのシステムでは、フォーマットごとに個別のテンプレートを作成する必要があり、15のサプライヤーが5つの異なるフォーマットタイプを使用している場合、テンプレートのメンテナンスだけで定期的な作業になってしまいます。

列名抽出は、設計上、フォーマットの多様性に対応します。なぜなら、レイアウトに依存しないからです。「数量（수량）」がPDFのグリッド表の3列目にある場合でも、手書きフォームの余白に走り書きされている場合でも、Excelの結合セルに埋め込まれている場合でも、AIは人間と同じようにドキュメントを読み取ることでその位置を特定します。つまり、ピクセル座標ではなく、意味的な意味をスキャンするのです。Douzone PDFで機能する同じ列定義が、手書きのカーボンコピーやExcel印刷物でも機能します。

実用的な限界はあります。人間がテキストを読めないほどぼやけた写真は、AIでも失敗します。しかし、「読み取り可能」の基準は、テンプレートベースのOCRに必要な基準よりも大幅に低くなります。なぜなら、ぼやけていても判読可能なテキストは、ピクセル座標がテンプレートで一致するには不正確であっても、意味的には判読可能だからです。

50件バッチでの例外処理

50件の書類バッチでは、必ず数件に問題が発生します。ある業者は簡易課税事業者のためVAT欄が空白で、別の業者は供給価額を誤ったセルに入力したため、抽出結果が予期しない数字になります。また、スマートフォンで撮影した写真では、10行の明細テーブルの最後の2行が切れてしまうこともあります。

単一書類処理では、書類とデータを同時に確認するため、これらの問題に即座に気づきます。しかしバッチ処理では、書類と抽出データが抽出工程で分離され、例外が400行の結合テーブルに埋もれてしまう可能性があります。

バッチモードでの例外処理のワークフロー：

重要なポイント：バッチ処理は例外をなくすのではなく、その見つけ方を変えます。入力時に1件ずつエラーを発見するのではなく、完全な出力に対して構造化されたチェックを実行し、問題のある書類を特定します。反応的なエラー発見（ミスを犯しながら気づく）から、積極的なエラー検出（出力全体をスキャンして異常を発見する）への移行こそが、バッチ処理を単に高速化するだけでなく、より信頼性の高いものにします。

既存の購買ワークフローへの一括取込の統合

一括 거래명세서 抽出はERPを置き換えるものではありません — また、そうすべきでもありません。ERPは売上記録、請求書発行、NTS送信、財務報告を処理します。一括抽出は、ERPが手入力に委ねているデータ取込ステップを担当します。

統合ポイントはExcel出力です。すべての受信 거래명세서 データを1つのスプレッドシートに抽出し、発注書や税額計算書と照合した後、ERPの標準Excelインポート機能を使用して検証済みデータをインポートします。主要な韓国ERPはすべてこれをサポートしています：DouzoneのSmart AとiCUBEは購買記録のExcel一括インポートを提供します。ECOUNTは거래명세서およびその他の取引書類のExcel一括インポートを提供します。iQuest 얼마에요は매입거래명세표データのExcelアップロードをサポートしています。抽出されたスプレッドシートは、ERPに取り込まれる前に、クリーンで構造化され、検証済みのインポートソースとなります。

海外サプライヤーからの書類も処理するチームにも、同じワークフローが適用されます。中国の部品サプライヤーからの納品書や、欧州の設備ベンダーからのパッキングリストも、同じ抽出ロジック（列を定義し、アップロードし、スプレッドシートを取得する）に従います。書類の言語や形式は変わりますが、列名抽出の原則は変わりません。

よくある質問

一括処理で、手書きと印刷された거래명세서を同じアップロードで処理できますか？

はい。AIは各書類を個別に読み取り、手書きの韓国語文字（様々な筆跡の質を含む）と印刷されたテキストを、同じ意味抽出ロジックで認識します。同じ列定義で両方の形式を処理します。実用的な限界は可読性です。人間が手書きを読めなければ、AIもおそらく読めません。

仕入先の거래명세서で項目名が標準と異なる場合はどうなりますか？

列名の抽出は文字列の一致ではなく、意味理解で値を特定します。数量フィールドのラベルが「수량」（数量）ではなく「출하수량」（出荷数量）でも、AIは両者が同じ概念だと理解するため正しく抽出できます。これがテンプレート一致（失敗する）と意味抽出（適応する）の根本的な違いです。

明細表が複数ページにまたがる거래명세서はどう処理されますか？

複数ページのPDFは1つの文書として処理されます。AIが全ページを読み取り、改ページに関係なく明細表から全明細行を抽出します。出力では全ページの全行が同じ文書のレコードとしてスプレッドシートに統合されます。

特定の注文番号に一致する明細のみ抽出できますか？

抽出工程では全文書の全データを抽出します。注文番号、仕入先、日付範囲などによるフィルタリングは抽出後のスプレッドシートで行います。これにより、抽出を事前に制限するのではなく、完全なデータセットを自由にフィルタリングできます。

거래명세서のデータ抽出は韓国の税務記録保存要件に準拠していますか？

거래명세서自体は私的証憑（사적 증빙）であり、法的に定められた様式はなく、政府機関への提出も不要です。そのデータ抽出や保存に関する特定のコンプライアンス要件はありません。法的なコンプライアンス義務があるのは、付加価値税法第32条に基づく税計算書（세금계산서）であり、これは別途処理されます。税計算書の抽出については一括税計算書処理ガイドをご参照ください。実務上、国税基本法（국세기본법）第85条の3は取引記録の5年間保存を推奨しており、ソースファイルのトレーサビリティがある構造化Excelファイルは、紙の書類の山よりもこの目的に適しています。

韓国の法人税請求書（세금계산서）の一括処理にも対応していますか？

はい、同じ一括抽出ワークフローが適用されます。税務書類の一括処理では、事業者登録番号（사업자등록번호）、供給価額（공급가액）、税額（세액）、承認番号（승인번호）などの列を定義し、100～200枚の税務書類を一度にアップロードして処理できます。抽出の仕組みは同一で、フィールド名が変わるだけです。

韓国のどのERPでも、売上記録から取引明細書を生成できます。ギャップ、そしてチャンスは、受け取り側にあります。一括抽出は、1つの列定義、1回のアップロード、1つのスプレッドシートでそのギャップを埋めます。来月の月末処理でお試しください。5.5時間のタイピングが、15分の確認作業に変わるのを実感してください。