1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

Ledger CLIで家計簿をつけたい!入門3 口座間の資金の移動

Last updated at Posted at 2022-12-04

←前編

前回はLedger CLIでクレカの買い物の際の家計簿の付け方を見ました。でも、クレカ代の支払いの記録の方法が決定打ではないねという話でした。Ledger CLIをまだインストールしていない人はこちらから↓

意味わかんねえよという人は入門1の銀行編も見てください

まず複数ファイルを同時に扱う方法

このチュートリアルでは銀行用にbank/okane/2022.ledgerというファイルを、クレカ用にcard/yellow/2022.ledgerというファイルを作ったんでした。このファイル、銀行やカードが増えるたび、そして年が進むたびに増えていきます。これら全部をまとめて俯瞰できると便利です。そのために、root.ledgerというファイルを一番上のディレクトリに作ります。

~journal$ cat > root.ledger <<EOF
include bank/okane/2022.ledger

include card/yellow/2022.ledger

EOF
~journal$ ledger -f root.ledger bal
         120,000 JPY  Assets:Banks:Okane
        -113,878 JPY  Equity:Opening Balances
          19,213 JPY  Expenses
           6,578 JPY    Fun:Game
           2,635 JPY    Grocery
          10,000 JPY    Travel
         -25,335 JPY  Liabilities:Card:Yellow
--------------------
                   0

include文は見ての通り他のファイルを読みこむための構文です。こうすることで口座ごとにファイルを分割しても問題なくなります。そして、大体のコマンドはこのroot.ledger相手に実行していくことになります。

もしファイルがすごく増えてきたら途中にbank.ledgerとかbank/okane.ledgerとかを更に追加したほうがいいかもしれません。でも、あまり多くないうちはシンプルにroot.ledgerに並べるのが一番だと思います。

カードの支払いを実にエレガントに記述する方法

前回のおさらい

さて、前回はカードの支払い額決定のイベントと、支払いのイベントを次のようにcard/yellow/2022.ledgerに記録しました。

2022/11/15 * 支払額決定
    Liabilities:Card:Yellow                        0 = -25,000 JPY

; ...その間のカード決済

2022/12/10 * 支払い
    Liabilities:Card:Yellow
    Assets:Bank:Okane                        -25,000 JPY

そしてこの方法の問題点は2つありました。

  1. 今月と翌月の支払額が一緒になっててよくわからない
  2. カードの支払イベントは銀行からカードへのお金の動きで、これをカード側と銀行側どちらに書けばいいかわからない

解決策: もう一つ「口座」を作る

これに対する私の現時点での解決策はもう一つ口座を作るというものです。と言っても、実際に銀行やカードの現実に存在する口座ではありません。あくまでLedgerの中で口座間の資金の振替を表す仮想の口座があると考えてしまうのです。そうするとさっきの2回のイベントは次のように書き換えられます。

  1. 11/15に「クレカ口座」から「仮想口座」に負債を25,000円移す
  2. 12/10に「銀行口座」から「仮想口座」にお金を25,000円移す

これだけで、先の問題の2つが解消します。なぜなら、

  1. 次の支払額は「仮想口座」に、まだ締め日が来てないクレカの残高は「クレカ口座」と、別々に管理されて一目瞭然です。
  2. 記録の仕方もはっきりします。1つ目の支払額決定をカード側に、2つ目の支払い自体は銀行側に書きます。
    それぞれのイベントがクレカ、銀行といった現実の口座一つだけに対応しているからです。

実際にさっきの記録をこの仮想口座を使う方法で書き直してみましょう。

card/yellow/2022.ledger
; まず2022/11/15の支払額決定のイベントを次のように書き換える

2022/11/15 * 支払額決定
    Liabilities:Card:Yellow                  25,000 JPY = 0
    Liabilities:Wire:Yellow

; そして次の支払いを削除
; 2022/12/10 * 支払い
;     Liabilities:Card:Yellow
;     Assets:Bank:Okane                        -25,000 JPY

Liabilities:Wire:Yellowというのが仮想の口座の名前です1。さて、この状態で一度残高を確認してみます。

$ ledger -f root.ledger bal
         114,855 JPY  Assets:Banks:Okane
        -113,878 JPY  Equity:Opening Balances
          24,358 JPY  Expenses
           5,000 JPY    Cash
           6,578 JPY    Fun:Game
           2,780 JPY    Grocery
          10,000 JPY    Travel
         -25,335 JPY  Liabilities
            -335 JPY    Card:Yellow
         -25,000 JPY    Wire:Yellow
--------------------
                   0

こうすると、支払額が確定したもののまだ引き落としされてない金額が25000円、翌月支払い分に335円残っていることがわかります。では銀行の方に支払ったときの記録を書き足しましょう。

bank/okane/2022.ledger
2022/12/10 * yellowカード支払い
    Assets:Bank:Okane                        -25,000 JPY
    Liabilities:Wire:Yellow

これで再度残高を確認すると、Liabilities:Wire:Yellowが消えて未払いのカード代金がなくなっていることが分かります。

$ ledger -f root.ledger bal
          99,855 JPY  Assets
         -25,000 JPY    Bank:Okane
         124,855 JPY    Banks:Okane
        -113,878 JPY  Equity:Opening Balances
          24,493 JPY  Expenses
           5,000 JPY    Cash
           6,578 JPY    Fun:Game
           2,915 JPY    Grocery
          10,000 JPY    Travel
         -10,000 JPY  Income:Baito
            -470 JPY  Liabilities:Card:Yellow
--------------------
                   0

この方法のメリットはカード代金の記録が漏れなくできてるかがすごく簡単にわかることです。次のコマンドでLiabilities:Card:YellowLiabilities:Wire:Yellowの残高推移を見てみましょう。

$ ledger -f root.ledger reg "Liabilities:Card:Yellow"
日付 摘要 金額 残高
22-Nov-01 初期残高 -6,122 JPY -6,122 JPY
22-Nov-02 とあるスーパー -2,300 JPY -8,422 JPY
22-Nov-02 ゲームショップ -6,578 JPY -15,000 JPY
22-Nov-03 新幹線のチケット -10,000 JPY -25,000 JPY
22-Nov-15 支払額決定 25,000 JPY 0
22-Nov-20 コンビニ -135 JPY -135 JPY
22-Nov-30 コンビニ -200 JPY -335 JPY
22-Dec-05 コンビニ -135 JPY -470 JPY

カード残高が締め日のたびにゼロになっていることが分かります。これがゼロになっていなければ、なにかつけ忘れてるはずです。

$ ledger -f root.ledger reg --sort=d "Liabilities:Wire:Yellow"
日付 摘要 金額 残高
22-Nov-15 支払額決定 -25,000 JPY 0
22-Dec-10 yellowカード支払い 25,000 JPY 25,000 JPY

--sort=dオプションは取引を日付順にするオプションで2これ以降regを使うときはほぼ必須になるオプションです。こちらも締め日に増える、支払ってゼロになるを繰り返します3。なので、支払うたびにゼロにならなければ、なにかミスがあるということに気づけます。私は、以前銀行の不手際でカードの支払が滞ってたことがあり、それに気づいたのもこのLiabilities:Wireの残高のおかげでした。

銀行口座間の振り込みも同じようにできる

この口座間の移動を別の口座として表現する手法は銀行口座間での振り込みにも応用できます。

; okane銀行側
2022/12/1 振り込み
   Assets:Banks:Okane      -10,000 JPY
   Assets:Wire:Mizuho

; みずほ銀行側
2022/12/1 振り込み
   Assets:Banks:Mizuho      10,000 JPY
   Assets:Wire:Mizuho

さっきのカードの未支払いの残高はLiabilities, 負債でしたが、この口座は振り込みの途中の状態にある自分の資産なのでAssetsになってるのがポイントです。あと、振り込みの口座(銀行)ごとに分けておくと何かと捗ります4。振込手数料がかかってしまった場合は振り込み取引内で手数料も記述してしまえます。

; okane銀行側
2022/12/1 振り込み
   Assets:Banks:Okane      -10,100 JPY
   Assets:Wire:Mizuho       10,000 JPY
   Expenses:Commission         100 JPY

; みずほ銀行側
2022/12/1 振り込み
   Assets:Banks:Mizuho      10,000 JPY
   Assets:Wire:Mizuho

このように取引の中には任意個の仕訳を並べることができます。ただその値の合計がゼロになれば大丈夫です。

これまでの入門1〜3編で日々の記録の付け方は多分全て網羅できていると思います。ここで使わないような取引は後で応用編として出します。例えば、企業でRSUをもらってる人、株を売買する人や固定資産を有する人などです。明日は一度立ち返って複式簿記って結局なんなんだろうというのをソフトウェアエンジニア視点でポエムにします。ポエムなので読まなくてもいいです。

  1. 簿記の上ではこういう負債は未払金に多分分類されるので、正しい英語の勘定科目風にするとLiabilities:Payable:Yellowとかになると思います。ただ、私の個人的な運用として口座間の移動に機械的に出てくる未払金と、人でちゃんと注意しないといけない本来の未払金を区別したいのでLiabilities:Wireという区分を作っています。

  2. Ledgerは標準だとファイル内での出現順で取引を並べるので、--sort=dを付けないと常に銀行側での取引が出てからカード側での取引が出ることになります。

  3. 全て一回払いで支払っている場合。複数回払いやリボ払いの場合この残高が支払ってもゼロにならないということになります。

  4. 「振り込む」と心の中で思ったならッ!その時スデに行動は終わっているんだッ!…ということはありませんが、振り込み元は振り込んだ以上何も心配することはないので、待つ方である振り込まれる側を基準に分類したほうがいいです。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?