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

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

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

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

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

事業者登録証の重要項目 — バッチ処理で各項目が重要な理由

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

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

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形式の不一致、業種コードと一致しない課税類型など）は、手動レビュー用の別キューに送られます。

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

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つのステップは別々であり、どちらも構造化データの恩恵を受けます。

ベンダーのスプレッドシートにバッチ抽出の結果が入力されたら、ホームタックス（홈택스）の国税庁（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の山を持つ人物ではなく、検証可能な構造化データセットであることが保証されます。