事業者登録証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検証からバッチサプライヤーオンボーディングへの根本的な転換です。作業は「200回入力する」から「列レイアウトを一度設計する」へと変わります。

ベンダーデータベースの構築 — どのデータを入れるか

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

バッチKYC検証用に最適化された推奨列セットは以下のとおりです。

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

実際のバッチKYCシナリオ3選

1. ECマーケットプレイス出品者オンボーディング

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

このシナリオ特有の課題はスピードです。新規出品者は商品の掲載開始を待っています。手動KYC処理による1日の遅延は、初回販売を遅らせます。バッチ処理を数日ではなく数分で完了させることが、マーケットプレイスの収益に直接影響します。

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

Samsung、Hyundai、LG、SKなどの韓国の大企業は、1,000〜5,000社のサプライヤーからなるエコシステムを運営しています。年次のKYC再確認では、全サプライヤーに直近3ヶ月以内に発行された事業者登録証の提出が求められます。サイクルごとに200〜400件の更新を処理する調達チームにとって、各証明書を既存のベンダーマスターレコードと照合し、住所変更、代表者変更、業種更新などの変更を検出する必要があります。

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

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

Airwallexなどのクロスボーダー決済プラットフォーム、グローバルフィンテックサービス、国内の韓国決済ゲートウェイは、すべてFRNAおよびAML/CFT規制（第35条〜第42条）に基づく法人アカウントKYCのために事業者登録証を要求します。韓国の加盟店をバッチでオンボーディングするプラットフォームには、証明書が英語と韓国語のバイリンガルで、かつ3ヶ月以内に発行されたものでなければならないという追加要件があります。

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

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

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

ベンダーのスプレッドシートにバッチ抽出の結果が入力されたら、ホームタックス（홈택스）の国税庁の公開ステータス確認でBRNを照合できます。このAPIは韓国公共データポータルのオープンAPIを通じて、1回の呼び出しで最大100件のレコードをチェックできます。

• 事業者ステータス — 계속사업자（営業中）、휴업（休業中）、폐업（廃業）。200社すべてのサプライヤーを一度に一括検証します。휴업または폐업と表示されたものをフラグ付けします。
• 課税類型の一致 — 証明書の과세유형が国税庁の記録と一致することを確認します。일반과세자を主張するサプライヤーがホームタックスでは간이과세자として記録されている場合は調査が必要です。
• BRNの有効性 — 国税庁は確認または不一致の指標を返します。削除済みまたは未登録のBRNは、特定のエラーメッセージでフラグ付けされます。

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

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

よくある質問

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

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

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

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