苦境にあるほぼすべての小規模ビジネスの勘定科目表を開いてみると、同じような光景が目に飛び込んできます。280もの科目があり、そのうち90は一度しか使われておらず、「事務用品費」には十数種類のバリエーションがあり、誰も説明できない科目が3つあるといった具合です。経営者は、2022年にある特定のベンダーにいくら支払ったかは正確に答えられますが、前期にビジネスで利益が出たかどうかは答えられません。
これが、肥大化した勘定科目表のパラドックスです。科目が多いほど情報が増えるように感じますが、実際には逆のことが起こります。損益計算書があまりに細分化され、一貫性がなくなるため、誰も読み解けなくなってしまうのです。優れた勘定科目表とは、あらゆるものを詰め込むための整理タンスではありません。それはレポートを作成するための計器であり、他の計器と同様、特定の問いに答えるために構築されたときに最も力を発揮します。
このガイドでは、実際に意味のある情報をもたらす勘定科目表の設計方法について詳しく説明します。番号の付け方、階層をどこまで深くするか、補助科目と部門やクラスの使い分け、そして財務諸表を密かに無用なものにしてしまう「肥大化」を見抜き、削減する方法を解説します。
勘定科目表の本来の目的
勘定科目表（COA）は、ビジネスでお金の流れを記録するために使用するすべてのカテゴリのマスターリストです。記帳されるすべての取引はいずれかの科目に分類され、すべての科目は貸借対照表または損益計算書のいずれかのレポートに集約されます。
科目は5つのグループに分類されますが、この順序は恣意的なものではありません。それは財務諸表の構造を反映しています。
- 資産 (Assets) — 現金、売掛金、備品、在庫など、ビジネスが所有するもの。
- 負債 (Liabilities) — 買掛金、借入金、クレジットカード、未払税金など、ビジネスが負っている義務。
- 純資産 (Equity) — 拠出金、利益剰余金、配当など、所有者の残余持分。
- 収益 (Revenue) — 事業活動を通じて得た収入。
- 費用 (Expenses) — 売上原価を含む、事業を運営するために費やすコスト。
最初の3つのグループは貸借対照表を構成し、後の2つは損益計算書を構成します。勘定科目表を設計する際のあらゆる工夫は、これら2つのレポートを一目で読み解けるようにするためにあります。
優れた勘定科目表であるかどうかのテストは簡単です。損益計算書を印刷したとき、どの行を見ても、それに対してどのようなアクションを取るべきか判断できるでしょうか？ もしある行に「雑費 — $14,200」と書かれていても、答えはノーです。その科目は何も伝えていません。むしろ、何かを隠しているのです。
番号体系：中身を決める前に枠組みを作る
勘定科目の番号は骨組みです。たとえ会計ソフトが名前だけで管理できるとしても、番号体系があれば科目が予測可能な順序で並び、勘定科目表の視認性が高まります。
ほぼ世界共通の慣習として、科目をグループごとに1,000単位のブロックで分類します。
| 範囲 | 科目のグループ |
|---|---|
| 1000–1999 | 資産 |
| 2000–2999 | 負債 |
| 3000–3999 | 純資産 |
| 4000–4999 | 収益 |
| 5000–5999 | 売上原価 |
| 6000–7999 | 営業費用 |
| 8000–9999 | 営業外収益・費用 |
ほとんどの小規模ビジネスでは、4桁の番号で十分です。非常に規模が小さく、そのままの規模を維持する予定であれば3桁でも機能しますが、4桁にしてもコストはかかりませんし、はるかに余裕を持てます。
現実の運用に耐えうる番号体系にするためには、2つのルールがあります。
番号の間隔を空ける。 6000、6001、6002のように割り当ててはいけません。6000、6010、6020とするか、主要なグループ分けには6100、6200、6300といった具合に割り当てます。既存の2つの科目の間に新しい科目が必要になったとき、下の番号をすべて振り直すのではなく、その隙間に差し込むことができます。余裕を持たせておくことは、設計において最も安上がりな決断ですが、それを忘れることは最も多い後悔のひとつです。
先頭の数字の意味を厳守する。 6000番台の番号は、常に営業費用でなければなりません。誰かが「番号が近かったから」という理由で、負債を5000番台に分類した瞬間、レポートの整合性は崩れ、番号体系はその唯一の役割を果たせなくなります。
どこまで深くすべきか？：肥大化の問題
ここで多くの勘定科目表が失敗します。社内の誰かが「ソフトウェアにいくら使っているのか？」という妥当な質問をすると、反射的に新しい科目を作ってしまいます。そしてまた一つ。さらにはソフトウェアベンダーごとに個別の科目を作るようになります。勘定科目表は対症療法的に、良かれと思って追加される科目によって、読みづらくなるまで増殖し続けます。
これが勘定科目表の肥大化です。本来は別の属性で処理すべきレポートのニーズを満たすために、元帳の科目が無秩序に増えていく現象です。メカニズムは常に同じです。誰かが新しい切り口のデータが欲しいと言ったとき、新しい属性を追加する代わりに、新しい「科目」が追加されるのです。
肥大化には、見落とされがちなコストが伴います。
- 仕訳の不整合。 ソフトウェア費用を計上できる場所が12箇所もあると、2人の担当者（あるいは同じ担当者でも別の日）で判断が分かれます。トレンドラインはノイズだらけになります。
- 読みづらい財務諸表。 140行もある費用の損益計算書は、30行のものより情報量が多いわけではありません。人間が一度に140もの数字を把握することはできないため、むしろ情報量は少なくなります。
- 決算の遅延。 科目が増えるごとに、確認、照合、説明の手間が増えます。肥大化は、5日で終わるはずの決算を3週間に長引かせます。
- 休眠科目。 肥大化した科目表の半分は一度しか使われず放置された科目であり、それぞれが将来の誤仕訳を招く小さな罠となります。
大まかな目安として、ほとんどの小規模ビジネスに必要な科目は、合計で30から60程度です。いくつかの収益科目、明確に区分された売上原価、20〜30の営業費用科目、そして実際にビジネスで保有している貸借対照表科目があれば十分です。もし、従業員が8人しかいないのに科目が200もあるなら、その科目表はビジネスの姿を映しているのではなく、過去に投げかけられたあらゆる質問の残骸を映し出しているに過ぎません。
肥大化を防ぐための規律は、新しい科目を作る前にたった一つの質問をすることです。「この行があることで、私の意思決定は変わるだろうか？」 もし「マーケティング費」を「Facebook広告」と「Google広告」に分けることで予算配分が変わるなら、分けるべきです。もし両方の数字をチラッと見て終わりなら、一つにまとめておきましょう。科目の存在価値は、理論的に区別できることではなく、意思決定を変えられるかどうかにあります。
構造のための勘定科目、詳細のためのディメンション
帳簿の肥大化のほとんどは、一つの間違いに起因します。それは、勘定科目に適さない要素を記録するために勘定科目を使ってしまうことです。
企業は単に「何に」お金を使ったかを知りたいだけではありません。「どこで」「どのプロジェクトのために」「どの拠点で」「どの顧客のために」使ったかを知る必要があります。これらの問いに答えるために、次のように勘定科目を増やすのは誤った方法です。
6100 給与 — 営業
6101 給与 — エンジニアリング
6102 給与 — オペレーション
6110 旅費交通費 — 営業
6111 旅費交通費 — エンジニアリング
6112 旅費交通費 — オペレーション
6120 ソフトウェア — 営業
...3つの部門と3つの費用タイプだけで9つの勘定科目が作成されてしまい、これでは合算しなければ給与総額さえ分かりません。さらに4つ目の部門を追加するたびに、勘定科目体系（COA）を編集し直すことになります。
正しい方法は、費用タイプごとに1つの勘定科目を維持し、各取引にその他の事実をタグ付けすることです。
6100 給与
6110 旅費交通費
6120 ソフトウェア「営業」「エンジニアリング」「オペレーション」といった部門は、取引上の別のフィールドとして扱います。会計ソフトによってこのフィールドの呼び方は異なります。QuickBooksではクラスやロケーション、Xeroではトラッキングカテゴリー、Sage IntacctやNetSuiteではディメンションと呼ばれます。原理はどれも同じです。勘定科目は「どのような種類のコストか」を答え、ディメンションは「ビジネスのどの部分か」を答えます。
この分離には大きな相乗効果があります。1つの「給与」勘定科目と「部門」ディメンションがあれば、給与総額、部門別給与、旅費総額、部門別旅費、部門別総支出を、すべて同じデータから算出でき、手計算による加算は不要になります。9つの重複した勘定科目がある場合、これらのビューのうち1つしか作成できず、残りは手動で集計しなければなりません。
便利な経験則として、ラベルがお金の「性質」を表すなら、それは勘定科目です。もし「お金が発生した文脈（コンテキスト）」、つまり部門、プロジェクト、場所、顧客、助成金、資金調達ラウンドなどを表すなら、それはディメンションです。プレーンテキスト会計ツールはこの考え方を直接的に取り入れています。Beancountでは、ポスティングにメタデータをタグ付けするか、勘定科目の階層構造を使用し、すべての組み合わせを体系にハードコーディングするのではなく、レポート層でデータを切り分けるようにします。
補助科目：適度な利用が効果的
補助科目（親科目の下に子科目をネストすること）は、詳細を管理するための正当で構造的な形式です。6200 保険料 の下に 6210 一般賠償責任保険、6220 労災保険、6230 健康保険 を配置するのは合理的です。これらは真に異なるコストであり、性質が異なり、管理者がそれぞれに対してアクションを起こす可能性があるからです。
補助科目が価値を発揮するのは次の場合です：
- 親の合計が報告対象である、かつ
- 各子が個別に調査や対策の対象となる。
実際の意思決定のレベルを下回ると、それは肥大化に変わります。事務用品費 を コピー用紙、ペン、トナー、付箋 に分割するのはこのテストに不合格です。付箋の予算を管理する人などいないからです。事務用品費 という1つの勘定科目が、誠実で適切な詳細レベルです。
実用的な2つの制限：階層は最大でも2レベル（親と子）にとどめてください。3レベル目は、ほぼ常にディメンションが姿を変えたものです。また、子科目を持つ親科目に直接取引を計上しないでください。取引は子科目に計上し、親科目にはその合計が集計されるようにします。そうしないと、レポートで二重計上されてしまいます。
売上原価と営業費用を分離する
製品や請求可能なサービスを販売するビジネスにおいて、他の何よりも重要な構造的決定があります。それは、売上原価は営業費用とは別のブロックにしなければならないということです。
売上原価（COGS）は、販売物の提供に直接結びつくコストです。原材料、製品を製造する労務費、販売時の決済手数料、請求可能なプロジェクトの外注費などが含まれます。営業費用は、家賃、会計ソフトのサブスクリプション、オフィス・マネージャーの給与など、単に存在するためにかかるコストです。
この分離によって、スモールビジネスの損益計算書において最も重要な数値である売上総利益（粗利）（売上高マイナス売上原価）が算出されます。売上総利益は、間接費を差し引く前の「コア事業そのものが利益を上げているか」を教えてくれます。もし売上原価が家賃などと一緒に6000番台の科目に散らばっていたら、売上総利益は把握できず、レポートの中で最も実用的な指標を失うことになります。売上原価を5000番台、営業費用を6000番台に保つことで、計算書が自動的にこの計算を行ってくれます。
初日から帳簿を綺麗に保つ
勘定科目体系は、取引が発生し始める前に構築されたときが最も価値があり、後から修正するのは最も苦痛です。稼働中の体系を再構築するということは、過去のデータをマッピングし直すことを意味し、待てば待てほど、再マッピングが必要な履歴が増えていきます。
ここにプレーンテキスト会計の真の利点があります。Beancount.ioは元帳全体を読み取り可能なバージョン管理されたテキストとして保存するため、体系の再構築はブラックボックス化された移行ではなく、透明性が高くレビュー可能な変更となります。また、勘定科目の階層構造とメタデータにより、設計段階から「構造のための勘定科目」と「詳細のためのディメンション」の分離が実現されています。ビジュアルダッシュボードであるFavaで数値を探索する際も、何がなぜ変更されたのかを正確に把握できなくなることはありません。無料で開始して、情報を隠すのではなく、問いに答えてくれる勘定科目体系を構築しましょう。
簡易チェックリスト
勘定科目表を完成させる前に、以下の項目を確認してください。
- 勘定科目は系統ごとのブロックで番号付けされ、将来の拡張に備えて番号に空きがある。
- 売上原価（COGS）は営業費用とは別に、専用の番号範囲に配置されている。
- 勘定科目の総数が事業規模に比例している（数百ではなく、数十程度）。
- すべての科目が意思決定に繋がるものである。「念のため」に存在する科目は一つもない。
- 部署、プロジェクト、拠点は重複した勘定科目ではなく、ディメンション（属性）で管理されている。
- 子科目は最大2階層までとし、親科目に直接記帳することはない。
- 少なくとも年に一度は科目表全体を見直し、使われていない科目を整理している。
これらを正しく整えることで、損益計算書は単なる数字の羅列ではなくなります。それは本来あるべき姿、つまり「何が機能しており、何がそうでないか、そして次にどこを見るべきか」を教えてくれる、簡潔で誠実なレポートへと変わります。