韓国取引明細書をExcelに
抽出する方法

韓国取引明細書の実際の内容

取引明細書（거래명세서）は、韓国の企業間で貨物に添付される書類です。税法上の法的規制対象であり、国税庁に送信される韓国付加価値税法第32条に基づく税計算書（세금계산서）とは異なり、거래명세서には必須フォーマットがありません。これは私的証憑（사적 증빙）であり、仕入税額控除の対象外、政府機関への提出義務なし、法律上の要件もありません。

この規制の空白が抽出問題を生み出します。標準形式がないため、各供給業者が独自のレイアウトを設計します。仁川の包装資材サプライヤーからの取引明細書は買い手情報を左上に、品目表を中央下部に配置します。浦項の鉄鋼販売会社からのものは、会社印（직인）をヘッダー全体に押し、品目行を横向きに配置します。どちらも間違いではありません — 基準となるテンプレートが存在しないからです。

典型的な거래명세서には以下のフィールドが含まれます：

この書類は通常、複写式で発行されます：供給者用（공급자용）の赤色コピーと買い手用（공급받는자용）の青色コピーです。購買業務フローでは、物理的な出荷物とともに届きます。受入チームは、発注書および実際の商品と照合し（3ウェイマッチングと呼ばれるプロセス）、後日届く税計算書に基づく支払いを承認します。

ECOUNT（이카운트）、Douzone（더존）、iQuestの얼마에요などの韓国ERPシステムでは、取引明細書は通常、販売記録から自動生成されます — これは出荷側では解決済みの問題です。問題が生じるのは入荷側です：これらの同じシステムは、自社の供給業者から受け取る取引明細書のデータを取り込むネイティブな方法を提供していません。

テンプレート方式のツールが거래명세서に対応できない理由

ほとんどの文書抽出ツールは、座標ベースのテンプレートか学習モデルのいずれかの原理で動作します。座標ベースのシステムでは、フィールドの周りに矩形を描画します。「仕入先名は (120, 340) にある」といった具合です。そしてツールはその領域に表示されたテキストを読み取ります。学習モデル方式では、10～50枚のサンプル文書にアノテーションを付けて、各フィールドが通常どこに現れるかをモデルに学習させます。

どちらのアプローチも、거래명세서では同じ理由で機能しません。「通常」の位置が存在しないからです。この文書には標準的なレイアウトがないため、座標やフィールドの位置は仕入先ごとに異なります。仕入先Aの取引明細書でモデルを学習させても、仕入先Bのフォーマットでは失敗します。学習セットに仕入先Bのフォーマットを追加しても、仕入先Cのレイアウトが新たな失敗要因をもたらします。これは学習データの問題ではなく、テンプレートに依存した抽出と、そもそもテンプレートを前提としていない文書タイプとの間の構造的なミスマッチです。

その代替となるのがセマンティック抽出です。ツールに「どこを」見るかを指示する代わりに、「何を」探すかを指示します。「品名」「数量」「単価」「供給額」など、必要な列名を入力します。するとAIが文書を視覚的に読み取り、ページ上の位置ではなく意味を理解することで各フィールドを特定します。列名抽出と呼ばれるこのアプローチでは、1つの列定義で、レイアウトや向き、仕入先名が左上にあるか中央にあるかヘッダーブロックに埋め込まれているかに関わらず、あらゆる仕入先の取引明細書を処理できます。

この違いが重要なのは、代替手段である仕入先ごとに個別のテンプレートを維持する方法がスケールしないからです。仕入先が3社なら機能しますが、30社になるとテンプレートライブラリの管理自体が管理業務になります。列名抽出はそのメンテナンスを完全に不要にします。同じ列定義が1社目の文書でも30社目の文書でも機能します。

ステップバイステップ：取引明細書データをExcelに抽出

取引明細書PDFを受け取ってから、スプレッドシートに構造化データを出力するまでの全ワークフローです。各ステップは1アクションで完了します。座標の指定、モデルのトレーニング、サプライヤーごとの設定は一切不要です。

抽出エンジンは各フィールドを意味で読み取ります。サプライヤー登録番号（사업자등록번호）はハイフン付きの10桁パターンで、供給価額（공급가액）は数量・単価列との位置関係で、品目名（품목명）は明細テーブル内の文脈で認識します。これが、光学文字認識とビジュアル言語理解の違いです。前者はテキストを読み、後者は書類を読み取ります。

このアプローチの仕組みを詳しく知りたい方は、列名で特定フィールドを抽出する方法のガイドをご覧ください。

3ウェイマッチング：発注書 vs 取引明細書 vs 税計算書

取引明細書から単独でデータを抽出するのも有用ですが、購買照合サイクルの一部として抽出することで、真の業務効率化が実現します。標準的な韓国の購買ワークフローは、発注書（발주서）を仕入先に送付 → 商品と共に取引明細書（거래명세서）が納品 → 検収 → 税計算書（세금계산서）が発行され国税庁に送信 → 支払い、という流れです。

検収段階では、3ウェイマッチングが行われます。発注内容（発注書）、納品内容（取引明細書）、請求内容（税計算書）を照合します。検収時に不一致が見つかれば電話一本で済みますが、月末の照合で発覚すると、納品記録や仕入先メール、ERP画面を遡るのに何時間も費やすことになります。

各書類が照合に提供するデータは以下の通りです。

ボトルネックは中央の列です。取引明細書のデータはほとんどデジタル化されていません。箱にクリップで留められた紙、または納品通知メールに埋もれたPDF添付ファイルとして届きます。このデータが、ERPからの発注書データや国税庁システムからの税計算書データと同じフォーマットのスプレッドシート形式にならない限り、3ウェイマッチングの自動化は不可能です。

取引明細データをExcelに抽出した後、計算列を使用して出力内で直接照合を行うことができます。差異: 発注数量 vs 納品数量 (PO数量 - 数量)のような列を定義すると、AIが抽出時に明細ごとに差を自動計算します。ゼロ以外の差異がある行は、スプレッドシートを開く前にフラグが立てられます。同じ抽出パイプラインで発注書を処理する場合は、POデータをExcelに抽出することも可能で、両方の文書タイプを同じ構造化形式にして直接比較できます。

並行したシナリオとして、特に税額請求書データの抽出については、韓国税額請求書データのExcel抽出ガイドをご参照ください。このガイドでは、7つの必須項目と四半期ごとのVAT申告ワークフローについて説明しています。VAT報告のために大量の請求書を処理する場合は、バッチ税額請求書処理ガイドでスループット面をカバーしています。

バッチ処理：日次納品明細書の処理

個別抽出は文書単位の問題を解決します。バッチ処理は日次ボリュームの問題を解決し、設定作業を繰り返す必要はありません。

上記ステップ2で作成した列定義は、特定の文書に依存しません。これは必要なフィールドを記述するものであり、それらのフィールドがどこに現れるかを指定するものではありません。つまり、15の異なるサプライヤーからの20件の取引明細書を、すべて異なるレイアウトであっても、1つのバッチでアップロードできます。同じ列定義がすべての文書に適用され、出力は1つの統合スプレッドシートとなり、各明細が1行を占め、同じ文書のすべての行にサプライヤー名と日付が入力されます。

一貫して紙の明細書と納品書を送付するサプライヤーには、収集リンク（수집 링크）を使用してデジタル化の工程を上流に移行できます。サプライヤーのログイン不要の共有可能なURLを生成し、サプライヤーオンボーディングの指示に含めます。サプライヤーはスマートフォンでリンクを開き、短い確認コードを入力して、取引明細書の写真またはPDFを直接処理キューにアップロードします。文書はデジタル化された状態で届き、チームは再入力ではなくデータを抽出するだけです。これは、韓国領収書抽出ガイドで説明されているのと同じメカニズムを、B2B調達のコンテキストに適応させたものです。

取引明細書を他の納品書類と一緒にバッチ処理する場合、抽出ワークフローは同じです。列を一度定義し、すべてをアップロードし、1つのスプレッドシートをダウンロードするだけです。納品書抽出ツールは、同じ出荷に取引明細書が添付されることの多い、運送会社発行の納品伝票についても同様のパターンをカバーしています。

よくある質問

次のステップ

韓国のB2B文書インフラの課題は発行側ではありません。ECOUNT、Douzone、NTS e-Taxシステムはすでに税額計算書を完全にデジタル化しています。課題は受領側、つまりサプライヤーから送られてくる、機械読み取りを想定していない文書にあります。取引明細書は、購買照合、入庫処理、支払承認という、下流の財務チームが依存する3つのワークフローに関わるため、その課題の中心に位置します。

この課題を解決するのに、サプライヤーの文書発行方法を変える必要はありません。必要なのは、届いた文書をチームが処理する方法を変えることです。かつて受領ログへの再入力に8分かかっていた取引明細書も、数秒で抽出できます。しかも、同じ列定義が、明日、別のサプライヤーから別の形式で届く明細書にもそのまま使えます。