基幹システムの刷新が終わり、最後の請求書が回ってくる。件名は「システム導入一式」。金額は数字が並んでいるが、内訳は添付されていない。経理が発注部門に問い合わせると、見積書の写しが送られてくる。見積書にも「一式」と書いてある。
ここから按分を始めることはできない。按分には根拠が要り、根拠は請求書でなく契約と稟議にしか残らないからだ。 資産計上できる範囲を決めているのは会計基準ではなく、発注時にどう切ったかである。切っていなければ、監査法人との交渉は「全額費用」か「全額資産」の二択に追い込まれる。どちらも実態と違う。
同じ「基幹刷新」でも、支出は三つの器に分かれる
まず土台を固める。自社利用のソフトウェアについて、研究開発費等実務指針第11項は、そのソフトウェアの利用により将来の収益獲得または費用削減が確実であることが認められるという要件が満たされているか否かを判断する必要があるとし、確実と認められる場合は無形固定資産に計上し、確実であると認められない場合または確実であるかどうか不明な場合には費用処理するとしている。
資産計上される一般的な例として同項が挙げるのは三つで、実務でよく当たるのは二つ目と三つ目である。自社で利用するためにソフトウェアを制作し、当初意図した使途に継続して利用することにより、利用する前と比較して業務を効率的または効果的に遂行することができると明確に認められる場合。そして、市場で販売しているソフトウェアを購入し、かつ予定した使途に継続して利用することによって、業務を効率的または効果的に遂行することができると認められる場合である。
注目すべきは、第11項が二つ目の説明の末尾に「ソフトウェア制作の意思決定の段階から制作の意図・効果が明確になっている場合である」と書いている点だ。 効果が事後に判明した場合ではない。意思決定の段階で明確になっていることを求めている。この一文が、後述する「稟議に置く」という結論の根拠になる。
導入費用の扱いは、第14項から第16項に分かれている。外部から購入したソフトウェアについて、導入に当たって必要とされる設定作業および自社の仕様に合わせるために行う付随的な修正作業等の費用は、購入ソフトウェアを取得するための費用として取得価額に含める。ただし重要性が乏しい場合は費用処理できる（第14項）。自社で過去に制作したソフトウェアまたは市場で販売されているパッケージソフトウェアの仕様を大幅に変更して、自社のニーズに合わせた新しいソフトウェアを制作するための費用は、それによる将来の収益獲得または費用削減が確実であると認められる場合を除き、研究開発目的のための費用と考えられるため、購入ソフトウェアの価額も含めて費用処理する（第15項）。データをコンバートするための費用と、ソフトウェアの操作をトレーニングするための費用は、発生した事業年度の費用とする（第16項）。
税務の側も並べておく。ソフトウエアの取得価額には、購入の代価に加えて購入に要した費用の額と事業の用に供するために直接要した費用の額が含まれ、導入に当たって必要とされる設定作業および自社の仕様に合わせるために行う付随的な修正作業等の費用の額は取得価額に算入される。耐用年数は原本と研究開発用が3年、それ以外が5年とされている（国税庁タックスアンサーNo.5461）。会計の第14項と、税務の取得価額の考え方は、この点でおおむね揃っている。
ここまでは、少なくとも文章としては明確である。問題は、この明確さがクラウドで消えることだ。
クラウドに移った瞬間、器が一つ消える
JICPAの会計制度委員会研究資料第7号「ソフトウェア制作費等に係る会計処理及び開示に関する研究資料 ～DX環境下におけるソフトウェア関連取引への対応～」（2022年6月30日）は、この論点を正面から扱っている。
研究資料はまず、クラウドサービスのユーザー側の会計処理について、現行の会計基準の体系の中では明確な規定は設けられていないと述べる。そのうえで、SaaSの利用料はユーザーが受けるサービスに係る対価であってソフトウェアを購入するための支出ではないため、サービスの発生に応じて費用処理されることとなり、ソフトウェアが計上されたりリース取引として処理されたりすることはないと考えられるとする。ここは争いが少ない。
争点は初期設定費用とカスタマイズ費用である。研究資料は、通常の自社利用ソフトウェアでは第14項によりこれらを取得価額に含めることとされているが、SaaSではソフトウェアが譲渡されておらずユーザー側にソフトウェアに対する支配を有していないと考えられること、かつ会計基準上の明示的な規定がないことから、これを自社のソフトウェアとして計上することは難しいと考えられるとする。したがって契約当初に一時に支払った初期設定費用やカスタマイズ費用について、支払時に一時の費用として計上することが考えられる、というのが一つの帰結である。
ただし研究資料はここで止まらない。 ASBJの討議資料「財務会計の概念フレームワーク」の資産の定義に当てはめ、これらの費用が経済的資源に該当し、そこから生み出される便益を享受できるため支配が存在している可能性があるとして、資産性の要件を満たす可能性があると述べる。そのうえで、資産性の検討に際しては自社利用のソフトウェアの資産性の要件に照らして検討することが考えられるのではないか、支払額の全てを資産計上するのではなく複数の性質の費用が含まれる場合は一部が資産、一部が費用となるケースも考えられるのではないか、という問いを提示している。実務上は長期前払費用として計上しているケースが考えられるとも記している。
無形固定資産として計上できるかについては、我が国においては無形固定資産に係る包括的な会計基準がなく、当該資産が無形固定資産に計上できるものかどうかの判断基準がないことから、現行の会計基準の下では無形固定資産に計上できるものと明確に判断することは難しいのではないかとしている。
要するに、日本基準はこの問いに答えを持っていない。 だからこそ、監査法人と握るための材料を自社で用意する必要がある。材料とは、支払の中身が何であるかを示す契約と見積の内訳である。
IFRSの側では、この論点はすでに二度たたかれている
日本基準に規定がないとき、監査法人への説明の骨格として使えるのがIFRS解釈指針委員会のアジェンダ決定である。研究資料の付録が経緯を整理している。
一つ目は2019年3月のアジェンダ決定で、SaaSのベンダーが提供するアプリケーション・ソフトウェアに対して、そのユーザーが将来にわたってアクセスできる権利のみを付与する契約は、IFRS第16号「リース」およびIAS第38号「無形資産」のいずれの適用範囲にも含まれないサービス契約であると結論づけた。ユーザーがサービスを受ける前に支払を行う場合、その前払い分は将来のサービスに対する権利を顧客に与えるものであり、顧客にとっての資産に該当するとされた。
二つ目は2021年4月のアジェンダ決定で、クラウド・コンピューティング契約におけるコンフィギュレーション又はカスタマイゼーションのコストを扱う。この決定で重要なのは、二つの用語を明確に分けた点である。 コンフィギュレーションは、ソフトウェアの既存のコードを特定の方法で機能するようにセットアップするため、アプリケーション・ソフトウェア内部に様々なフラグやスイッチを設定し、または値やパラメータを設定することを伴う。カスタマイゼーションは、アプリケーションの中のソフトウェアのコード修正または追加コード作成を伴い、一般的にソフトウェア内部の機能変更または追加機能の開発である。
会計処理の結論はこうである。顧客はコンフィギュレーションまたはカスタマイゼーションが行われたソフトウェアを支配しておらず、顧客によって支配される資源を別個に創出しないため、SaaS契約においては顧客は無形資産を認識しないことが多いと仮定された。無形資産を認識しない場合、サービスの提供者がSaaSベンダーであることを前提として、顧客が受け取るサービスが別個のものであればベンダーが作業を行った時点で費用として認識し、別個のものでなければ契約期間にわたりアプリケーション・ソフトウェアへのアクセスを提供する時点で費用として認識する。サービスを受ける前に支払を行う場合は、その前払額を資産として認識する。
日本基準を採用している会社でも、この二分は使える。 ベンダーの見積書に「導入支援一式」と書かれているものを、パラメータ設定の作業とコード追加の作業に分けて出し直させる。分けた結果は、日本基準の下でも「役務の性質が異なるものが混在している」という説明の根拠になる。研究資料自身が、複数の性質の費用が含まれる場合に一部が資産、一部が費用となるケースを想定していることと整合する。
税務は、会計と別のところで資産にする
ここを外すと、申告調整の漏れが後から出る。
研究資料の付録は税務上の取扱いを整理しており、クラウドサービスにおいてカスタマイズしたソフトウェアがベンダー側にあり、当該カスタマイズ費用をユーザーが一括で支払った場合、ユーザー側では会計上の処理にかかわらず、支出の効果が将来に及ぶものであるため、当該費用を税務上の繰延資産として計上して一定の期間にわたって損金として処理するとしている。根拠は法人税法施行令第14条第1項第6号で、同号は自己が便益を受けるために支出する費用等のうち支出の効果がその支出の日以後1年以上に及ぶものを繰延資産としている。
償却期間については、法人税基本通達8-2-3の表にある令第14条第1項第6号ロの権利金等のうち(3)の取扱い、すなわち5年（契約による賃借期間が5年未満である場合において、契約の更新に際して再び権利金等の支払を要することが明らかであるときはその賃借期間）と同様に考えて5年とする見解が紹介されている。一般的なクラウドサービスは契約期間の満了時に更新できる仕組みになっており、更新に際してカスタマイズ費用などの一時金の支払が発生することは通常ないという整理である。
含意は単純である。会計で一時の費用として落としたカスタマイズ費用が、税務では5年の繰延資産になる。 差額は申告調整で処理し、税効果の対象になる。導入の期に「全額費用処理しました」とだけ報告して終わると、翌年以降の別表で毎年つまずく。導入プロジェクトの終了時点で、会計上の処理と税務上の処理を並べた一枚を作っておく。 これは決算のときに作るのではなく、検収のときに作る。
なお、オンプレミスでライセンスを購入した場合は、この論点は生じない。取得価額に含めて5年で償却するという、会計と税務がおおむね揃った世界である。クラウドに移ることで増えたのは、利便性と、申告調整の手間である。
分ける作業を、経理から発注部門へ移す
ここまでの整理を踏まえると、経理が決算期に按分することは不可能に近いと分かる。按分の材料が請求書に存在しないからだ。したがって、材料を作る工程を上流へ動かす。
置き場所は稟議である。研究開発費等実務指針第12項は、資産計上の開始時点を将来の収益獲得または費用削減が確実であると認められる状況になった時点とし、それを立証できる証憑として制作予算が承認された社内稟議書やソフトウェアの制作原価を集計するための制作番号を記入した管理台帳を挙げている。基準そのものが稟議書を証憑として名指ししている以上、稟議の様式を直すのが最短の打ち手になる。
稟議様式に置く欄は四つでよい。
第一に、ライセンス購入または利用料の金額。第二に、コンフィギュレーション、すなわちパラメータやフラグの設定作業の金額。第三に、カスタマイゼーション、すなわちコードの修正または追加開発の金額。第四に、データ移行と研修の金額。そして、この四区分での内訳提示をベンダー見積りの提出条件として発注仕様に書く。 見積りを取る段階で書いておけば、ベンダーは分けて出す。契約後に頼むと「一式で合意済み」と言われる。
契約書の切り方も同じ論理で決まる。利用契約と導入役務契約を1本にまとめると、分離の根拠が契約に残らない。2本にしておけば、後から説明する材料が自動的に残る。契約を分けるのに追加の費用はかからない。かかるのは、発注前に決めるという一手間だけである。
検収の単位もあわせて設計する。実務指針第13項は、資産計上の終了時点を実質的にソフトウェアの制作作業が完了したと認められる状況になった時点とし、証憑としてソフトウェア作業完了報告書や最終テスト報告書を挙げている。四区分ごとに検収の書面を取れば、資産計上の開始と終了の両端に証憑が揃う。
ベンダー見積りの読み方と、追加費用が生まれる境目については別稿でも扱っている（SAP導入の見積りと契約をどう読むか｜追加費用が生まれる境目を先に潰す）。判定を発注前に終えるという発想は、資本的支出と修繕費の線引きと同じ構造である（資本的支出と修繕費の線引き｜請求書が来てから判定する会社は決算で戻せない）。
決めるのは会計処理でなく、発注の切り方
第一に、ベンダー見積りを四区分で提出させることを、発注仕様に書く。 ライセンスまたは利用料、パラメータ設定、コードの修正と追加開発、データ移行と研修。契約後に頼んでも遅い。四区分は、日本基準に明文がない領域で監査法人と話をするための唯一の共通言語になる。
第二に、利用契約と導入役務契約を分けて締結する。 1本にまとめると、分離の根拠が契約に残らない。分けるのに費用はかからず、必要なのは発注前に決めるという一手間だけである。検収も四区分ごとに取り、実務指針第13項が挙げる作業完了報告書や最終テスト報告書を証憑として残す。
第三に、会計処理と税務処理を並べた一枚を、決算期でなく検収の時点で作る。 会計で一時費用としたカスタマイズ費用が、税務では法人税法施行令第14条第1項第6号の繰延資産として5年に伸びる組み合わせは普通に起きる。この一枚がないと、導入から数年にわたって毎期の別表でつまずく。 作るのに要するのは半日で、作れるのは検収の内容を覚えているうちだけである。
