こんにちは、jojo太郎です。
年商300億円くらいの未上場企業で、経理財務、管理本部の仕事をしています。

今日は、取引先コードのハナシです。
皆さんの会社は、取引先コード活用されてますか？
顧客とか、仕入れ先とかのリストを、コードで管理するってやつです。
いまどき、当然ですよね。
昭和の世界じゃないんですからね。

当社では・・・
2023年まで、てんで活用できてなかったですね（爆）。
というか、中途半端にコードを使っていて、収拾つかない状態でした。
交通整理を行い、現在はコードをそれなりに使えていると思います。
そこで行った改善を、今日は振り返ります。

当社における取引先コードの扱い

当社でいう取引先とは、基本的に仕入れ先のことです。当社は店舗型BtoCビジネスをやっているので、法人顧客をリストで管理するってことがあまりないんです。

商売のために、品物を買う、その代金を支払う、
その一連の業務において支払い申請ソフト（BtoBプラットフォーム請求書）を使ってます。そこで取引先コードが必要になる訳です。
その後、会計ソフトに支払いを記帳します。ここでも取引先コードが必要になります。

抱えていた課題

課題①：いろんな人がコードを付与していた
店舗のスタッフが、支払い申請ソフトに新規取引先を登録してました。登録時、取引先コードを付与することになります。そう、いろんな人がコードを付与していたんですよ。これが原因でさまざまな問題が派生していました。

課題②：命名規則が決まってなかった。ゆえに、表記揺れが激しかった。
法人の名前を登録する際、命名規則が決まっていませんでした。だから表記揺れがめちゃくちゃありました。例えばカタカナで言えば全角カタカナで登録する人も半角カタカナで書く人もいます。ソフトバンクとｿﾌﾄﾊﾞﾝｸみたいに。英数字も同様です。（個人的にはあり得ないだろと思いますが）全角英数を使う人が世の中には沢山いるんですよ。Softbankではなく、Ｓｏｆｔｂａｎｋと入力してしまう訳です。以上の四種類は、すべて検索では別物と認識されます。恐ろしいですね。
ここに更に２語以上の法人名の場合、スペースが問題になります。スペースが半角か全角か、ですね。信じられませんが、半角の英数字二つの間に入るスペースを全角で入れる人も存在します。cyber agent ではなく、cber　agentとやってしまう訳です。これも検索では別物と認識されます。（※Cyberとcyberのように、英語の大文字と小文字は、同一のものと見なされ、どちらであっても検索にひっかかります。やっかいなのは全角半角なのです）
ここに更に商号の問題が入ります。株式会社か(株)か、はたまた商号を入れないか、です。言葉って難しい！
上記のように言葉は表記揺れしやすいです。本来、ルールを定めて、登録する人を教育する必要があります。しかし当社では命名規則を決めずに、２０人とか３０人という大人数で登録していました。その結果・・・そう、表記揺れしまくった取引名が山ほど登録されました。

課題③：社名で検索→見つからない→同じ取引先を何度も登録する
毎月、支払い処理をするスタッフ数十名が、「当店はこの取引先に今月支払いしないといけないが、BtoBプラットフォーム請求書上に既に登録あるかな？」とBtoBプラットフォーム請求書上で検索する訳ですが、この時、社名で検索してました。
　そう、お分かりのとおり、表記揺れしまくって登録されているので、登録されているのに、検索してもひっかからないんです。（例：ソフトバンクと検索したが、ｿﾌﾄﾊﾞﾝｸと登録されているため検索には引っかからず、「あ、登録されてないんだ」と検索者は誤認識してしまう）。そして、そう、新たに登録してしまうんですね。恐ろしや！そうすることで、次々同じ取引先がちょっと表記揺れして何度も重複して登録されていきます。

課題④：グループ内の各法人がそれぞれ取引先を登録→グループ全社的に横断して情報共有がなされない→自社の取引履歴で検索するが見つからない→同じ取引先をそれぞれ登録するので重複
当社グループには、法人がいくつかあります。法人A、法人Bが同じ取引先と取引していても、その情報を横断して管理していませんでした。※BtoBプラットフォーム請求書上では、異なるグループ法人の情報を横断して検索できないのです。そう、グループ全体で見れば取引実績があり取引先登録されているのに、個別の会社で登録がなければ取引先コードを改めて付与していたのです。こういう理由でも、同じ取引先が重複して登録されていきます。

課題⑤：異なるツール（支払い申請ソフトと、会計ソフト）において、それぞれ別個の取引先コードを付与していた。
本来、ツールやソフトが異なっても、コードは共通したものを使うべきなのに、ツールごとに異なる取引先コードを付与していました。百歩譲ってツールごとに異なる取引先コードを付与するなら、ツールAにおけるコードが、それぞれツールBにおいてどんなコードに対応しているのか、という対応表が必要なのですが、それもありませんでした。結局、ツール間はcsvで情報を渡してはいますが、あくまでテキストベースで渡しているだけ。入金消し込みなども目で社名を確認して消し込んでいました。そう、データじゃなくて人間の目で追って手で消し込むような仕事のやり方してたんです。

要は、
取引先コードを使っている、のではなく、
コードを付与してはいるが、実際はコードを活用してない状態ですね。
運用を設計せず、ルールを設定しないまま、
いろんな人がその都度思い思いに付与しまくって収拾つかない状態、でした。

やったこと

・これまでに付与された膨大なコードを、名寄せし、重複削除。
・スプレッドシートで取引先マスタを作成。（グループ全社共通、全ツール共通）
・管理者を設定（重複付与の撲滅）
・命名規則を設定（表記揺れの撲滅）
・検索場所を変更（BtoBプラットフォーム請求書ではなくマスタ内で検索）
・検索方法を変更（社名ではなく、口座番号で検索）

得られたこと

・重複していない取引先マスタが手に入った。
・グループ全社で共通、全ツールで共通のマスタが手に入った。
・重複して登録するミスが無くなった。
・同じ取引先を各ツールでコード付与する二度手間が無くなった。
・同じ取引先を各グループ法人でコード付与する二度手間が無くなった。

工夫した点

・マスタ（スプレッドシート）は、閲覧者用と管理者用で分けて作成。閲覧者用は管理者用からIMPORTRANGE関数で自動的にコピーされるようにした。こうすることで閲覧者は常に最新状態を閲覧できるが編集できないため、人為的ミスによるマスタ破壊が起こらない。

・条件付き書式で、支払先コードが重複したら赤くなるようにした。
こうすることで、管理者がコード付与の際、ミスに自分で気づけるようにした。

・銀行コードと支店コードを入力したら、自動的に銀行名、支店名が出るようにした。

今後

ふう・・・
簡単に振り返るつもりが、
長くなってしまいました。

今後は、
付与するのを、管理者ではなく、自動化したい、と考えています。
キーエンスのRPAが非常に使いやすそうだったので、取り入れたいです。

コード付与の話しは、他にも工夫した点があるので、
それはまたどこか別の記事で書きたいと思います。

最後までお読み頂き、ありがとうございます。