仕訳と勘定科目

<ある取引が発生した時の仕訳の手順>

  1. その取引が『資産』 『負債』 『資本』 『収益』 『費用』のどれに当たるかを見つける。
  2. 最も適切と思われる具体的な『勘定科目』を見つける。
  3. 見つけた『勘定科目』がその取引によって『増加』『減少』というどの変化があったかを考える。
  4. 変化の内容によって各勘定科目の借方、貸方を決める。
  5. 出来上がった仕分けを帳面などに記入する。

 

仕訳とは

「取引」の記事で説明しましたが、取引には必ず、出るものと入るもののペアが発生します。
簿記では、この取引における増減のペアを間違いのないように『仕訳』という作業を行って記録していきます。

勘定科目とは

仕訳は取引を『資産』 『負債』 『資本』 『収益』 『費用』のいずれかの勘定グループに分類しますが、これだとあまりにも大雑把すぎますね。
そこで勘定グループを細分化します。この細分化したもののことを『勘定科目』と呼びます。例えば、『資産』であれば『現金』 『銀行預金』 『土地』 『備品』といった『勘定科目』に分けられますね。

ここで、『備品』を『現金』で買った、というひとつの取引を例にしましょう。

『備品』という『資産』を、『現金』という『資産』を使って購入したわけですから、『資産の増加』と『資産の減少』が同時に発生します。
もちろん、簿記ではこれをきちんと同時に記録しなければなりません。
そこで、『資産』という勘定グループだけでは、何が減って何が増えたかが曖昧になってしまうので、『現金』 『備品』という2つの勘定科目ごとに仕訳して記録するわけです。
仕訳の際には、必ず2つ以上の勘定科目が関わってくる、というのが大事なポイントです。

先ほどの取引を、もう少し具体的にして、5,000円で書棚を買ったとしましょう。

  1. 「現金を払った」 「書棚を買った」 の2面に分類
  2. 「現金=資産」 「書棚=資産」 とそれぞれ勘定グループに当てはまるので、「書棚という資産の増加」 「現金という資産の減少」となる。
  3. 「現金」はそのまま「現金」という勘定科目を使用。「書棚」は「備品」という勘定科目に当てはまる。
  4. 備品が増えて、現金が減ったので、「借方:備品 5,000円」 「貸方:現金 5,000円」となるので、それを記帳。

仕訳の8つのルール

  1. 資産が増えた時は「借方」
  2. 資産が減った時は「貸方」
  3. 負債が増えた時は「貸方」
  4. 負債が減った時は「借方」
  5. 資本が増えた時は「貸方」
  6. 資本が減った時は「借方」
  7. 費用が生じた時は「借方」
  8. 収益が生じた時は「貸方」
実際の取引の仕訳の際には、上記の8つが組み合わさって記帳されることになります。
また、帳簿に近い形でイメージすると、以下のようになります。
借方(左側) 貸方(右側)
資産の増加
負債の減少
資本の減少
費用の発生
資産の減少
負債の増加
資本の増加
収益の発生



業務の手順・ルールとシステムの手順やルールは揃える

基本的に、業務側で手順やルールが決まっている場合、それを情報システム化したとしてもその手順やルールは引き継ぐことになります。
業務効率の改善を図るために、パッケージ化されたシステムを導入し、それに合わせて業務側を改善するケースもありますが、いずれにしても実際の業務と情報システムで手順やルールに矛盾が無いようにします。

そうしておかないと、開発もしにくいですし、システムの使い勝手もよくありません。

そういう観点で見ると、「簿記」という業務の中に「仕訳」という作業があるわけですから、『簿記情報システム』においても、『仕訳』をするための機能が必要になりますし、何がしかの画面を使って情報を入力させるわけですから、画面の遷移や画面のデザインといったことが必要になります。

こういった業務の概要ももちろん設計しないといけないわけです。この辺りの作業を、「概要設計」や「業務設計」といったフェーズとして行います。場合によっては「要件定義」に含むかもしれません。
最近の開発でよく行われる、「テストドリブン」や「アジャイル」ではこういった用語は使わないのかもしれませんが、外せない観点ではありますね。

仕訳の手順やルールをシステムの設計に落としこんでいく際には、以下の点が重要になってくるでしょう

  • 仕訳の手順
  • 仕訳のルール
  • 勘定科目

まずは、仕訳の手順では、この記事の冒頭に上げた1~5の手順があるわけですが、もちろんこの順序にそって、というのも大事なのですが、せっかく情報システムを使うわけですから、定型的な部分はシステムで自動化することを考えます。
そこで、仕訳のルールも絡んでくるのですが、事業を営んでいると様々な取引が発生するわけですが、ある程度パターンというのは決まっています。
例えば、備品の購入であれば、「備品という資産の増加」 「現金という資産の減少」といったように。

ですので、予め「取引パターン/仕訳パターン」は用意しておき、システムの利用者はパターンの中から、実際に入力すべき取引を選ぶ、という手順にします。

さらに「勘定科目」も予め用意しておき、システムの利用者は「取引パターン/仕訳パターン」一覧から実際に入力すべき取引を選んだ時点で、借方/貸方双方に勘定科目がセットされるようにしておくと、後はシステムの利用者は日付と実際の金額を入力すればよいだけになります。

このように、業務の流れやルール、更には効率化出来る箇所などを考えながら設計を行う必要もあるわけです。

これらの設計フェーズでは、様々な設計手法や図面を活用することになります。
例えば、ユーザーが実際に操作する「仕訳入力画面」であれば、図面をかけるソフトや手書きで、画面デザインを行いますし、
画面が複数登場するような場合であれば、「画面遷移図」を作成します。
予め仕訳パターンや、勘定科目を用意しておくのであれば、その一覧の整理やコード化といった作業が必要になります。
 
この辺りは、現場によってローカルルールもあるでしょうが、WordやExcelを活用することも多いでしょう。
*実際に設計ドキュメントのテンプレートが公開されていることもありますし。
 
まあ、大事なポイントとしては、どんなソフトを使う、どんな技法を使うというよりも、何らかのカタチで目に見える形にして、開発チーム内や開発側とユーザー側で意思疎通を図って進めていくということです。

Track Back

Track Back URL

コメントする

※ コメントは認証されるまで公開されません。ご了承くださいませ。

公開されません

(いくつかのHTMLタグ(a, strong, ul, ol, liなど)が使えます)

このページの上部へ

プロフィール

HN:キリ
京都府南部を拠点にフリーのITエンジニアとして活動しています。

サイト内検索

Powered by Movable Type 6.3.2