編集

ご回答いただきありがとうございます。

> ソフトウェアについては、
> 通達で言うところの機能維持か機能追加かというのは
> 明確な区分は難しいにしても
> 仕様書や説明書、機能評価などにより判別可能です。

そこが、やはり難しいところでして、厳密に考えると、バグ修正以外については、どんな小さな修正にせよ、すべて機能追加といえないこともなく、そうすると全ての修正開発が資産計上が必要になってしまいます。

そこで、金額的な判断基準を設けることで、切り分けをすることが出来ればと考えたわけです。

ご回答いただきありがとうございます。

> ソフトウェアについては、
> 通達で言うところの機能維持か機能追加かというのは
> 明確な区分は難しいにしても
> 仕様書や説明書、機能評価などにより判別可能です。

そこが、やはり難しいところでして、厳密に考えると、バグ修正以外については、どんな小さな修正にせよ、すべて機能追加といえないこともなく、そうすると全ての修正開発が資産計上が必要になってしまいます。

そこで、金額的な判断基準を設けることで、切り分けをすることが出来ればと考えたわけです。

返信

編集

通達から出発なさっていることから、
税務上の取り扱いの疑問点と思われましたので、
それに絞って記します。

実務上で多く使われている形式基準は、
本来は、資本的支出か修繕費かの判断が困難な場合に持ち出すものであり、
つまりは適用順序が決まっています。

ソフトウェアについては、
通達で言うところの機能維持か機能追加かというのは
明確な区分は難しいにしても
仕様書や説明書、機能評価などにより判別可能です。

つまり、すべてのソフトウェアについて、
基通７−８−６の２に基づく区分が可能といえます。

となれば、通達の適用順序を考慮して、
形式基準を適用することはあり得ない、
と結論づけられます。

通達から出発なさっていることから、
税務上の取り扱いの疑問点と思われましたので、
それに絞って記します。

実務上で多く使われている形式基準は、
本来は、資本的支出か修繕費かの判断が困難な場合に持ち出すものであり、
つまりは適用順序が決まっています。

ソフトウェアについては、
通達で言うところの機能維持か機能追加かというのは
明確な区分は難しいにしても
仕様書や説明書、機能評価などにより判別可能です。

つまり、すべてのソフトウェアについて、
基通７−８−６の２に基づく区分が可能といえます。

となれば、通達の適用順序を考慮して、
形式基準を適用することはあり得ない、
と結論づけられます。

返信