韓国の取引明細書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 시장은 수십 년간 매출 문서 생성 자동화에 투자해 왔으며, 그 결과는 인상적입니다. 더존비즈온 — 2025년 스웨덴계 사모펀드 EQT에 1.3조 원에 인수된 국내 최대 ERP 기업 — 은 WEHAGO와 iCUBE를 통해 약 2만 개의 기업 고객이 판매 기록에서 거래명세서를 한 번에 생성하고, 거래처 DB에서 공급자·구매자 정보를 자동 입력하며, 수백 건의 명세서를 일괄 인쇄·메일 발송할 수 있습니다.

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

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

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

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

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

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

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

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

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

スケールする3ウェイマッチング：PO → 取引明細書（거래명세서）→ 税計算書（세금계산서）

韓国の購買チームにとって、取引明細書（거래명세서）のデータをスプレッドシートに抽出することは最終目標ではなく、中間ステップです。実際の成果物は、注文書（발주서）→ 取引明細書（거래명세서）→ 税計算書（세금계산서）の3ウェイマッチングです。

韓国の付加価値税（VAT）制度において、税計算書（세금계산서）は法的に規制された文書であり、付加価値税法第32条に基づき、供給者と購入者の事業者登録番号、供給価額、付加価値税額、作成日などの必須項目が定められています。この文書により購入者は仕入税額控除（매입세액 공제）を受ける権利を得、四半期ごとの付加価値税申告（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は売上記録、送り状の生成、国税庁への送信、財務報告を処理します。バッチ抽出は、ERPが手入力に委ねているデータ取り込みステップを担当します。

統合ポイントはExcel出力です。すべての受信取引明細書データを1つのスプレッドシートに抽出し、POや税計算書と照合した後、検証済みデータをERPの標準Excelインポート機能を通じて取り込みます。韓国の主要ERPはすべてこれをサポートしています。DouzoneのSmart AとiCUBEは、購買記録のExcel一括インポートを提供しています。ECOUNTは、取引明細書やその他取引書類のExcel一括インポートを提供しています。iQuestのオルマエヨERPは、매입거래명세표データのExcelアップロードをサポートしています。抽出されたスプレッドシートは、ERPに取り込まれる前に、クリーンで構造化され、検証済みのインポート元となります。

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

FAQ

バッチ処理では、手書きと印刷された取引明細書（거래명세서）を同じアップロードで処理できますか？

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

供給者の取引明細書（거래명세서）で標準的でないフィールド名が使用されている場合はどうなりますか？

列名の抽出はテキスト文字列と一致させるのではなく、意味理解によって値を特定します。数量フィールドのラベルが「수량」（数量）ではなく「출하수량」（出荷数量）となっている供給者の場合でも、AIは両方のラベルが同じ概念を指していると理解するため、正しく抽出されます。これがテンプレートマッチング（失敗する）と意味抽出（適応する）の根本的な違いです。

明細項目のテーブルが複数ページにまたがる取引明細書（거래명세서）はどのように処理されますか？

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

特定の明細項目のみ、たとえば特定のPO番号に一致する項目のみを抽出することはできますか？

抽出ステップでは、すべての文書からすべてのデータを抽出します。PO番号、供給者、日付範囲、またはその他の基準によるフィルタリングは、抽出後に出力スプレッドシートで行います。これにより、抽出を事前にサブセットに制限するのではなく、操作およびフィルタリング可能な完全なデータセットを利用できます。

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

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

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

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

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