200件の事業者登録証、1つの検証済みデータベース：
韓国でのサプライヤーKYCを手入力なしで処理する方法

韓国の事業者登録書類に初めて触れる方は、韓国書類抽出市場の比較で、政府ポータル、国内ERPツール、クロスボーダープラットフォームの価格動向をご確認ください。本記事では、バッチKYCワークフローに焦点を当て、サプライヤー登録を大規模に処理する際に何が変わるのかを解説します。

韓国サプライヤーKYCにおける見えないバッチ問題

単一サプライヤーのKYCには確立された手順があります。事業者登録証を収集し、国税庁（NTS）データベースで事業者登録番号を確認し、課税類型を確認し、代表者名と事業場所在地をチェックし、スキャンしたコピーを保管します。すべてのコンプライアンスガイドがこの流れを網羅しています。

しかし、この手順はバッチ条件下では機能しなくなります。その理由は、多くのガイドが認めていない点にあります。つまり、ボトルネックは検証ではなく、データ抽出なのです。何かを検証する前に、情報がデータベースに存在していなければなりません。そして、スキャンされた事業者登録証から構造化されたベンダーレコードを作成する唯一の方法は、ほとんどのチームにとって、依然として人間が書類を読み、フィールドをExcelの行に入力することです。

事業者登録証（사업자등록증）の重要項目と、バッチ処理で各項目が重要な理由

韓国の事業者登録証には、いくつかの重要な項目が記載されています。単一サプライヤーのシナリオでは、これらを一つずつ読み取ります。バッチ処理では、各項目がベンダーデータベースの列になります。そして、各項目が何を示すかを理解することで、データベースの設計方法が決まります。

事業者登録番号（사업자등록번호）

XXX-XX-XXXXX形式の10桁の事業者登録番号（BRN）は、韓国のベンダー記録における主要キーです。多くの処理ガイドでは触れられていませんが、中央の2桁は事業者タイプをエンコードしており、自動検証に活用できるシグナルです。

200件のBRNを一括抽出する際、法人（법인）を名乗るサプライヤーのBRNが10-XXの範囲で、XXが81～88ではなく01～79だった場合、不一致を示しており、手動レビューが必要です。この自動的な整合性チェックは、データが個別のPDF内に存在する場合は不可能です。

課税類型（과세유형）

課税類型は、貴社の経理チームがこのサプライヤーとの取引をどのように処理するかを決定します。付加価値税法に基づき、以下の区分があります。

• 一般課税者（일반과세자） — 10%のVATを含む電子税計算書を発行。VAT申告は法人は四半期ごと、個人は半期ごと。すべての取引先に税計算書を発行可能。
• 簡易課税者（간이과세자） — 軽減税率（1.5%～4%）を適用。税計算書の発行に制限あり。年間売上高が4,800万ウォン未満の場合は税計算書を発行不可。VAT申告は年1回。
• 免税事業者（면세사업자） — VAT納税義務なし。税計算書は一切発行不可。代わりに免税領収書を発行。

200社のサプライヤーを一括処理する購買チームにとって、課税類型の抽出は単なるデータ入力作業ではなく、分類作業です。簡易課税者（간이과세자）とマークされたサプライヤーは、ERPにおいて税計算書を期待しないようシステムに指示するフラグが必要です。このフラグがないと、サプライヤーはVATを支払うべきものとして処理され、その不一致は月末の照合時になって初めて表面化します。

業種コード（업종코드）

6桁の業種コード（업종코드）は、製造業、卸売業、飲食サービス業、ITサービスなど、供給者の事業活動を分類します。単一の供給者を扱う場合は、ざっと確認するだけで済みます。しかし、バッチ処理では、このコードがフィルターとして機能します。どの供給者が自社の業種に該当し、どの供給者が関連セクターに属し、どの供給者が異なるコンプライアンス要件をトリガーするカテゴリーに該当するかを判断できます。

업종코드が52（도매 및 소매업 / 卸売及び小売業）で始まる供給者と、55（숙박 및 음식점업 / 宿泊及び飲食店業）で始まる別の供給者では、仕入れに関する税額控除のルールが異なります。このコードをバッチで抽出してスプレッドシートに取り込めば、リスク階層に基づくKYC審査のために、供給者リストを業種別にセグメント化できます。これは、データが紙の上にある場合には実用的ではありません。

バッチ処理におけるその他の主要フィールド

상호（商号） — 証明書上は韓国語のみです。英語名は非公式の音訳です。200件の商号をバッチで抽出する場合、ハングルの生データが参照キーとなります。供給者が申込書に異なる表記で記入した可能性のある英語名と照合してはいけません。

개업연월일（開業年月日） — 事業年数に基づくリスク評価に不可欠です。開業から30日の供給者と10年間営業している供給者では評価が異なります。これを日付列に抽出すれば、供給者の成熟度を自動計算できます。

사업장소재지（事業場所在地） — バッチ処理では、住所から地理的な集中や顕著な偏りが明らかになります。韓国の6つの道にまたがる200名の販売者をオンボーディングするEコマースプラットフォームにとって、その分布状況は追跡すべきシグナルです。

バッチの算術：200件の証明書 × 各14フィールド

사업자등록증には、事業者登録番号、商号、代表者名、開業日、住所（複数のサブフィールド）、課税類型、業種コード、事業者区分（개인/법인）、発行機関、発行日、交付事由など、約14の抽出可能なデータポイントが含まれています。200件の証明書の場合、2,800のデータポイントになります。

10時間という見積もりは、鮮明な書類から中断なく入力することを前提としています。実際には、スキャン品質の低さ、馴染みのないハングル文字、同じ3桁の業種コードを200回コピーする際の精神的疲労により、実際の所要時間はさらに長くなり、エラー率も上昇します。

BRNの1桁の入力ミス（81を18と入力するなど）は、NTSの検証チェック（홈택스）が正確な10桁の番号を使用するため、供給者レコード全体を無効にします。手動データ入力から予想される28～84件のエラーは、単なる管理上の煩わしさではありません。それぞれが検証に失敗する供給者であり、手動で追跡、修正、再検証する必要があります。

バッチ抽出の仕組み — 全サプライヤー共通の単一カラム設計

従来のKYCワークフローが拡張性に欠ける理由は、テンプレートベースの抽出ツールでは、サプライヤーごとに異なる書式の解析レイアウトを定義する必要があるからです。証明書によってレイアウトは微妙に異なり、スキャン解像度が違ったり、住所欄の位置が少しずれていたり、課税類型のスタンプが専用欄ではなく余白に押されていることもあります。

ImageToTable.aiのカスタム列抽出は、このロジックを逆転させます。各項目がページ上のどこにあるかをシステムに指示する代わりに、必要な列に名前を付けて「何を抽出したいか」を指定するだけで、AIが文書を意味的に読み取り、項目の出現場所に関係なく値を特定します。「사업자등록번호 (BRN)」という列は、印刷物をスキャンした証明書、ホームタックスからダウンロードしたPDF、オフィスの壁に飾られた証明書を撮影した写真のいずれでも、同じように機能します。

バッチファースト処理の設計はさらに一歩進んでいます。列名を一度定義し、200件すべての証明書を一度にアップロードすれば、システムはすべての文書を同じ意味的抽出パスで処理します。出力は単一のスプレッドシートで、すべてのサプライヤーのデータが同一の行構造（BRN列、商号列、課税類型列、業種コード列）に整理され、レビュー、並べ替え、ベンダーデータベースへの取り込みがすぐに行えます。

これこそが、個別のKYC確認からバッチでのサプライヤー onboarding への根本的な転換です。作業が「200回の入力」から「一度のカラムレイアウト設計」に変わります。

ベンダーデータベースの構築 — 入力するデータ

バッチ抽出用のカラムレイアウトを設計する際に問うべきことは、「証明書にはどんな項目があるか？」ではなく、「各サプライヤーについてどのような判断が必要で、その判断にはどのデータが必要か？」です。

以下は、バッチKYC確認に最適化された推奨カラムセットです。

抽出された各取引先レコードには、自動検証ルールを実行するのに十分な情報が含まれています。BRNの中間桁が申告された事業者区分と一致するか？取引先がホームタックス上で有効かつ確認済みか？課税類型が事業を営む業種と整合しているか？すべてのチェックに合格した取引先は、システムに迅速に登録できます。フラグが立った取引先（BRN形式の不一致、課税類型が業種コードと一致しないなど）は、手動レビュー用の別のキューに送られます。

3つの実践的なバッチKYCシナリオ

1. Eコマースマーケットプレイスのセラーオンボーディング

Coupang（クーパン）とNAVER SmartStore（ネイバースマートストア）では、アカウント登録の一環として、すべてのセラーに有効な事業者登録証の提出を義務付けています。月に150～300人の新規セラーをオンボーディングするマーケットプレイス運営者にとって、各証明書は個別のアップロードとして届きます。データはセラー管理システムに抽出する必要があります。支払い決済用のBRN、セラー手数料のVAT処理用の課税類型、セラープロフィール確認用の事業者名と住所です。

このシナリオに固有の課題はスピードです。新規セラーは商品の出品開始を待っています。手動KYC処理が1日遅れるごとに、初回販売が遅れます。バッチ処理を数日から数分に短縮することは、マーケットプレイスの収益に直接影響します。

2. 企業サプライチェーンの年次取引先更新

Samsung、Hyundai、LG、SKなどの韓国の大企業は、1,000～5,000の取引先からなるサプライチェーンエコシステムを運営しています。年次のKYC再確認では、すべての取引先に現在の事業者登録証（過去3ヶ月以内に発行されたもの）の提出が求められます。1サイクルあたり200～400件の更新を処理する調達チームにとって、各証明書を既存の取引先マスターレコードと比較し、新しい住所、代表者の変更、更新された事業者区分などの変更を検出する必要があります。

ここでのバッチ抽出は、初期データ入力ではなく差分が重要です。新しい証明書から抽出された列は、保存されている取引先レコードと比較されます。住所の変更、課税類型の切り替え、新しい商号など、変更があった取引先のみが手動レビューを必要とします。残りの80%は自動的に確認されます。

3. 決済プラットフォーム / フィンテック口座開設

Airwallexのようなクロスボーダー決済プラットフォーム、グローバルフィンテックサービス、国内の韓国系決済ゲートウェイは、FRNAおよびAML/CFT規制（第35条～第42条）に基づく法人口座KYCのため、いずれも사업자등록증を必要とします。韓国の加盟店を一括でオンボーディングするプラットフォームには、証明書が英語と韓国語の二言語で、かつ発行から3ヶ月以内であることが追加で求められます。

このシナリオでは、抽出されたデータは直接KYB（Know Your Business）ワークフローに投入されます。抽出されたBRNは、制裁対象者スクリーニング、PEPチェック、ネガティブメディア検索に並行して使用されます。認定された200社の仕入先データベースが、監査用のコンプライアンス記録となります。

抽出の先へ — 抽出データの検証

バッチ抽出はPDFからデータを取り出します。検証は、そのデータが公的機関の情報と一致することを確認します。この2つのステップは別個のものであり、どちらも構造化データの恩恵を受けます。

バッチ抽出で仕入先スプレッドシートが完成したら、NTSの公開ステータス確認（홈택스）でBRNを検証できます。これは韓国公共データポータルのオープンAPIを通じて、1回の呼び出しで最大100件のレコードをチェックできます。

• 事業状態 — 계속사업자（営業中）、휴업（休業）、폐업（廃業）。200社すべての仕入先を一度に一括検証します。휴업または폐업と表示されたものをフラグ付けします。
• 課税類型の一致 — 証明書の과세유형がNTSの記録と一致することを確認します。일반과세자を主張しているが、홈택스では간이과세者と記録されている仕入先は調査が必要です。
• BRNの有効性 — NTSは確認結果または不一致を示す情報を返します。削除済みまたは未登録のBRNは、特定のエラーメッセージでフラグ付けされます。

データがスプレッドシートにあれば、これらのチェックはフィルタ操作になります。「NTSステータス」列を휴업で並べ替えて問題リストを取得します。「課税類型」列と「NTS課税類型」列を照合して不一致を特定します。バッチ抽出がなければ、これらのチェックは一つ一つPDFを開き、BRNを見つけ、홈택스に入力し、結果を記録する必要があります。

この差 — 数分と数日 — こそが、バッチワークフロー設計の本質です。

よくある質問

200件のPDFから1つのベンダーテーブルへ

韓国のサプライヤーKYCは、根本的にはコンプライアンスの問題ではなく、データ抽出の問題です。コンプライアンスの枠組みは存在し、機能しています。ボトルネックは、「ここにスキャンされた証明書がある」から「ここにERPが処理できる構造化されたベンダーレコードがある」へのステップにあります。

バッチ抽出を出発点として捉え、「この1社のサプライヤーをどう確認するか」ではなく「200件の証明書をどう一度にデータベースに入れるか」と問うことで、オンボーディングワークフロー全体が変わります。データは構造化されて届きます。NTS検証は個々のPDFに対してではなく、カラムに対して実行されます。手動での対応が必要なサプライヤーは、誰かが200の書類を読むのではなく、データフラグによって特定されます。

このフローの最後に行うコンプライアンス判断は、最初のデータと同じだけ信頼できます。自動バッチ抽出により、最初のステップがキーボードとスキャンされたPDFの山を持つ人物ではなく、検証可能な構造化データセットであることが保証されます。