( 4 )労務費原価計算のプロセスと注意点

原価計算の目的は、最終的には経営管理ですが、いっぽうで、財務会計や税務申告のための基礎情報を作る目的もあります。そこで、計算にあたっては会計基準や税法を念頭に置く必要があります。 あらかじめ、どんな区分が求められており、どうすれば把握・集計できるのかを自社の具体的作業に即して検討しなければなりません。

会計にせよ税務では、一定期間での情報を収集・計算しなければなりません。計算時点での確定額と概算額を区分して把握・集計し、コストの確定時点で洗い替えられるようにする必要があります。

データは、フレキシブルでシンプルに、そして第三者の検証に耐えられるようなものにしておくことが重要です。

原価計算の計算プロセス

一般に、原価計算は、製品や一定の作業といった集計対象について発生したコストを計算する営みですが、より具体的には次の計算となります。

  • 集計対象に対して直接に発生したコストを把握・集計する(直課)
  • 集計対象に対して間接的に発生しているコストを把握・集計して、一定の基準で割り当てる(配賦)

たとえば、ある製品の製造だけに必要な材料や、あるソフトウェアの制作のみに携わる従業員の給料等は、当該製品やソフトウェア(集計対象)についてのみ直接発生しているため、これらのコストはもれなく集計すれば足ります。

いっぽう、複数の製品を製造している場合に共通する材料や、従業員がさまざまな業務に関係している場合には、これらのコストは製造・制作には不可欠ですが、そのすべてが当該集計対象のために発生してはいません。これらのコストは、もれなく集計するだけでなく、集計後に何らかの基準で当該集計対象に割り当てることになります。

原価計算に重要な要素

原価計算にあたり、とくに必要な要素は次の点です。

  • 一定期間でのコストの把握と集計(いくらかかったのか)
  • 集計対象の特定(ナニを集計するのか)
  • コスト配分のための基礎情報の収集(労務費の場合は主に作業時間)

1.一定期間でのコストの把握と集計

経営は常に継続していますが、会計にせよ税務では、一定期間での情報を収集・計算しなければなりません。その一定期間はある月の末日までであることが大半です。このため、給料が20日締めの場合には、前月21日から当月20日までの給料支給確定額のうち、前月21日から前月末日までの分を区分、除外するだけでなく、当月21日から当月末日までの情報を収集し、収集できない場合には合理的な概算額を算定できるようにする必要があります。

この概算額は、後日に正確な確定額が算定された段階で確定額に置き換えられることになります。このため、置き換えれられることになる概算額と、置き換えられることがない確定額は別個に把握して集計していないと、この置換後の再計算にロスが生じることになります。

たとえば、賞与を支給した場合、その労務費は賞与が支給された月のみに発生したのではありません。賞与支給期間に潜在的に発生し、支給月に確定したといえるのです。この場合、支給対象期間中に合理的な概算額を月割などで配分して原価計算を行うことになります。

しかも、賞与には法定福利費が伴います。健康保険料や厚生年金保険料、労働保険料(労災保険料や雇用保険料など)です。これらも賞与支給額が確定しなければ確定しませんが、支給対象期間中の概算額を基礎にして法定福利費相当額を計算して原価計算を行うことになります。

さらに、税務を考慮すれば損金算入の可否にも注意する必要があります。原則として売上原価(製造費用)に係るコストについては概算額も損金算入できますが、(販売費及び)一般管理費になると概算額では損金算入できません。つまり、研究開発費(一般管理費)になるのかならないのかは、法人税の税額計算にも大きな影響を与えるのです。また、何月までの会計期間かによっては、労働保険料の損金算入時期を考慮しなければなりません。

このように、多くの項目で計算・再計算が必要なため、各項目の金額を集計してから原価計算を行うのではなく、個々の項目ごとに原価計算を行い、それぞれで概算額と確定額の計算・再計算を行うほうがよいと考えられます。

2.集計対象の特定

原価計算の目的は、最終的には経営管理ですが、いっぽうで、財務会計や税務申告のための基礎情報を作る目的もあります。そこで、計算にあたっては会計基準や税法を念頭に置く必要があります。

たとえば、ソフトウェア開発業については、会計基準では「既存ソフトの機能の著しい改良に要した作業」「既存ソフトの機能の維持に要した作業」「既存ソフトの機能の著しくない改良に要した作業」「購入したソフトの導入やカスタマイズの作業」「既存ソフトのマイナーバージョンアップの作業」「既存ソフトのメジャーバージョンアップの作業」ごとにコストを把握・集計する必要があります。と申しますのも、それぞれのコストが会計処理(仕訳)に直結し、会計上の損益に影響を与えるからです。

あらかじめ、どんな区分が求められており、どうすれば把握・集計できるのかを自社の具体的作業に即して検討しなければなりません。事後的に集計しようとしても、集計に必要な情報が不足していたり、余計な事務作業が必要になるからです。

3.コスト配分のための基礎情報の収集

一定の期間中、もっぱら特定の作業だけをしていた従業員に係る労務費ならば、当該期間の労務費をもれなく把握・集計すれば足ります。ところが、期間内に(会計上は別処理が求められている)異なる作業を行っていた場合には、それぞれの作業ごとの労務費を把握・集計しなければなりません。

そのために最優先で必要な情報となるのが、作業時間です。

単純に一定期間中の作業時間を把握するだけでは足りず、会計基準上で求められている区分を画する時点までの作業時間が収集されなければなりません。ソフトウェア開発業では、「最初に完成した製品マスターの完成時点」「製品マスターや購入ソフトウェアの著しい改良の終了時点」「収益獲得または費用削減が確実になった時点」「ソフトウェア制作の完了時点」と明確にし、それまでの作業時間を把握・集計する必要があります。

データの作成で注意すべきこと

原価計算のプロセスは、データにして検証可能にしておくわけですが、とりわけ次のポイントを高いレベルでバランスさせることが大切です。

  • 事後的な状況変化に対する修正が容易なこと(フレキシブル)
  • 集計ミスや計算ミスが発見しやすいこと(シンプル)
  • 第三者(会計監査や税務調査)に耐えられる精度、わかりやすさ

1.変更や修正が容易なこと

事業それ自体や経営方針の変更、従業員数の増減などによって、ワークシートは大きく変わることになります。フォーマット自体を変えた方が作業効率がよくなることは少なくありません。

また、やましい動機とは関係なく、いろいろな事情で作業内容に事後的に変更が加わる(追加や分割や併合)こともあります。 「やっぱりこの作業はふたつに区分して把握すべきだった」など後になってから思うこともあります。

このため、ワークシートはガチガチに組むのではなくフレキシブルに調整しやすくすることが大切です。

2.集計ミスや計算ミスが発見しやすいこと(シンプル)

ワークシートは担当者しかわからない複雑な計算の入ったブラックボックスにしてはなりません。検証可能性のあるシンプルなシートにすべきです。他人が検証しやすいワークシートを作ることを意識することで、シンプルでミスの少ないものになると思われます。

3.第三者(会計監査や税務調査)に耐えられる精度、わかりやすさ

データをシンプルにすれば、おのずと第三者も検証しやすくなります。

とはいえ、社内ではなく外部の第三者が検証する場合には、会計基準や税法への準拠性に対する説明ができなければなりません。つまり、数値に対する理論的な根拠です。

とくに、労務費の場合、作業内容の解釈については、会計的(税務的に)な判断しにくいところがあります。恣意性はまったくなくても、期首あたりの判断と期末あたりの判断が異なることはありえます。

と申しますのも、そもそも作業の内容が専門的なものであることに加え、誰がどんな作業をしたかということは、完全に内部的なもので、外部からはうかがうことが相当難しいものです。つまり、うがった目でみればいかようにでもできるのです。 たとえば、「利益出すぎそうだから研究開発費ってことにしちゃおうか」「赤字になりそうだから新製品の制作ってことにしちゃおうかということです。

よって、データの作成にあたっては、批判的にチェックする側(監査や税務調査)を念頭に、いかにデータの信頼性を高めるかが重要です。

ただし、たとえば社内メールや開発計画や業務指示書などの非財務データとの間に矛盾があると、チェックする側は一気に色めき立ち、データに対する信頼性すべてに疑問を感じることになります。チェックする側も感情を持った人間ですから。このあたりの整合性をキチンと取っておくことが大切です。

逆に、「このメールの日付と一致してますよね」「このプレスリリースと一致してますよね」ということを積極的にアピールすることで、よい心証を持ってもらえる確率も高まるでしょう。

いっぽうで、「見解の相違」に対応できる粘り腰のあるデータ取りも求められると考えられます。

「見解の相違」が生じるポイントはあらかじめ予測することができます。未然に誤解を生じないような対応は必要ですが、立場の違いから生じる「見解の相違」が避けられないことがあります。それは、基準や法令の解釈そのものというよりも、事実の当てはめにあると思われます。

たとえば、研究開発費とは認められない作業内容として見解の相違があると想定される場合を想定して、ソフトウェア仮勘定にいつでも組み込んで再計算できる準備をしておくことが望ましいと考えられます。作業内容の集計をまた最初からやり直すということのロスは避けなければなりません。

( つづく )