韓国取引明細書を
Excelに抽出する方法
韓国では、NTS e-Taxシステムを通じて年間6億件以上の電子税計算書が処理されています。しかし、実際にすべての物理的な出荷に添付される書類、すなわち取引明細書（거래명세서）は、デジタル上の盲点となっています。法的に定められた形式はなく、政府のシステムに送信されることもありません。週に40件もの取引明細書を20社の異なる供給者から受け取る調達チームにとって、それらはすべてPDF、印刷物、またはスマートフォンで撮影された写真として届き、レイアウトはさまざまで、同じ品目レベルのデータを同じ受入スプレッドシートに抽出する必要があります。
このガイドでは、韓国の取引明細書に実際に含まれる内容、従来のOCRツールが苦手とする理由、そしてあらゆる供給者の取引明細書（거래명세서）から明細データをExcelに抽出する方法について説明します。一度の処理で、供給者ごとの設定は不要です。
重要ポイント
- 韓国のNTSシステムでは毎年6億件の電子税計算書が処理されていますが、実際に出荷ごとに受け取る取引明細書（거래명세서）は、そのシステムの完全に外側にあり、法的に定められた形式もデジタル送信経路もありません。
- ボトルネックは韓国語の文字認識ではありません。法律で定められていないため、すべての供給者が独自のレイアウトを設計しています。テンプレートベースの抽出は一貫したフォーマットを前提としていますが、2社目の供給者から書類が届いた時点でその前提は崩れます。
- 「供給者名」「品目名」「数量」「単価」という単一の列定義があれば、位置ではなく意味に基づいてあらゆる取引明細書（거래명세서）を読み取ることができます。ImageToTable.aiは、供給者が項目を配置した場所に依存するのではなく、書類の内容を解読することでフィールドを特定します。
韓国取引明細書の実際の内容
取引明細書（거래명세서）は、韓国の企業間で貨物とともに送付される書類です。税法上の法的規制対象であり、国税庁に送信される韓国付加価値税法第32条に基づく税計算書（세금계산서）とは異なり、거래명세서には強制フォーマットがありません。これは私的証憑（사적 증빙）であり、仕入税額控除の対象外、政府機関への提出義務なし、法律上の要件もありません。
この規制の空白が抽出問題を生み出しています。標準フォーマットが存在しないため、各サプライヤーが独自のレイアウトを設計します。仁川の包装資材サプライヤーからの取引明細書は買い手情報を左上に、品目表を中央下部に配置します。浦項の鉄鋼ディストリビューターからのものは、会社印（직인）をヘッダー全体に押し、品目行を横向きに配置します。どちらも間違いではありません — 基準となるテンプレートがないからです。
一般的な거래명세서には以下の項目が含まれます：
| 項目 | 韓国語名 | 目的 |
|---|---|---|
| サプライヤー情報 | 공급자 | 事業者名、登録番号、住所、連絡先 |
| 買い手情報 | 공급받는자 | 受取事業者名、登録番号、住所 |
| 取引日 | 거래일자 | 商品納品日 |
| 品目名 | 품목명 | 納品品目の名称またはコード |
| 規格 | 규격 | 寸法、型番、グレード |
| 数量 | 수량 | 納品単位数 |
| 単価 | 단가 | 単価 |
| 金額 | 금액 | 行合計（수량 × 단가） |
| 供給価額 | 공급가액 | 全行金額の合計（VAT除く） |
| 税額 | 세액 | 付加価値税（供給価額の10%） |
| 備考 | 비고 | 追加メモ — 納品条件、分割出荷フラグ、発注書参照 |
この書類は通常、サプライヤー用（공급자용）の赤色コピーと買い手用（공급받는자용）の青色コピーの2部で発行されます。購買ワークフローでは、物理的な出荷とともに届きます。受入チームは、発注書および実際の商品と照合し（3ウェイマッチングと呼ばれるプロセス）、後日送付される税計算書に基づく支払いを承認します。
ECOUNT（이카운트）、Douzone（더존）、iQuestの얼마에요などの韓国ERPシステムでは、取引明細書は通常、販売記録から自動生成されます — これは出荷側では解決済みの問題です。問題が生じるのは入荷側です：これらの同じシステムは、自社のサプライヤーから受け取る取引明細書のデータを取り込むネイティブな方法を提供していません。
テンプレートベースのツールが取引明細書（거래명세서）を処理できない理由
ほとんどの文書抽出ツールは、座標ベースのテンプレートか学習済みモデルのいずれかの原理で動作します。座標ベースのシステムでは、フィールドの周りに矩形を描画します — 「供給者名は (120, 340) にある」 — そしてツールはその領域に表示されたテキストを読み取ります。学習済みモデルシステムでは、10～50枚のサンプル文書にアノテーションを付けて、各フィールドが通常どこに現れるかをモデルに学習させます。
どちらのアプローチも、取引明細書（거래명세서）では同じ理由で機能しません。「通常」の位置が存在しないからです。この文書には標準的なレイアウトがないため、座標やフィールドの位置は供給者ごとに異なります。供給者Aの取引明細書でモデルを学習させても、供給者Bの形式では失敗します。供給者Bの形式を学習セットに追加しても、供給者Cのレイアウトが新たな失敗モードを生み出します。これは学習データの問題ではなく、テンプレートに依存した抽出と、そもそもテンプレートに依存するように設計されていない文書タイプとの間の構造的なミスマッチです。
その代替案がセマンティック抽出です。ツールにどこを見るかを指示する代わりに、何を探すかを指示します。「品目名」「数量」「単価」「供給価額」など、必要な列名を入力するだけで、AIが文書を視覚的に読み取り、ページ上の位置ではなく意味を理解して各フィールドを特定します。列名抽出と呼ばれるこのアプローチでは、1つの列定義で、レイアウトや向き、供給者名が左上にあるか中央にあるかヘッダーブロックに埋め込まれているかに関係なく、すべての供給者の取引明細書を処理できます。
この違いが重要なのは、代替案である供給者ごとに個別のテンプレートを維持する方法がスケールしないからです。3社の供給者をオンボーディングする分には問題ありませんが、30社になるとテンプレートライブラリの維持自体が管理業務になります。列名抽出はそのメンテナンスを完全に不要にします。同じ列定義が1社目の文書でも30社目の文書でも機能します。
テンプレートベースのOCRは文書レイアウトが一貫していることを前提とします。列名抽出はそうではないことを前提とします — そして、法的に定められた形式を持たない韓国のB2B文書にとって、これが正しい前提です。
ステップバイステップ：取引明細書（거래명세서）データをExcelに抽出する
取引明細書のPDFを受け取ってから、構造化されたデータをスプレッドシートで利用できるようになるまでの完全なワークフローをご紹介します。各ステップは1つのアクションです。座標の指定、モデルのトレーニング、サプライヤーごとの設定は一切必要ありません。
抽出エンジンは各フィールドを意味で読み取ります。事業者登録番号（사업자등록번호）はハイフン付きの10桁パターンで、供給価額（공급가액）は数量や単価の列との位置関係で、品目名（품목명）は品目テーブル内のコンテキストで認識します。これが、光学式文字認識とビジュアル言語理解の違いです。前者はテキストを読み、後者は文書を読みます。
このアプローチの背後にある仕組みの詳細については、列名による特定フィールドの抽出に関するガイドをご覧ください。
ファイルは安全に処理され、保存されることはありません。
3ウェイマッチング：発注書 vs 取引明細書（거래명세서） vs 税計算書（세금계산서）
取引明細書からデータを抽出するだけでも有用ですが、これを調達照合サイクルの一部として活用することで、真の業務効率化が実現します。韓国の標準的な調達ワークフローは、発注書（발주서）を仕入先に送付 → 商品と共に取引明細書（거래명세서）が納品される → 検収を実施 → 税計算書（세금계산서）が発行されNTSに送信 → 支払い、という流れで進行します。
検収段階での業務は3ウェイマッチングです。発注内容（PO）、納品内容（거래명세서）、請求内容（세금계산서）を照合します。検収時に差異を発見できれば電話一本で解決できますが、月末の照合時に見つかると、納品記録や仕入先メール、ERP画面を遡って確認するのに何時間も費やすことになります。
各書類が照合に提供するデータは以下の通りです。
| 書類 | 提供元 | 照合用の主要項目 |
|---|---|---|
| 発注書（발주서） | 貴社ERP | 発注数量、合意単価、希望納期 |
| 取引明細書（거래명세서） | 仕入先（紙/PDFで納品時に添付） | 納品数量、品目名、明細上の単価 |
| 税計算書（세금계산서） | 仕入先（NTS電子税計算書経由） | 請求数量、請求単価、供給価額、付加価値税、NTS承認番号 |
ボトルネックは中央の列です。取引明細書のデータはほとんどデジタル化されていません。段ボールにクリップで留められた紙、または納品通知メールに添付されたPDFとして届きます。このデータが、ERPからの発注書データやNTSシステムからの税計算書データと同じ形式でスプレッドシート化されない限り、3ウェイマッチングの自動化は実現できません。
取引明細書のデータがExcelに抽出されれば、計算列を使用して出力内で直接照合を行うことができます。差異：発注数量 vs 納品数量（PO数量 - 数量）のような列を定義すると、AIが抽出時に明細行ごとに差額を計算します。差異がゼロでない行は、スプレッドシートを開く前の段階でフラグが立てられます。同じ抽出パイプラインで発注書も処理する場合は、発注書データをExcelに抽出することも可能で、両方の書類を同じ構造化形式に変換して直接比較できます。
税計算書データの抽出に特化した並行シナリオについては、韓国税計算書データをExcelに抽出するガイドをご参照ください。このガイドでは、7つの必須項目と四半期ごとの付加価値税申告ワークフローを解説しています。大量の請求書を付加価値税報告用に処理する場合は、バッチ税計算書処理ガイドで処理能力面をカバーしています。
バッチ処理：日々の取引明細書の処理
個別抽出は文書単位の問題を解決します。バッチ処理は日々のボリューム問題を解決します。しかも、設定作業を繰り返す必要はありません。
上記ステップ2で作成した列定義は、特定の文書に依存しません。これは、必要なフィールドを記述するものであり、それらのフィールドがどこにあるかを記述するものではありません。つまり、15社の異なる供給者からの20件の取引明細書を、すべて異なるレイアウトであっても、1つのバッチでアップロードできます。同じ列定義がすべての文書に適用されます。出力は1つの統合スプレッドシートで、各明細書のすべての明細項目が1行を占め、同じ文書のすべての行に供給者名と日付が入力されます。
週に30件の取引明細書を受け取る購買チームは、手動データ入力の約3～4時間を節約できます。購買担当者の推定時給が18,000～25,000ウォンの場合、この1つのワークフロー変更だけで月額22万～40万ウォンの節約になります。この数字には、排除されたエラー修正時間は含まれておらず、実際には入力時間自体と同等かそれを上回る可能性があります。
一貫して紙の明細書を納品と一緒に送ってくる供給者の場合、コレクションリンク（수집 링크）を使用すると、デジタル化のステップを上流に移行できます。共有可能なURLを生成し（供給者のログインは不要）、供給者オンボーディング手順に含めます。供給者はスマートフォンでリンクを開き、短い確認コードを入力し、取引明細書の写真またはPDFを直接処理キューにアップロードします。書類は既にデジタル化された状態で到着し、チームは再入力する代わりにデータを抽出します。これは、韓国領収書抽出ガイドで説明されているのと同じメカニズムで、B2B購買のコンテキストに適応させたものです。
取引明細書を他の納品書類と一緒にバッチ処理する場合、抽出ワークフローは同じです。列を一度定義し、すべてをアップロードし、1つのスプレッドシートをダウンロードするだけです。納品書抽出ツールは、同じ荷物に取引明細書が同封されていることの多い、運送会社発行の納品伝票についても同じパターンをカバーしています。
よくある質問
取引先ごとに取引明細書のフォーマット設定が必要ですか？
いいえ。列名抽出は、位置ではなく意味でフィールドを特定します。同じ列定義（供給者名、品目名、数量、単価、供給価額）がすべての取引先のレイアウトで機能します。AIが文書を視覚的に読み取り、取引先がページ上のどこに配置したかに関係なく、各フィールドが何を表すかを理解するからです。
手書きの取引明細書も処理できますか？
はい、印刷されたテンプレート形式に手書きで記入されたものは処理可能です。これは韓国の物流で最も一般的な紙の形式で、取引先が白紙の거래명세서テンプレートを印刷し、数量や日付を手書きで記入します。印刷された構造がなく完全に手書きの文書はより難しく、精度は低くなります。システムは印鑑（직인）や署名を視覚要素として扱います。存在を検出することはできますが、そこからテキストを抽出することはありません。
供給価額（공급가액）と税額（세액）はどのように区別しますか？
AIは文書の意味的な階層を理解します。공급가액はVAT前の合計金額です。세액は通常、その金額の10%（韓国のVAT税率）です。両方の列を定義すると、AIはそれらの関係を利用して抽出を検証します。検出された공급가액の値が세액との期待される関係と一致しない場合、システムはフラグを立てます。VAT検証（세액 / 공급가액）のような計算列を定義して、各行の比率を出力することもできます。
Excelではなく、ECOUNTやDouzoneにデータを抽出できますか？
直接の出力形式はExcel（XLSX）、CSV、またはJSONです。ECOUNTとDouzoneはどちらも取引データのExcelインポートをサポートしています。XLSXとしてエクスポートし、お使いのERPのインポート機能を使用してデータを読み込んでください。Excel出力の列名は、お使いのERPのインポートフィールド名に合わせて設定できるため、マッピング作業を省くことができます。
韓国語と英語のフィールドが混在する文書はどうですか？
AIは両方の言語を読み取ります。多くの韓国の取引明細書には、特に輸入品や多国籍サプライチェーンの場合、韓国語の説明とともに英語の品目名が含まれています。出力に必要な言語で列を定義してください。AIはソース文書の言語に関係なく、対応する値を見つけ出します。
次のステップ
韓国のB2B文書インフラの課題は発行側ではありません。ECOUNT、Douzone、NTS e-Taxシステムはすでに税額計算書を完全にデジタル化しています。課題は受領側、つまりサプライヤーから送られてくる、機械読み取りを想定していない文書にあります。取引明細書は、購買照合、入庫処理、支払承認という、下流の財務チームが依存する3つのワークフローに関わるため、その課題の中心に位置します。
この課題を解決するのに、サプライヤーの文書発行方法を変える必要はありません。必要なのは、届いた文書をチームが処理する方法を変えることです。かつて受領ログへの再入力に8分かかっていた取引明細書も、数秒で抽出できます。しかも、同じ列定義が、明日届く別のサプライヤーからの異なるフォーマットの明細書にもそのまま使えます。