得意先マスタとは｜粒度とコード体系の決め方

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

B2B EC-COLUMN

得意先マスタとは何か ― 販売先を一意に識別する基本データ

得意先マスタとは、商品やサービスの販売先を一意のコードで識別し、名称・所在地・取引条件・請求先などの情報を、受注から請求までの各業務が共通して参照できる形で保持する基本データです^*3。設計の要は項目数ではなく、法人・請求先・納品先の3層に分ける粒度と、変更ルールを持つコード体系の2点にあります。

定義と、受注から請求までのどこで参照されるか

得意先マスタは、受注入力・与信確認・出荷指示・請求書発行という一連の業務が同じレコードを参照する土台です。ここでいう「マスタ」とは、各業務システムが共通して参照する基本データを指します。受注時に参照する得意先コードと、請求書発行時に参照するコードが一致しないと、二重登録や請求先の取り違えが起こります。

だからこそ、得意先マスタは受注管理・請求・与信管理のどのシステムからも同じ粒度・同じコードで参照できるように設計する必要があります。

得意先マスタ・取引先マスタ・顧客マスタ・仕入先マスタとの違い

「得意先マスタ」と似た呼び方に、取引先マスタ・顧客マスタ・仕入先マスタがあります。何を管理する台帳かを整理すると、次の表のとおりです。

設計で決めるべきは項目の数ではなく「粒度」と「コード」の2点である

得意先マスタの検討では、項目を並べる作業から着手しがちです。しかし項目を決める前に、何を1件のレコードとするか（粒度）と、そのレコードをどう識別するか（コード）を先に決めておく必要があります。

この2点が固まっていないまま項目を増やすと、後から同じ会社が複数件に分かれて登録される、コードの意味が実態とずれるといった問題が起こります。次章から、粒度とコードの決め方を順に見ていきます。

何を「1件」とするか ― 粒度を3層で決める

法人の層 ― 法人番号を参照キーにする

法人の層は、法人番号を参照キーとする設計が有効です。国税庁は法人番号について「法人番号は、株式会社などの法人等が持つ13桁の番号です」と説明しています^*3。あわせて、商号又は名称・本店又は主たる事務所の所在地・法人番号を基本3情報として公表しています^*3。

法人番号は「利用範囲の制約がなく、誰でも自由に利用できます」とされており^*3、自社マスタの参照キーとして使えます。ただし法人番号は法人にしか付与されないため、個人事業主の得意先には対応する番号がありません。全得意先を法人番号だけで管理する設計は成立しない点に注意が必要です。

請求先の層 ― 適格請求書の記載事項が根拠になる

請求先の層は、適格請求書（インボイス制度で消費税額等の記載が定められた請求書）の記載事項が判断材料になります。消費税法第57条の4第1項は、適格請求書に記載する事項の一つとして「書類の交付を受ける事業者の氏名又は名称」を第六号に挙げています^*6。

請求書の宛先は法令が記載を求める事項であり、納品場所と一致しない場合は請求先を独立した層として扱う根拠になります。発注元と支払元が異なる帳合取引のような商習慣では、この層分けが特に重要になります。

納品先の層 ― GLNで場所を識別する

納品先の層は、一般財団法人流通システム開発センター（GS1 Japan）が管理するGLN（Global Location Number、事業者・部門・場所を識別するGS1識別コード）が参考になります。GLNは「『GS1事業者コード』＋『ロケーションコード』＋『チェックデジット』の13桁で構成されます」^*4。

識別対象は「①事業者（法人、団体、個人事業主など）②部門（経理部、人事部など）③物理的な場所（事業所、工場、物流センター、店舗など）④電子的な場所（システムのアクセスポイントなど）」の4種類です^*4。設定単位は「本社、支社、支店、営業所、店舗、工場、物流センター、倉庫等および事業部門」とされています^*5。

層を分ける・分けないの判断基準

層を分けるかどうかは、次のいずれかに当てはまるかで判断します。第一に請求の締めが法人単位と異なる場合、第二に与信枠を層ごとに別で見る場合、第三に納品場所が複数ある場合です。いずれにも当てはまらず、表示名が違うだけであれば、層を分けずに1件で管理して構いません。

層の分け方を誤ると、請求書の宛先間違いや同一得意先の二重登録といった手戻りにつながります。自社の商習慣に合わせて分け方を確認するには、無料相談で要件を整理するのが近道です。

得意先コードの設計 ― 意味を持たせず、変えない

コードに意味（地域・業種・ランク）を埋め込まない理由

得意先コードに地域や業種、ランクといった属性の意味を埋め込む設計を見かけますが、避けるべきです。理由は、属性は時間の経過とともに変わるためです。得意先が移転したり業種区分が変わったりするたびにコードを付け替えると、過去の伝票が参照するコードの意味が入れ替わり、履歴を正しく追えなくなります。

コードには意味を持たせず、名称・住所・業種といった属性は別項目として持たせる設計にすると、属性が変わってもコード自体は変更せずに済みます。

桁数と検査数字 ― 誤入力を機械で弾ける設計にする

桁数を一律に定める公的な基準はありませんが、参考になる仕様はあります。総務省の全国地方公共団体コード仕様は、「５桁のアラビア整数に、１桁の検査数字（□の枠の中に入れて記載）を加え、６桁とする」と定めています^*1。都道府県を表す第1桁・第2桁は「01から47までの連番号」と定められています^*1。

GLNもモジュラス10（10で割った余りを使う計算方式）のチェックデジットを持ちます^*4。検査数字やチェックデジットを含めておくと、入力ミスをシステム側で機械的に検知できます。

変更のルール ― 名称変更は据置、実体変更は新設と欠番

コード設計で最も判断に迷うのが、変更時の扱いです。総務省の全国地方公共団体コード仕様は、名称が変わっただけの場合について「市町村の名称変更の場合：コードは、名称変更前のコードとする」と定めています^*1。つまり名称変更ではコードを据え置きます。

一方、合併や分割のように対象の実体そのものが変わった場合は、「関係市町村の従前のコードは、欠番とする」とされ^*1、新しい主体には新しいコードを新設します。この仕様は地方公共団体のコードを対象とした規定であり、得意先コードに直接適用される規則ではありません。ただし、名称変更と実体変更を区別してコードの扱いを決めるという考え方は、得意先コードの設計にそのまま参考にできます。

得意先に置き換えると、社名変更や移転だけならコードは据え置き、合併や分社のように会社そのものが変わる場合は新設して旧コードを欠番にする運用になります。なお同仕様は、一部事務組合等のコードについては番号が上限に達した場合に欠番を再利用すると定めていますが^*1、得意先コードでは欠番を再利用しない設計が無難でしょう。過去の伝票が参照していたコードの意味が、別の得意先にすり替わってしまうためです。

移行時に旧コードを持ち込むか

基幹システムを刷新する際、旧システムの得意先コードをそのまま新コードとして使い回したくなりますが、慎重に判断すべきです。旧コードの体系が新しいコード体系の設計方針（意味を持たせない、桁数、検査数字の有無）と異なる場合は、コードを付け替えず、旧コードを「legacy_code」のような別項目として残す設計だと、対応関係の作り直しを避けられます。

コードを付け替えると、過去伝票との対応関係を作り直す作業が発生し、移行工程全体の負荷が増えます。

マスタ本体に持たせるもの・持たせないもの

得意先マスタに持たせる項目は、由来ごとに整理すると管理しやすくなります。項目の一覧化はここでは扱わず、どこに置くべきかの判断だけを示します。

4系統で棚卸しする

得意先マスタの項目は、①識別（コード・名称）②所在・連絡（住所・電話）③取引条件（掛率・与信枠）④担当者・個人情報の4系統に分けて棚卸しすると、どこに置くべきかを判断しやすくなります。

取引条件はマスタ本体に直接持たせない

掛率・単価・与信枠といった取引条件は、期間によって変わるという性質があります。マスタ本体の項目を上書きする設計にすると、条件変更のたびに過去の値が消え、当時の伝票を正しく再現できなくなります。

取引条件は、有効期間を持つ別テーブルに分離し、得意先マスタからは参照する形にすると、過去の値を保持できます。

担当者情報は個人情報として区別する

個人情報保護法第22条は、「個人データを正確かつ最新の内容に保つとともに、利用する必要がなくなったときは、当該個人データを遅滞なく消去するよう努めなければならない」と定めています^*8。これは努力義務であり、義務として一律に消去を強制する規定ではありません。

ただし、退職した担当者の個人データを消去せず残し続けることは、この努力義務の趣旨に沿いません。得意先マスタの担当者欄は、法人・請求先・納品先の情報とは別区分で管理し、異動・退職のたびに見直す運用にすると整合します。

住所は全国地方公共団体コードを併せ持つ

住所欄には、都道府県コード・市区町村コードから成る全国地方公共団体コードを併せて持たせておくと、地域単位の集計や名寄せが安定します^*1。総務省は同コードについて「都道府県コード及び市区町村コードは、情報処理の効率化と円滑化に資するため、コード標準化の一環として…設定した」と説明しています^*2。

外部の識別コードと突き合わせる ― EDIで繋ぐ前提を先に置く

自社コードを外部コードに置き換えない

法人番号やGLNといった外部の識別コードは、自社の得意先コードをそのまま置き換える対象にはしません。自社コードは自社コードとして残し、法人番号・GLNは「参照キー」として別項目で持たせる設計にします^*3*4。こうしておくと、外部との照合が必要な場面だけ参照キーを使い分けられます。

流通BMSでEDI連携する前提を持つ

EDI（電子データ交換。企業間で電子的に取引データをやり取りする仕組み）で相手先とコードを突き合わせる場面も想定しておく必要があります。一般財団法人流通システム開発センター（GS1 Japan）と流通システム標準普及推進協議会（流通BMS協議会）は、流通BMS（消費財流通業界向けのEDI標準仕様）を「メッセージ（電子取引文書）と通信プロトコル/セキュリティに関するEDI標準仕様」と説明し、消費財流通業界の標準となることを目標に策定していると述べています^*7。

流通BMSは消費財流通業界を対象とし、基本形のほかに百貨店版・生鮮業界編といった業界別の仕様・ガイドラインが公開されています^*7。同協議会の推計では、卸・メーカーの流通BMS導入企業数は2025年6月1日時点（第28回推計）で21,600社以上とされ、この半年間で700社以上増加したと公表されています^*7。得意先が消費財流通業界に属する場合は、EDIでコードを突き合わせる前提でマスタを設計する必要があります。

法人番号はWeb-APIとダウンロードで一括取得できる

法人番号は、国税庁法人番号公表サイトの検索に加えて、Web-APIやCSV形式・XML形式でのダウンロードが用意されています^*3。マスタに登録済みの商号・所在地と法人番号公表サイトの情報を突き合わせれば、表記ゆれの点検にも使えます。

得意先マスタを腐らせない運用

変更履歴を残す

得意先マスタは、登録して終わりではなく、社名変更・移転・担当者交代のたびに更新が発生します。上書きだけの運用にすると、いつ・誰が・何を変えたかという過去の状態が消えてしまいます。変更履歴を項目単位で残す設計にしておくと、後から問い合わせがあった際にも当時の状態を確認できます。

重複が出たときは統合の手順に沿って寄せる

粒度とコードの設計が固まっていても、入力ミスや部署ごとの個別登録によって重複レコードが発生することがあります。重複した複数のレコードを1件に寄せる作業は、突合キーの選定や表記ゆれの吸収を含む別の工程になるため、本記事では扱いません。

取引が終わった得意先は削除せず使用停止にする

取引が終了した得意先を物理的に削除すると、過去の伝票が参照先を失い、履歴が確認できなくなります。削除ではなく「使用停止」のステータスを持たせ、伝票からの参照は残したまま新規の受注入力だけを止める設計にします。使用停止にした得意先のコードは欠番のまま残し、再利用しない運用にします。

登録・更新の責任者を1か所に決める

得意先マスタの登録・更新権限が複数部署に分散していると、同じ得意先が別々の担当者によって重複登録される原因になります。登録・更新の責任者を1か所に決め、承認フローを一本化しておく必要があります。

得意先マスタの設計を内製で完結させるには、消費税法や個人情報保護法などの関連法令の知識に加えて、EDI標準やコード体系の設計経験が求められます。基幹システムと受発注システムの両方のデータ構造を理解した担当者が、情シス・営業事務・EDI担当を横断して合意形成する工程になります。専門パートナーに相談すると、他社の商習慣で得た設計の型を踏まえて選択肢を整理できる点が、内製だけで検討する場合との違いです。

まとめ：得意先マスタ設計の3つの判断軸

本稿では、得意先マスタの設計で先に決めるべき論点を整理しました。要点は3つに集約できます。第一に、法人・請求先・納品先という粒度の3層を先に決めることです。第二に、コードには意味を持たせず、名称変更は据え置き、実体が変わったときは新設と欠番で扱うことです。第三に、取引条件や担当者情報をマスタ本体に直接持たせず、別区分で管理することです。この3点を先に決めておくと、パッケージ選定や移行設計の判断が速くなります。

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

よくある質問

得意先マスタと取引先マスタは何が違いますか。

取引先マスタは、得意先と仕入先の両方を包含する上位概念として使う企業が多く見られる台帳です。得意先マスタは、そのうち販売方向を切り出した台帳に当たります。呼称は企業ごとに異なるため、自社でどちらの意味で使っているかを確認してください。

得意先コードは何桁にすればよいですか。

桁数を一律に定める公的な基準はありません。ただし全国地方公共団体コードは5桁のアラビア整数に検査数字1桁を加えた6桁で構成され^*1、GLNもモジュラス10のチェックデジットを持ちます^*4。将来の増加余地と誤入力を検知できる桁を確保する設計が参考になります。

得意先の社名が変わったら、コードも変えるべきですか。

総務省の全国地方公共団体コード仕様は、名称変更の場合はコードを据え置くと定めています^*1。得意先コードにも同じ考え方を参考にでき、社名変更や移転だけならコードは変えず、合併や分社のように実体が変わったときに新設して旧コードを欠番にする設計が整合します。

得意先コードに法人番号をそのまま使ってよいですか。

法人番号は法人にしか付与されず、個人事業主の得意先には対応する番号がありません^*3。全得意先を法人番号だけで管理することはできないため、自社コードは別に持ち、法人番号は参照キーとして併記する設計が現実的です。

支店ごとに得意先を分けて登録すべきですか。

請求の締めが別、与信を別に見る、納品場所が複数あるといった条件に該当する場合は、支店単位で層を分ける根拠になります。GLNも本社・支社・支店・営業所・店舗・工場・物流センター・倉庫等の単位で設定する仕組みです^*5。表示名が違うだけであれば、分けずに済みます。

1. *1　出典：総務省「全国地方公共団体コード」仕様（平成19年4月1日）
2. *2　出典：総務省「全国地方公共団体コード（地方行政のデジタル化）」（一覧表は令和6年1月1日更新）
3. *3　出典：国税庁「法人番号とは（国税庁法人番号公表サイト）」
4. *4　出典：一般財団法人流通システム開発センター（GS1 Japan）「GLN（企業・事業所識別コード）」
5. *5　出典：一般財団法人流通システム開発センター（GS1 Japan）「GLNの設定」
6. *6　出典：e-Gov法令検索「消費税法（昭和六十三年法律第百八号）第57条の4」（2026-04-01施行版）
7. *7　出典：流通システム標準普及推進協議会（流通BMS協議会／GS1 Japan）「流通BMS標準仕様」（基本形Ver2.2／メッセージ別項目一覧ver2.2.2・2025年7月15日再修正版／導入企業数は2025年6月1日時点・第28回推計）
8. *8　出典：e-Gov法令検索「個人情報の保護に関する法律（平成十五年法律第五十七号）第22条」（2026-07-17施行版）