得意先マスタとは｜項目設計と名寄せ・一元管理の要点

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

B2B EC-COLUMN

得意先マスタとは

得意先マスタとは、商品やサービスの販売先を一意に識別し、その取引条件をひとまとめに管理する台帳です。販売先ごとに割り振ったコードを主キーとして、商号や所在地、請求先、締日、支払条件、与信枠などを結び付けて持ちます。受注入力から出荷、請求、入金消込までの処理がこの台帳を参照するため、ここでの持ち方が下流の処理の精度を左右します。設計を検討する出発点は、自社が得意先と呼ぶ範囲を言葉のうえで揃えることです。

得意先マスタが担う役割は、業務の入口で参照される点に集約されます。受注を登録する際は得意先コードを指定し、そこから請求先や支払条件、価格の条件が伝票へ引き渡されます。販売実績の集計や与信の残枠の判定も、同じコードを軸に集められます。台帳が持つ値がそのまま伝票の値になるため、いつの時点の値を使ったのかを追える設計も併せて考えます。

顧客マスタや取引先マスタとの違いは、対象とする範囲にあります。顧客マスタは見込み客や過去に問い合わせた相手を含む広い台帳として扱われることがあり、取引の実績がない相手も入ります。取引先マスタは販売先と仕入先の両方をまとめた呼び方として使われます。得意先マスタはこのうち債権が発生する販売先に絞った台帳で、締日や与信枠といった回収側の条件を持つ点に特徴があります。

販売先でありながら仕入先でもある相手をどう持つかは、早い段階で決めておきたい論点です。同じ企業が得意先と仕入先の双方に登場する場合、債権と債務を別の台帳で管理し、企業単位の名寄せキーで結び付ける形が扱いやすいでしょう。相殺の可否や相殺後の入金額の扱いは、両方の台帳をまたいで判断します。1つの台帳に販売と購買の条件を混在させると、項目の意味が二重になり、入力時の取り違えを招きます。

一意に識別する手段としては、社内のコードのほかに公的な番号を併せ持つ方法があります。国が公表する法人番号は13桁で、1つの法人に1つだけ指定され、商号や本店所在地が変わっても番号自体は変わりません¹。公表されるのは商号、本店所在地、法人番号の3項目で、誰でも検索して確認できます1。社内コードと切り離して別項目に持たせておくと、名寄せの照合キーとして後から使えます。

粒度の食い違いは、連携を始めた後に表面化します。会計側は請求先の単位で残高を見たいのに、販売側は納品先の単位で実績を見たいという要求は、同時に起こります。EC側では発注する担当者の単位でアカウントを持つため、企業、事業所、担当者の三階層で考える必要が出てきます。どの階層を得意先コードの単位とし、どの階層を関連テーブルで持つかを決めてから、項目の設計へ進みます。

定義をそろえる作業は、地味に見えて後戻りを減らします。用語の指す範囲が部署ごとに違うまま設計へ進むと、同じ項目名に別の意味が入り込み、移行の段階で解釈のやり直しが発生します。得意先とは誰か、請求先とは何か、納品先はどこまで分けるのか、という三点を文書に落としてから項目を並べると、後の判断が速くなります。

得意先マスタに持たせる主な項目

得意先マスタに持たせる項目は、識別コードと基本情報、請求と回収条件、与信と取引条件、担当者情報の四つの群に整理できます。群ごとに参照する業務が違うため、どの群にどの項目を置くかを決めておくと、後から項目を足すときの判断が揺れません。全得意先で値が埋まらない項目は台帳本体に置かず、関連テーブルへ切り出す方針を先に決めます。入力の手間と参照の頻度が釣り合わない項目は、運用のなかで空欄のまま残るからです。

識別コードと基本情報の群には、得意先コード、登記のとおりの商号、商号のカナ表記、本店や事業所の所在地、電話番号、法人番号を置きます。商号は正式な表記と、帳票や検索で使う略称を別項目に分けると、表記のゆれを吸収できます。法人格の位置や全角と半角の混在は、カナの項目を正規化して保持することで照合に使えるようになります。

請求と回収条件の群は、請求書の発行と入金消込のために持ちます。請求先が納品先と別の企業や事業所になる取引では、請求先を独立した項目として持たせ、複数の納品先を1つの請求先へ寄せられる形にします。締日、支払方法、支払期日の起算、消費税の端数処理、請求書の送付経路もこの群です。適格請求書発行事業者の登録番号は、公表システムのWeb-API機能を使って登録の状態を自社のシステムから照合できます^*2。

与信と取引条件の群には、与信枠、与信の判定区分、価格の掛率や価格グループ、出荷条件、運賃の負担、取引の開始日と停止の区分を置きます。価格の条件を得意先ごとの個別値として持つか、価格グループを介して持つかで、条件を変えるときの作業量が変わります。個別値は柔軟ですが、改定のたびに全件へ手を入れることになりがちです。停止の区分は受注の可否に直結するため、更新が遅れない経路で持たせます。

担当者情報の群は、氏名や連絡先を含むため、個人情報として取り扱う前提で設計します。取得した個人情報は、利用する必要がなくなったときに遅滞なく消去するよう努める旨が示されています^*3。異動や退職で不要になった連絡先を台帳に残し続けない運用と、保持の期間の考え方を、項目の設計と同時に決めておきたいところです。EC側のアカウントと結び付ける場合は、権限の区分もこの群で持ちます。

項目を増やすときは、1つの項目に1つの意味だけを持たせる原則を守ります。備考欄に条件や約束事を書き込む運用が始まると、値が文章になり、集計にも判定にも使えなくなります。条件として使う値は選択肢を定義した項目にし、文章は別の記録へ回します。使う業務が1つに限られる項目は、台帳本体ではなくその業務側で持つほうが保守しやすいでしょう。

項目の群と参照する業務の対応を一覧にすると、抜けの点検に使えます。受注入力で参照する項目、請求で参照する項目、入金消込で参照する項目を並べ、どの業務からも参照されない項目を洗い出します。参照されない項目は、記録として残す意味があるのか、それとも入力の負担になっているだけなのかを見分けられます。

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

得意先マスタが乱れると起きる業務への影響

得意先マスタが乱れると、同じ企業が複数のコードで登録され、売上の集計と与信の判定が別々の単位で走り始めます。請求先の誤りは請求書の再発行と入金の遅れにつながり、締めの処理をやり直す作業も発生します。電子的な受発注では、双方が使う識別コードが一致しないと明細の突き合わせが人手に戻ります。乱れの影響は入力の手間にとどまらず、回収と与信の判断そのものに及びます。

重複登録は、悪意ではなく経路の多さから生まれます。営業の担当者が見込み先を登録し、受注センターが電話で受けた注文のために別に登録し、EC側で相手が自ら会員登録するという三つの入口が並存すれば、同じ企業が三重に入ることは起こり得ます。合併や商号の変更のあとに旧商号のレコードが残ることも、重複の一因です。

重複登録による売上集計と与信管理の分断は、算数の問題として現れます。同じ企業が2件のコードで登録されていれば、与信枠も2件に分かれ、それぞれの枠の内側で受注が通ります。企業単位で見れば枠を超えているのに、システム上はどちらも枠内という判定になります。回収が滞ったときの与信の見直しも、片方のコードにしか反映されません。

請求先と納品先の誤りは、条件の持ち方が曖昧なときに増えます。本社で一括して請求を受け、納品は各事業所へという取引では、請求先と納品先を別の階層で持たないと、担当者の記憶に頼った入力になります。請求先を誤れば、請求書の差し替え、入金予定の付け替え、消込の修正が連鎖します。月末に集中する処理のなかでこの連鎖が起きると、締めの日程に影響します。

電子的な受発注では、識別コードの不一致がそのまま作業量になります。流通業向けの標準仕様である流通BMS（企業間の取引データを電子的に交換するための標準メッセージ仕様）は発注、出荷、受領、請求のメッセージの形を定めていますが⁴、事業所を指すコードが双方の台帳で一致していなければ、受け取った明細をどの得意先のどの納品先に当てるかを人が判断することになります。企業や事業所を国際的に識別するGLN（企業・事業所識別コード。13桁）が用意されており、これを台帳に併せ持つ方法があります5。

入金の消込も、識別が揃っているかどうかで手間が変わります。振込の電文に支払の通知情報を添えて送れる仕組みが整えられており、どの請求に対する入金かを電子的に受け取れる経路があります^*6。この経路を使う場合でも、通知に含まれる得意先の識別と自社の台帳のコードが結び付いていなければ、突合は目視に戻ります。振込の名義と商号の表記ゆれだけが手掛かりの状態は、件数が増えるほど負担になります。

乱れを放置した場合の是正の費用は、時間の経過とともに増えます。伝票が発生した後のコードの統合は、受注残、売掛残、与信、価格の条件、契約の紐付けを付け替える作業を伴います。残高が残っているコードを締めの途中で統合すると、月次の残高が合わなくなる恐れがあります。着手が遅れるほど、対象の件数と付け替えの範囲が広がる関係にあります。

コード設計と名寄せの考え方

得意先コードの設計では、コードそのものに分類の意味を持たせず、業種や地域、担当の区分は属性の項目で持つ方針が扱いやすいです。分類が変わってもコードを振り直さずに済み、桁の枯渇も避けられます。照合の手掛かりとしては、公的な番号や標準のコードを別項目で併せ持ちます。名寄せは、判定のルールと、項目ごとに正とするデータを先に決めてから着手します。順序を逆にすると、決めごとの前後が入れ替わってやり直しになります。

意味を持たせたコードは、初期の使い勝手と引き換えに変更への弱さを抱えます。先頭の桁に地域、次の桁に業種を割り当てた体系では、拠点の移転や事業内容の変化でコードと実態がずれます。ずれを直すためにコードを振り直せば、過去の伝票や外部との取り決めにも影響します。特定の分類に割り当てた範囲だけ先に埋まり、桁が足りなくなる事態も起こります。

意味を持たせないコード設計では、採番を連番とし、誤入力を検知するための桁を末尾に加える形が採られます。集計や絞り込みは、業種や地域の属性項目を軸に組み立てます。属性は後から値を追加でき、1つの得意先に複数の属性を持たせることもできます。コードは識別のためだけに使うと決めておけば、分類の見直しが属性の付け替えで済みます。

照合キーの併載は、社内コードと外部の番号を役割で分ける考え方です。国が公表する法人番号は13桁で、1つの法人に1つだけ指定され、名称や所在地の変更では変わりません¹。ただし指定の対象は登記された法人などに限られ、個人で事業を営む相手には指定されないため、これだけで全件を識別することはできません。事業所の単位で識別したい場合は、13桁のGLNを併せて持つ方法があります5。

請求のための登録番号も、照合に使える値です。法人の場合の登録番号は、記号のTと13桁の法人番号を組み合わせた形で表されます。公表システムのWeb-API機能を使えば、登録の状態を自社のシステムから照合できます^*2。登録は取消や失効が起こり得るため、照合した日付を記録し、請求の時点で有効だったかを後から確認できるようにしておきます。

名寄せの判定ルールは、機械が寄せる範囲と人が判断する範囲を分けて決めます。法人番号が一致する組は完全一致として自動で寄せ、商号のカナと所在地を正規化したうえで近い組は準一致として候補に出し、最後は目視確認で決めるという三段の組み立てが実務で使いやすいです。所在地は丁目や番地の表記、ビル名の有無で差が出るため、正規化の規則を明文化します。判定の記録を残せば、後から見直せます。

正とするデータの決め方は、レコード単位ではなく項目単位で考えます。商号と所在地は登記の情報を正とし、請求先や締日、支払条件は契約の書面を正とし、与信枠は与信を判定する側の記録を正とするという割り当てです。どちらのレコードを残すかという問いだけで進めると、片方にしかない正しい値が失われます。統合の際は、残すコードと消すコードの対応表を保管し、旧コードでの問い合わせに答えられる状態を保ちます。

基幹システムとBtoB ECサイトの連携方法

基幹システムとBtoB ECサイトの連携では、得意先マスタを基幹側の正として持ち、EC側へは参照用の複製を配信する型が扱いやすいです。EC会員のアカウントは得意先コードに結び付け、企業、事業所、担当者の階層で権限を分けます。価格や掛率、出荷条件は得意先の単位で出し分け、条件の元データは基幹側だけで更新します。双方で登録できる形にすると、重複の入口が二つに増えます。

正の置き場所を決めることは、重複を防ぐ最初の手当てです。EC側で相手が自ら登録した情報をそのまま得意先として扱うと、既存の得意先と同じ企業が別のコードで生まれます。EC側の登録は申込のデータとして受け取り、既存の得意先との照合を経てから基幹側で採番し、その後に会員を有効化する流れにします。照合には商号のカナ、所在地、法人番号を使い、候補が出た場合は人が確認します。

配信の方式は、全件の同期と差分の連携を組み合わせて考えます。差分は更新日時か更新の区分で抽出し、漏れを検知するために定期的な全件の照合を挟みます。取引を停止した得意先の区分は、伝わるまでの時間が短いほど、停止した相手への出荷を防げます。配信が止まったことに気付ける仕組みを併せて用意しておくと、古い条件のまま受注を受け続ける事態を避けられます。

EC会員アカウントと得意先コードの結び付けは、一対多の関係で設計します。1つの得意先に複数の担当者のアカウントがあり、発注できる人、金額を承認する人、閲覧だけの人が混在します。異動や退職でアカウントを止める手続きが遅れると、取引を離れた相手が発注できる状態が残ります。担当者の情報は個人情報として扱い、必要がなくなった後の消去に努める旨に沿った運用を決めておきます^*3。

価格や掛率の出し分けは、得意先の単位と条件の単位を分けて持つと保守しやすくなります。販売の管理を担うパッケージの標準的な設計では、得意先の情報を全社で共通の部分、会計の単位で持つ部分、販売の領域ごとに持つ部分の3区分に分けて保持する考え方が示されています^*7。同じ企業に対して、会計の条件と販売の条件を別に持てる形です。EC側にはこのうち販売の条件だけを渡し、会計の条件は基幹側に留めます。

電子的な受発注の経路とECの経路は、同じ得意先のなかで併存します。標準の仕様に沿った発注を受ける相手と、画面から発注する相手が混在する場合でも、得意先コードを1つに寄せておけば実績と与信を企業単位で見られます⁴。入金側も、支払の通知情報を電文に添えて受け取れる経路がある一方で、従来の振込データだけを受け取る相手も残ります6。経路ごとに識別の付け方が違う点を、連携の設計に織り込みます。

連携の設計を誤ったときの影響は、受注の可否と請求額に直接出ます。停止したはずの得意先が発注できる状態、改定前の掛率で受注が通る状態、請求先が旧情報のまま請求書が出る状態は、いずれも相手との調整を伴います。自社の条件でどこまで作り込む必要があるかは、既存の販売管理の作りと得意先の階層の持ち方によって変わります。設計に入る前に、現在の粒度と将来の要求を書き出して照らし合わせる作業が効きます。

得意先マスタ整備の進め方

得意先マスタの整備は、棚卸し、クレンジングと統合、移行テストと切り替えの3段階で進めます。棚卸しでは重複候補の抽出と更新部署の洗い出しを済ませ、対象の範囲を決めます。クレンジングと統合では表記の正規化と代表コードの決定まで進め、旧コードとの対応表を残します。移行テストと切り替えでは残高の突合と切り戻し手順の準備を経て、業務を新しい台帳へ移します。段階を飛ばすと、直した内容が業務に反映されないまま古い値が戻ります。

棚卸しは、数を把握することから始めます。登録の総件数、直近に取引のある件数、伝票が1件もない件数を数え、重複候補の抽出では商号のカナと所在地、法人番号を手掛かりに組を出します。更新部署の洗い出しでは、どの部署がどの項目を更新しているかを一覧にします。誰も更新していない項目と、複数の部署が別の意図で更新している項目が見つかります。

対象を絞ることで、整備は終わりに近づきます。全件を同時に直そうとすると、影響の確認が追いつかず、途中で止まりがちです。直近に取引のある得意先から手を付け、伝票のない休眠先は統合の対象から外し、更新を止める区分へ移します。休眠先は件数だけかさむ割に業務への効果が小さいため、後回しにする判断が成り立ちます。

クレンジングでは、表記の正規化から進めます。全角と半角、法人格の位置、カナの長音や記号の扱いを規則として定め、機械的に整えられる範囲を先に処理します。次に法人番号を突き合わせ、一致した組は同じ企業として扱えます。正規化の規則は文書に残し、以後の新規登録でも同じ規則を使えるようにします。

代表コードの決定は、統合の中心となる作業です。残すコードを1つ選び、他方を別コードとして対応表に記録し、伝票の参照を付け替えます。どのコードを代表にするかは、伝票の件数が多いほう、外部との取り決めで使われているほう、といった基準を先に決めておきます。対応表を残せば、旧コードでの照会にも答えられ、統合の判断を後から検証できます。

移行テストと切り替えでは、残高の突合を判定の軸にします。移行の前後で件数、売掛の残高、受注残、与信の使用額が一致するかを確かめ、差が出た場合は原因を特定できるまで進めません。受注から出荷、請求、入金消込までを一巡させ、旧の台帳と新しい台帳で同じ結果になるかを照合します。切り戻し手順の準備として、どの時点まで戻せるか、戻す判断を誰がするかを事前に決めます。

整備を自社だけで進める場合、必要な知識の幅が課題になります。販売管理と債権の業務の理解、データの正規化と突合の技術、EC側の会員と権限の設計、電子的な受発注の仕様の把握が同時に求められます。通常の業務と兼務のまま進めると、棚卸しの段階で止まり、重複の件数だけが増えていく状態になりがちです。どの段階を自社で持ち、どの段階を外部の支援に委ねるかを、着手の前に線引きしておくと進みます。

運用ルールと更新体制の整え方

整備した状態を保つ仕組みは、登録と変更の申請と承認の流れ、休眠先と担当者情報の扱い、定期点検の三つです。登録の権限を絞り、起票、内容確認、与信と請求条件の確認、登録という順序に載せると、重複の入口を1本に保てます。休眠先は削除ではなく停止の区分で扱い、担当者情報は必要がなくなった後の消去に努めます。点検は指標を決めて推移を見る形にすると、続けやすくなります。

申請と承認の流れは、判断の主体を分けることで機能します。取引の開始や条件の変更は営業の担当者が起票し、受注センターが内容確認として重複の有無と記載の整合を確かめ、与信と請求条件の確認を与信や経理の担当が引き受け、最後にマスタを管理する担当が登録します。起票の画面に重複の検索を組み込み、商号のカナ、所在地、法人番号で既存の候補を出す作りにすると、登録の前に気付けます。

変更の扱いでは、履歴を残すかどうかで後の説明のしやすさが変わります。商号の変更、所在地の変更、請求条件の変更は、いつ何を変えたかを記録し、過去の伝票は当時の値で表示できる形にします。法人番号は商号や所在地が変わっても変わらないため^*1、名称の変更を検知する手掛かりとして使えます。変更の理由を短く残す運用は、後から経緯をたどる際に効きます。

休眠先と解約先は、削除せずに区分で表すほうが後の照会に支障が出にくくなります。過去の伝票が参照しているレコードを消すと、履歴の確認や請求書の再発行に手間がかかります。停止の区分に移す際は、EC側のアカウントも同時に止め、発注できる経路が残っていないかを確かめます。停止したはずの得意先に受注が入っていないかという点検は、月次の項目に入れておきたいところです。

担当者情報の管理は、法令上の取扱いの範囲で決めます。取得した個人情報は、利用する必要がなくなったときに遅滞なく消去するよう努める旨が示されており^*3、努力を求める規定として整理されています。異動や退職の連絡を受けたときに台帳の連絡先をどう扱うか、保持の期間をどう考えるかを、運用の文書に書き残します。担当者の一覧を業務の必要を超えて広く共有しない取り決めも、併せて決めます。

定期点検は、指標を決めて数の推移を見る形にすると続きます。重複候補の件数、入力が求められる項目が空欄のレコードの件数、停止区分の得意先に入った受注の件数を月次で数え、増減の理由を確認します。請求のための登録番号は、公表システムのWeb-API機能で状態を照合でき^*2、失効や取消の検知に使えます。点検の結果を1枚にまとめ、申請の運用の見直しへつなげます。

自社だけで運用を回す場合と、外部の支援を組み合わせる場合の違いは、判断の記録の残り方に出ます。業務の理解、データの整備、EC側の会員の設計、電子的な受発注の仕様という四つの領域を限られた人数で兼務すると、点検が後回しになりがちです。外部に委ねる場合も、コードの体系と正とするデータの決め方は自社で決め、決めた理由を文書に残す形が続きます。委託の範囲を段階ごとに区切ると、途中からでも組み替えられます。

よくある質問

得意先コードの桁数はどのように決めればよいですか

将来の登録件数の見込みに余裕を持たせた桁数とし、桁に分類の意味を割り当てない形が扱いやすいです。地域や業種を桁で表すと、拠点の移転や事業内容の変化でコードと実態がずれ、振り直しが過去の伝票や外部との取り決めに影響します。分類は属性の項目で持ち、コードは識別だけに使う決め方にしておくと、見直しが属性の付け替えで済みます。

法人番号だけで名寄せは完結しますか

完結しません。法人番号は13桁で1つの法人に1つ指定され、商号や所在地が変わっても変わらないため照合キーに向いていますが^*1、指定の対象は登記された法人などに限られます。個人で事業を営む相手には指定されず、企業単位の番号では事業所を区別できません。事業所の単位で突き合わせる場合は、13桁のGLNなどを併せて持つ方法があります^*5。

適格請求書発行事業者の登録番号は得意先マスタに持つべきですか

請求と支払の突合に使うため、項目として持つ形が扱いやすいです。法人の登録番号は記号のTと13桁の法人番号を組み合わせた形で表されます。公表システムのWeb-API機能を使えば登録の状態を自社のシステムから照合できるため^*2、照合した日付を記録し、取消や失効が起きた場合に検知できる運用にしておくと確認の手間が減ります。

取引が止まった得意先のレコードは削除してよいですか

削除ではなく停止の区分で扱う形が無理がありません。過去の伝票が参照しているレコードを消すと、履歴の確認や請求書の再発行に手間がかかります。停止の際はEC側のアカウントも同時に止め、発注の経路が残っていないかを確かめます。担当者の連絡先は個人情報にあたり得るため、利用する必要がなくなった後の消去に努める旨に沿って扱います^*3。

EC側で得意先を新規に登録できる形にしてもよいですか

そのまま得意先として登録する形は、重複の入口を増やします。EC側の登録は申込のデータとして受け取り、商号のカナ、所在地、法人番号で既存の得意先と照合してから基幹側で採番し、その後に会員を有効化する流れが安全側です。照合で候補が出た場合は人が確認する手順を挟むと、同じ企業が別のコードで生まれる事態を抑えられます。

1. *1　出典：国税庁「法人番号とは（国税庁法人番号公表サイト）」（2026年9月確認）　経路
2. *2　出典：国税庁「適格請求書発行事業者公表システムWeb-API機能」（2026年9月確認）　経路
3. *3　出典：個人情報保護委員会「よくある質問「取得した個人情報は、いつ廃棄しなければなりませんか。」」（2026年9月確認）　経路
4. *4　出典：流通BMS協議会（一般財団法人流通システム開発センター）「流通BMS標準仕様」（2026年9月確認）　経路
5. *5　出典：一般財団法人流通システム開発センター「GLN（企業・事業所識別コード）」（2026年9月確認）　経路
6. *6　出典：一般社団法人全国銀行資金決済ネットワーク「全銀EDIシステム（ZEDI）とは」（2026年9月確認）　経路
7. *7　出典：SAP「得意先マスタデータ管理」（2015年）　経路