50枚の韓国取引明細書、
1つのスプレッドシート：入力なしのバッチ処理
韓国のどのERPも、販売記録から取引明細書（거래명세서）をワンクリックで生成できます。しかし、それを読み取れるERPは一つもありません。韓国企業間の物理的な出荷に必ず添付されるこの書類 — 品目、数量、単価、供給価額が記載されている — は、キーボードから1項目ずつ調達ワークフローに入ってきます。月末に15社の供給者から50枚を受け取ると、この非対称性は単なる珍事ではなくなり、受領チームが午後10時になってもオフィスに残っている理由になります。
主なポイント
- 韓国のどのERPも販売記録から거래명세서をワンクリックで生成できますが、それを読み取れるものは正確にゼロです。だからこそ受領チームは午後10時になっても入力しているのです。
- 15社の供給者からの50枚の거래명세서は手入力で5.5時間かかりますが、本当の問題は入力速度ではありません — 業界が何十年もかけて送信側の自動化を完璧にし、受信側の抽出をあなたのキーボードに任せてきたことです。
- ImageToTable.aiは1つの列定義で50枚すべての書類を処理します — 供給者ごとのテンプレートも、書類ごとのレビューループも不要 — そしてすべての明細行が元のファイルにたどれる1つのスプレッドシートを提供します。
韓国の取引明細書を初めて扱う方は、まず韓国の取引明細書データをExcelに抽出するガイドをご覧ください。フィールド構造、3ウェイマッチング、テンプレートが機能しない問題を解説しています。本記事では、1件から50件へ、1社のフォーマットから15社のフォーマットへと規模を拡大したときに何が変わるかに焦点を当てます。
韓国の購買業務におけるバッチ処理の実際
取引明細書（거래명세서）を1件処理する場合と50件処理する場合の違いは、単に時間の問題ではありません。まったく別の種類の問題が生じます。
取引明細書を1件処理する場合——供給者1社、出荷1件、ドキュメント1件——ワークフローは単純です。PDFを開き、供給者名（공급자）、取引日（거래일자）、品目テーブルを読み取ります。各行の品目名（품목명）、数量（수량）、単価（단가）、金額（금액）を受領スプレッドシートに入力します。供給価額（공급가액）と税額（세액）を照合ファイルにコピーします。完了です。1件あたり3分、供給者のレイアウトが密だったりスキャン品質が悪ければ5分ほどでしょう。
では、これを50回行ってみてください——15社の供給者から、それぞれ独自のレイアウト、独自の品目コード体系、独自の印刷品質で届きます。規模を拡大して初めて現れる問題は、1件処理では見えません：
- フォーマットの横断。供給者Aの取引明細書はDouzone iCUBEが生成した鮮明なPDFで、品目テーブルは標準的なグリッドレイアウトです。供給者Bのものは手書きフォームをスマホで撮影した写真で、数量は余白に走り書きされています。供給者Cのものはセル結合されたExcel印刷のドキュメントです。ドキュメント1で機能した抽出アプローチが、ドキュメント2では失敗します。ドキュメント50に至るまでには、韓国のB2Bサプライチェーンが持ちうるあらゆるフォーマットのバリエーションに遭遇し、そのすべてを手作業で入力することになります。
- 命名規則。どの行がどのファイルから来たのかを知る必要があります。「거래명세서_20260430.pdf」では供給者がまったく分かりません。同じ供給者から月内に3件の請求書を受け取った場合、各明細行を元のドキュメントまで追跡する必要がありますが、ファイル名だけではその追跡可能性を担保できません。
- 例外処理。50件のドキュメントでは、空欄のフィールドに遭遇します。ある供給者は単価の印刷を忘れ、別の供給者は税額セルを空欄のままにし、スマホ写真では品目テーブルの下部の行が切れていました。1件処理ではこれらにすぐ気づいて解決できます。バッチ処理では、例外は山の中に埋もれてしまい、見つけるには完了したすべての行をスキャンする必要があります。
- 出力のマージ。たとえ各ドキュメントを完璧に抽出できたとしても、50個の別々のスプレッドシートができるだけです。実際の成果物——受領チームが必要とするもの——は、すべての供給者のすべての明細行を1つのテーブルにまとめ、日付、供給者、PO番号で並べ替え・フィルタリングできるようにしたものです。
1件処理はタイピング速度を試します。バッチ処理はシステム設計を試します。ボトルネックは「どれだけ速く入力できるか」から「どこから来たかを把握したまま、どうやってすべてのドキュメントを一度に処理するか」へと移ります——これは根本的に異なる問いです。
Douzone、ECOUNT、iQuestが受信データ抽出を解決できない理由
韓国のERP市場は、送信ドキュメント生成の完成度を高めるために数十年を費やしてきました。その成果は確かに目覚ましいものです。Douzone Bizon（더존비즈온） — 韓国最大のERPプロバイダーで、2025年にスウェーデンのPEファンドEQTに1.3兆ウォンで買収された企業 — は、約2万社の法人顧客が売上記録から取引明細書をワンクリックで生成し、顧客データベースから供給者・購入者欄を自動入力し、WEHAGOとiCUBEを通じて数百件の明細書を一括印刷または一括メール送信できるようにしています。
ECOUNT（이카운트）は、8万社以上の法人顧客に月額一律40,000ウォンでサービスを提供しており、同じモデルを踏襲しています。売上入力 → 取引明細書の自動生成 → マルチチャネル配信（メール、カカオトーク、SMS、FAX）。その購買モジュールでは受信した購買データを記録できますが、データ入力は手動です。受け取ったドキュメントをアップロード → フィールドを自動抽出する経路はありません。
iQuest（아이퀘스트）は、オルマエヨERPの開発元であり、韓国の主要ベンダーで唯一、OCRベースの取引明細書データ抽出を提供しています。モバイルアプリで受け取った取引明細書を撮影すると、AIが供給者情報と品目リストをERPに抽出します。これは真の前進であり、ある意味ではImageToTable.aiが単一ドキュメントに対して行うことに最も近い国内の類似機能です。しかし、その設計上の前提は一度に1ドキュメントです。撮影し、画面上でAI抽出結果を確認し、誤りを修正し、確定し、繰り返す。1回のランチミーティングで1枚の領収書を取得する営業担当者にとっては、これは機能します。月末に15社の供給者から50枚の取引明細書を受け取る購買チームにとっては機能しません。ボトルネックはドキュメントごとの抽出精度ではなく、真のバッチ処理を妨げるドキュメントごとの人手によるレビューループだからです。
キョンナリナラとキョンヨンイジ — シンプルさで韓国の中小企業に人気 — は取引明細書の発行を適切に処理しますが、受信データ抽出は一切提供していません。主要なASPプラットフォームも同様です。Popbill（팝빌）は37万3千以上の登録事業者と3億2,400万件以上の累計ドキュメントを持ち、Barobill（바로빌）は一括発行とホームタックス連携のAPIを提供していますが、その取得機能は自身が発行したドキュメントからデータを取得するものであり、受け取ったPDF、スキャン、写真形式の供給者ドキュメントから構造化データを抽出するものではありません。
このパターンは、韓国のあらゆるERPおよび会計プラットフォームで一貫しています。送信の自動化は解決済みの問題です。受信データ抽出は、製品ロードマップにすら載っていません。購入者がデータを入力するという前提 — 暗黙的でありながら一律に — が存在するのです。
月末の現実：この問題に期限がある理由
韓国のB2B決済サイクルは、バッチ処理のプレッシャーを増幅させます。支配的な決済パターンは2つあります。納品された月の末日に決済される月末決済と、翌月の末日に決済される翌月決済です。どちらの場合も、月中に受け取った取引明細書は山積みになり、支払いを承認する前に照合しなければなりません。
10～30社の取引先を持つ中規模の韓国メーカーや卸売業者では、通常1か月に50～200件の取引明細書が届きます。これらは月中を通じて少しずつ届きますが、照合作業は圧縮された期間、つまり支払い承認前の最後の3～5営業日に集中します。受領部門は、注文書と照合し、経理チーム向けの支払いスケジュールを作成するために、すべての取引明細書の全明細行をシステムに入力する必要があります。
控えめに見積もって50件のバッチを処理する場合の、この期間の計算は次のとおりです。
| タスク | 1件あたり | × 50件 |
|---|---|---|
| 供給者・購買者のヘッダー項目を開いて確認 | 1分 | 50分 |
| 明細行を抽出（1件あたり平均8行） | 3分 | 2.5時間 |
| 供給価額を注文書と照合 | 1分 | 50分 |
| 税計算書（세금계산서）と照合 | 1分 | 50分 |
| 手作業の合計 | 約5.5時間 |
5時間半はほぼ丸1日の作業時間です。しかもこれは、すべてのドキュメントがきれいで判読可能なPDFで届くことを前提としています。実際には、標準A4に印刷されたERP生成のPDF、請求書ソフトを使ったことのない小規模な家族経営の供給者からの手書きフォーム、配送ドライバーが撮影してカカオトークで送信したスマホ写真、傾いたスキャンコピーなどが混在します。フォーマットの違いはそれぞれ手間を増やし、期限に追われているときにはその手間が積み重なります。
だからこそ、ドキュメント20件あたりになると「もっと速く入力すればいい」は答えにならなくなります。本当の課題は、個々の項目をどれだけ速く入力できるかではなく、すべてのドキュメントを一度に、1つのワークフローで、1つの出力にまとめ、各ソースファイルへの明確な監査証跡を保ちながら処理する方法です。
バッチ抽出の仕組み：1つの列定義で全供給者に対応
バッチでの取引明細書処理を可能にする核心的な仕組みは列名抽出です。これは、各フィールドがドキュメント上のどこにあるかをツールに指示する（座標を四角で囲んだり、サンプルレイアウトでモデルを学習させたりする）のではなく、探したいフィールド名を入力して何を探すかを指示する方式です。AIはドキュメントを視覚的に読み取り、フィールド名の意味をセマンティックに理解して各値を特定し、供給者がページ上のどこにそのフィールドを配置したかに関係なく、出力テーブルにデータを入力します。
座標ベースの抽出とセマンティック抽出のこの違いが、バッチ処理を実現可能にします。座標ベースのツールは、供給者ごとのレイアウトに個別のテンプレートを必要とします。供給者Aの「数量」フィールドはピクセル位置(400, 320)にあり、供給者Bのそれは(380, 450)にあるからです。15社の供給者から50件のドキュメントがあれば、15個のテンプレートが必要になり、供給者がフォームレイアウトを変更するとテンプレートは壊れてしまいます。セマンティック抽出ツールは1つの列定義——「供給者名」「取引日」「品目名」「数量」「単価」「供給価額」といったフィールド名のリスト——を必要とするだけで、レイアウトに関係なくバッチ内のすべてのドキュメントに同じ定義を適用します。
ImageToTable.aiのバッチ処理はこの原則で動作します。50件の取引明細書ファイルを一度にアップロードします——PDF、JPGスキャン、PNGスクリーンショット、WebP写真、すべてを1回のアップロードで。出力スプレッドシートに抽出したい列を定義します。AIはすべてのドキュメントを読み取り、位置ではなく意味によってすべてのフィールドを見つけ、すべての結果を1つのマージされたExcelテーブルにまとめます。各ドキュメントは1行になり（複数行の品目テーブルが含まれる場合は複数行）、要求した各フィールドは1列になり、50個の個別ファイルではなく1つのスプレッドシートをダウンロードできます。
ファイルは安全に処理され、保存されません。
効率の倍率効果は、ドキュメントごとの設定を排除することから生まれます。供給者ごとに何かを設定する必要はありません。テンプレートを構築する必要もありません。モデルを学習させる必要もありません。列を一度定義するだけです——「供給者名（공급자）」「事業者登録番号（사업자등록번호）」「取引日（거래일자）」「品目名（품목명）」「規格（규격）」「数量（수량）」「単価（단가）」「金額（금액）」「供給価額（공급가액）」「税額（세액）」「PO参照番号」——そして同じ列セットがすべての供給者からのすべての取引明細書を処理します。50ファイル、15社の供給者、1つの出力。
1ページあたり5～10秒、手入力なら1ドキュメントあたり3分に対し、バッチワークフローは5.5時間の入力作業を約15分の処理に圧縮します。効率は18倍ですが、本当の価値は時間短縮ではありません。出力が1つのマージ済みスプレッドシートとして届き、すべての明細行が元のドキュメントまで追跡可能で、POや税計算書との3ウェイマッチングにすぐ使えることです。
大規模な3ウェイマッチング：PO → 取引明細書（거래명세서） → 税計算書（세금계산서）
韓国の購買チームにとって、取引明細書のデータをスプレッドシートに抽出することは最終目的ではなく、中間ステップです。実際の成果物は3ウェイマッチングです：注文書（발주서） → 取引明細書（거래명세서） → 税計算書（세금계산서）。
韓国の付加価値税の枠組みでは、税計算書（세금계산서）が法的に規制されたドキュメントです。付加価値税法第32条に基づき、供給者と供給を受ける者の事業者登録番号、供給価額、税額、作成日などの必須項目を含みます。これは買い手が仕入税額控除（매입세액 공제）を受けられる根拠となるドキュメントであり、四半期ごとの付加価値税申告（1月25日、4月25日、7月25日、10月25日締切）に正確に反映する必要があります。取引明細書にはそのような法的効力はなく、税額控除の対象とならない私的証憑（사적 증빙）ですが、実際に商品とともに届き、税計算書がしばしば省略する品目レベルの詳細を含むドキュメントです。法的に規制された韓国の税務ドキュメント一式（税計算書、現金領収書、証明書）については、韓国税務ドキュメント抽出の概要でそれぞれの項目セットをまとめています。
大規模な3ウェイマッチングのワークフロー：
PO → 取引明細書：発注内容と納品内容を照合する
各供給者の取引明細書に記載された品目名、数量、単価を、元の注文書と比較します。ここでの不一致 — 数量の相違、未承認の代替品、誤った単価 — は、税計算書を処理する前に必ず検出し解消する必要があります。取引明細書のデータを、各行のPO参照番号を含む列構造に抽出しましょう。
取引明細書 → 税計算書：請求額と納品額が一致するか確認する
税計算書は別途届きます — 多くの場合、商品の数日後、時には月次の一括請求サイクルに添付されて送られてきます。その供給価額（공급가액）と税額（세액）は、取引明細書の合計と一致していなければなりません。ここでマージされたスプレッドシートが威力を発揮します。取引明細書の抽出から1列、税計算書の抽出から1列 — 単純な並べ比較で、別々のドキュメントをまたいだ手作業の照合が不要になります。
税計算書 → 国税庁申告：付加価値税申告の正確性を確認する
税計算書のデータは、取引明細書と照合された後、四半期ごとの付加価値税申告に反映されます。国税庁が供給者の電子申告から保有している内容と、あなたが申告する内容との間に相違があると、相互検証フラグが立ちます。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件を処理するときは、あなたが覚えておかなくて済むように、システムに覚えてもらう必要があります。
アップロード前に確立する命名規則が、あなたの監査証跡になります。[SupplierCode]_[Date]_[DocumentType].pdfのような一貫したパターンは、1ファイルあたり10秒で済み、照合中に不一致が表面化したときの何時間ものファイル名調査を節約します。
フォーマットの多様性への対応：手書きからERP生成まで
韓国のB2B調達におけるフォーマットの多様性問題は、供給者の規模と業界によって決まります。蔚山の大手化学メーカーは、Douzone iCUBEで生成したPDFで商品を出荷します。レーザー用紙に印刷され、専門的に整形され、すべてのフィールドが予測可能なグリッドに収まっています。仁川の小規模な包装資材供給者は、あらかじめ印刷されたカーボン複写式の用紙に取引明細書を手書きし、青色の買い手用控え（供給を受ける者用）を切り取って配送ドライバーに渡します。中規模の食品卸売業者は、画面上では専門的に見えるものの、印刷すると結合セルがフィールドの境界と重なるExcelテンプレートを使用しています。
予測可能な位置にテキストがあることを前提とする従来のOCRは、2番目と3番目のカテゴリでは失敗します。カーボン複写式用紙に手書きされた韓国語の文字は、ドライバーの筆跡を考慮するまでもなく、すでにコントラストが低い状態です。結合セルを含むExcel印刷フォームは、フィールドのラベルと値が互いににじみ合ったテキストブロックを生成します。テンプレートベースのシステムでは、フォーマットごとに個別のテンプレートを構築する必要があります。5種類の異なるフォーマットを使用する15社の供給者がいる場合、テンプレートのメンテナンスだけでも定期的な作業になります。
列名抽出は、レイアウトに依存しない設計のため、フォーマットの多様性に対応します。「数量（수량）」がPDFのグリッド表の3列目にあっても、手書きフォームの余白に走り書きされていても、結合されたExcelセルに埋め込まれていても、AIは人間と同じようにドキュメントを読んでそれを特定します。つまり、ピクセル座標ではなく意味的な内容を探すのです。DouzoneのPDFで機能する同じ列定義が、手書きのカーボン複写やExcelの印刷物でも機能します。
ただし実用的な限界があります。人間が読めないほどぼやけた写真は、AIにとっても失敗します。しかし「読み取り可能」の基準は、テンプレートベースのOCRが要求するものよりも大幅に低くなります。ぼやけていても判読できるテキストは、たとえそのピクセル座標がテンプレートの照合には不正確すぎても、意味的には依然として判読可能だからです。
50件バッチでの例外処理
50件のドキュメントのバッチでは、いくつか問題が発生します。供給者が簡易課税者（간이과세자）であるためにVAT欄を空欄にしているケース。別の供給者が供給価額を誤ったセルに入力したため、抽出結果が予期しない数値になるケース。スマートフォンで撮影した写真で10行の品目テーブルの最後の2行が切れているケースなどです。
単一ドキュメント処理では、ドキュメントとデータを同時に確認できるため、こうした問題にすぐ気づきます。しかしバッチ処理では、ドキュメントと抽出データが抽出ステップによって分離され、例外が400行のマージされたテーブルの中に隠れてしまうことがあります。
バッチモードで例外を処理するワークフローは次のとおりです。
必須列の空白をスキャンする
抽出後、出力スプレッドシートで重要な列（供給者名、供給価額、数量）の空セルをフィルタリングします。数量が空白の場合、通常は品目行が見落とされたか、ドキュメントに数量フィールドが含まれていなかったことを意味します。いずれにせよ、確認が必要です。
合計をドキュメント単位の合計値と照合する
取引明細書の供給価額（공급가액）は、すべての明細金額の合計です。抽出した明細金額の合計が抽出した供給価額と一致しない場合、明細が見落とされたか、供給価額が誤って読み取られたことになります。このクロスチェックにより、すべてのドキュメントを再確認することなく、抽出漏れを検出できます。
問題のあるドキュメントを個別に再処理する
特定のドキュメントで信頼できない結果が生じた場合（必須フィールドの空白や合計の不一致で検出）、そのドキュメントを個別に再アップロードして2回目の抽出を行います。バッチワークフローでは、1件のドキュメントのエラーを修正するためにバッチ全体を再処理する必要はありません。
重要なポイント：バッチ処理は例外をなくすものではなく、例外の発見方法を変えるものです。入力しながら1件ずつエラーを見つける代わりに、完全な出力に対して構造化されたチェックを実行し、問題のあるドキュメントを特定します。受動的なエラー発見（入力中にミスを見つける）から能動的なエラー検出（完全な出力をスキャンして異常を探す）への移行が、バッチ処理を単に高速にするだけでなく、より信頼性の高いものにします。
既存の購買ワークフローへのバッチ抽出の統合
バッチ取引明細書抽出は、ERPを置き換えるものではありませんし、そうすべきでもありません。ERPは売上記録、送信請求書の生成、国税庁への送信、財務報告を処理します。バッチ抽出は、ERPがキーボード入力に委ねているデータ取り込みステップを処理します。
統合ポイントはExcel出力です。受信したすべての取引明細書データを1つのスプレッドシートに抽出し、POや税計算書と照合してから、ERPの標準的なExcelインポート機能を通じて検証済みデータをインポートします。主要な韓国ERPはすべてこれをサポートしています。DouzoneのSmart AとiCUBEは購買記録向けのExcelバッチインポートを提供しています。ECOUNTは取引明細書やその他の取引書類のExcel一括インポートを提供しています。iQuestオルマエヨは仕入取引明細表データのExcelアップロードをサポートしています。抽出されたスプレッドシートがインポート元となり、ERPに触れる前にクリーンで構造化され、検証済みの状態になります。
海外の供給者からの書類も処理するチームにも、同じワークフローが適用されます。中国の部品供給者からの納品書や、ヨーロッパの機器ベンダーからのパッキングリストも、同じ抽出ロジックに従います。列を定義し、アップロードし、スプレッドシートを取得します。書類の言語とフォーマットは変わりますが、列名抽出の原則は変わりません。
これはオールインワンERPの約束とは根本的に異なります。財務システムを置き換えるのではありません。すべての韓国ERPが開けたままにしている1つのギャップを埋めるのです。供給者の書類が、どのようなフォーマットで届いても、ERPの記録になる前にスプレッドシートの行になる必要がある、その瞬間です。
FAQ
バッチ処理は、手書きと印刷された取引明細書（거래명세서）を同じアップロードで処理できますか？
はい。AIは各書類を個別に読み取り、手書きの韓国語文字（さまざまな手書き品質を含む）と印刷テキストを同じ意味抽出ロジックで認識します。同じ列定義が両方のフォーマットを処理します。実用的な限界は判読性です。人間が読めない手書き文字は、AIもおそらく読めません。
供給者の取引明細書（거래명세서）が非標準のフィールド名を使用している場合はどうなりますか？
列名抽出はテキスト文字列を照合するのではなく、意味理解によって値を特定します。数量フィールドを「수량」（数量）ではなく「출하수량」（出荷数量）とラベル付けしている供給者のフォームでも、AIは両方のラベルが同じ概念を指すことを理解するため、正しく抽出されます。これがテンプレートマッチング（失敗する）と意味抽出（適応する）の根本的な違いです。
品目テーブルが複数ページにまたがる取引明細書（거래명세서）はどのように処理されますか？
複数ページのPDFは1つのドキュメントとして処理されます。AIはすべてのページを読み取り、ページ区切りに関係なく品目テーブルからすべての明細行を抽出します。出力は、すべてのページのすべての行をスプレッドシート内の同じドキュメントのレコードに統合します。
特定の明細行のみを抽出できますか？例えば、特定のPO番号に一致する品目のみなど。
抽出ステップでは、すべてのドキュメントからすべてのデータを抽出します。PO番号、供給者、日付範囲、その他の基準によるフィルタリングは、抽出後の出力スプレッドシートで行います。これにより、事前に抽出をサブセットに制限するのではなく、完全なデータセットを操作し、必要に応じてフィルタリングできます。
取引明細書（거래명세서）のデータ抽出は、韓国の税務記録保持要件に準拠していますか？
거래명세서自体は私的証憑（사적 증빙）であり、法的に義務付けられた形式はなく、いかなる政府機関にも提出されません。そのデータの抽出方法や保存方法を規定する特定のコンプライアンス要件はありません。付加価値税法第32条に基づく税計算書（세금계산서）が法的コンプライアンス義務を負う文書であり、別途処理されます。税計算書の抽出については、バッチ税計算書処理ガイドをご覧ください。実務上、国税基本法（국세기본법）第85条の3は取引記録を5年間保持することを推奨しており、ソースファイル名の追跡可能性を備えた構造化されたExcelファイルは、紙のフォームの山よりもこの目的に適しています。
韓国の税計算書（세금계산서）のバッチ処理にも対応していますか？
はい — 同じバッチ抽出ワークフローが適用されます。税計算書のバッチ処理では、事業者登録番号（사업자등록번호）、供給価額（공급가액）、税額（세액）、承認番号（승인번호）などの列を定義し、1回のアップロードで100〜200件の税計算書を処理できます。抽出の原理は同一で、変わるのはフィールド名だけです。
韓国のERPはどれも、売上記録から取引明細書を生成できます。欠けているもの — そしてチャンス — は受け取り側にあります。バッチ抽出は、1つの列定義、1回のアップロード、1つのスプレッドシートでそれを埋めます。次の月末バッチで試してみてください。5.5時間の入力が15分の確認作業になるかどうか、確かめてみましょう。