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

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

B2B EC-COLUMN

得意先マスタとは

得意先マスタとは、商品やサービスを販売する相手を一意の得意先コードで識別し、商号・所在地・請求条件・与信枠などを一元的に管理する台帳です。受注から出荷、請求、入金消込までの伝票は、この台帳の1件を参照して処理されます。販売管理の基幹システムとBtoB ECサイトで台帳の粒度が食い違うと、売上集計と与信の判断が分かれてしまいます。まず「誰を1件と数えるか」を決めておくことが、後の連携の前提になります。

台帳が担う役割は3つに整理できます。第一に、受注や出荷の伝票がどの相手のものかを識別する役割です。第二に、締日や支払条件といった請求の前提を伝票へ引き渡す働きがあります。第三に、与信枠や掛率のように取引ごとに変わる条件を保持し、価格と出荷の判断に使われます。3つがそろっていれば、担当者ごとの判断のばらつきを抑えられるでしょう。

顧客マスタ・取引先マスタとの違いは、対象範囲と粒度にあります。顧客マスタは見込み客や会員を含む広い範囲を指し、請求先を持たない場合もあります。取引先マスタは販売先と仕入先の双方を1つの台帳へ収める呼び方で、債権と債務の両側を扱う点が特徴です。得意先マスタは債権側に絞り、請求と回収の条件まで保持します。呼び名の違いではなく、どの業務が参照するかで整理すると設計の議論が進みます。

販売先と仕入先を1件へまとめるか、分けて持つかは、相殺取引の有無で判断が変わります。同じ相手と売りと買いの双方があるなら、共通の企業コードを親に置き、得意先と仕入先を子として持つ形が扱いやすくなるでしょう。債権と債務を同じコードで混ぜると、残高の照合や与信枠の計算が入り組みます。分けて持つ場合でも、親のコードで名寄せできる状態は保っておきます。

代表的な基幹システムの公式文書では、得意先のデータが一般データ・会社コードデータ・販売エリアデータの3つの階層に分けて保持されます^*8。商号や所在地は全社で共通、支払条件は会社コード単位、価格や出荷条件は販売エリア単位という分け方です。1件の得意先に対して条件が複数あり得る前提を設計の初めに置くと、後戻りが減ります。階層を持たない台帳へ支店別の条件を押し込むと、値の上書きが起こります。

どこまでを1件と数えるかは、法人単位か事業所単位かで分かれます。法人番号は13桁で構成され、商号・所在地・法人番号の3つの情報が公表制度のもとで公開されています^*1。法人単位の識別はこの番号で足りますが、支店ごとに請求を分ける取引では事業所の粒度が要ります。親を法人、子を事業所とする2階層で持てば、集計と請求の双方に対応できます。

粒度の決め方は、売上を集計したい単位と請求書を出す単位のどちらを優先するかで変わります。集計を優先して法人単位へまとめると、支店別の与信や納品条件を持てなくなります。請求を優先して事業所単位に割れば、同じ法人の与信枠が分散してしまうでしょう。与信は親、請求は子で管理する折衷案を採り、その根拠を設計書へ残しておきます。

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

得意先マスタに持たせる項目は、基本情報・請求条件・取引条件・担当者情報の4区分で整理すると過不足を確かめやすくなります。基本情報は相手を識別するための項目、請求条件は請求書を正しく出すための項目です。取引条件は価格と与信の判断に使い、担当者情報は連絡と承認の経路を示します。項目を足す前に、どの区分に属し誰が更新するのかを決めておけば、台帳の増改築を繰り返さずに済みます。

基本情報には、得意先コード、商号、所在地、電話番号、法人番号を持たせます。法人番号は13桁で、公表制度で確認できる商号・所在地とあわせて照合に使えます^*1。商号は株式会社の前後、全角と半角、旧字体の扱いで表記が割れやすい項目です。入力形式を1つに定め、正規化した値を別項目へ持たせると突合が安定するでしょう。

請求条件には、請求先コード、締日、支払条件、振込手数料の負担区分、登録番号を持たせます。適格請求書の登録番号は「T」に続く13桁で表され、法人ではその13桁に法人番号が使われる形です^*2。納品先と請求先が異なる取引では、両者を別の項目として保持します。1つの項目へ兼務させると、宛先を誤ったときの原因追跡に時間がかかります。

取引条件には、与信枠、掛率または価格区分、出荷条件、取引通貨、休眠の別を持たせます。価格は得意先ごとに変わるため、単価そのものではなく価格表と掛率で保持すると改定に耐えます。与信枠は法人単位、出荷条件は納品先単位というように、項目ごとに適用の粒度が異なる点にも注意が要ります。粒度の違いを1つの表へ押し込めると、支店ごとの条件が上書きされてしまいます。

担当者情報には、営業担当、受注窓口の連絡先、承認者を持たせます。担当者の氏名や連絡先は個人情報にあたるため、保管の期間と消去の扱いを定めておく必要があります。利用する必要がなくなった個人データは遅滞なく消去するよう努める旨が、法第22条に定められています^*3。退職や異動の連絡を受けたときの更新手順まで含めて設計しておきましょう。

4区分の項目と設計上の留意点を並べると、次のとおりです。

<!– SVG_FIGURE {"type":"table","caption":"得意先マスタに持たせる項目の4区分と設計上の留意点","alt":"得意先マスタの項目を4つの区分で並べた表です。基本情報は得意先コードや商号、法人番号を持ち、入力形式を1つに定めて正規化した値を別項目へ持たせます。請求条件は請求先コードや締日、登録番号を持ち、納品先と請求先を別の項目として保持します。取引条件は与信枠や掛率、出荷条件を持ち、項目ごとに適用の粒度が異なる点を前提にします。担当者情報は営業担当や受注窓口の連絡先、承認者を持ち、保管の期間と消去の扱いを定めます。","columns":["区分","主な項目","設計上の留意点"],"rows":[["基本情報","得意先コード、商号、所在地、法人番号","入力形式を1つに定め、正規化した値を別項目へ持たせます"],["請求条件","請求先コード、締日、支払条件、登録番号","納品先と請求先を別の項目として保持します"],["取引条件","与信枠、掛率、出荷条件、休眠の別","項目ごとに適用の粒度が異なる点を前提にします"],["担当者情報","営業担当、受注窓口の連絡先、承認者","保管の期間と消去の扱いを定めます"]]} –>

項目を増やすときは、その値を使う画面と帳票を先に確かめます。使い道の定まらない自由記述欄は、担当者ごとの覚え書きで埋まり、後から意味を読み取れなくなるためです。追加の可否を決める基準を運用の定めへ書いておけば、項目数の膨張を抑えられるでしょう。既存の項目についても、参照されていないものを毎年の見直しで整理します。

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

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

得意先マスタの乱れは、売上集計・与信・請求の3つへ同時に及びます。同じ法人が別コードで二重に登録されると、売上は2件に分かれ、与信枠も二重に与えられてしまいます。請求先と納品先の取り違えは、請求書の再発行と入金消込のずれを招きます。電子取引では識別コードが一致せず、着信した伝票の紐付けを人手で埋める場面も生まれるでしょう。乱れの影響は、登録件数が増えるほど後戻りの手間として表れます。

重複登録は、受注窓口ごとに新規登録が許されている運用で起きます。同じ法人に対して支店名や旧商号で別の1件が作られ、売上の集計単位が割れてしまうためです。与信の判断も台帳の1件ごとに下されるため、法人としての残高を把握できません。回収が滞ったとき、どのコードで出荷を止めるべきかの判断が遅れます。

与信の分断は、出荷を止める判断の遅れとして表れます。与信枠を超えた受注を検知できないまま出荷すると、回収不能の債権が積み上がるおそれがあります。出荷後の値引きや返品の処理も、対象の得意先を特定できなければ確定しません。台帳の整合は、経理の締め作業の前提でもあると言えます。

請求先・納品先の誤りは、項目の兼用から生じます。納品先を請求先の項目へ書き込んでいると、請求書の宛先が現場の住所になってしまうためです。締日と支払条件を台帳ではなく担当者の記憶で運用している場合も、入金の遅れにつながります。請求に関わる項目は、変更のたびに承認の記録を残す扱いが向いています。

電子取引では、自社のコードだけで相手を特定できません。標準仕様に沿った受発注では、企業や事業所を識別する13桁のコードが用いられます⁵。この標準は版を重ねており、基本形のVer2.0は2018年11月に公開されたものです6。自社の得意先コードと相手側の識別コードの対応表がないと、着信データの割り当てに人手が要ります。

入金の消込も、台帳の乱れに影響を受けます。振込に添えられる情報の欄には制約があり、請求と入金の対応付けを人手で補う運用が残ってきました。商流の情報を電子的な形式で送受信する仕組みが用意されており、支払通知と請求の突合に使えます^*7。仕組みを取り入れる前提として、請求先の識別が台帳側でそろっている必要があります。

乱れを抱えたままサイトを新設すると、公開の直前に名寄せの作業が集中します。期限が迫った状態での統合は、判断の記録が残りにくく、後から復元しづらくなるためです。整備は連携の設計へ入る前に着手するほうが、手戻りを抑えられるでしょう。台帳の状態を先に測っておけば、必要な作業量の見立ても立てやすくなります。

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

コード設計では、得意先コードに意味を持たせず、意味は項目として別に持つ考え方が扱いやすくなります。業種や地域を桁へ埋め込むと、取引の変化のたびに付け替えが必要になり、過去伝票との対応が切れてしまうためです。名寄せでは、公表制度で確認できる番号を照合キーに据え、一致と保留の条件を先に決めます。どの台帳の値を正とするかを項目ごとに定めておけば、統合の判断が担当者によって揺れません。

意味を持たせないコード設計とは、連番や採番の規則だけでコードを決める方法です。桁へ情報を埋め込む方式には、一覧で見たときに判別しやすい利点があります。ただし業種の変更や担当地域の変更が起きると、コードの意味と実態がずれてしまいます。ずれを直すために付け替えれば、過去の伝票や集計の連続性が失われます。

桁数は、将来の登録件数から余裕を持って決めます。桁が足りなくなったときの拡張は、連携先の受け入れ仕様にも影響が及ぶためです。英字と数字を混ぜる場合、大文字と小文字の扱いや紛らわしい文字の除外を定めておきましょう。体系を決めた根拠を文書として残せば、引き継ぎのたびに議論を蒸し返さずに済みます。

照合キーの選定では、自社だけで完結しない番号を選びます。法人番号は13桁で、商号と所在地とあわせて公表制度で確認できます¹。適格請求書の登録番号は「T」に続く13桁で表され、法人ではその13桁に法人番号が使われる形です2。電子的な受発注で用いる13桁の識別コードも、突合の軸として使えます^*5。

名寄せの判定ルールは、一致・保留・不一致の3つに分けて定めます。法人番号が一致する場合は同一と見なし、商号と所在地だけが近い場合は保留へ回す形が現実的でしょう。保留分は人の目で確認し、判断の理由を記録として残します。ルールを決めずに機械的な統合へ進めば、別法人を1件へまとめる誤りが起こります。

正とするデータの決定は、台帳ごとではなく項目ごとに決めます。商号と所在地は公表制度の値、締日と支払条件は販売管理の値、連絡先はサイト側の値というように、採用元を項目単位で割り当てます。台帳を丸ごと採用すると、更新の新しい値が古い値で上書きされてしまいます。採用元の一覧を残しておけば、統合後に値の出どころをたどれます。

統合後の履歴保持では、旧コードと新コードの対応表を残します。過去の伝票や帳票は旧コードで記録されているため、対応表がなければ集計の連続性が切れてしまうためです。統合した日付と担当を記録に残すと、問い合わせを受けたときに経緯を説明できます。対応表は作業用の控えではなく、台帳の一部として保管しましょう。

<!– SVG_FIGURE {"type":"vflow","caption":"得意先コードの整理から名寄せまでの判断の順序","alt":"得意先コードを整理する順序を5段で示した図です。意味を持たせないコード設計から始め、照合キーの選定で突合の軸を決めます。次に名寄せの判定ルールを定め、正とするデータの決定へ進みます。最後に統合後の履歴保持として、旧コードと新コードの対応を残します。","steps":[{"label":"意味を持たせないコード設計","desc":"桁に業種や地域を埋め込まず、番号だけで採番します"},{"label":"照合キーの選定","desc":"公表制度で確認できる番号を突合の軸に据えます"},{"label":"名寄せの判定ルール","desc":"一致と保留の条件を決め、人の確認へ回す範囲を絞ります"},{"label":"正とするデータの決定","desc":"項目ごとにどの台帳の値を採るかを先に定めます"},{"label":"統合後の履歴保持","desc":"旧コードと新コードの対応を残し、過去伝票を追えるようにします"}]} –>

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

基幹システムとサイトの連携では、得意先マスタを基幹側の正の台帳とし、サイトへ片方向で配信する型が扱いやすくなります。双方で登録と更新を許すと、価格や与信の値がどちらの更新か判別できなくなるためです。サイト側は会員アカウントを持ち、そのアカウントを得意先コードへ結び付けて運用します。価格や掛率は得意先単位で出し分け、条件の適用範囲を階層で持たせておけば改定にも耐えます。

配信の型では、基幹側で登録・変更した内容を差分としてサイトへ渡します。サイト側は複製を保持し、参照だけに用いる位置づけとします。新規の取引先がサイトから申し込んだ場合は、仮登録として受け、基幹側で本登録してから配信する流れにしておきましょう。仮登録のまま受注できる作りにすると、与信のない出荷が生まれます。

EC会員アカウントと得意先コードの結び付けは、1対多で設計します。1つの得意先に購買担当が複数いる取引では、担当ごとにアカウントを発行し、いずれも同じ得意先コードへ紐付けます。承認者のアカウントには金額の上限や承認の権限を持たせ、担当者のアカウントと分けて扱います。退職や異動の連絡を受けたら、アカウントの停止と担当者情報の更新を同時に進めます。

価格・掛率・出荷条件は、得意先単位で出し分けます。公式文書に示された階層の考え方では、価格や出荷条件が販売エリアの単位で保持されます^*8。同じ法人でも販売の区分が違えば条件が変わる前提を、サイト側の表示にも反映させる必要があります。台帳の条件とサイトの表示価格がずれると、受注後の値引き処理が増えてしまうでしょう。

連携の方式は、更新の頻度と業務の許容範囲から選びます。与信枠のように出荷判断へ直結する項目は即時、商号の表記のように急がない項目は日次でそろえる分け方が現実的です。標準仕様に沿った電子的な受発注を併用する場合は、識別コードの対応表も同じ経路で配信します^*6。連携が失敗したときの再送と、順序が入れ替わったときの扱いも決めておきます。

配信の設計では、削除の扱いに注意が要ります。基幹側で消した得意先をサイト側でも消すと、過去の注文履歴が参照できなくなるためです。削除ではなく休眠の状態を配信し、サイト側は新規注文だけを止める作りにしておきます。状態の値と画面の挙動の対応を一覧にしておけば、問い合わせ対応の判断も早まります。

2025年6月26日に公表された国内のデジタル化の動向調査では、企業のデータ利活用の進み方が継続して調べられています^*4。データを事業へ生かす前提として、台帳の識別と粒度がそろっている状態が求められます。連携の仕組みだけを新しくしても、参照する台帳が割れていれば効果は限られるでしょう。基幹側の整備と連携の設計は、同じ工程として並べて進めます。

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

得意先マスタの整備は、現状の棚卸し、クレンジングと統合、移行と切り替えの3段階で進めます。棚卸しでは台帳の数と登録件数を数え、項目の埋まり方を測ります。クレンジングでは表記をそろえ、同一と見なす条件で重複の候補を洗い出します。移行では新旧の台帳を並べて結果を照らし合わせ、切り替え後も数日は登録と連携の状態を見守ります。段階を飛ばすと、判断の記録が残らないまま統合が進みます。

現状の棚卸しでは、登録件数の把握から始めます。販売管理、会計、名刺や表計算の控えなど、得意先の情報がどこに何件あるかを数え上げます。次に項目の充足率の確認として、法人番号や締日といった必須項目の空欄がどれだけあるかを測ります。件数と空欄の割合が分かれば、作業量の見立てを数字で示せます。

棚卸しでは、利用の実態も合わせて調べます。直近の取引がない得意先、請求先としてだけ使われている得意先、同一法人と見られる別コードの組み合わせを分類します。分類の結果は、統合の対象と対象外を分ける判断材料になります。件数の多い台帳ほど、分類の基準を先に決めておくと作業が滞りません。

クレンジングと統合では、表記ゆれの補正を先に進めます。株式会社の前後、全角と半角、番地の表記などを1つの形へそろえ、正規化した値を照合用の項目として持たせます。続いて重複候補の突合として、法人番号の一致、正規化した商号と所在地の一致という順で候補を抽出します。抽出した候補は保留として扱い、人の確認を経てから統合します。

登録番号の確認には、公表されている照会の仕組みを使えます。適格請求書発行事業者の公表事項は、外部から取得できる仕組みが用意されています^*2。取得した値と台帳の値を突き合わせれば、失効や商号変更の見落としを減らせるでしょう。照会の頻度と対象の範囲は、取引の件数に合わせて定めます。

移行と切り替えでは、並行稼働での照合を挟みます。旧台帳と新台帳の双方で受注から請求までの処理を進め、金額と宛先が一致するかを見比べます。差異が出た場合は、原因を項目単位で特定してから統合の規則へ反映させます。切り替え後の監視として、登録の誤りと連携の失敗を数日単位で確認する体制を敷いておきます。

<!– SVG_FIGURE {"type":"stage","caption":"得意先マスタを整備する3段階と各段階で進める作業","alt":"得意先マスタの整備を3段階で示した図です。現状の棚卸しでは登録件数の把握と項目の充足率の確認を進めます。クレンジングと統合では表記ゆれの補正と重複候補の突合を進めます。移行と切り替えでは並行稼働での照合と切り替え後の監視を続けます。","steps":[{"label":"現状の棚卸し","cards":[{"label":"登録件数の把握","desc":"台帳ごとの件数と重複の見込みを数えます"},{"label":"項目の充足率の確認","desc":"必須項目の空欄がどれだけあるかを測ります"}]},{"label":"クレンジングと統合","cards":[{"label":"表記ゆれの補正","desc":"商号や住所の書き方を1つの形へそろえます"},{"label":"重複候補の突合","desc":"同一と見なす条件で候補を抽出し確認します"}]},{"label":"移行と切り替え","cards":[{"label":"並行稼働での照合","desc":"新旧の台帳で結果が一致するかを見比べます"},{"label":"切り替え後の監視","desc":"登録の誤りと連携の失敗を数日単位で見ます"}]}]} –>

整備の期間は、台帳の数と登録件数、項目の空欄の割合で変わります。作業量を見立てる材料が棚卸しの数字ですから、最初の段階を省くと後の計画が崩れます。統合の判断は業務の知識を要するため、営業と経理の担当が確認へ加わる時間も見込んでおきます。段階ごとに完了の条件を決めておけば、途中で範囲が広がることを防げるでしょう。

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

整備した得意先マスタは、変更の申請、内容の承認、マスタへの反映、定期点検という流れで保ちます。誰でも直接登録できる状態に戻せば、重複と表記ゆれは短い期間で再び増えていきます。休眠先や解約先は削除せず、状態の値で区別して過去伝票をたどれるようにします。担当者情報は個人情報として扱い、保管の期間と消去の手順まで定めておく必要があります。

変更の申請では、申請者、変更する項目、変更の理由、根拠となる資料を残します。商号や所在地の変更であれば、公表制度で確認できる情報を根拠として添えます。申請の様式を1つに定めておけば、後から経緯を追う手間が減るでしょう。口頭やメールだけの依頼で更新すると、誤りが起きたときに原因を特定できません。

内容の承認は、項目の区分ごとに担当を分けます。基本情報は受注の窓口、請求条件と与信枠は経理、取引条件は営業の管理者というように、値の責任を持つ部署へ割り当てます。承認の記録は、いつ誰が何を認めたかが分かる形で保存します。マスタへの反映では、反映日と担当を記録し、連携先へ配信された結果まで確認します。

休眠先・解約先の扱いは、削除ではなく状態の変更で表します。削除すると、過去の売上や債権の集計が取れなくなるためです。休眠の状態にした得意先は新規の受注を止め、サイト側のアカウントも同時に停止します。取引が再開したときは、同じコードを再び有効にすれば履歴が連続します。

担当者情報の管理では、更新の契機を決めておきます。退職や異動の連絡を受けた時点で、連絡先の削除とアカウントの停止を進めます。利用する必要がなくなった個人データについては、遅滞なく消去するよう努める旨が法第22条に定められています^*3。保管の期間と消去の手順を運用の定めへ書き、点検の対象へ含めておきましょう。

定期点検では、休眠の候補と番号の状態を見直します。直近の取引がない得意先を抽出し、休眠へ移すかどうかを営業の担当と確認します。登録番号については、公表されている照会の仕組みで失効や変更の有無を突き合わせられます^*2。点検の周期と担当を決めておけば、月次の締めや年度末の作業と重ならずに済みます。

この運用を内製で回すには、販売管理の業務知識、コード体系と連携の設計、データ移行の3つの技能が要ります。加えて、統合の判断へ営業と経理の担当が加わる時間も見込む必要があります。外部の支援を受ける場合、台帳の測定、統合規則の設計、移行の手順づくりを分担し、社内は判断と承認へ集中できます。内製と委託のどちらを選ぶかは、登録件数と連携先の数、切り替えまでの余裕から判断すると整理しやすいでしょう。

<!– SVG_FIGURE {"type":"flow","caption":"得意先マスタの登録・変更を承認する運用の流れ","alt":"得意先マスタの更新を4段で示した図です。変更の申請から始まり、内容の承認、マスタへの反映と進みます。最後に定期点検として休眠先と登録番号の状態を見直します。","steps":[{"label":"変更の申請","desc":"申請者と理由を残します"},{"label":"内容の承認","desc":"営業と経理が分担します"},{"label":"マスタへの反映","desc":"反映日と担当を記録します"},{"label":"定期点検","desc":"休眠先と番号を見直します"}]} –>

よくある質問

既存の得意先コードは新しい体系へ付け替えるべきですか

既存コードは残し、新しい体系は名寄せ後の統合先だけに適用する方法から検討します。全件を付け替えると、過去の伝票や帳票との対応が切れ、集計の連続性が失われるためです。桁数が不足している場合や、桁に業種などの意味を埋め込んでいる場合に限り、旧コードと新コードの対応表を残したうえで付け替えます。

BtoB ECサイトの会員アカウントは得意先1件につき1つにすべきですか

1つに絞る必要はなく、1つの得意先コードへ複数のアカウントを紐付ける設計が現実的です。購買の担当が複数いる取引では、担当ごとにアカウントを発行し、承認者には金額の上限や権限を別に設定します。退職や異動の連絡を受けたときは、アカウントの停止と担当者情報の更新を同じ手順の中で進めます。

取引が終わった得意先のデータは削除してよいですか

得意先の台帳そのものは削除せず、休眠や解約の状態で区別する扱いが向いています。削除すると過去の売上や債権の集計が取れなくなるためです。ただし担当者の氏名や連絡先は個人情報にあたり、利用する必要がなくなった個人データは遅滞なく消去するよう努める旨が法第22条に定められています^*3。台帳と個人情報を分けて考えます。

適格請求書の登録番号は得意先マスタで管理する必要がありますか

請求と仕入の処理で参照するため、台帳の項目として持たせておくほうが扱いやすくなります。登録番号は「T」に続く13桁で表され、法人ではその13桁に法人番号が使われます^*2。公表事項を外部から取得できる仕組みも用意されているため、失効や商号変更の有無を定期点検で突き合わせられます。

名寄せは自動の突合だけで完了できますか

自動の突合だけで完了させる進め方は避けます。法人番号のように一意の番号が一致する場合は自動で同一と見なせますが、商号と所在地が近いだけの組み合わせは別法人の可能性が残るためです。一致・保留・不一致の3つに分け、保留分は営業や経理の担当が確認し、判断の理由を記録として残す運用が現実的でしょう。

1. *1　出典：国税庁「法人番号とは（国税庁法人番号公表サイト）」（2026年9月確認）　経路
2. *2　出典：国税庁「適格請求書発行事業者公表システムWeb-API機能（インボイス制度適格請求書発行事業者公表サイト）」（2026年9月確認）　経路
3. *3　出典：個人情報保護委員会「よくある質問「取得した個人情報は、いつ廃棄しなければなりませんか。」（個人情報保護法第22条の努力義務）」（2026年9月確認）　経路
4. *4　出典：独立行政法人情報処理推進機構（IPA）「DX動向2025」（2025年6月26日公表）　経路
5. *5　出典：一般財団法人流通システム開発センター（GS1 Japan）「GLN（企業・事業所識別コード）」（2026年9月確認）　経路
6. *6　出典：流通BMS協議会（一般財団法人流通システム開発センター）「流通BMS標準仕様」（2026年9月確認・基本形Ver2.0は2018年11月公開）　経路
7. *7　出典：一般社団法人全国銀行資金決済ネットワーク「全銀EDIシステム（ZEDI）とは」（2026年9月確認）　経路
8. *8　出典：SAP「得意先マスタデータ管理（SAP公式文書）」（2015年）　経路