月次決算早期化のための業務設計(5)その他の会計処理

本シリーズも今回が最終回となりました。

これまで月次決算早期化を会計以外の業務にもフォーカスを当てながら、全社プロジェクトとしてどのように進めていくかについて書いてきました。会計ソフトという箱に流し込むデータをどう集め、どう整形していくのかという観点で、本シリーズではCRMをフル活用し、時にはデータベースをカスタマイズしていくことを前提としています。会計にしても、人事・労務にしても、自社のビジネスをしっかりと理解し、そのデータの流れを掌握しているかどうかは非常に重要であり、これからのバックオフィスにはそういう人材が必要不可欠であると私は考えています。

世の中にはExcelという非常にすぐれたデータ加工ツールがありますが、何でもできるがゆえに、データを蓄積しておく箱（データベース）として活用するのには向いていません。データ同士を関連させ多層的な構造を作ることも苦手ですし、エラーチェックや特定条件における自動処理も得意ではありません。よって、弊社では一貫して「Excelはデータを一時的に加工するものであり、データを蓄積するものとしては使わないでください」とお客様にご案内しております。

今回はその他の会計処理として、IT企業を中心に月次決算早期化の中で、難易度が高めの「ソフトウェア」と「前受金の管理」について見ていきます。扱うデータが広範になるため、ここでは月次決算時の一時処理としてここではあえてExcelを使っています。毎月1回だけの計算であり、その後の償却額の計算などは専門ソフトで行うことができるためです。まずはソフトウェアの管理について見ていきましょう。

ソフトウェアの管理を見ていく前に、会計基準や税務上でソフトウェアがどのような扱いになっているかを確認しておきましょう。ここをきちんと理解しておかないと「ソフトウェア」をどう管理するべきなのかが曖昧になってしまいますので、少し小難しい内容になりますが、お付き合いください。

ソフトウェアは無形固定資産の１つです。産業の中心が製造業からITに移っていく中で、会計上の重要性も高まっています。「研究開発費等に係る会計基準」においてソフトウェアは、その制作目的に応じて、自社利用目的のソフトウェアか販売目的のソフトウェアに分類されます。

自社利用目的のソフトウェアは、ユーザーへのサービス提供の際に利用するソフトウェアと、自社の生産管理や顧客管理などの社内管理のために利用するソフトウェアに分類されます。このソフトウェアの対価を直接ユーザーから得るものではないことが特徴です。

一方で、販売目的のソフトウェアは、特定のユーザーから個別に受託して制作する受注制作のソフトウェアと、不特定多数のユーザーに販売するパッケージ型の市場販売目的のソフトウェアに分けられます。ソフトウェアそのものを利用する対価をユーザーから得るために開発されるものになります。

ソフトウェアは無形であり、外部からはその仕様や状況を容易に把握することが困難であるため、かねてよりソフトウェア制作費の資産計上については、様々な課題が指摘されてきました。資産性の評価や適切な計上額の算出、収益認識のタイミングなど、会計上の論点は多数有ります。さらには、最近のソフトウェア産業の構造変化によって、新しい論点が発生しています。

１つは、ソフトウェアの販売方法が、パッケージの買い切り型からクラウドのサブスクリプション型への変わってきたことです。パッケージ型ソフトウェアの最王手だったマイクロソフトとアドビも、販売手法をゼロから見直し、サブスクリプション型に移行することで業績を回復させました。ユーザーにとって、ソフトウェアは買うものではなく、毎月定額の利用料を払って使用するものなりつつあります。

もう１つは、クラウドで簡単にアップデートを提供できるようになったことによって、開発手法も要件定義や設計、テストなどの工程を計画通りに進めていくウォータフォール型から、より小さな単位でスピーディーに開発サイクルを回していくアジャイル型が主流になりつつあることです。クラウド型のソフトウェアは、「永遠のβ版」と呼ばれるほど常にアップデートを繰り返しているものがほとんどです。

これらの変化に対して、会計基準も税務も対応が追いついていないのが現状です。会計基準上の分類は前述の通りであり、主なクラウド型のソフトウェアは市場販売目的のソフトウェアに分類されますが、会計基準上はまだパッケージ型のソフトウェアを前提としているため、クラウド上でサブスクリプション型で提供することはあまり想定されていません。また、クラウド上で非常に短いサイクルでアップデートを行えることも想定されていません。

会計基準では「製品マスターが完成し、販売の意思が明らかにされる」以前に発生した費用は研究開発費に該当し、販売の意思が明確になった以後に発生した費用は、メンテナンス費用を除きソフトウェアとして資産計上することとされていますが、アジャイル型の開発においてはこの境目を見極めることは非常に困難です。また、リリース後の開発費についても、バグ対応などは発生時の費用、機能改良についてはソフトウェアに計上することとされていますが、後からアップデートをする前提で多少粗い状態でもリリースしてしまうため、この見極めも容易ではありません。

更には、会計と税務の資産計上基準が異なることが事態をより複雑にしています。会計は「将来の収益獲得または費用削減が確実なもの」を資産計上の基準としているのに対して、税務は一定の資産性のあるものはソフトウェアとして計上するべきという立場であり、明らかにバグ対応であるアップデートを除いては資産計上する必要があります。

よって、ソフトウェア開発の費用については、明らかに保守対応であるもの以外は資産計上することとし、それをアップデートの都度計上した上で、減価償却を通じて費用化していくことが原則となり、エンジニアの人件費や外注費を社内で決めた基準に従って、ソフトウェアの取得原価か費用かに振り分ける必要があります。エンジニアの工数管理が必要になってくるのもこのためです。アップデートのリリース時には資産計上が必要になるため、ほぼ毎月ソフトウェアを計上することになり、非常に管理が煩雑になるのです。なお、保守対応であるもの以外は資産計上するという考え方が原則であり、利益を出すために恣意的に資産計上をするなどの対応はもちろん認められていません。

ソフトウェアの管理を行うためには、まず開発プロジェクトを保守対応か機能開発かに分けて管理する必要があります。エンジニアの稼動をすべて保守か資産計上に振り分ける必要があるため、どんな小さな対応も、なんらかのプロジェクトに属していなければなりません。そのために各エンジニアはどのプロジェクトにどれだけの時間をかけているのかを、工数管理という形で記録していく必要が生じます。

次に、人件費と外注費を工数に従って、保守費用と資産に振り分けていきます。人件費は給与だけではなく、通勤手当を含む各種手当、法定福利費や賞与の金額も含むため、これらを集計した上で振り分ける必要があります。外注費も同様です。そして、計算した資産計上額を固定資産管理ソフトに登録した上で、ようやく当月の減価償却費の計算が可能になります。他の固定資産が取得時のエビデンスを集めて計上額を確定させるのに比べると非常に手間がかかります。

プロジェクト管理、勤怠管理、工数管理、人件費となる費用の集計、外注費の中から開発費となるものの抽出、という形で管理しなければならないもの、集計しなければならないものが多岐にわたります。これを集計するExcelを作成しておき、各数値を貼り付けるだけで資産計上額を計算することができるようにしておく必要があります。毎月の減価償却費の計算は、固定資産管理ソフトで行いますので、Excelで計算するのは「当月の資産計上額」のみです。複雑ではありますが、明確な基準を定め、それに従って運用していれば、毎月の作業は勤怠や工数さえ確定してしまえばそこまで時間はかかりません。ソフトウェアの資産計上の仕組みをエンジニアをはじめとした関係部門に理解してもらった上で、運用することが重要です。

クラウドでのソフトウェアサービスの提供（いわゆるSaaS）はサブスクリプション型で、利用機能やユーザー数に応じて課金をしていきます。月額料金を提示している会社がほとんどですが、キャシュフローを良くするために年間利用料金を一括で請求するケースが非常に多く見られます。将来の利用料金をあらかじめ払ってもらうわけですから、これらは「前受金」とし、実際の利用期間に按分して収益計上をしていく必要があります。

このような処理においては、請求書発行時には売掛金と前受金の両建てで計上し、債権管理と収益管理を完全に切り離しておくことが必要です。なお、当月利用分が含まれる請求であってもいったんは全額を前受金として計上した上で、収益計上の処理の中で当月利用分を売上に振り替えていきます。こうすることで、請求金額はすべて前受金を経由した上で、売上に計上されていくため、前受金の管理が容易になります。

また、この前受金は、契約単位で計上額や計上期間が異なるため、それらを個別に管理しなければなりません。CRMなどをカスタマイズして毎月の売上計上額を算出するか、Excel上で前受金を個別に按分した上で、積上げ集計することで当月の収益金額を算出し、会計ソフトにはその合計額のみを計上します。会計ソフト上で前受金の内訳管理をしようとすると煩雑になりすぎるため、ここでも会計ソフトはデータを集約する箱として、その前処理は別のソフトで行っておきます。

Excelで行うか、CRMをカスタマイズするかの判断は量にもよりますが、プラン変更やキャンセル処理の反映を正確に行うためには100件を超えたあたりから、きちんと開発した方がいいでしょう。月次決算処理としては、この前受金の残高検証まで行っておけば決算時の確認が非常に楽になります。

ソフトウェアの資産計上と償却、前受金の計上と収益管理は古くて新しい論点です。ソフトウェアがクラウドにシフトしていく中で、会計基準や税務がその変化に対応出来ていないため少し違和感はあるかもしれませんが、原則をきちんと理解して論点を整理し、会計処理から逆算して業務を組み立てることで、月次決算という限られた期間の中できちんとした処理を行うことができるようになります。

なお、ソフトウェアも前受金も、これまで見てきた請求管理、支払管理、給与計算などの処理がきちんと行われていることが大前提であることは言うまでもありません。月次決算早期化というプロジェクトは、全社を巻き込んで会計処理だけでなく様々な業務を適切に管理することができる体制に移行しなければ成功しません。処理スピードを上げる、リソースを増やすという解決策で乗り切るのではなく、会社の業務全体を掌握し、適切なデータが適切な形で会計ソフトに流れる業務フローを構築すること、それこそが月次決算早期化のための業務設計になるのです。月次決算早期化のための最大のポイントは、経理側の思考回路の切り替えなのです。