得意先マスタの多拠点管理｜重複登録と与信のズレを防ぐ設計と運用の考え方

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

B2B EC-COLUMN

複数拠点があると得意先マスタで何が起きるか——重複登録と情報不一致の正体

同じ取引先なのに、東京本社では「A商事株式会社」、大阪支店では「エー商事(株)」として別コードで登録されている。
請求書の締め日が拠点によって違い、与信限度額も片方だけ古いまま——多拠点で得意先マスタを扱っていると、こうした食い違いは珍しくありません。
この状況で最初に決めたくなるのが「拠点別に持つか、本社で一元管理するか」という二択ですが、実はこの立て方だと答えが出にくくなります。
ERPの得意先マスタ設計では、取引先を識別する基本情報を一元的に持ちながら、会社コードや販売エリアといった組織単位の情報だけを同じ得意先に紐づける構造が採られています²。
つまり「分ける／分けない」ではなく「何を共通にして、何を組織単位で持たせるか」を分けて考える。
この軸で、名寄せの基準、与信見直しの共通化、登録・変更権限の分担という順に整理していきます。

同じ取引先が拠点ごとに登録されるとどんな支障が起きるか

拠点ごとに得意先を登録できる状態は、現場から見れば合理的です。
大阪支店が新規の取引先と商談をまとめたとき、本社に登録を依頼して数日待つより、自分たちで登録して受注を入れたほうが早い。
この判断自体が間違っているわけではありません。
問題は、その取引先が実はすでに東京本社と取引のある会社だった、という場面で表面化します。

同じ法人に対して二つのコードが存在すると、まず売掛金の残高が分かれます。
東京側の債権が500万円、大阪側が300万円あっても、システム上は別々の取引先として集計されるため、「この会社に対していくら貸しているか」という全社の数字がどの画面にも出てきません。
与信限度額を各拠点が500万円と設定していれば、合計800万円の債権に対して、どちらの拠点も「限度内」と判断してしまいます。

次に、請求と入金の照合でつまずきます。
取引先の経理は自社を一つの会社として扱うため、東京分と大阪分をまとめて一本の振込にしてくることがあります。
受け取った側は、片方の請求書に対して金額が合わない入金として処理せざるを得ず、入金消込のたびに手作業の調整が発生します。
取引先から住所変更や商号変更の連絡が来たときも同じで、連絡を受けた拠点だけがマスタを直し、もう一方は旧住所のまま請求書を送り続けることになります。

拠点分散が引き起こす典型パターン

重複がどう生まれるかを見ていくと、いくつか繰り返し起きる形があります。
最も多いのは表記の揺れです。
「株式会社」と「(株)」、全角と半角、支店名を社名に含めるかどうか。
登録時に既存データを検索しても、入力した表記と登録済みの表記が違えばヒットせず、担当者は「まだ登録されていない」と判断して新規に作ります。

もう一つは、取引先の側にも拠点がある場合です。
「A商事 大阪支店」と「A商事 本社」を別々に登録している状態は、請求先が実際に分かれているなら妥当な運用ですが、請求は本社一括なのに納品先の違いで別コードを作ってしまうと、後から与信も債権も分散します。
納品先の違いなのか、請求の主体が違うのかを区別しないまま登録すると、この混乱が起きます。

三つ目は、システム更改やM&Aのタイミングです。
別々に運用していたシステムのデータを一つに寄せると、それまで表に出てこなかった重複が一度に可視化されます。
実際、重複した取引先データの名寄せ・統合を専門に請け負うマスターデータ管理サービスが商用で提供されている³という事実は、この作業が社内の片手間では済みにくい規模になりやすいことを示しています。

ここまでは、なぜ食い違いが起きるかという構造の話です。
では、どう持たせれば防げるのか。
ここで最初に挙げた二択に戻ります。

得意先マスタは拠点ごとに分けるべきか、一元管理すべきか

拠点ごとに完全に分けて持つ場合の弱点

拠点ごとにマスタを完全に分離する構成は、登録のスピードと現場の自由度という点では優れています。
拠点が独立採算に近い形で動いていて、扱う商材も取引先層も重ならないなら、この形でも当面は回ります。

ただし前節で見たとおり、取引先が重なった瞬間に、全社としての債権把握ができなくなります。
そしてこの「重ならない」という前提は、営業エリアの拡大や取引先自身の多拠点化によって、いつの間にか崩れます。
崩れたことに気づくのは、たいてい何かが起きた後です。

逆に、すべてを本社の一元管理にして、拠点からの登録を一切認めない形も検討されます。
重複は確実に減りますが、今度は登録の待ち時間が受注のスピードに直結します。
また、拠点によって与信の考え方や請求サイクルが違う実態があるとき、それを一つのレコードに押し込めようとすると、備考欄に条件を書き込むような運用に流れます。
備考欄の情報はシステムで集計も検証もできないため、結局は別の形の不整合になります。

「共通情報+拠点別属性」で一つの得意先を持たせるという考え方

この二択から抜ける手がかりが、ERP製品の得意先マスタの構造にあります。
SAPの得意先マスタデータ管理では、得意先マスタが一般データ、財務データ、販売エリア、会社コード、取引先担当者を含むデータで構成されると説明されています²。
ここで注目したいのは、これらが横並びの項目群ではなく、適用範囲の違う層として置かれている点です。

商号や住所といった一般データは、その取引先が誰であるかを決める情報なので、どの拠点から見ても同じである必要があります。
一方、会社コードや販売エリアは、自社のどの組織がその取引先とどう取引するかという情報です。
同じ得意先に対して、複数の販売エリアや会社コードの情報を持たせられる構造になっていれば、東京の販売エリアでは締め日を末日、大阪の販売エリアでは20日、といった実態の差をそのまま表現できます。
それでいて、識別の単位は一つなので、その取引先に対する全社の債権は集計できます。

つまり「分けるか、分けないか」ではなく、識別情報は一元化し、取引条件は組織単位で持たせる、という切り分けです。
なお、これはSAPの得意先マスタ管理アプリケーションにおける構成であり、すべてのERP製品が同じ層構造を採っているとは限りません²。
設計思想として参考にしつつ、自社で使っている、あるいは検討している製品がどこまでこの分離を表現できるかは、製品側の仕様として確認することになります。

この考え方を自社に当てはめるとき、最初に手を動かすべきなのは項目の棚卸しです。
いま拠点ごとに別々に持っている項目を並べて、「取引先が誰であるかを決める情報」と「自社のどの組織がどう取引するかの情報」に仕分けていく。
商号、住所、法人番号、代表者名は前者です。
与信限度額、支払条件、請求締め日、担当営業は、拠点によって実態が違うなら後者として扱う余地があります。

層の分け方が決まると、次に出てくるのが現実的な問題です。
すでに複数コードで登録されている取引先を、どうやって一つにまとめるのか。

拠点をまたぐ得意先をどう名寄せ・統合するか

名寄せで照合すべき項目

名寄せとは、表記や登録経路の違いで別々になっているデータを、同一の対象として突き合わせる作業です。
この作業の核心は、どの項目が一致したら「同じ取引先」と判定するかという基準づくりにあります。

信用調査会社が提供するマスターデータ管理サービスでは、名寄せの必須項目を商号と住所とし、そこに郵便番号・電話番号・代表者名を組み合わせて精度を高めるという実務が採られています³。
この組み合わせ方には理由があります。
商号だけでは同名の別法人を区別できず、住所だけでは同じビルに入る別会社を分けられません。
両方を軸に据えたうえで、補助項目で確度を上げていく構えです。

ただし、商号も住所も表記の揺れが最も出やすい項目でもあります。
照合の前に、法人格の表記を統一する、全角半角を揃える、住所の丁目・番地の書き方を正規化するといった前処理が必要になります。
この前処理をどこまでやるかで、後の目視確認の量が大きく変わります。

なお、この項目構成は東京商工リサーチのMDMサービスにおける実務であり³、すべての名寄せツールや手法が同じ基準を採っているわけではありません。
自社で使うツールがある場合は、そのツールが何をキーに突き合わせているかを把握したうえで、足りない補助項目を自社で追加できるかを見ます。

統合後に残す情報・見直す情報の判断

候補が出たあと、機械的に片方を消して終わり、とはいきません。
統合の判断で迷うのは、二つのコードに紐づく取引履歴と条件をどう扱うかです。

過去の受注・売上・入金の伝票は、旧コードを参照しています。
コードを統合するとき、過去伝票の参照先をどう付け替えるか、あるいは旧コードを残して新コードへの参照関係だけ持たせるかで、締めた会計期間のデータの扱いが変わります。
この点は使っているシステムの仕様に依存するため、統合の手順を決める前に、過去伝票がどう扱われるかを確認しておく必要があります。

条件面の統合は、もっと判断が分かれます。
東京側の支払条件が月末締め翌月末払い、大阪側が20日締め翌月10日払いだった場合、これを一本化するのか、組織単位の条件として両方残すのか。
前節の層分けの考え方に沿えば、実態として取引先と取り交わした条件が違うなら、組織単位の条件として保持するのが自然です。
逆に、単に登録時の慣習で違っているだけなら、この機会に取引先と確認して揃えたほうが、請求業務は簡素になります。

与信限度額は、統合時に特に注意が要ります。
東京500万円、大阪300万円を単純に足して800万円にすると、誰も800万円の与信判断をしていない限度額が生まれます。
統合を機に、その取引先に対する全社としての与信をあらためて設定し直す。
この判断をどの基準で行うかが、次の論点です。

与信限度額や請求条件をどう揃えるか——見直し基準を拠点間で共通化する

与信限度額を拠点裁量にするとどんな不整合が起きるか

名寄せが終わって取引先が一つのコードになっても、与信の運用が拠点任せのままだと、別の形で不整合が戻ってきます。

分かりやすいのは、見直しのタイミングのずれです。
東京支店は年度初めに全取引先の与信を見直す運用、大阪支店は決算書を入手したときだけ見直す運用だとすると、同じ取引先の与信限度額が、一方では直近の財務状況を反映し、一方では数年前の判断のまま置かれます。
統合後のマスタでは限度額は一つなので、どちらの判断を採るかを決めなければなりません。

もう一つは、判断の材料が揃わないことです。
大阪支店が「取引先の支払いが最近遅れがちだ」という感触を持っていても、それが東京側の判断材料になっていなければ、東京側は取引量を増やす判断をしてしまうかもしれません。
与信限度額という数字を一元化しても、その数字を動かす根拠が共有されていなければ、数字が実態から離れていきます。

ここで押さえておきたいのは、与信限度額を拠点別に持つべきか全社共通で持つべきかを直接論じた資料は、今回の範囲では確認できていないという点です。
金額そのものの持ち方は、業種や取引形態、拠点の独立性によって妥当な形が変わります。
ただ、金額の持ち方とは別に、見直しの基準とタイミングを揃えることは、どの持ち方であっても効いてきます。

見直し頻度をリスクに応じて揃える

与信管理の実務では、見直し頻度を取引先のリスクレベルに応じて使い分ける考え方が示されています。
大口取引先や要注意先の与信限度は、年2回見直すなど管理レベルを上げることが好ましいとされます¹。
この「リスクに応じて頻度を変える」という骨格が、拠点間で基準を揃えるときの出発点になります。

なぜ骨格として使えるかというと、揃えるべきなのは「全社で一律に何回見直す」という回数ではなく、「どういう取引先をどの頻度で見直すか」という区分の仕方だからです。
東京と大阪で大口の定義が違えば、同じ取引先が片方では年2回の対象、片方では対象外になります。
取引額の閾値、要注意先とする条件、決算書の入手時期といった区分の物差しを共通化しておけば、どの拠点が担当していても同じ取引先は同じ頻度で見直されます。

なお、年2回という頻度は大口取引先・要注意先を対象とした一般的な与信管理の考え方として示されたもので¹、業種や取引額を問わず一律に当てはまる基準ではありません。
また、この数字は限度額の金額水準や、拠点別と全社共通のどちらが優れているかを示すものでもありません。
自社の取引先構成に照らして、どのリスク区分をどの頻度で見るかは、あらためて設計することになります。

請求条件についても、考え方は同じです。
締め日や支払サイトは取引先と取り交わした個別の条件なので、全社で一律にはできません。
ただ、条件を変更するときに誰の承認が要るか、変更をいつからの請求に反映するかというルールは、拠点をまたいで共通化できます。
ここが揃っていないと、同じ取引先の請求条件が拠点ごとに別のタイミングで更新され、また食い違いが生まれます。

登録・変更のルールをどう運用に落とし込むか

共通ルールとして文書化しておきたい項目

層の分け方を決め、名寄せの基準を定め、与信の見直し頻度を揃える。
ここまでやっても、誰がどの項目を登録・変更できるかが決まっていなければ、数か月で元の状態に戻ります。
新しい担当者が着任したとき、参照できるものが何もなければ、その人は自分の判断で登録するしかないからです。

文書化しておく価値が高いのは、判断が分かれる場面のルールです。

このうち、新規登録の前に既存データを検索する手順は、最も効果が見えやすい部分です。
前節までで見たとおり、重複の多くは「検索したがヒットしなかった」ことから生まれます。
商号の一部だけで検索する、法人格を外して検索する、電話番号や住所でも検索する、といった手順を具体的に書いておくと、担当者ごとの検索の粗さがそろいます。
これで重複がゼロになるとは言えませんが、少なくとも「検索の仕方を知らなかったために作られた重複」は減らせます。

納品先違いと請求先違いの区別も、文書化しておきたい項目です。
取引先の支店に納品するが請求は本社一括、という形をどう登録するか。
ここを個別判断に任せると、同じパターンでも担当者によって別コードになったり納品先情報として登録されたりします。
前半で整理した層の分け方に照らせば、請求の主体が同じなら識別情報は一つ、納品先は組織単位あるいは伝票単位の情報として持つ、という整理になります。

承認権限は内部統制方針に照らして検討する

では、登録・変更の承認権限は本社に集中させるべきか、拠点に委譲すべきか。
この点について、どちらが適切かを直接裏づける資料は今回確認できませんでした。
ここで一般論としての優劣を書くことはできますが、それは根拠のない断定になります。

代わりに言えるのは、この判断が自社の内部統制の考え方に強く依存するということです。
マスタの変更は債権の金額や請求先を左右するため、多くの組織で内部統制上の統制対象として扱われます。
自社に販売管理や債権管理に関する統制のルールがあるなら、得意先マスタの変更権限はその枠組みの中で位置づけられているはずで、まずそこを確認するのが順序として先です。

そのうえで検討の材料になるのは、項目ごとに権限を分ける余地です。
前半で整理した層の分け方は、ここでも使えます。
商号・住所・法人番号といった識別情報は全社共通の情報なので、変更が他拠点に波及します。
一方、販売エリア単位の担当営業や納品先の情報は、その拠点の中で完結しやすい。
すべてを同じ権限で扱うのではなく、影響範囲の広い項目ほど承認を厚くするという考え方であれば、登録のスピードと統制の両方に配慮できます。

与信限度額の変更権限は、この中でも扱いが難しい部分です。
金額の変更は債権リスクに直結する一方、営業の現場から離れた場所で判断すると実態と合わなくなります。
前節で触れたリスク区分ごとの見直し頻度と組み合わせて、定期見直しは所定の手続きで行い、期中の臨時変更には別の承認を求める、といった形で分けることは検討に値します。
ただしこれも、自社の統制方針と照らして決めるべき事柄で、外から一律の答えを出せるものではありません。

運用ルールを整えても、登録の判断ミスや条件の更新漏れがなくなるわけではありません。
ただ、拠点ごとにばらばらだった判断の基準が一本になれば、食い違いが見つかったときに「どちらが正しいか」を議論せずに済みます。
確認の手数が減るのは、この部分です。

得意先マスタをどの層に分けて持たせられるかは、使っているシステムが何を組織単位で保持できるかに左右されるため、一般的な設計論だけでは自社の可否まで判断できない

いま拠点ごとに別々に持っている項目を並べたうえで、どこまでを共通化でき、どこから運用でカバーする必要があるかを一緒に切り分けられます無料相談で要件を整理する

得意先マスタの持ち方——三つの考え方と向き不向き

取引先の識別情報と取引条件を、どの単位で保持するかで並べた

• 拠点別に完全分離：登録は速いが、取引先が重なると全社の債権と与信を把握できない

• 本社で完全一元化：重複は抑えられるが、登録待ちが受注速度に影響し、拠点固有の条件が備考欄に流れやすい

• 識別情報は共通・条件は組織単位：取引先の単位を一つに保ちながら、拠点ごとの取引条件の差をそのまま持てる

拠点間で取引先が重ならない前提が崩れているなら、三つ目の持ち方が検討の起点になる

要点の整理

軸	基準
マスタの持ち方	識別情報は全社共通、取引条件は会社コード・販売エリアなど組織単位で保持する
名寄せの照合項目	商号と住所を必須の軸とし、郵便番号・電話番号・代表者名で確度を確認する
統合時の与信	旧コードの限度額を合算せず、全社としての限度額をあらためて設定する
与信見直しの共通化	金額の持ち方より先に、大口・要注意先の定義と見直し頻度の区分を揃える
登録・変更権限	影響範囲の広い識別情報ほど承認を厚くし、最終的な分担は自社の内部統制方針で判断する

名寄せの対象件数や過去伝票の扱いは実際のデータを見ないと工数が読めず、与信や請求条件の統合判断も現在の運用とあわせて見る必要がある 現状の登録データと運用の実態を踏まえて、統合の進め方と、先に決めておくべきルールの範囲を確認できます

よくある質問

得意先マスタと商品マスタを同時に整理する場合、どちらから手を付けるべきか

どちらを先にすべきかを示す資料は今回確認していないため、一般論としての順序は断定できません。
判断の手がかりになるのは、いま起きている支障がどちらに起因しているかです。
請求金額の食い違いや与信の分散が問題なら得意先マスタ側、在庫や原価の集計が合わないなら商品マスタ側が先になります。
両方を同時に進めると、名寄せの判断とコード体系の設計が並行して走るため、現場の確認作業が集中します。
段階を分けるほうが、途中で判断が止まりにくいという面はあります。

拠点によって得意先コードの桁数や体系が違う場合、どちらの体系に合わせて統一すればよいか

コード体系の具体的な設計指針(桁数や階層の持たせ方)を裏づける資料は今回の範囲では確認できておらず、どちらが望ましいかは断定できません。
実務上の判断材料として挙げられるのは、既存伝票への影響の大きさと、コードに意味を持たせているかどうかです。
コードの一部に地域や業種の分類を埋め込んでいる体系は、その分類が変わったときにコードを変えるか意味を捨てるかの選択を迫られます。
本記事で整理した層の分け方に沿うなら、分類情報はコードではなく属性項目として持たせ、コード自体は識別だけに使うという考え方もあります。
いずれにせよ、過去伝票の参照がどう扱われるかをシステム側の仕様として確認してから決めることになります。

名寄せ作業を社内で行うか、外部のサービスに依頼するか、判断の分かれ目はどこか

重複した取引先データの名寄せ・統合を専門に行うマスターデータ管理サービスは商用で提供されています³。
社内でやるか外部に出すかの分かれ目になりやすいのは、対象件数と、照合に使える情報の質です。
件数が数百程度で、商号・住所の表記が比較的そろっているなら、前処理と目視確認で進められる範囲に収まります。
件数が多い、複数システムのデータが混在している、住所が旧表記のまま残っているといった条件が重なると、突き合わせの工数と判断の難しさが急に上がります。
なお、外部に依頼した場合の費用や期間を示す材料は今回ありませんので、具体的な水準は個別に確認してください。

与信限度額の見直しを拠点任せにしている場合、まず何から着手すればよいか

金額そのものを一斉に見直すより先に、区分の物差しを揃えるほうが着手しやすいはずです。
与信管理の実務では、大口取引先や要注意先の与信限度は年2回見直すなど管理レベルを上げることが好ましいとされています¹。
この考え方を使うなら、まず自社で何を大口とし、何を要注意先とするかの定義を拠点間で一つにする。
定義が揃って初めて、同じ取引先が拠点をまたいでも同じ頻度で見直される状態になります。
この頻度の目安は大口・要注意先を対象とした一般的な考え方であり¹、全業種・全取引額に一律で当てはまるものではない点は留意してください。

取引先が合併して商号が変わった場合、拠点にどう周知すればよいか

周知の方法そのものより、商号・住所といった識別情報の変更を、どの拠点が検知しても一箇所に集約する経路を決めておくことが先です。
本記事で整理した層の分け方では、識別情報は全社共通の層に置くため、変更は一箇所で行われ、結果として全拠点に反映されます。
問題は、変更の情報が本社に届かず拠点内で止まることなので、取引先から変更連絡を受けた担当者が誰に伝えるか、その連絡先を運用ルールに明記しておく。
合併の場合は、債権の引き継ぎ先や与信限度額の扱いも同時に判断が要るため、マスタの更新だけで完結しないことも押さえておく必要があります。

1. 1　出典：株式会社リスクモンスター「取引先与信の見直しをしよう！(与信管理講座)」（2026年閲覧時点）
2. 2　出典：SAP SE「得意先マスタデータ管理(SAP製品オンラインヘルプ)」（2026年閲覧時点）
3. 3　出典：株式会社東京商工リサーチ「マスターデータ管理(MDM)ソリューション」（2026年閲覧時点）