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

韓国の取引明細書に実際に含まれるもの

取引明細書（거래명세서、文字通り「取引詳細文書」）は、韓国の企業間で出荷に同行する文書です。税法で規制され、国税庁に送信される韓国付加価値税法第32条に基づく法的規制文書である税計算書（세금계산서）とは異なり、取引明細書には必須形式がありません。これは私的証明文書（사적 증빙）であり、仕入税額控除の対象外で、政府機関への提出義務も法的要件もありません。法的に規制される韓国文書ファミリー（税計算書、現金領収書、証明書）については、韓国税計算書抽出の概要で必須項目のある形式を説明しています。

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

典型的な取引明細書には以下の項目が含まれます：

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

韓国のERPシステム、ECOUNT（イカウント）、Douzone（ドゾン）、iQuestの얼마에요では、取引明細書は通常、売上記録から自動生成されます。これは出荷側では解決済みの問題です。問題が発生するのは仕入側です。これらのシステムには、自社の供給者から受け取る取引明細書のデータを取り込むネイティブな方法がありません。

テンプレートベースのツールが取引明細書（거래명세서）を処理できない理由

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

どちらのアプローチも、取引明細書（거래명세서）では同じ理由で機能しません。「通常」というものが存在しないからです。この文書には標準レイアウトがないため、座標やフィールドの位置は供給者ごとに異なります。供給者Aの取引明細書でモデルを学習しても、供給者Bの形式では失敗します。供給者Bの形式を学習セットに追加すると、供給者Cのレイアウトが新たな失敗モードを生み出します。これは学習データの問題ではなく、テンプレートに依存する抽出と、そもそもテンプレートに依存するよう設計されていない文書タイプとの間の構造的な不一致です。

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

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

ステップバイステップ: 取引明細書（거래명세서）データをExcelに抽出する

取引明細書PDFの受け取りから、スプレッドシートに構造化データが入るまでの完全なワークフローは以下の通りです。各ステップは1つの操作です — 座標の描画、モデルのトレーニング、供給者ごとの設定は一切不要です。

抽出エンジンは各フィールドを意味で読み取ります — 事業者登録番号（사업자등록번호）はハイフン付きの10桁パターンで認識し、供給価額（공급가액）は数量および単価の列との相対的な位置で認識し、品目名（품목명）は品目テーブル内のコンテキストで認識します。これが、光学文字認識と視覚言語理解の違いです。前者はテキストを読み、後者は文書を読みます。

このアプローチの背後にある仕組みの詳細については、列名による特定フィールドの抽出に関するガイドを参照してください。

3ウェイマッチング: 発注書（PO） vs 取引明細書（거래명세서） vs 税計算書（세금계산서）

取引明細書から単独でデータを抽出するのも有用ですが、調達照合サイクルの一部として抽出することこそが、実際の業務効率化の本領です。韓国の標準的な調達ワークフローは、予測可能な順序で進みます: 発注書（발주서）が供給者に送られる → 取引明細書（거래명세서）とともに商品が納品される → 検収が行われる → 税計算書（세금계산서）が発行されNTS（国税庁）に送信される → 支払いが行われる。

検収の現場での作業は3ウェイマッチングです: 発注されたもの（PO）、納品されたもの（거래명세서）、請求されたもの（세금계산서）を照合します。現場で見つかった不一致は電話一本で解決できます。月末の照合で見つかった不一致は、納品記録、供給者メール、ERP画面を何時間も遡って調査するコストがかかります。

照合に使用する各文書タイプのデータは次のとおりです:

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

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

並行シナリオとして — 税計算書データの抽出に特化したもの — は、韓国語の税計算書データをExcelに抽出するガイドをご覧ください。7つの必須項目と四半期ごとの付加価値税申告ワークフローをカバーしています。VAT申告用に大量の請求書を処理する場合は、バッチ税計算書処理ガイドでスループット面をカバーしています。

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

個別抽出は文書単位の問題を解決します。バッチ処理は日次ボリュームの問題を解決します — セットアップ作業を繰り返すことなく実現します。

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

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

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

よくある質問

次のステップ

韓国のB2B文書インフラのギャップは発行側にはありません。ECOUNT、Douzone、NTS電子税計算書システムはすでに税計算書をエンドツーエンドでデジタル化しています。ギャップは受領側にあります。つまり、サプライヤーが送ってくる、機械読み取りを想定して設計されていない文書です。取引明細書は、調達照合、在庫受入、支払承認という、下流の財務チームが依存する3つのワークフローに関わるため、そのギャップの中心に位置しています。

そのギャップを埋めるために、サプライヤーの文書発行方法を変える必要はありません。必要なのは、届いた文書をチームが処理する方法を変えることです。受入台帳への転記に8分かかっていた同じ取引明細書も、数秒で抽出できます。同じ列定義が、別のサプライヤーから別の形式で届く明日の明細書にもそのまま機能します。