freee会計における前受金処理の最適解
こんにちは、BYARD（バイアード）の武内です。
先日、マジカチmeetup"＋更新Night"でLTをしてきました。
このnoteはLTの中ではお話ししなかったfreeeの「取引」と「＋更新」の有用性などについて書いていきます。
1.freeeの取引の概念
複式簿記は優れた仕組みであり、財務諸表の基礎が簿記である以上すべての社会人が仕訳やB/S・P/Lについての学ぶことは意味があります。一方で、簿記の仕組みは非常に合理的ではありますが、紙の帳簿で管理して時の名残も多く残っており、システムで会計処理を行うことを前提に構築されたわけではないことを認識しておく必要があります。
会計ソフトは入力された仕訳データを集計することで、B/S・P/Lはもちろん総勘定元帳や補助元帳を表示し、会計実務を支援してきました。仕訳をベースにしたデータベースとしての側面です。簿記の仕組みが非常に合理的であるからこそ、デジタル化がやりやすい分野だと思います。
一方でひとつひとつの仕訳は独立したデータとして存在しています。「この仕訳に関連する処理」などの紐付けはできず、勘定科目・補助科目や部門などでの集計によって内容を確認することができるのみです。
財務諸表を作る、という目的においてはこの機能で全く問題ありませんが、逆に会計以外の分野に応用することが難しい柔軟性がない仕組みです。（だからこそ、財務諸表は存在価値があるのですが）
中小企業の経理実務において、会計ソフトで管理すべきではないのに、会計ソフト（＋Excel）で管理されてしまっている実務のナンバーワンが債権債務管理でしょう。多くの企業が補助科目に取引先名を設定し、補助元帳などでその残高推移を見ることで適切な処理が行われているかを確認していると思います。月で30件ぐらいまでならこの方法でもまだなんとかなるのですが、それ以上の件数になるとミスが発生しやすくなり、かつ、未入金や未払いの発覚が遅れてしまうとリスクがあります。
その問題を解決するためのソリューションが、freeeの「取引」という概念です。
freeeのすべての「取引」の中には「発生」と「決済」という2つの箱があります。さらに「発生」については登録時に「収入」or「支出」を選択します。そして、その「取引」の決済状態を確認することで未入金/未払いを判断することができるため、集計して補助元帳を確認する必要がありません。取引の中で「発生」があれば、必ず「決済」がなければいけないからです。なお、現金取引などの場合は、「発生」と「決済」が同時に生じたとして処理します。
「決済」は銀行やクレジットカードの明細と連携して処理されます。企業の売上や費用は請求書を発行/受領して、後日支払われるというやり取りが基本になりますので、取引が生じた際にきちんと「発生」を登録していれば、簡単に消し込みをすることができます。いわゆる「発生主義」をベースにした処理の流れで組み立てられており、非常に合理的です。
一部の中小企業や個人事業主などでは、発生主義での処理が徹底されていない場合もあり、そうなるとこの仕組みをうまく活用することができないのですが、通常の企業経理であれば「発生主義」で処理することが当たり前であり、「発生」と「決済」をワンセットにして処理するだけで、債権債務管理が自然にできるのです。
（基本は）仕訳入力はさせない、という信念で作られているのがfreeeの「取引」という仕組みです。もちろん財務諸表を作成するために「取引」の裏側で仕訳は生成されるので、仕訳がないわけではありませんが、（原則は）仕訳を直接切ることができないため、帳簿組織や発生主義などの原理原則をきちんと理解していないと混乱してしまうかもしれません。
日本の会計ソフトでこの仕組みを採用しているのはfreee会計だけです。会計界隈では当初は非常に不評だったようですが、近年では会計の専門家にも「取引」の概念の理解が広まってきており、freee専門の会計事務所も少しずつ増えてきています。
そのfreeeの「取引」の概念があることで生まれた副産物が、今回のLT主題である「＋更新」です。
2.「＋更新」を使った処理
このように資産勘定と負債勘定を同時に計上する処理は両建処理と呼ばれます。資産除去債務やリース会計などの特殊な処理を除いては、あまりよろしくないとされています。
「前受金」という勘定科目は、「商品を引き渡す前にその商品代金の一部または全額を受け取る「手付金」や「内金」などのこと」と説明されています。つまり、請求書を発行した段階ではまだ代金を受け取っていないため、相手科目に「前受金」を計上するのは簿記の教科書的には正しくありません。年次ベースで考えるのであれば請求書発行時の相手科目は「売上高」で立てておいて、期末に未経過分の利用料を「前受金」に振り返る処理が正解といえるでしょう。
しかし、前受金の対象となる請求書が毎月数十〜数百件も発生する場合において、1件ずつこの教科書的な処理をしていられるでしょうか。正確な月次決算をするためには、月次で何十本も前受金への振替と取り崩しの処理をしなければいけません。また、それぞれの仕訳とは別に、前受金の残高を検証するためのExcelを作成し、きちんと管理しなければならないでしょう。
SaaSのようなサブスクリプションモデルでの料金体系では、膨大な量の前受金管理が必要になります。1件ずつ処理していれば、バチッと残高が合うはずなのに、なぜか毎回合わない。請求金額が間違っていたり、途中で契約更新があった場合の処理が漏れていたり、原因は様々ですが、いずれも仕訳による処理の限界であり、ここの残高管理に結構な時間を使わなければいけませんでした。それを解決したのが「＋更新」です。
売掛金の消し込みについては、前述の通り「取引」の「発生」と「決済」で管理されています。「未決済」になっているかどうかを見れば、どの取引が未入金/未払いかは一発で分かるため、ここはあまり気にする必要ありません。
問題は「前受金」のような経過勘定の取り崩し処理ですが、ここを円滑にするために「＋更新」という仕組みがfreee会計には用意されています。
「＋更新」は前受金を売上に振り替えるような処理を、「取引」の中で行う仕組みです。振替伝票ではなく、「＋更新」を使用することでその取り崩し処理がどの取引から発生したものなのかが明確になるため、処理のログを追うことも容易になります。なお、毎月の振替処理を1件ずつ行わなくていいように、一括処理をする「前受/前払入力アプリ」も用意されています。
上図のように仕訳をベースに考えるのであれば、青い枠が「決済」側の処理、赤い枠が「＋更新」側の処理となります。「決済」で債権債務の消し込みを管理し、「＋更新」で取り崩しを管理しています。
売掛金と前受金の両建処理は、1つの仕訳の中に2種類の性質のものを混在させるため邪道とされていますが、freee会計においては「取引」の仕組みの中で「決済」と「＋更新」が独立して処理され、かつ、その発生源が明確になるため、freee会計を使用する場合は積極的にこの両建処理を行うように私は説明しています。
仕訳は非常に合理的な仕組みではありますが、仕訳伝票は1枚ずつが完全に独立して存在するため、取り崩しなどの処理が重なれば重なるほどミスが発生しやすく、かつ、そのミスも集計してみなければ気づけません。
一方でfreee会計においては、1つの「取引」の中で「発生」と「決済」そして「＋更新」による取り崩しが明確に紐付いているため、処理の経路が明確になり、前受金の残高もズレることが起きにくいのです。
紙の帳簿でこのような処理をしようと思うと、かなり複雑な帳簿組織が必要になりますが、デジタルデータとして「取引」が存在し、各処理の裏側で対応する「仕訳」も生成されるため、債権債務管理の実務と月次の売上高の正確な計上を簡単な処理で実現することができます。
3.ちょっとした裏話
今回のLTの元になったのは今年の3月にboardさんに寄稿させていただいた記事です。執筆の経緯としては、運営元であるヴェルク・田向さんから「年間一括で請求する場合の最適な処理を、サポート側では会計知識やfreeeの経験が不足しているため、うまく案内できずに困っている」という相談を受けたことがきっかけでした。
私もその昔、監査法人に対して売掛金と前受金の両建処理の説明に苦慮したことを思い出し、簿記の教科書的な部分の理解はしている前提で、freee会計においてはこの両建処理こそが手間や処理のログの明確性の観点からは最適解である、ということを可能な限り仕訳を使いながら説明しました。
簿記検定の3級・2級あたりでは「仕訳100問」などで取引内容に最適な勘定科目を瞬間的に答えられるように訓練するはずです。簿記学習の入り口としては問題ありませんが、知識として身につけるためにはそこから一歩踏み込んで取引の性質も含めて理解する必要があります。また、実務においては原理原則だけでなく、その処理をすることによる手間やミスがいかに発生しないようにするか、といった観点も必要不可欠です。
freeeの「取引」の概念は実務に即した良い仕組みであると感じる一方で、会計の基礎ができていない人が使ってしまうことによる危険性も最近は感じています。例えば、上図では青いボックスの中が「取引」上で表示されている内容なのですが、裏側には「売掛金」が隠れています。仕訳プレビュー機能もあるので、簿記の基礎知識がある人であれば当たり前に理解できるはずですが、その基礎がない人にとってはこの取引がどのような処理になっているかを理解することは難しいでしょう。
自営業でほとんどが現金取引である場合などは別として、企業経理で月次決算を発生主義できちんと処理する場合などは、むしろきちんとした会計知識が必要になってしまうのが「取引」の概念や「＋更新」の仕組みなのです。
私は学生時代に、日商簿記検定2級を仕訳100問の丸暗記と2年分の過去問を繰り返し解きまくる、という勉強法だけ合格してしまったことがあります。たまたま過去問でやったところが出題された、という運に助けられた部分も大きいのですが、会計的な理解などはまったくせずにパズルを解くような感じで簿記に向き合ってしまいました。
もちろん、その後の日商簿記検定1級や税理士試験ではそのようなやり方は通用するはずもなく、結局、簿記3級・2級の教科書で基礎からすべてやり直すことになりました。また、経理実務の観点でも勘定科目や仕訳の切り方の正しさではなく、取引の背景や業務プロセスの理解の方が遙かに重要であることを身をもって体験しました。
freee会計の仕組みは、会計知識が不要なわけではありません。むしろ逆で、裏側で仕訳が生成されてしまうからこそ、きちんとした会計知識が必要になってしまうのです。
他の会計ソフトとは違う入力インタフェースを採用しているからこそ敬遠されてしまう部分もあるかと思いますが、特に「＋更新」の仕組みなどは仕訳伝票の積み上げでは管理が出来なかった「処理の発生源との紐付け」を自然に実現できる非常に良く出来た機能だと思います。
ビジネスの定量管理領域において、簿記は非常にインパクトのある発明でした。しかし、いつまでも紙の帳簿で管理していた時代の原理原則を後生大事に守ることが正しいとは限りません。原理原則をしっかりと押さえた上で、デジタルでの処理に最適化したやり方を適用していくことこそ、これからは求められていくはずです。
教科書的な「正しい処理」の多くは今後はシステムによる自動化に置き換えられていくでしょう。だからこそ人間は、「どのような処理をするべきか」を考え、「適切な業務プロセス」を設計することがこれから人材には求められていきます。
簿記検定○級などの資格は今後も基礎知識としては必要ですが、処理スピードや正確性では人間がシステムを上回ることはできません。基礎知識を身につけた上で「何をどのようにすれば正しいと言えるのか」を定義するのが人間の役割です。デジタル化とは人間を単純作業から解放する代わりに、より高度で抽象的な思考を求めるゲームチェンジなのです。
おまけ
業務設計士®として、あらゆる業務プロセスを再構築する「業務設計スキル」こそがこれからバックオフィス人材が見つけるべきスキルの本丸だと考えております。
そんな想いをこめて開発しているのが、「業務設計プラットフォーム BYARD（バイアード）」です。
2022年10月ローンチ予定となっておりますので、もしご興味をもっていただける方は、ぜひトライアルのお申し込みをいただければ幸いです。
なお、トライアルにあたっては、カスタマーサクセス担当者との打ち合わせを必須とさせていただいております。当面の間は「Web上で申し込んで気軽に試す」というトライアルを提供する予定はありませんので、担当者との打ち合わせが負担だと感じる場合は、トライアルのお申し込みはお控えください。
ノートの内容が気に入った、ためになったと思ったらサポートいただけると大変嬉しいです。サポートいただいた分はインプット（主に書籍代やセミナー代）に使います。