得意先マスタ登録とは｜項目設計と運用ルールの勘所

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

B2B EC-COLUMN

得意先マスタ登録とは何かを整理します

得意先マスタ登録とは、商品やサービスを販売する相手の情報を、受注・出荷・請求・回収の各処理が共通して参照できる形で台帳に登録することです。単なる住所録ではありません。請求先と納品先の関係、締日と支払条件、与信枠、<a href="/column/qualified-invoice-registration-number/">適格請求書発行事業者の登録番号</a>までを一つの台帳に集約します。ここが崩れると、受注は入力できても請求書が出せない状態が生まれます。項目の設計と登録の運用を同時に決めることが出発点になります。

得意先マスタが担う役割は、取引の起点を一つに定めることにあります。受注伝票は得意先コードを鍵に単価表を引き、出荷指示は納品先の住所を引きます。請求処理は締日と支払方法を引き、入金消込は請求先の名義を引きます。一つの登録内容が、四つ以上の業務の入力を肩代わりしている計算になります。項目が一つ欠けるだけで、その先の処理が止まります。

顧客マスタや仕入先マスタとの違いは、金銭の向きと必要な条件項目にあります。仕入先マスタは支払側の条件を持ち、支払サイトや振込手数料の負担区分を管理します。得意先マスタは回収側の条件を持ち、与信枠や回収予定日を管理します。個人向けの顧客マスタは氏名と配送先が中心で、法人番号や登録番号を持たない設計も見られます。同じ会社が仕入先と得意先の両方になる場合、台帳を二つに分けるか、一つの取引先台帳に区分を立てるかを先に決めます。

登録が滞ると受注や請求が止まる理由は、後続処理が前提とする項目が空欄のまま流れるからです。締日が未設定の得意先は請求締め処理の対象から外れ、翌月まで請求書が出ません。与信枠が未設定であれば、受注時の与信判定が通らず出荷が保留になります。登録番号を持たないまま適格請求書を発行すれば、受け取った側で仕入税額控除の要件を満たさない書類になってしまいます。回収の遅れは資金繰りに直結します。

登録の誤りは、金額の大小ではなく波及の広さで効いてきます。請求先を誤って登録すると、請求書の誤送付が取引条件や担当者情報の漏えいにつながります。個人データの漏えい等が報告の対象に当たる場合、速報と確報の二段階での報告が求められ、確報の期限は原則30日以内、不正アクセスによるものは60日以内です^*4。事務の手戻りに加えて、報告の準備という別の作業が発生します。

自社だけで設計を完結させる場合、必要な知識は一つの部署に収まりません。<a href="/column/sales-management-system/">販売管理</a>の伝票設計、適格請求書の記載要件、<a href="/column/electronic-transaction-data-storage/">電子取引データの保存要件</a>、個人情報の取扱いという四つの領域を同時に見る必要があります。加えて、既存データの棚卸しと移行の判断が重なります。情報システム部門だけ、経理部門だけで進めますと、どこかの要件が抜け落ちます。

2026年に入っても、取引先情報を基幹システムと表計算ソフトで二重に持つ運用は残っています。二重管理は、どちらが正しいかを人が判断する作業を毎日生み出します。判断が属人化すると、担当者の異動でそのまま止まります。台帳を一つに寄せる作業は、システムの入れ替えより先に着手できる部分です。

得意先マスタに登録する項目を設計します

登録する項目は、区分ごとに分けて持つことが設計の要点になります。基本情報、請求・回収条件、請求先・納品先、与信・取引条件、担当者情報という5つの区分に分け、更新の頻度と責任者を区分ごとに変えます。一つのレコードにすべてを平らに並べると、社名変更や支払条件の見直しのたびに関係のない項目まで触ることになります。区分ごとに登録する情報と設計上の留意点を並べると、変更の影響範囲が読めるようになります。

基本情報には、商号、所在地、法人番号、適格請求書発行事業者の登録番号を置きます。法人番号は13桁の数字で、原則として一つの法人に一つだけ指定されます¹。公表されている基本3情報は、商号または名称、本店または主たる事務所の所在地、法人番号の三つです1。商号や所在地が変わっても番号自体は変わりませんので、名寄せ（同一の取引先を指す複数レコードを一つにまとめる作業）の鍵として使えます。この三つを自社の登録内容と突き合わせる運用にすると、表記ゆれの発見が早まります。

請求・回収条件は、締日、支払日、支払方法、消費税の端数処理を持ちます。端数処理の扱いは適格請求書の記載内容と直結します。軽減税率の8%と標準税率の10%という2つの区分ごとに、対価の額と消費税額を分けて記載する必要があるためです。得意先ごとに切り上げと切り捨てが混在しますと、同じ商品でも請求額が一致しません。処理方法は項目として持ち、備考欄の文章では管理しないようにします。

請求先・納品先が分かれる場合は、一つのコードで兼ねず、別のレコードとして持って対応関係を結びます。本社が請求先で、支店や工場が納品先になる形は珍しくありません。納品先が複数あっても請求先は一つ、という一対多の関係を対応表で表現します。ここを一つのレコードに押し込むと、納品先ごとの出荷実績が集計できず、請求書の明細も組めません。BtoB EC（企業間取引の電子商取引サイト）から受注を取り込む場合も、この対応関係が受け皿になります。

与信・取引条件には、与信枠、取引区分、単価適用区分を置きます。与信枠は受注時の自動判定に使いますので、金額と有効期限の2つを組で持ちます。取引区分は直販か代理店経由かといった取引の性格を表し、単価適用区分は価格表の切り替えに使います。判定や切り替えに使う値を備考欄へ文章で書くと、システム側が読み取れません。機械が使う値は独立した項目にします。

担当者情報の区分には、氏名、部署、役職、電話番号、電子メールアドレスを置きます。窓口が発注、検収、支払で分かれる得意先もありますので、用途の区分を添えて複数の担当者を登録できる形にします。ここで決めるのは、担当者を得意先レコードへ直接書き込まず、別のレコードとして持って得意先コードで結ぶという置き方です。担当者は異動や退職で入れ替わりますので、商号や所在地とは更新の頻度がまったく違います。個人情報に当たる項目ですので、利用目的の特定と保存期間の決め方は、後段の法令・制度の節でまとめて扱います。

区分を分けた設計は、権限の設計にもつながります。与信枠を営業担当者が自由に書き換えられる状態は、回収リスクの管理として弱くなります。基本情報は営業事務、請求・回収条件は経理、与信・取引条件は<a href="/column/credit-management/">与信管理</a>の責任者というように、区分と承認者を対応させます。項目の分離は、そのまま職務の分離になります。

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

得意先コードの体系を決めます

得意先コードは、意味を持たせない連番を主キーにし、意味は別の項目で持つ形が扱いやすくなります。地域や業種をコードへ埋め込むと、担当地域の変更や業種区分の見直しのたびにコードを振り直すことになります。振り直しは過去の伝票との対応を壊します。桁数は将来の取引先件数から逆算し、外部のコードとは対応表で結びます。統合や分社が起きても、対応表の側を書き換えれば済む形にしておきます。

意味を持たせるコードには、一覧を見ただけで属性が分かる利点があります。先頭2桁が地域、次の2桁が業種、残りが連番という設計はよく採られます。一方、属性が変わったときには、番号を変えるか実態と合わないまま残すかの二択を迫られます。連番のコードは読んだだけでは何も分かりませんが、変える理由が生じません。属性は検索や集計のための項目として別に持てば、絞り込みには困りません。

法人番号は13桁で、公表サイトのWeb-API（外部のシステムからデータを取り出すための接続口）から商号や所在地を取得できます¹。流通の分野では、企業や事業所を識別する共通取引先コードやGLN（Global Location Number／事業所を識別する国際標準の番号）が使われています。GLNは事業者コードとロケーションコード、チェックデジット1桁で構成される13桁のコードです6。共通取引先コードもGLNと同じ13桁の体系に整理されています^*5。チェックデジットは残る12桁から計算されますので、入力誤りをその場で弾く仕組みとして使えます。

統合、分社、社名変更に耐える設計の鍵は、コードと名称を切り離すことです。社名変更は名称項目の更新で済ませ、コードは動かしません。分社では新しいコードを採番し、旧コードとの関係を後継として記録します。統合では、どちらのコードを残すかを決め、残さない側を統合先へ向けた参照として残します。過去の伝票が指すコードを消しますと、履歴の照会ができなくなります。

桁数は、現在の取引先件数ではなく、10年先の件数から決めます。6桁の連番であれば、000001から999999まで、約100万件を採番できます。桁数の判断では、この上限と10年先に見込む取引先件数を並べて比べます。逆に4桁で始めると、9999件で行き止まりになります。桁の追加は、連携先のシステムやEDI（企業間で取引データを電子的にやり取りする仕組み）の電文定義にまで影響が及びます。採番は人手で決めず、システムの採番機能に任せる設計にします。

コード体系の作り直しは、後になるほど費用が膨らみます。得意先コードは受注、出荷、請求、入金、会計仕訳の各データに埋め込まれていますので、変更はすべての履歴に波及します。取引先へ通知している注文書の記載や、EDIの取引先識別にも影響します。稼働後の変更は、旧コードと新コードの対応表を全システムへ配る作業を伴います。設計段階での判断が、後からの是正よりも負担を抑えられます。

コード体系の決定は、情報システム部門だけで完結しません。営業は担当割り当て、経理は請求単位、物流は納品先の粒度を、それぞれコードに求めます。三者の要求をコードそのものへ詰め込むと、意味の重なった体系になります。求める粒度は項目に分け、コードは識別だけを担う役割に絞ることが落としどころになります。

法令・制度に対応した情報を持たせます

法令や制度への対応は、書類を作る段階ではなく、得意先マスタの項目として先に持つことで手戻りが減ります。適格請求書発行事業者の登録番号、その失効の履歴、検索に使う取引先名、担当者情報の取扱いという4点が中心になります。いずれも請求書や保存データの要件から逆算して決まる項目です。制度の細部は改正が続きますので、項目を増減しやすい設計にしておくことも合わせて必要になります。

登録番号の保持は、取引先ごとに専用の項目を設けることから始まります。適格請求書発行事業者の登録番号は、記号のTに13桁の数字が続く14文字の形です。備考欄へ文字列として書きますと、桁数の検証も、公表情報との突き合わせもできません。公表サイトにはWeb-APIが用意されており、登録番号を指定して公表情報を取得できます^*2。取得した内容を自社の登録内容と比べる仕組みを作ると、点検が定期の作業になります。

失効の履歴を持たせる理由は、過去の取引を後から判定するためです。登録には取消しや失効が起こりますので、現在の状態だけを上書きしますと、いつから無効だったのかが分かりません。有効期間の開始と終了を組で記録し、伝票の日付と突き合わせられるようにします。この形にしておけば、税務上の確認を求められたときに、当時の状態を根拠付きで示せます。判断そのものは税理士に確認する前提で、記録の側を整えておきます。

取引先名の統一は、電子取引データの保存要件に直結します。保存の規則では、取引年月日、取引金額、取引先という3つの項目を検索の条件として設定できることが求められています³。得意先マスタの名称が表記ゆれのまま複数存在しますと、この検索条件が機能しません。規則が定める条件を満たす場合には、検索要件が不要になる措置も置かれています3。基準期間の売上高が5,000万円以下であることなどが条件で、ダウンロードの求めに応じることが前提です^*3。自社が該当するかは条文と公式の資料で確認します。

担当者情報の点検では、利用目的と保存期間を項目単位で決めます。ガイドラインでは、利用目的をできる限り特定し、本人にとって想定できる程度に具体的に定めることが求められています⁴。あわせて、個人データの安全管理措置や、漏えい等が生じた場合の報告についても定められています4。報告は速報と確報の二段階で、確報は原則30日以内、不正アクセスによるものは60日以内です^*4。得意先マスタは営業、経理、物流が同時に参照しますので、参照できる範囲を役割ごとに絞る設計が現実的でしょう。退職や異動の連絡を受けた時点で更新する手順を用意し、連絡先を無期限に持ち続ける運用は見直しの対象にします。全員が全項目を見られる状態も、同じく見直しの対象になります。

制度に関わる項目は、改正のたびに増える前提で設計します。ガイドラインは改正が重ねられており、2026年時点でも見直しが続いています^*4。項目を固定の列として作り込みますと、追加のたびにシステム改修が必要になります。取引先ごとの属性を、項目名と値の組で持てる汎用の枠を用意しておけば、追加の負担が下がります。税務上の可否の判断は税理士に確認し、システム側は記録の網羅性を担保する役割に徹します。

登録・変更・停止の運用ルールを定めます

登録の質は、項目設計よりも運用の手順で決まります。申請、承認、反映という3つの段階を分け、それぞれで誰が何を確かめるかを文書にします。申請者が自分で登録できる状態では、確認が働きません。停止の扱いも同じで、削除、休止、与信停止を別の状態として持ち、伝票の履歴を残したまま新規取引だけを止められるようにします。手順が決まりますと、担当者が替わっても品質が揃います。

申請の段階では、入力規則の確認と添付書類の確認という2つの作業が入ります。入力規則の確認は、必須項目の空欄、桁数の不一致、全角と半角の混在を機械的に弾く作業です。添付書類の確認では、登記事項証明書や取引申込書など、実在と取引意思を示す資料が揃っているかを見ます。営業担当者が口頭で伝えた条件をそのまま登録する運用では、後から根拠をたどれません。申請の記録自体も保存の対象として扱います。

承認の段階では、実在性の確認と与信の判定を分けて扱います。実在性の確認は、法人番号の公表情報と申請内容を突き合わせる作業です^*1。商号と所在地が一致しない場合は、変更が公表に反映されていないのか、申請の誤りなのかを切り分けます。与信の判定では、金額の上限と有効期限を決め、営業部門ではない責任者が承認します。二つを一人が兼ねますと、受注を通したい動機が判定に混ざります。

反映の段階では、コードの採番と連携先への配信を続けて処理します。コードの採番はシステムに任せ、人が番号を選べないようにします。連携先への配信は、会計、在庫、BtoB ECなど、得意先情報を参照する側へ同じ内容を届ける作業です。配信が遅れますと、受注は登録できても請求書の宛先が古いままという食い違いが生じます。反映の完了をもって申請の完了とする定義にしておけば、途中で止まった案件が見えます。

入力規則と必須項目は、画面の説明ではなく仕様として明文化します。法人番号は13桁の数字のみ、登録番号はTと13桁の数字で計14文字、電話番号はハイフンなしといった水準まで決めます。住所は都道府県から建物名までの区切りを定め、丁目と番地の表記も揃えます。表記の揺れは、後の名寄せで手間のかかる部分です。入力の時点で揃えるほうが、後から直すより負担が軽くなります。

休止、与信停止、削除は、それぞれ意味が違います。休止は取引が途絶えている状態で、再開の可能性を残します。与信停止は入金の遅延などを理由に新規受注を止める状態で、既存の売掛金の管理は続きます。削除は登録そのものを消す操作ですが、過去の伝票が参照している以上、実際には消せません。物理的に消すのではなく、状態を示す項目で区別し、受注画面での選択可否を制御する設計が扱いやすくなります。

変更の記録には、誰が、何を、どの値からどの値へ変えたかを残します。与信枠と支払条件の変更は金額への影響が大きいため、承認者の記録まで残します。履歴がなければ、条件が変わった時点を後からたどれません。監査や取引先からの照会に応じる際、履歴の有無が回答の速さを決めます。

データ品質を保ち、他システムと連携させます

データ品質は、登録時の規則だけでは保てません。重複の検出、公表情報との照合、名寄せの適用、連携の反映という4つの作業を、定期の仕組みとして回す必要があります。取引先は社名を変え、統合し、担当者を替えますので、台帳は放っておくと現実から離れていきます。点検の周期と担当を決め、結果を会計や受注の側へ届けるところまでを一連の作業として設計します。点検を人の気づきに頼りますと、気づいた人が異動した時点で止まります。

重複の検出は、表記ゆれをまとめて洗い出すことから始めます。株式会社の前株と後株、旧字体と新字体、全角と半角のカッコ、支店名の有無が典型的なゆれです。名称だけで突き合わせると取りこぼしますので、法人番号、電話番号、住所の組み合わせで候補を絞ります。候補の一覧を出したうえで、統合するかどうかは人が判断します。自動で統合しますと、同名の別法人を誤って一つにまとめる危険があります。

公表情報との照合は、外部のWeb-APIを使えば定期の作業にできます。法人番号の公表サイトは、商号、所在地、法人番号の基本3情報を取得できるWeb-APIを提供しています¹。適格請求書発行事業者の公表サイトも、登録番号を指定して公表情報を取得できるWeb-APIを備えています2。いずれも利用にはアプリケーションIDの取得が必要ですので、開発の前に申請の手続きを見込んでおきます。提供の開始時期や仕様の版は改定されますので、着手の前に各公表サイトの最新の案内で確認します。取得した値と自社の登録内容を比べ、差分だけを担当者へ通知する形が現実的でしょう。

名寄せの適用では、代表となるレコードを一つ決め、残りを統合先へ向けた参照に切り替えます。統合しても過去の伝票は旧コードを指したままですので、参照をたどれば代表レコードへ行き着く形にします。統合の結果は履歴として残し、後から分離が必要になった場合に戻せるようにします。名寄せを一度きりの作業として扱いますと、数年で同じ状態へ戻ります。周期を決めて繰り返す作業として組み込みます。

連携の反映では、得意先情報を参照するすべてのシステムへ同じ値を届けます。会計は請求先と支払条件を、在庫と物流は納品先を、BtoB ECは掲載価格と与信枠を参照します。決済の側でも、振込電文へ商流の情報を載せる仕組みが整えられてきました。従来の総合振込はEDI情報欄が20桁の固定長で、支払通知の情報を十分に載せられませんでした。全銀EDIシステムは2018年に稼働し、この制約を緩めています^*7。

連携方式は、更新の即時性と運用負荷の兼ね合いで選びます。日次のバッチ連携は仕組みが簡単ですが、当日の新規登録が翌日まで反映されません。APIによる即時連携は反映が速い代わりに、障害時の再送とエラー監視の仕組みが要ります。中間に連携用のテーブルを置き、成功と失敗を記録する方式が折衷案になります。どの方式を採る場合でも、正となる台帳を一つに定めることが前提です。

連携の設計を誤りますと、影響は請求書の宛先だけにとどまりません。会計側に古い請求先が残れば、入金消込が合わず、月次の締めが遅れます。BtoB EC側に古い与信枠が残れば、本来止めるべき受注が通ってしまいます。台帳の値が3つのシステムでばらつく状態は、どれが正しいかを人が毎回判断する作業を生みます。

得意先マスタ登録の見直しを進めます

見直しは、システムの入れ替えを待たずに始められます。現状の棚卸し、移行時のクレンジング、点検の仕組みという3つの順で進めますと、途中で止まりにくくなります。棚卸しでは件数と重複の実態を数字で押さえ、クレンジングでは残す値と捨てる値の基準を先に決めます。点検は、月次や四半期の定例作業へ組み込みます。順序を飛ばして移行から入りますと、汚れたデータを新しい器へ移すだけになります。

現状の棚卸しでは、登録件数、直近1年の取引実績があるレコードの件数、重複候補の件数を数えます。取引が数年止まっている登録がそのまま残っている台帳は珍しくありませんので、まず母数を把握します。次に、必須項目の空欄率を項目ごとに出します。登録番号や締日の空欄が目立つ項目は、運用の穴がそのまま現れている箇所です。数字が出れば、どこから直すかの優先順位を議論できます。

移行時のクレンジングでは、手順を先に文書化してから作業へ入ります。名称の表記統一、住所の分割、法人番号と登録番号の付与、重複の統合という順で進めますと、後戻りが減ります。作業前のデータは別に保存し、移行後に件数と金額の合計で突き合わせます。判断に迷うレコードは、捨てずに保留の状態で移し、担当部門へ確認を回します。移行の当日に判断を求められる状態を作らないことが肝心です。

運用が定着しているかは、指標で点検します。必須項目の空欄率、公表情報と一致しないレコードの件数、申請から反映までの日数、重複候補の残件数という4つを毎月確認します。数値が悪化した月は、手順のどこで止まったかを追えます。点検の結果を承認者と申請者の双方へ戻す仕組みにすれば、入力の質が上がります。指標を決めずに始めますと、定着しているかどうかを誰も答えられません。

内製で進める場合、必要な役割は3つ以上に分かれます。販売管理と会計の伝票設計を理解する担当、制度要件を条文と公式資料まで確認できる担当、データの抽出と突き合わせを書けるエンジニアです。加えて、営業と物流の合意を取りまとめる進行役が要ります。棚卸しから移行、点検の仕組みづくりまでを1人で兼ねる体制では、通常業務と並行したときに止まります。人員の確保が難しい場合、どこを外部へ委ねるかを先に決めます。

外部の支援を受ける場合と内製の違いは、判断の速さと手戻りの量に表れます。コード体系や請求先の持ち方は、稼働後の変更費用が大きい部分です。社内に販売管理と制度要件の両方を確認できる担当がいない場合、設計の妥当性を稼働前に検証する工程が抜けやすくなります。移行の実績がある相手と進めれば、過去の事例に照らして選択肢を絞る材料が得られます。FSOLは、現状データの棚卸し、移行時のクレンジング、会計や受注の各システムとの連携設計という3つの工程を支援しています。制度要件の確認と項目設計の突き合わせも同じ体制で担いますので、部門をまたぐ調整の負担を抑えられます。外部へ委ねる目的は、作業を減らすことよりも、やり直しのリスクを下げることに置きます。

制度に関わる項目は、公式の資料に当たって確認します。条文やガイドラインは改正されますので、社内の手順書だけを根拠にしますと古い要件のまま運用が続きます。税務上の可否の判断は税理士に確認し、システム側は記録と検索の要件を満たす役割に絞ります。役割を分けておけば、改正時に見直す範囲が限定されます。

最後に、本記事の要点を整理します。第一に、登録する項目は基本情報、請求・回収条件、請求先・納品先、与信・取引条件、担当者情報の区分ごとに分け、区分と承認権限を対応させます。第二に、得意先コードは意味を持たせない連番にし、地域や業種は別の項目で持ちます。第三に、登録の手順は申請、承認、反映の三段階に分け、申請者と承認者を同じ人にしません。第四に、重複の検出と公表情報との照合は、月次や四半期の定例作業として回します。第五に、登録番号の失効履歴と取引先名の表記統一は、請求と保存の要件から逆算して項目に落とします。この五点を先に決めておけば、システムの入れ替え時期に関わらず着手できます。

本記事で参照した資料は次のとおりです。数値や要件は法令とガイドラインの改正により変わりますので、実務での判断は各発行元が公表している最新版で確認してください。

*1 「法人番号公表サイト」／国税庁／2015年公開・随時更新／https://www.houjin-bangou.nta.go.jp/

*2 「適格請求書発行事業者公表サイト」／国税庁／2021年公開・随時更新／https://www.invoice-kohyo.nta.go.jp/

*3 「電子帳簿保存法関係（電子取引データの保存）」／国税庁／令和5年度税制改正対応版／https://www.nta.go.jp/law/joho-zeikaishaku/sonota/jirei/

*4 「個人情報の保護に関する法律についてのガイドライン（通則編）」／個人情報保護委員会／改正版を随時公表／https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/

*5 「共通取引先コード」／一般財団法人流通システム開発センター／随時更新／https://www.dsri.jp/

*6 「GLN（Global Location Number）」／一般財団法人流通システム開発センター／随時更新／https://www.dsri.jp/standard/gln/

*7 「全銀EDIシステム（ZEDI）」／一般社団法人全国銀行資金決済ネットワーク／2018年稼働／https://www.zengin-net.jp/zedi/

よくある質問

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

将来の取引先件数から逆算して決めます。6桁の連番であれば99万件を超える範囲まで採番できますので、桁が足りなくなる心配はほぼありません。桁数の変更は、受注や会計の履歴だけでなく、EDIの電文定義や取引先へ渡す帳票にも波及します。現在の件数に合わせて4桁で始めますと、9999件で行き止まりになりますので、余裕を持たせた設計にします。

取引先の法人番号や登録番号は自動で取得できますか。

公表サイトのWeb-APIを使えば、プログラムから取得できます^*1*2。法人番号の公表サイトからは商号、所在地、法人番号の基本3情報を取得でき、適格請求書発行事業者の公表サイトからは登録番号を指定して公表情報を取得できます。いずれも利用にはアプリケーションIDの取得が必要ですので、開発の前に申請の期間を見込んでおきます。

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

物理的な削除は避けます。過去の受注、請求、入金の伝票が得意先コードを参照していますので、レコードを消すと履歴の照会ができなくなります。休止や与信停止といった状態を示す項目で区別し、受注画面での選択だけを止める設計にします。担当者の連絡先など個人情報に当たる項目は、保存期間を決めて別に整理します。

請求先と納品先は一つのコードにまとめてはいけませんか。

一つの請求先へ納品先が複数ぶら下がる取引がある場合は、分けて持ちます。まとめますと、納品先ごとの出荷実績が集計できず、請求書へ納品先別の明細を載せられません。請求先が1件、納品先が1件の取引しかない場合は、当面まとめても支障は出ません。ただし後から分ける改修は、過去データの振り分けを伴いますので負担が大きくなります。

表計算ソフトでの管理から移行する際、最初に何をすればよいですか。

棚卸しから始めます。登録件数、直近1年の取引実績があるレコードの件数、必須項目の空欄率を数え、現状を数字で押さえます。次に、残す項目と捨てる項目の基準を決めてから移行の作業へ入ります。基準を決めずに移しますと、表記ゆれと重複をそのまま新しいシステムへ持ち込むことになります。

1. *1　出典：国税庁「法人番号システム Web-API（国税庁法人番号公表サイト）」（2015）　経路
2. *2　出典：国税庁「適格請求書発行事業者公表システム Web-API機能（インボイス制度適格請求書発行事業者公表サイト）」（2021）　経路
3. *3　出典：デジタル庁（e-Gov法令検索）「電子計算機を使用して作成する国税関係帳簿書類の保存方法等の特例に関する法律施行規則（平成10年大蔵省令第43号）」（1998）　経路
4. *4　出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」（2026）　経路
5. *5　出典：GS1 Japan（一般財団法人流通システム開発センター）「共通取引先コードとは」（2024）　経路
6. *6　出典：GS1 Japan（一般財団法人流通システム開発センター）「GLN（企業・事業所識別コード）」（2024）　経路
7. *7　出典：一般社団法人全国銀行資金決済ネットワーク「全銀EDIシステム（ZEDI）」（2026）　経路