勘定科目体系の設計で会計数値を戦略的に
ERPを導入する際、結構初期段階でプロジェクト責任者が迷うことの一つが、勘定科目コード体系の設計でしょう。これ、結構迷います。そして困ります。
「科目コードは何桁にするべきか？そもそも桁数は固定するべきか？」
「勘定体系に階層を持たせるか？並列にするべきか？」
「英数字を組み合わせるべきか？数字だけにするべきか？」
「勘定科目は英語でも定義すべきか？」
「そもそも勘定科目はいる？」
と、いうのも、勘定科目体系は他の決定事項への依存関係から、ERP検討・導入のかなり初期段階で決めなければいけません。そして運用が開始した後ではなかなか変更できるものではありません。（できなくはないですが・・・）
今まで使っていたものを引き継ぐというケースもあるでしょう。でも、もしかしてそれはあまり意味がない場合もあるかもしれません。
従来型の会計ソフトは大抵３桁程度の勘定科目を持っていたり、体系立てて作られていなかったりするケースが多々あるからです。個人事業主や中小企業はそれでも十分なのですが、管理会計を行う際には問題があります。
しかし、会社を大きく成長させることを考えた場合、勘定科目体系の設計次第で、会計数値をいかに戦略的に使えるかが変わってきます。会社にある数値をいかに精緻に分析できるか、物量が急激に増えたときに管理ができるか等が変わってくるのです。
だからこそ、この勘定科目コードは、かなりセンスがいる作業です。将来の会社を見据えて設計しなくてはいけません。
市販の会計ソフトでは勘定科目が最初にセットされている場合が多いですが、ネットスイートのようなミドル～ハイエンドのＥＲＰは最初から自分で設計するようにフレキシブルになっているケースが多いように思われます。
これは、勘定科目の設計自体が業種業態によって変わる可能性があるからであり、それ自体が企業の性格や戦略を反映するからだと思われます。
では、一般的にどのような勘定体系を持つべきなのでしょうか。ベストプラクティスとはいかないまでも、考えてみましょう。（以下、私見です。）
英数字は組み合わせるべき？オススメは勘定科目を数字で定義
資産は英語でAssetだからAxxxで始まる勘定を、負債はLxxx、というのも考え方としてはあると思いますし、実際そのような運用をされている企業も多いと思います。そもそもコード体系を一切持たずに勘定科目名称で定義しているケースもあるかもしれません。
私は、勘定科目をすべて数字で定義するのが良いと思います。その主な理由は以下です。
勘定科目でソートできるため数字が適切
勘定科目コードや仕訳のデータをダウンロードした時に勘定科目で一気にデータをソートできるメリットがあります。簿記の世界では勘定科目は原則並び方が決まっているのでその順に並ぶようにしましょう。
勘定科目が数字だとテンキーだけで打ち込み可能
経理業務が大分自動化されてきているとはいえ、まだまだ職人仕事は残っています。手慣れた経理スタッフがショートカットを駆使してキーボードだけで打ち込んでいく、という光景もよく見ます。勘定科目に英数字が混在していると入力が一行あたり（たぶん）0.5秒くらい遅れます。大量に実務をこなすスタッフにとっては意外とストレスになりますし、腱鞘炎になるリスクが高まります。
英数字を織り交ぜるメリットがあるとすれば桁数を少なくできることでしょうか。他の社内システムとの連携を考える場合もあり得るかもしれません。
[RELATED_POSTS]勘定科目が最低5桁必要な理由とは？
勘定科目内に階層を持つのであれば最低５桁以上が必要になるかと思います。
１桁目は簿記の大項目を定義する。これが基本です。一般的に以下のような形になるのが理想かと思いますし、これに沿っている会社が多いと思います。
1～ 資産
2～ 負債
3～ 株主資本・純資産
4～ 売上
5～ 売上原価・製造原価
6～ 販売費・一般管理費
7～ 営業外収益・費用
8～ 税金
階層を持つ場合に最低５桁必要なのは、最低限でも最初の３桁が簿記の階層に充てる必要があるからです。例えば、売掛金という勘定は、①負債、②流動負債、③売掛金という３段階階層を持つ必要があります。
また、特に経費は管理会計上重要になの４桁を上位階層に充てる必要があるでしょう。①経費、②変動費、③人件費、④賞与引当金 といった感じです。上位階層に管理会計的な概念を入れることで管理会計の効率が上がります。（例えばこの場合は②変動費を上位階層に入れることで損益分岐点分析がやり易くなりますね。）
そう考えると、最低５桁か６桁は必要そうです。最後の１～２桁は個別の勘定であったりさらに細分化するためだったりに使います。経験上、７桁以上あると経理スタッフが覚えるのが大変になる気がします。５桁か６桁が理想でしょうね。
[SMART_CONTENT]
ＸＢＲＬのタクソノミ
ここで、勘定科目の体系づくりに迷った時の必殺技を教えましょう。特に海外子会社まで対応するように日英で勘定科目の体系を作らなければいけない場合などに重宝します。
それは、ＥＤＩＮＥＴのＸＢＲＬタクソノミを参考にするとよいということです。はい、意味不明ですね。これでわかったあなたはよほどプロです。
ＥＤＩＮＥＴは恐らくご存知の方が多いと思います。金融庁が運営する金融商品取引法に基づいた開示を行うサイトがＥＤＩＮＥＴです。そう、上場企業が有価証券報告書や大量保有報告書を公示するサイトですね。
このＥＤＩＮＥＴはデータをＸＢＲＬ（eXtensible Business Reporting Language）という言語で保存しています。上場会社は実務支援会社の専用ソフトを利用してＸＢＲＬデータを作成し、ＥＤＩＮＥＴに送付しています。
ＸＢＲＬは財務データを扱うためのいわゆる規格されたコンピュータ言語です。すごく簡単に言うと、ＸＢＲＬはデータに対して＜タグ＞をつけて分類していきます。それにより有価証券報告書のデータがアップロードと同時に瞬時に分析できたり、ワンボタンで英語化できたりします。国税局のe-Taxや東証のTD-NETもＸＢＲＬを使っています。
その＜タグ＞を分類する規格がタクソノミです。タクソノミは英語で分類学の意味。実はＥＤＩＮＥＴに使われるタクソノミは金融庁が毎年更新してホームページにて公表しているのです。
前置きが長くなりました。２０１５年のタクソノミはこちらにあります。ぜひ、ホームページの下のほう、エクセルで公開されている勘定科目リストを確認してみて下さい。
有価証券報告書の元になる勘定科目が網羅され階層化されているのがご覧いただけるかと思います。２０以上ある個別の業法特有の勘定科目も網羅されています。しかも、冗長化された名称と、丁寧に英語名称も付されております。
これらは日本の会計基準と国際標準化された財務報告基準に合うように作られているので、勘定科目の設計の際には非常に役立つのではないでしょうか。少なくとも、ここにある勘定はＥＤＩＮＥＴに繋がるというわけです。
（※）金融庁のタクソノミは多分に公的なものですが、所有権が金融庁にありますので念のため。また、個別の勘定科目の設計等のために作られているものではないので、わが社固有の勘定が無い！という文句を金融庁に言わないであげてくださいね。
真っ白なキャンパスに絵を描く楽しさ
以上ですが、未来志向の会計プロフェッションの方々には、ＥＲＰ導入とともに新たに勘定科目を設計しなおす作業は、真っ白なキャンパスに絵を描いていくのと同じ、刺激的な作業だと思います。
ＣＦＯの方、是非、コンサルタント任せにせず、自らの手で勘定科目体系をデザインしてみてはいかがでしょう。
著者紹介
齋藤 和紀氏
（Kii株式会社 ファイナンス・ディレクター兼コントローラー）
2013年9月Kii参画。以来、成長期にある同社の管理部門全般を統括。シリコンバレーを主とした海外投資家、シリコンバレー大手IT企業からの資金調達をリードし成功させている。それ以前には、米大手石油化学メーカーの国内10社以上の経理業務を統括する国内グループの経理部長や、米系コンピューター会社日本法人のファイナンスマネージャーの要職を歴任し、成長期や過渡期にある企業を財務経理のスペシャリストとして支えてきた。2008年には金融庁国際会計調整室において政府のIFRS採用計画策定に参加。早稲田大学卒、同大学院ファイナンス研究科修了。
Kii株式会社について
Kii株式会社は日本発のグローバルなIoTプラットフォーマーとして注目のベンチャー企業です。同社の中核サービスである「Kii Cloud」IoTプラットフォームや同社が北米を中心に展開する「Space」IoTエコシステムは、世界中の大企業からスタートアップに至るまで、様々なIoT製品やモバイルアプリを支えるツールとして利用されています。シリコンバレー、東京、上海、香港、台湾、スペイン、ロンドンにメインのオフィスを置き、グローバルに事業を展開しています。Kiiは業務革新にも最先端技術を積極採用、シリコンバレースタンダードのクラウドERPであるネットスイートが急成長するKiiの事業基盤を支えています。
