記帳時のルール

記帳時のルール

<概要>

  • あとから消すことが出来ないように、ペン・ボールペンを使う。
  • 文字は楷書ではっきりと。
  • 訂正するときは、赤二重線で消し、訂正印を押す。

実際に紙ベースでの記帳を行うにあたっては、色々とルールを覚えておく必要があります。
基本は記入した人以外が見てもわかるように、はっきりと正確に書くことです。

文字や数字の記入

記帳は『取引が確かに行われた』という信ぴょう性を保つため、あとから消したり、修正したり出来ないように、ペン・ボールペンで記入するのが基本です。
鉛筆やシャープペンはもちろんNGですが、ここのところコンビニでも気軽に買えるほど浸透した感のある、フリクションボールなどの『消せるボールペン』もNGです。

余談ですが、フリクションボールなどの『消せるボールペン』は簿記以外でも、各種の申込書の類や、契約書など申し込み・契約の証票となるものにも使えませんので、ボールペンの感覚で使うのではなく、鉛筆やシャープペンの延長で使ったほうが良いですね。

その他、細かい点をあげると以下の様なことも注意が必要です。

  • 文字は楷書ではっきりと
  • 文字は下の罫線から、極力離れないように。
  • 1行間には2行以上記入しない
  • 数字は3桁毎にカンマを打って位を揃える。

 

また、記入の際には適宜、記号を使っても良いことになっています。
どの記号を使うかは職場のルール次第ですが、よく使われるものを紹介しておきます。

記号 意味・(読み方・呼称) 使用例
円(えん) ¥15,000
% 百分率(パーセント) 8%
上に同じ(ディトー・踊り字) 仕入
@¥ 単価(たんか) @¥250
# 番号(ナンバー) #15
No. 番号(ナンバー) No.15
記帳済み、照合済み(チェックマーク)
, 桁区切り(カンマ) 150,000
. 円の位を示す(ピリオド) 155.5
1単位につき(アット) @150
a/c 勘定(かんじょう) 売掛金 a/c

訂正方法

間違って記帳した場合、修正テープなどで消してはいけません。
間違えた文字や数字を赤の二重線で消し、その上に正しい記述を行います。
文字の訂正の場合は、間違えた文字だけ、数字の訂正は全部を訂正します。

また、記入すべきでない文字や数字を記入してしまい、1行まるごと削除したい場合は、行間いっぱいに赤の二重線を引いて『空行』と記入したうえで、訂正理由を赤字で付記します。

ページ全部を訂正する場合は、ページの左下から右上に向けて赤の二重線を引き、『空ページ』と記入したうえで、訂正理由を赤字で付記します。

なお、訂正時の押印は責任の所在を明らかにするために、『訂正者の認印』を押すのが基本です。

これら、記帳時のルールは紙ベースの帳簿を元に行う場合の注意点なので、一見システムとは関係ないように思えます。
が、『簿記をシステム化』することの目的の一つには、『定型的な記帳のルール』に則って、人為的ミスを減らす、という点があります。
実際、システム化することによって、文字を楷書ではっきりと書く、という点には気を取られずに済みますし、筆記用具の心配もいりません。
数値を入力すれば、システムが勝手に3桁毎のカンマ区切りにしてくれます。

このように、人力で行うと大変なことを楽にするのも、システム化の目的になってきます。

ところが、情報システムも万能ではありません。
問題になるのは、『修正が発生した場合』の扱いです。

例えば、Excelなどの表計算ソフトを使って、仕訳帳や総勘定元帳を記録している場合を想像してみましょう。
非常に簡単に『記帳済みの仕訳』を跡形もなく修正・削除できてしまいます。

あくまでも、Excelの利用は入力の手間を軽減するためで、最終的にはプリントアウトする、ということであれば、

  • 記帳済みの仕訳を変更しない
  • 修正・削除はプリントアウト後のものに対して行う

などのルールを徹底すれば、問題は無いかもしれませんが、折角システム化したのに、運用上のルールが増えるのは現場では歓迎されないでしょうし、修正・削除が簡単にできてしまう、という問題点は残ったままです。
性善説にもとづいて、経理担当者を信用して任せる・・・というのもありでしょうが、残念ながら、経理担当者が帳簿を誤魔化して会社や組織の資金を横領してしまう、というニュースは度々報じられます。

ということなので、簿記をシステム化する上では、一旦記帳したものを簡単には修正・削除出来ない仕組みや、修正・削除を行った履歴を残す仕組みが必要になってきます。
以前の記事でも触れてはいますが、実際のシステムの開発では、このような『エラー処理』・『例外処理』というものが、実際に開発する機能の多くを占めます。

「記帳済みの仕訳を修正・削除しないといけない場合」

というのも、システムの『例外処理』として、十分に考慮して設計しなければなりません。

 

コメント

タイトルとURLをコピーしました