得意先マスタ統合とは｜名寄せとコード設計の要点

◆監修・編集責任者　小園 将隆　2026年9月7日

B2B EC-COLUMN

得意先マスタ統合とは

得意先マスタ統合とは、販売管理・会計・与信・受注などのシステムに別々のコードで登録された取引先の情報を、正となる1つのデータへ集約し、その状態を保ち続ける取り組みを指します。作業の中心は重複の解消だけではありません。どの情報を正とするか、誰が更新するか、外部の識別子とどう突き合わせるかを決めるところまでが範囲に入ります。国内の法人であれば、国税庁が公表する13桁の法人番号を突合キーの候補に置けます。この番号は1法人につき1つ指定されます¹。

得意先マスタが抱える項目は、商号と所在地にとどまりません。請求先・納品先・支払条件・与信枠・回収の条件・担当部門といった取引条件が、同じレコードにぶら下がります。1社に対して請求先が2つに分かれる、納品先が拠点ごとに分かれるという並びも珍しくありません。項目の持ち方を決めないまま集約すると、住所は1つに寄ったのに請求先が失われるという取りこぼしが起きます。

データクレンジングは、表記のゆれや不備を整える工程です。全角と半角、株式会社の前株と後株、旧字体、番地の枝番といった表記を、決めた形へそろえます。名寄せは、そのうえで同一の相手を指すレコードどうしを結びつける工程を指します。マスタ統合は、この2つの結果をどのシステムのどのコードで受け止めるかを決め、以後の更新の経路まで含めて設計する工程です。

3つの工程は一度で終わりません。クレンジングと名寄せは移行の直前に集中しますが、継続運用は統合後も毎月続きます。商号変更や合併の届出は取引先の都合で発生しますので、統合の完了をゴールに置くと、時間の経過とともに再び表記のゆれが混じります。移行の計画と同時に、運用の担い手を決めておく必要があります。

統合が議題に上がる引き金は、次の3つに整理できます。

<ul><li>M&Aやグループ再編で別コードの重複が生まれる</li><li>基幹システムの刷新で移行対象の重複が表に出る</li><li>BtoB ECの追加でWeb側の取引先IDが増える</li></ul>

M&Aやグループ再編では、同じ得意先が2つの会社に別コードで存在する状態が生まれます。基幹システムの刷新では、移行対象のレコードを棚卸しした段階で重複が表に出ます。BtoB ECや電子取引の追加では、Web側の取引先IDを既存の得意先コードへ結ぶ必要が生じます。いずれの場面でも引き金となるのは新しい仕組みの追加であって、マスタの不備そのものが起点になるわけではありません。

経営層への説明では、統合を情報システム部門の内部作業として位置づけない方が通ります。請求の突合、与信の判断、売上の集計という日々の業務が、同じ相手を1件として数えられるかどうかに依存しているためです。デジタル庁の政府相互運用性フレームワークでは、コアデータモデルとして法人を表すデータ項目の共通化が進められています³。社外の取り決めが整うほど、社内側の持ち方をそこへ合わせる利点も増えます。

着手にあたっては、対象の範囲を先に区切ると進みます。全社の全システムを同時に扱うより、売上と請求に直結する2系統から始める順序を採ります。扱う件数が絞られれば、判定の基準を短い周期で見直せるためです。範囲を区切れば、突合できなかったレコードを人が判断する件数も見通せます。判断の件数が読めれば、体制と期間の見積もりを社内へ数字で示せます。範囲の外に置いたシステムは対応表の列として残し、次の段で取り込む前提にしてください。

得意先マスタが分散する原因と業務への影響

得意先マスタが分散する原因は、登録の仕組みに関する次の3点に集約できます。

<ul><li>システムごとに採番の規則が違う</li><li>商号変更や合併で履歴が切れる</li><li>部門ごとに登録の運用が分かれる</li></ul>

結果として与信枠が相手ごとではなく登録レコードごとに管理され、同じ相手に対する債権が2つに割れます。請求の突合と出荷の宛先確認は人手で吸収され、月次の締めのたびに同じ確認が繰り返されます。分散は不具合として表に出にくく、担当者の判断で覆い隠されたまま残ります。

採番の規則は、導入した時期と目的に引きずられます。販売管理では地域と業種を桁に埋め込み、会計では補助科目の並び順で採番し、受注管理では自動採番の連番を振るという持ち方が並存します。桁数が6桁と8桁で違えば、突合の前に桁ぞろえの処理を挟むことになります。コードに意味を持たせた体系では、業種の変更や統廃合が起きるたびに番号の意味と実態がずれていきます。

商号変更と本店移転は、取引先の都合で通知の時期が前後します。旧商号のまま残るレコードと新商号で新規登録されたレコードが並ぶと、同じ相手が2件になります。国税庁が運営する法人番号の公表制度では、商号・所在地とその変更履歴が公表され、Web-API機能から取得できます¹。この公表情報を手がかりにすれば、分断された履歴を後から結び直せます。手がかりとして使える理由は、第3節で述べる識別子の性質にあります。

不整合が金額に直結するのは与信です。1社が3レコードに分かれていれば与信枠も3つに割れ、合算した実際の残高が見えません。請求では、支払条件の異なるレコードへ売上が計上され、締め日の違いから未収の照合が合わなくなります。出荷では、旧住所のレコードが残っていると配送のやり直しが発生し、納期の遅れとして取引先へ伝わります。

電子取引を増やすほど、分散の影響は取引先側にも波及します。適格請求書の記載事項を確認する場面では、登録番号の有無と失効の状態を相手ごとに把握する必要があります。国税庁の適格請求書発行事業者公表システムのWeb-API機能では、登録番号から公表事項を照会できます²。登録番号は「T」に13桁の数字を続けた形で、法人の場合は法人番号がそのまま用いられます²。

手作業で吸収している間は、不具合が表に出ません。担当者が相手の顔を覚えていて、コードが違っても同じ相手だと判断できるためです。異動や退職でその判断が失われた時点で、突合の誤りが一度に噴き出します。属人的な吸収に頼った状態は、体制が変わるまで見えない負債として残ります。引き継ぎの資料に判断の根拠が残っていない場合、後任は同じ調査を最初からやり直すことになります。

影響の大きさは、重複の件数だけでは測れません。同じ重複でも、取引が止まっている相手なら実害は小さく、毎月の請求がある相手なら締めのたびに作業が積み上がります。棚卸しの段階では、重複の件数とその相手との取引の頻度を並べて見ます。件数だけを見ても、毎月発生する作業量までは読み取れないためです。優先順位が付けば、限られた期間でも効果の出る範囲から手を付けられます。上位から順に処理する計画を立てると、途中で予算が止まっても成果が残ります。

自社の商流に合わせた要件整理を進めたい場合は、無料相談で要件を整理するのが近道です。

統合の軸となる識別子とコード体系の設計

識別子の設計では、自社の得意先コード1本に頼らず、外部の公的な識別子と対応させる持ち方を採ります。自社の都合で書き換わらない番号が1つ加わると、システムをまたいだ照合の基準が固定されるためです。国内の法人には13桁の法人番号があり、1法人につき1つ指定されます¹。ただし個人事業主や海外法人、支店・事業所には法人番号が付きませんので、これだけで全ての得意先を識別できるわけではありません。届かない範囲を自社コードと事業所単位の識別子で補う二段構えが前提になります。

法人番号を突合キーに据える利点は、商号と所在地が変わっても番号が変わらない点にあります。国税庁が提供する公表用のWeb-API機能では、法人番号・商号・所在地とその変更履歴を取得できます¹。仕様書はVer.4.0が公開されており、以降の改定の有無と現行の版数は、着手の前に国税庁の公式サイトで確かめてください¹。利用にはアプリケーションIDの申請が要り、利用規約と仕様の版はいずれも改定の対象になります¹。番号を保持する欄をマスタに1つ足すだけでも、後の照合の起点になります。

法人番号で届かない範囲は、先に決めておく方が安全です。個人事業主との取引、海外法人との取引、同一法人の支店や工場を別の届け先として扱う取引がこれに当たります。適格請求書発行事業者であれば、登録番号から公表事項を照会できますので、課税事業者かどうかの確認には使えます²。ただし登録は失効し得ますので、照会の結果は取得した時点とあわせて保持します。

事業所や部門の単位を識別するコードとしては、GS1が定めるGLN（企業・事業所を識別する13桁の国際標準コード）があります⁴。GLNは事業者コードにロケーションコードと1桁のチェックデジットを続けた形で構成されます⁴。適用が想定されるのは消費財流通など標準への対応が進んだ商流で、全ての業種で必要になるわけではありません。取引先からGLNの提示を求められる商流にいるかどうかを、設計の前に確かめてください。

自社コードと外部識別子は、どちらかへ寄せるのではなく対応表でつなぐ形を採ります。片方の体系が変わっても、もう一方の列を書き換えるだけで整合が戻るためです。対応表は、自社の得意先コードを主キーとし、法人番号・登録番号・GLN・旧コードを列として持ちます。旧コードの列を残せば、過去の伝票を新しいコードへ読み替える経路が保てます。1対1に収まらない対応には、対応の種別を示す列を足して区別します。

一社一コードでは表現しきれない階層は、レコードを分けずに階層の列で持ちます。法人の単位、請求先の単位、納品先の単位、部門の単位という4階層を分け、それぞれに識別子を割り当てる持ち方です。上位の階層に法人番号を、下位の階層に自社の枝番やGLNを置くと、集計の粒度を後から変えられます。与信は法人の単位、請求は請求先の単位というように、業務ごとに参照する階層を決めておきます。

識別子と項目の定義は、外部の規格を参照すると社内の議論が早く収束します。国際標準化機構が定めるマスタデータ品質の規格のうち第110部は2021年版として発行され、構文・意味の符号化・データ辞書への準拠を要件として扱っています⁶。この規格群は改訂と追補が続きますので、2021年版が現行かどうかは参照する時点で公式の情報と照合します。版数を確かめた日付を定義書に書き添えておけば、次の改訂で見直す範囲が絞れます。規格をそのまま導入しなくても、要件の並びは自社の定義書の目次として使えます。

得意先マスタ統合の進め方

統合の進め方は、現行マスタの棚卸し、名寄せの実行、統合先への移行という3つの段階に分けます。段ごとに完了の条件が違うため、まとめて進めると差し戻しの原因を特定できません。棚卸しでは項目定義の統一と重複の抽出を先に終わらせます。名寄せでは突合キーの優先順位を決め、機械で判定しきれない例外の判定を人が引き取ります。移行では統合先を1つに決め、並行稼働の期間を置いてから切り替え判定へ進みます。段階を飛ばすと、後戻りの費用が切り替えの直前に集中します。

棚卸しでは、対象システムごとに項目の一覧と件数を並べます。同じ取引先名の欄でも、片方は法人格を含み、片方は略称で入っているという違いがここで見えます。項目定義の統一では、次の4項目を文書に落とします。

<ul><li>桁数をシステム間でそろえる</li><li>必須入力の可否を決める</li><li>入力の形式を1つに定める</li><li>履歴の保持の要否を決める</li></ul>

定義が固まる前に名寄せを始めると、判定の基準が担当者ごとに揺れます。

重複の抽出は、機械的な一致から段階的に広げます。法人番号が一致するレコードをまず結び、次に商号と所在地の組み合わせ、最後に電話番号や取引口座という順です。抽出の各段で、結んだ件数と結ばなかった件数を記録します。件数の推移が残っていれば、後から判定の基準を見直すときに再実行の範囲を絞れます。抽出の条件は文書に残し、誰が実行しても同じ結果になる状態にしておきます。

突合キーの優先順位は、変わりにくい情報から順に並べます。法人番号は第3節で述べた性質から上位に置き、商号と所在地の組み合わせを次に、代表電話や取引口座を下位に置きます¹。上位の情報ほど取引先の事情で書き換わりにくく、判定の基準として長く使えるためです。判定は一致と不一致の2値ではなく、確度に応じて自動確定・人の判定・対象外の3区分に分けます。例外の判定へ回る件数を見積もっておけば、必要な人員と期間を先に押さえられます。

統合先の決定は、機能ではなく更新の起点で選びます。得意先の登録と変更が最初に発生するシステムを正とし、他のシステムはそこから受け取る側へ回す並びです。受注が起点の会社もあれば、与信審査が起点の会社もありますので、業務の流れを追って決めます。統合先を決めないまま複数のシステムで登録を続けると、統合の翌月から再び差異が生まれます。

並行稼働の期間には、新旧のマスタを両方更新する運用が要ります。二重の更新は負担が重いため、期間は締めの周期に合わせて区切り、差異の検出は自動で回します。切り替え判定では、差異の件数が収束したことと、旧コードからの読み替えが伝票で通ることの2点を条件にします。条件を先に文書化しておけば、判定の場で議論が振り出しに戻りません。

内製で完結させる場合に要る知識は、次の4領域にまたがります。

<ul><li>対象システムのデータ設計を読み解く</li><li>名寄せの判定ロジックを組み立てる</li><li>移行時の一括更新を安全に流す</li><li>公的な識別子の照会を実装する</li></ul>

1人でこの4領域を担うと、切り替えの直前に確認の負荷が1点へ集中します。外部の支援を使う判断は、難しいからではなく、失敗が請求と出荷へ波及する範囲を小さくするためです。差し戻しが起きたときの復旧手順まで含めて、体制を先に決めてください。

統合後にマスタ品質を保つ運用

統合の効果は、移行が終わった時点ではなく、その後の運用で決まります。変更差分の取り込みを定期の作業として組み、自動照合で差異を検出し、登録・失効の検知を与信への反映へつなぐ流れを作ります。更新の責任は、営業・経理・情報システムのどこが持つかを項目ごとに割り当てます。担当が決まらない項目は、やがて誰も更新しない欄になります。運用の型を先に作っておけば、次の再編でも同じ手順を使い回せます。

変更差分の取り込みでは、外部の公表情報と自社のマスタを突き合わせます。国税庁の法人番号の公表制度では、商号・所在地の変更履歴を含む公表情報がWeb-API機能から提供されています¹。取得の周期は月次から始め、差異の多い項目だけ周期を詰めます。全項目を日次で取り込むと、確認を待つレコードが処理できる量を超えるためです。取り込んだ差分をそのまま上書きせず、確認待ちの状態を挟めば、誤った更新が本番へ流れません。

自動照合では、一致と不一致に加えて確認待ちという3つの状態を持たせます。商号の変更は自動で反映してよい項目ですが、所在地の変更は納品先の変更を伴うことがあり、営業側の確認が要ります。項目ごとに自動反映の可否を決めた表を1枚持っておくと、運用の引き継ぎが早く済みます。表の改定は日付ではなく年度の単位で管理し、判断の根拠も併記します。

登録・失効の検知は、請求の実務に直結します。国税庁の適格請求書発行事業者公表システムのWeb-API機能では、登録番号から公表事項を照会でき、登録の年月や失効の状態を確認できます²。失効を見落とすと、記載事項の確認が後追いになりますので、照会の周期は請求の締めに合わせてください。与信では、商号変更や合併の検知を審査の再実行の引き金として扱います。相手の状態が変わった月のうちに、枠の妥当性を見直せるためです。

更新責任の分担は、システム単位ではなく項目単位で決めます。商号と所在地は情報システムが外部の公表情報から更新し、支払条件と与信枠は経理が、納品先と担当者は営業が持つという分け方です。1つの項目に2つの部門が更新権を持てば、上書きの応酬が起きます。権限の一覧はマスタの項目定義書と同じ文書に置き、改定の履歴を残します。

品質の状態は、件数で測れる指標に落とします。月次で並べる指標は、次の3つです。

<ul><li>突合できなかったレコードの件数を数える</li><li>確認待ちのまま滞留している件数を追う</li><li>法人番号が未設定の得意先の件数を見る</li></ul>

国際標準化機構が定めるマスタデータ品質の規格のうち第110部は、データの交換で満たすべき要件を示しており、社内の指標を組む際の参照点になります⁶。数値が悪化した月に手を打てば、次の大がかりな統合作業を呼び込まずに済みます。

運用の担い手が1人に寄ると、その1人の不在で更新が止まります。手順書には、照会の周期、確認待ちの扱い、判断に迷った場合の相談先という3項目を残します。日々の作業を自動化しても、例外の判断は人が引き取る前提で設計します。判断の分かれ目は取引先ごとの事情に左右され、規則だけでは書き切れないためです。担当が交代する場面を想定し、判断の基準そのものを文書へ残しておく必要があります。

BtoB ECと基幹システムをつなぐときの要点

BtoB ECを追加する前に、3点をマスタ側で決めておきます。Web受注の取引先IDと得意先コードの対応、取引条件・単価マスタとの紐づけ、電子取引データの標準仕様への適合です。EC側で新しいIDを採番してから対応表を作ると、既存の得意先と重複した登録が最初の月から積み上がります。単価と取引条件を基幹側に置いたままEC側でも持ち直せば、値引きの改定が2箇所に分かれます。標準仕様への適合は、取引先から求められる商流かどうかを先に見極めます。

Web受注の取引先IDは、得意先コードとは別の目的で発番されます。EC側は利用者アカウントの単位で、基幹側は請求の単位で持つためです。1つの得意先に購買の担当者が複数いる場合、アカウントは複数で得意先コードは1つという対応になります。この1対多の対応を先に定義しないと、注文の集計が担当者の単位に割れ、与信の残高が読めなくなります。

階層の持ち方は、EC側の画面設計にも影響します。第3節で定めた4階層をEC側が参照する形にすれば、画面の権限と表示の範囲をマスタの定義から組み立てられます。部門ごとに購買の承認者が分かれる取引先では、部門の単位で発注枠と納品先を分けて表示する設計が要ります。マスタ側が1階層しかない場合、EC側に独自の階層ができ、統合すべき対象が新たに1つ増えます。承認の経路をEC側だけで持つと、基幹側の与信の単位と食い違ったまま運用が始まります。

単価は、得意先ごと・商品ごと・期間ごとに決まる並びが通例です。得意先マスタ側で単価の適用単位を決めていないと、EC側は個別の価格表を持たざるを得ません。適用の単位は、法人の単位か請求先の単位かを1つに決め、例外は期間付きの上書きとして持たせます。改定の履歴を残せば、過去の注文がどの単価で通ったかを後から追えます。

取引データの様式は、商流によって求められる標準が異なります。消費財流通では、流通システム開発センターが公開する流通ビジネスメッセージ標準（企業間の電子取引の様式を定めた業界標準）が用いられます⁵。基本形はVer.2.0が2018年に公開されており、その後の改定の有無と現行の版数は、参照する時点で同センターの公式サイトの記載と照合します⁵。標準に沿った様式では、取引先の識別にGLNなどのコードを用いる前提が置かれます⁴⁵。取引先から様式の指定を受けている場合は、マスタ側にそのコードを保持する欄を先に足してください。

社外との連携は、業界標準だけにとどまりません。デジタル庁の政府相互運用性フレームワークでは、コアデータモデルと実践のための手引が公開され、法人を表すデータ項目の共通化が進められています³。データの持ち方を外部の共通の定義へ寄せておけば、連携先が増えたときの改修の範囲を抑えられます。自社だけで通じる項目名は社内の定義書に残しつつ、外部へ出す様式では共通の名称へ写します。

ECと基幹をつなぐ工程では、要る知識が広がります。マスタの設計、連携の様式、価格の適用ルール、公的な識別子の照会という4領域を、同じ期間内に押さえる必要があります。1つでも欠けたまま公開すると、受注の初月に注文の取り消しと再入力が発生し、取引先の手間として跳ね返ります。社内の体制で足りない領域があれば、切り替えの前に外部の支援を検討します。要件の整理だけでも先に第三者と突き合わせておけば、公開後の手戻りを抑えられます。

よくある質問

得意先マスタ統合にはどのくらいの期間がかかりますか

期間は対象システムの数と、突合できずに人の判断へ回る件数で決まります。棚卸しの段階で、重複の件数と自動確定できない件数を数えておけば、必要な工数を見積もれます。件数を数える前に日程だけを先に決めると、名寄せの終盤で判断待ちが積み上がり、切り替えの直前に遅れが表面化します。

法人番号だけで得意先を一意に識別できますか

国内の法人については、1法人につき1つ指定される13桁の法人番号が有効な突合キーになります。ただし個人事業主や海外法人には付番されず、同一法人の支店・工場も番号は同じです。届け先や請求先を分けて管理する場合は、自社の枝番やGLNなど事業所を識別するコードを併せて持つ必要があります。

名寄せの判定はどこまで自動化できますか

自動化の範囲は、確度に応じた3区分で線を引きます。法人番号が一致する候補は自動確定、商号と所在地の部分一致は人の判定、取引が終了した相手は対象外という分け方です。判定の基準を文書に残しておけば、再実行のたびに結果が揺れることを避けられます。

統合の費用はどのように見積もればよいですか

費用は、棚卸し・名寄せ・移行・並行稼働という4区分に分けて積み上げると説明しやすくなります。変動が大きいのは人の判定に回る件数と、並行稼働で二重更新を続ける期間です。この2つを棚卸しの結果から先に押さえておけば、投資判断の場で条件付きの見積もりを示せます。

BtoB ECを先に立ち上げてから統合しても間に合いますか

EC側の取引先IDと得意先コードの対応表だけは、公開の前に用意してください。対応表がないままEC側で新規のIDを採番すると、既存の得意先と重複した登録が初月から積み上がります。全社のマスタ統合を待つ必要はありませんが、法人番号を保持する欄と階層の持ち方は先に決めておく方が後の手戻りを抑えられます。

1. 1　出典：国税庁「法人番号システム Web-API機能（仕様書 Ver.4.0まで公開）」（2026年時点で公開中）　経路
2. 2　出典：国税庁「適格請求書発行事業者公表システム Web-API機能」（2026年時点で公開中）　経路
3. 3　出典：デジタル庁「政府相互運用性フレームワーク（GIF）コアデータモデル・実践ガイドブック」（2026年時点で公開中）　経路
4. 4　出典：GS1 Japan（一般財団法人流通システム開発センター）「GLN（企業・事業所識別コード）標準解説」（2026年時点で公開中）　経路
5. 5　出典：流通BMS協議会（一般財団法人流通システム開発センター）「流通ビジネスメッセージ標準（流通BMS）標準仕様 基本形Ver.2.0」（2018年）　経路
6. 6　出典：国際標準化機構（ISO）「ISO 8000-110:2021 Data quality — Part 110: Master data」（2021年）　経路