フリーランス、小規模ビジネス、個人財務のための設定例
このガイドでは、フリーランスの専門家、小規模なブティックビジネス、個人の家計財務など、異なるニーズに合わせてBeancount元帳を調整する方法を探ります。各シナリオには、独自の勘定科目構造と考慮事項があります。各設定の根拠を説明し、Beancountのサンプルコードを提供し、追跡を容易にする便利な機能(カスタムタグや自動インポートなど)を紹介します。トーンは教育的でありながら親しみやすいものとし、開発者、テクノロジーに精通した専門家、財務愛好家など、誰でもこれらの例を現実世界でBeancountを適用するのに役立てることができます。
フリーランス
フリーランス(ソフトウェア開発者やグラフィックデザイナーなど)は、複数のクライアントやプロジェクトの経費を同時に管理することがよくあります。シンプルなBeancountの設定は、各クライアントからの収入、事業経費(雇用する下請け業者を含む)、および税金のために確保するお金を追跡するのに役立ちます。目標は、フリーランスのビジネスが成長するにつれて拡張でき、不必要な複雑さを伴わない、わかりやすい状態を維持することです。
フリーランスのための主要な勘定科目: フリーランスの元帳は通常、事業用財務と個人財務を分離します。例えば、次のようなものが考えられます。
- Assets:Business:Checking – すべてのクライアントからの支払いと事業経費のためのビジネス用銀行口座。
- Assets:Business:TaxSavings – 収入の一部を税金の支払いのために確保するための普通預金口座(雇用主があなたの代わりに税金を源泉徴収していないため)。
- Income:Client:Name – クライアントからの支払いのための収入勘定。主要なクライアントごとにサブ勘定を作成したり(例:
Income:Client:ACME)、単一のIncome:Freelance勘定を使用して取引にクライアント名をタグ付けしたりできます。 - Expenses:Business:Contractors – 下請け業者や外部委託作業への支払い用。
- Expenses:Business:Software(およびTravel、Suppliesなどの他のカテゴリ) – 通常の事業経費(ソフトウェアのサブスクリプション、備品、クライアント先への旅費など)用。
- Equity:OwnerDraw – (オプション)事業から自分自身への利益の移動を記録します。これは、自分自身に支払う際に事業資金と個人資金を区別するのに役立ちます。
根拠: この構造により、事業関連のすべてのお金が専用の勘定で追跡されます。各クライアントからの収入が記録され(主要なクライアントを簡単に確認できる)、経費は税務申告時の控除に備えて分類されます。税金を別の資産勘定に確保する(または税金の負債を記録する)ことで、政府に支払うべきお金を誤って使ってしまうことを防ぎます。元帳はシンプルに保たれます。新しいクライアントや経費カテゴリが発生した場合は、すべてを再編成することなく、新しい勘定を追加したりタグを使用したりできます。よくある落とし穴は、個人取引と事業取引を1つの口座に混在させることです。専用のビジネス用当座預金口座(および対応する資産勘定)を維持することで、照合とレポート作成がよりクリーンになります。避けるべきもう1つの落とし穴は、税金や事業主の引き出しのための現金移動の記録を忘れることです。TaxSavingsやOwnerDrawなどの勘定を使用することで、すべてのドルが説明されます。
強調すべきBeancountの機能: タグとメタデータはフリーランスにとって非常に便利です。例えば、取引にプロジェクトや請求書番号をタグ付けしたり、クライアントごとに別々の収入勘定を使用しない場合にクライアント名をメタデータフィールドに記録したりできます。これにより、特定のクライアントやプロジェクトの取引を簡単にフィルタリングまたはクエリできます(例:#ProjectXのタグが付いたすべての経費の合計)。さらに、Beancountの自動インポーターはデータ入力を簡素化できます。例えば、銀行やクレジットカードの明細のインポーターを設定して元帳に取り込み、適切な経費または収入勘定名を追加するだけです。これにより、多数の小口取引(ソフトウェアのサブスクリプションや旅費など)がある場合に時間を節約できます。
フリーランスの元帳サンプルコード
以下は、フリーランス開発者のための簡略化されたBeancountコードです。いくつかの主要な勘定の開設、クライアントからの入金、下請け業者への支払い、典型的な事業経費、そして税金用の口座への資金移動を示しています。(実際には、旅費や備品の購入などの他の経費も同様に記録します。)
1970-01-01 open Assets:Business:Checking
1970-01-01 open Assets:Business:TaxSavings
1970-01-01 open Income:Client:ACME
1970-01-01 open Expenses:Business:Contractors
1970-01-01 open Expenses:Business:Software
; クライアント収入 – 請求書の支払い
2025-08-15 * "ACME Corpからの請求書支払い"
invoice: "INV-2025-08-15"
Assets:Business:Checking 5000 USD
Income:Client:ACME -5000 USD
; 通常経費 – 例:事業用ソフトウェアサブスクリプション
2025-08-05 * "GitHubサブスクリプション"
Expenses:Business:Software 15 USD
Assets:Business:Checking - 15 USD
; 下請け業者経費 – 手伝いのための下請け業者への支払い
2025-08-20 * "下請け業者への支払い – Jane Doe"
Expenses:Business:Contractors 2000 USD
Assets:Business:Checking -2000 USD
; 税金の確保 – 税金用の貯蓄口座への資金移動
2025-08-31 * "第3四半期の税金を確保"
Assets:Business:TaxSavings 1500 USD
Assets:Business:Checking -1500 USD #tax何が起こっているのかを見てみましょう。
- 上部で必要な勘定を(開始日を指定して)開設します。これはBeancountでは厳密には必須ではありません(最初に使用されたときに勘定が作成されます)が、宣言しておくことをお勧めします。
Assets:Business:CheckingとAssets:Business:TaxSavingsの勘定はUSD残高を保持します。収入と経費の勘定は、取引通貨(この場合はUSD)を継承するため、openディレクティブでは通貨を省略できます。 - クライアントからの請求書支払い: _2025-08-15_に、クライアントからの$5,000の支払いを記録する収入取引があります。
Income:Client:ACMEを貸方記入し(複式簿記では収入はマイナス額で増加します)、当座預金口座を借方記入します。請求書番号をメモするためにメタデータフィールドinvoice: "INV-2025-08-15"が含まれています。これはオプションですが、取引に追加情報を添付する方法を示しています。この取引に#ACMEや#client-ACMEのタグを付けて、迅速にフィルタリングすることもできます。複数のクライアントがいる場合、多数のサブ勘定を作成する代わりに、一般的なIncome:Clients勘定を使用し、このメタデータや支払人フィールドに依存してクライアントを区別することもできます。 - 事業経費(ソフトウェア): _2025-08-05_に、GitHubサブスクリプション(プライベートリポジトリやその他のサービス用かもしれません)の$15の経費を記録します。転記は
Expenses:Business:Softwareに行き、ビジネス用当座預金口座を減少させます。このような少額の定期的な経費にはタグを付けることができます(例えば、以下の税金取引に#taxを追加しました。同様に、毎月発生する経費には#recurringなどのタグを付けることもできます)。この場合、勘定名自体(Software)で明確です。 - 下請け業者への支払い: _2025-08-20_に、フリーランスは下請け業者(Jane Doe)に$2,000を支払いました。これは
Expenses:Business:Contractorsの経費として、当座預金口座からの現金支出として記録されます。説明に下請け業者の名前を含めるか(今回のように)、メタデータフィールド(例:contractor: "Jane Doe")として含めることができます。これにより、誰に、なぜ支払ったのかの監査証跡が残ります(税務申告や予算編成時に詳細が必要な場合に便利です)。 - 税金のための貯蓄への移動: _2025-08-31_に、フリーランスはメインの当座預金口座から専用の税金貯蓄口座に$1,500を移動します。この取引には
#taxのタグを付けて視認性を高めています。これは経費ではなく(自分のお金を移動しているだけです)、2つの資産勘定間の移動です。これを毎月または四半期ごとに行うことで、予定納税をカバーするための資金を蓄積できます。実際に政府に税金を支払う時が来たら、経費(例:Expenses:Taxes)とTaxSavings(またはChecking)口座からの控除を記録します。よくある落とし穴は、この移動をレポートの経費として扱うことです。これは経費ではなく、予防的な割り当てにすぎないことを忘れないでください。実際の税務当局への税金の支払いのみが経費(または、そのように追跡する場合は未払税金負債の減少)となります。
まとめ: フリーランスのBeancount元帳は、シンプルさと明確さを重視しています。ビジネスに関連するすべての収入と支出が秩序正しく記録されます。意味のある勘定名と適切なタグ/メタデータを使用することで、クライアントごとや経費カテゴリごとのレポートを簡単に生成できます(例:クライアントごとの総収入、今年の下請け業者への総支出など)。この設定は拡張可能です。ビジネスの発展に応じて、新しいクライアントや経費カテゴリを追加できます。自動インポート(銀行取引を取り込むため)やプロジェクト/請求書のカスタムタグ付けなどの機能により、Beancountはフリーランスの簿記のオーバーヘッドを大幅に削減し、いつでも財務の全体像を明確に把握できます。
小規模ビジネス
次に、手作りの商品を販売するオンラインストアなど、小規模なブティックeコマースビジネスを考えてみましょう。このシナリオでは、在庫管理、売上原価(COGS)、およびオンライン決済処理業者の処理など、複雑さが増します。Beancountは、思慮深い勘定科目構造と取引記録方法でこれらに対応できます。ビジネスが製品の在庫を追跡し、オンラインプラットフォーム(Stripeで決済するShopifyなど)を通じて販売を記録し、典型的な事業経費を記録するケースを使用します。
ブティックeコマースビジネスのための主要な勘定科目: 基本的な銀行口座と経費勘定に加えて、小売ビジネスの元帳には、在庫と販売の流れを追跡するための勘定が含まれます。
- Assets:Bank:Checking – ビジネスの当座預金口座(仕入先への支払い、運営費、および決済処理業者からの送金の受け取り用)。
- Assets:Stripe:Balance(またはAssets:PayPalなど) – まだ銀行口座に届いていないオンライン支払いで回収された資金のためのクリアリング勘定。例えば、顧客がStripe経由で支払った場合、そのお金はバッチで銀行に預け入れられるまでStripe口座に留まることがあります。
- Assets:Inventory:Product – 製品の在庫勘定。各製品(または製品カテゴリ)をBeancountの商品として扱い、手持ちの数量を追跡できます。例えば、
Assets:Inventory:Widgetsは、現在在庫にある「Widget」アイテムの数量を、原価で評価して保持する場合があります。 - Income:Sales – 製品販売による収益を記録します。ビジネスに複数のチャネルがある場合、異なる販売チャネル(例:
Income:Sales:OnlinevsIncome:Sales:InStore)にサブ勘定を使用することもできますが、ここでは簡単のため1つの売上収入勘定とします。 - Expenses:COGS – 売上原価。在庫アイテムが販売された際の原価を取得します。この勘定は、一定期間に販売された在庫のコストを効果的に示します。粗利益の計算における重要な要素です。
- Expenses:Fees – 決済処理手数料およびプラットフォーム手数料(Stripeの手数料、Shopifyの手数料、PayPalの手数料など、すべてここに記録できます)。必要に応じて、これをより詳細な勘定(例:
Expenses:Fees:StripeやExpenses:Fees:Shopify)に分割することもできますが、すべての取引手数料には1つの勘定で十分な場合もあります。 - Expenses:Operating – COGSに直接関係しない一般的な事業経費(マーケティング、ウェブホスティング、ソフトウェア、出荷備品など)。これらは、さまざまなコストセンターを分析するためにサブ勘定(例:
Expenses:Marketing、Expenses:WebHosting、Expenses:Shipping)に分割できます。 - Liabilities:SalesTax – (該当する場合、オプション)ビジネスが売上に対して消費税やVATを徴収する必要がある場合、この負債勘定は徴収されたがまだ政府に納付されていない税金を追跡します。各販売では、税金部分をこの勘定に分割します。これにより、徴収された税金が収入としてカウントされず、税務当局への支払いに割り当てられます。
- Equity:OwnerEquity – (オプション)オーナーの投資と利益剰余金を表します。事業が開始されたとき、オーナーによる初期資金は、現金または在庫を提供した場合は銀行または在庫の借方記入とともに、ここに貸方記入されます。また、オーナーが利益を引き出す場合(分配)、それはこの資本勘定に対して記録されます。これによりバランスシートのバランスが保たれますが、日々の業務では頻繁に使用されることはありません。
根拠: この設定は、商品とお金の流れを分離します。在庫の購入は、最初はバランスシート(資産として)に記録され、すぐに経費として計上されるわけではありません。製品を販売した場合にのみ、そのコスト(COGS)を経費として計上し、収益を関連する経費と照合して適切な利益計算を行います。販売による収入は総販売価格で記録され、手数料は別途記録されるため、総収益と支払った手数料の両方を確認できます(したがって正味収益も)。Assets:Stripe:Balanceのようなクリアリング勘定を使用すると、入金の照合に役立ちます。お金はStripeから銀行にまとめて移動しますが、混乱なくそれらの移動を記録できます。新しい店舗オーナーによくある落とし穴は、在庫を適切に記録しないことです。例えば、すべての在庫購入をすぐに経費として計上してしまうことです。これはキャッシュフローの追跡には問題ないかもしれませんが、利益を歪めます。在庫を補充した月は利益が少なく見え、販売した月は利益が多く見えることになります。たとえ在庫を以前に購入していたとしてもです。在庫資産勘定とCOGSを使用することで、コストを販売と一致させることができます。もう1つの落とし穴は、手数料や返金を考慮しないことです。これにより、銀行やStripeの残高が記録された収入と一致しなくなる可能性があります。手数料を明示的に記録し、Stripe資産勘定を使用してStripeが支払うべき金額または支払った金額を追跡することで、これを回避します。
強調すべきBeancountの機能: Beancountでの在庫追跡は、商品と原価を処理する能力を活用します。各製品は商品シンボル(例:WIDGET)にすることができ、数量と単価の両方を記録できます。アイテムを販売すると、Beancountの在庫ロジック(デフォルトはFIFO)が、在庫ロットから適切な原価を自動的に選択できます。これは例で確認します。また、メタデータやリンクを使用して、販売とそれに対応するCOGSエントリを関連付けることもできます(例えば、両方の取引で同じ注文番号を使用したり、販売と在庫削減に#order1001のような共有タグを使用したりして、各販売に対応するCOGSエントリがあることを簡単にクエリしたり再確認したりできます)。さらに、自動インポートも役立ちます。ShopifyやStripeの支払いレポートから販売データをインポートしたり、銀行取引や支払いを取得するために銀行取引明細をインポートしたりするスクリプトを使用できます。これらの反復的なデータ入力タスクを自動化することで、分析により多くの時間を費やし、数字を入力する時間を減らすことができます。
小規模ビジネスの元帳サンプルコード
以下は、ブティックeコマースビジネスのための簡略化されたBeancountの例です。在庫の購入、販売の記録(決済処理業者の手数料を差し引いたもの)、およびその販売の売上原価の記録を示しています。実際には、他の経費(プラットフォーム手数料、広告費など)も、示されている手数料の例と同様に記録します。通貨はUSDを想定し、在庫で商品として追跡する「Widget」という製品があると仮定します。
1970-01-01 open Assets:Bank:Checking
1970-01-01 open Assets:Stripe:Balance
1970-01-01 open Assets:Inventory:Widgets WIDGET
1970-01-01 open Income:Sales
1970-01-01 open Expenses:COGS
1970-01-01 open Expenses:Fees
; 在庫の購入(Widget 50個、原価@10ドル)
2025-03-10 * "SupplierCoからWidgetを50個購入"
Assets:Inventory:Widgets 50 WIDGET {10 USD}
Assets:Bank:Checking -500 USD
; 顧客への販売(オンラインストア経由の注文#1001、Widget 2個販売)
2025-04-05 * "販売注文 #1001 (Shopify経由のWidget 2個)"
Assets:Stripe:Balance 58 USD ; 手数料差引後の正味受取額
Expenses:Fees 2 USD ; 処理手数料(Stripe)
Income:Sales -60 USD ; Widget 2個の売上 (@ 30ドル/個)
; 上記販売の売上原価(Widget 2個、原価@10ドル/個)
2025-04-05 * "注文#1001のCOGS (Widget 2個)"
Expenses:COGS 20 USD
Assets:Inventory:Widgets -2 WIDGET {10 USD}ここで何が起こっているかを順を追って説明します。
-
勘定の開設: 当座預金口座、Stripe残高勘定、Widgetの在庫勘定(ユニットを追跡するために商品
WIDGETで宣言)、および主要な収入・経費勘定(Sales、COGS、Fees)を開設します。Assets:Inventory:Widgets WIDGETと宣言することで、この勘定が商品「WIDGET」の数量を保持することを示します。これにより、Beancountはそこで商品単位が期待されることを認識し、それらの単位に原価を付加できます。 -
在庫の購入: _2025-03-10_に、在庫を購入します。仕入先からWidget 50個を各$10で購入し、合計$500かかります。この取引は、
Assets:Inventory:Widgetsを50 WIDGET {10 USD}で借方記入します。これは、記録された原価10 USDの商品WIDGET 50ユニットが在庫勘定に追加されることを意味します。貸方記入はAssets:Bank:Checking -500 USD(現金支出)です。ここでは経費勘定に直接触れていないことに注意してください。購入を在庫資産として資産計上しています。これで、バランスシートには在庫として評価額$500のWidget 50個が表示されます。(残高レポートを実行すると、在庫勘定は50 WIDGETユニットと$500の価値を示します。) -
販売の記録(注文#1001): _2025-04-05_に、オンラインストアを通じてWidget 2個の販売を記録します。明確にするために、説明に注文番号を含めています。この取引には3つの転記が含まれます。
Assets:Stripe:Balance 58 USD: 販売から受け取ったお金ですが、現在はStripeにあります(手数料差引後)。顧客が合計$60を支払い、Stripeが$2の手数料を取り、$58がStripe口座にあるとします(後で銀行に送金されます)。$58をStripeの資産として記録します。Expenses:Fees 2 USD: $2の手数料は事業経費として記録されます。これにより、損益計算書にそのコストが反映され、Stripe資産と手数料経費を合わせると顧客の総支払額と等しくなります。Income:Sales -60 USD: 売上からの$60の収入を記録します。(収入勘定は貸方記入で増加するため、Beancountの表記ではマイナス額になります。)
この取引の後、正味の効果は次のとおりです。Income:Salesが60増加、$58の追加資産(Stripeからの売掛金)、および手数料の$2の経費。Stripeが後で$58を銀行に預け入れる場合、支払い日に
Assets:Bank:Checking 58 USD / Assets:Stripe:Balance -58 USDのような単純な振替を記録します。これは、資産をStripe勘定から銀行に移動するもので、収入や経費には影響しません(資産を移し替えるだけです)。上記ではその振替を示していませんが、すべてが送金されたらStripe勘定を$0に保つために、実際の簿記では重要なステップです。 -
販売のCOGSの記録: 同じく_2025-04-05_に、販売したWidget 2個の原価を記録するための別の取引があります。
Expenses:COGS 20 USDを借方記入し、Assets:Inventory:Widgets -2 WIDGET {10 USD}を貸方記入します。これにより、在庫から2ユニットが削除されます(各ユニットの原価は以前に記録された$10で、合計$20)。{10 USD}を指定して、どの原価ロットから引き出すかをBeancountに指示します。この場合、2025-03-10に追加したロットと一致します。これで、在庫勘定には48個のWidgetが残り、関連する原価は$480になります。$20はCOGS経費に移動され、損益計算書に表示され、それらの商品の原価分だけ粗利益が減少します。(これを記録しない場合、収入は経費に比べて過大評価されます。)明確にするために別の取引を使用していますが、販売とCOGSを1つの複数行取引に組み合わせることも可能です。読みやすさと照合のために分割して表示することを好む人もいます(各COGSエントリを注文に明確に結び付けることができます)。また、このCOGSエントリが注文#1001に対応することを簡単に確認できるように、説明に注文番号を反映させました。在庫が関与する場合、すべての販売に対応するCOGSエントリがあることを確認することは良い習慣です。1つでも欠けると、在庫数が狂ってしまいます。避けるべき落とし穴は、販売のための在庫の削除を忘れることです。これにより、バランスシートに架空の在庫が残り、経費が過少に計上されます。Beancountの在庫機能({}原価表記)を使用すると、手持ちのユニット数よりも多くのユニットを削除しようとした場合に、ソフトウェアがエラーを出すため、問題を発見するのに役立ちます。
まとめ: Beancountを使用する小規模ビジネスは、驚くほど堅牢な会計システムを維持できます。お金がどこにあるのか、どこから来るのか、コストがどのように流れるのかを追跡するために勘定を構造化することで、収益性の正確な全体像を得ることができます。この例では、在庫と販売の処理方法を示しました。同様に、インターネット代の支払い(Expenses:Operating:Internet vs. Assets:Bank:Checking)、ローンや投資の受け取り(Assets:Bank vs. Liabilities:LoanまたはEquity:OwnerEquity)、または消費税の支払い(納付時はLiabilities:SalesTax vs. Assets:Bank)など、他の取引も記録します。重要なのは一貫性です。各タイプの取引を同じパターンで記録すれば、Beancountは帳簿のバランスを保ちます。自動データインポート(例えば、毎月のStripe手数料や銀行取引を取り込むため)やカスタムタグ/リンク(販売や返金などの関連取引を関連付けるため)などの機能により、このシステムは柔軟かつ効率的です。結果として、ビジネスの成長に応じて拡張できる整理された元帳が得られます。システム全体を再構築することなく、新しい製品在庫勘定、新しい経費カテゴリ、または追加の収入源(新しいオンラインマーケットプレイスなど)を追加できます。
個人財務
最後に、個人または家庭の財務にBeancountを使用する場合を考えてみましょう。この設定は、日常の経費、銀行口座、クレジットカード、ローン、投資を管理する個人または家族向けです。ここでの重点は、お金の行き先(経費)、お金の出所(収入)、そしてお金がどのように貯蓄または投資されているか(資産と負債) を追跡することです。Beancountは、予算管理アプリを置き換えたり補完したりして、財務の透明でカスタマイズ可能なビューを提供し、複式簿記の厳密さにより、何も二重にカウントされたり忘れられたりしないようにします。
個人財務のための主要な勘定科目: 個人財務の元帳には通常、さまざまな資産、負債、収入、経費の勘定が含まれます。
- Assets:Bank:Checking – 収入の入金や請求書の支払いのためのメインの当座預金口座。
- Assets:Bank:Savings – 緊急資金や特定の目標のための普通預金口座。(複数の貯蓄口座や投資口座がある場合があります。それぞれ資産勘定になります。)
- Assets:Cash – 経費に現金を使用する場合、引き出しや現金支出を追跡するための現金勘定があるかもしれません。
- Assets:Investments:Broker – 投資口座。証券口座、退職金口座401(k)/IRAなど。これらはさらに投資タイプごとに分類することも、単に機関ごとに1つの勘定としてまとめることもできます。例えば、
Assets:Investments:VanguardIRAやAssets:Investments:Robinhoodなど。投資の追跡には株式やファンドの商品も含まれる場合がありますが、詳細すぎる場合は、拠出額と口座残高を追跡するだけで済ませることもできます。 - Liabilities:CreditCard:Name – クレジットカードごとに1つの勘定(例:
Liabilities:CreditCard:Visaや銀行名)。カードでのすべての購入はここに記録され(同額の経費と共に)、カードへの支払いはこの負債を減少させる振替として記録されます。 - Liabilities:Loan:Name – 任意のローン(学生ローン、住宅ローン、自動車ローン)は負債勘定で追跡できます。元本残高と、各支払いを利息(経費)と元本(負債減少)に分割して記録します。これは高度な側面ですが、完全な財務状況を把握するためには重要です。
- Income:Salary(および/またはIncome:Bonus、Income:Interestなど) – 給与、ボーナス、利息収入、配当などを記録します。収入勘定を使用すると、さまざまな源泉からの総収入を確認できます。(給与からすでに税金が差し引かれている場合は、正味の入金を収入として記録するか、総額と税金の源泉徴収を経費または負債として記録するか、さまざまなアプローチがありますが、多くの人は個人の帳簿では簡略化のために正味収入を収入として記録します。)
- Expenses: 通常は多数あり、自分にとって意味のあるカテゴリに分類されます。例えば、Expenses:Housing:Rent、Expenses:Food:Groceries、Expenses:Food:DiningOut、Expenses:Utilities:Electricity、Expenses:Entertainment、Expenses:Travel、Expenses:Taxes、Expenses:Misc – 自分の支出パターンを反映する任意のカテゴリです。必要に応じて、詳細にも一般的にもできます。勘定科目階層は集計に役立ちます(例:
Expenses:Foodは食料品と外食の両方を合計します)。一般的な方法は、主要なグループ(住居、食費、交通費、医療費など)の階層を持つことです。 - Equity:Opening-Balances – 元帳を開始するときに口座残高を初期化するために使用されます(すべての資産から負債を差し引いたものが資本に記録された開始時の純資産と等しくなるように)。開始後は、Equity:Retained-Earningsなどを使用して累積純利益を表すこともありますが(個人財務では、通常、収入から経費を差し引いたものを純資産に組み入れます)。資本勘定は日常的には目立ちませんが、会計等式のバランスを保証します。
根拠: 個人財務の設定は、財務生活を1つの一貫したシステムで捉えることです。上記の各勘定は、さまざまな種類の財務を分離するのに役立ち、「今月の食費はいくら使ったか」(Expenses:Food:*の合計)、「まだどれだけの借金があるか」(負債勘定を確認)、「私の純資産はいくらか」(資産から負債を差し引く)といった質問に答えられるようにします。ここでの複式簿記の大きな利点は正確性です。例えば、クレジットカードで$100の食料品の請求をすると、それを経費および負債の増加として記録します。後でクレジットカードを支払うときは、銀行からカードへの振替を記録します。これにより、負債は減少しますが、食料品の経費(すでに記録済み)が二重にカウントされることはありません。複式簿記がない場合のよくある落とし穴は、クレジットカードの支払い自体を経費として扱い、$100を実質的に2回カウントしてしまうことです。Beancountは設計上これを防ぎます。避けるべきもう1つの落とし穴は、口座の照合を怠ることです。Beancountでは、残高表明またはbalanceディレクティブを使用して、例えば元帳の当座預金口座残高が実際の銀行取引明細と一致することを確認できます。これにより、エントリの欠落や重複を発見できます。
強調すべきBeancountの機能: 個人財務では、取引量が多いため、自動インポートが特に役立ちます。Beancountのインポーターフレームワークまたはコミュニティスクリプトを使用して、銀行取引、クレジットカード明細、さらにはCSV、OFX、またはAPIソースからの投資取引をインポートできます。これにより、コーヒーを買うたびに手動で入力する時間を削減できます。カスタムタグは、勘定ではできない方法でデータをスライスするのに便利です。例えば、フライト、ホテル、食事にかかわらず、休暇関連のすべての経費に#vacation2025のタグを付けます。そうすれば、その休暇の総費用を簡単にクエリできます。または、特定の経費に#deductibleのタグを付けて、後で参照するために税控除対象項目を追跡することもできます。定期的な請求書(例:#monthly)にタグを付けて、すべてのサブスクリプションと固定費を毎年見直すこともできます。メタデータは、メモや領収書を添付するために使用できます(例:receipt: "path/to/file.jpg"で保存済みの領収書画像があることを示したり、category: "Work Expense"で経費精算可能な項目を追跡したり)。タグとメタデータの柔軟性により、数十もの追加勘定を作成することなく、個人の追跡ニーズにシステムを適応させることができます。
先月の銀行明細のエクスポートを CSV→Beancount コンバーター に、.ofx、.qfx、.qif のダウンロードは OFX & QIF から Beancount への変換ツール にかけてみましょう。個人の帳簿ならたいていこれで足り、自作の importer が出力すべき仕訳の形も分かります。
個人財務の元帳サンプルコード
以下は、個人のBeancount元帳のサンプルコードで、いくつかの典型的な取引(クレジットカードで支払った日常の経費、当座預金口座から支払った定期的な請求書、退職金投資口座への拠出)を捉えています。(簡潔にするために、勘定を開設し、給与収入を記録するための初期設定は行われているものとします。ここでは支出と貯蓄の側面に焦点を当てます。)
1970-01-01 open Assets:Bank:Checking
1970-01-01 open Liabilities:CreditCard:Visa
1970-01-01 open Expenses:Food:Coffee
1970-01-01 open Expenses:Housing:Rent
1970-01-01 open Assets:Investment:401k
; 日常の支出例(クレジットカードでのコーヒー)
2025-09-10 * "スターバックス コーヒー"
Expenses:Food:Coffee 5.50 USD
Liabilities:CreditCard:Visa -5.50 USD #daily
; 定期的な毎月の請求書(当座預金口座から支払う家賃)
2025-09-01 * "9月のアパート家賃"
Expenses:Housing:Rent 1200 USD
Assets:Bank:Checking -1200 USD #recurring
; 退職金拠出(当座預金口座から401k投資口座への移動)
2025-09-15 * "401(k) 拠出"
Assets:Investment:401k 500 USD
Assets:Bank:Checking -500 USD #retirementこれらの取引を解釈してみましょう。
- 勘定の開設: 当座預金口座、Visaクレジットカード勘定、コーヒー経費勘定(食費のサブカテゴリの例として)、家賃経費勘定、401k投資口座を開設します。実際の元帳では、使用する予定のすべての勘定(普通預金、その他の経費カテゴリ、収入など)を開設します。ここではサンプルコードに必要なものだけに絞っています。
- 日常の経費 – コーヒー: _2025-09-10_に、$5.50のコーヒー購入が記録されています。経費は
Expenses:Food:Coffeeに分類され、Visaクレジットカードで支払われたため、Liabilities:CreditCard:Visaを貸方記入(増加)します。#dailyのタグは、これが日常的な裁量支出項目であることを示すために追加されています。おそらく後で、日常的な裁量支出をすべてフィルタリングしたい場合があります。この後、クレジットカード勘定は$5.50の残高を示すことに注意してください(Visaに$5.50支払う義務があることを意味します)。このコーヒーを現金で支払った場合、取引は代わりにAssets:Cashを貸方記入します(手元の現金を減らす)。デビットカードで購入した場合、Assets:Bank:Checkingを貸方記入します。仕組みは類似していますが、異なる勘定を使用します。 - 定期的な請求書 – 家賃: _2025-09-01_に、毎月の家賃$1200の支払いを記録します。これは当座預金口座から引き落とされ(
Assets:Bank:Checkingを貸方記入)、Expenses:Housing:Rentとして分類されます。これが繰り返し発生する請求書であることを示すために#recurringのタグを付けました。完全な元帳では、毎月このようなエントリがあるでしょう。(Beancountには組み込みの自動定期取引機能はありませんが、スクリプトで実現するか、毎月コピー&ペーストすることができます。タグは、後で月を逃していないことを確認したり、1年分の家賃をすばやく合計したりするのに役立ちます。)一部のユーザーは、Beancountインポーターフレームワークの定期取引機能を使用してこれらを自動生成しますが、これはここでの範囲を超える高度な使用法です。重要なのは、この取引がお金の行き先(住居費の経費)と銀行残高の減少を明確に示していることです。注意すべき落とし穴:経費を分担したりルームメイトがいる場合、家賃の一部のみを支払うことがあります。その場合、取引を自分の負担分と他の誰かが支払う分に分割し(彼らがあなたに支払う場合は、その部分をIncome:Reimbursementsとして記録する可能性があります)、処理できます。この単純なケースでは、全額を支払います。 - 退職金拠出: _2025-09-15_に、$500が当座預金口座から401(k)投資口座に移動されます。これは経費ではなく、資産をある形態(現金)から別の形態(退職金)に移すものです。この取引は
Assets:Investment:401kを借方記入し、Assets:Bank:Checkingを貸方記入します。明確にするために#retirementのタグを付けています。この後、当座預金口座残高は500減少し、元帳の401k口座残高は500米ドル相当分増加します(投資の追跡方法によっては、その後その現金でミューチュアルファンドのユニットを購入する場合があります。これは投資口座内での別の取引になります。例えば、特定の価格でファンドのX株を購入し、401k資産から現金が出ていく)。基本的な個人元帳では、401kを普通預金口座のように扱い、定期的に残高を更新したり、このような拠出を記録し、成長については価格引用を使用したりする場合があります。重要なのは、この取引は振替であり、経費ではないということです。資産を構築しています。多くの予算管理ツールは退職金拠出を「経費」としてカウントしますが(当座預金口座から出ていくため)、会計上は単に別のポケットにお金を移しているだけです。この区別は、貯蓄率と支出を理解するのに役立ちます。
クレジットカードの請求書を支払う取引がある場合、それは当座預金口座からクレジットカード負債にお金を移すように見えます(例:Liabilities:CreditCard:Visa 100 USD / Assets:Bank:Checking -100 USD)。これにより、クレジットカードの残高が減少し(おそらく全額支払った場合はゼロになり)、それに応じて銀行残高が減少しますが、経費勘定には影響しません。購入時にすでに経費を記録しているからです。クレジットカードをこのように処理することを忘れないことは、正確な個人財務追跡のために非常に重要です。支払いにもタグを付けたり(#cc-paymentなどを使用する人もいます)、説明に明細期間を含めたりして明確にすることもできます。
まとめ: Beancountでの個人財務元帳は、お金の追跡に規律と構造を与えるのに役立ちます。取引を勘定(およびオプションでタグ)で分類することで、月別支出カテゴリ、年間合計、貯蓄額など、洞察に富んだレポートを生成できます。複式簿記アプローチにより、すべてのドルが説明されます。ある口座の残高が減少した場合、それはどこか(別の口座が増加)に行っています。これにより、エラーを発見し、より単純な追跡ツールでよくある「お金の紛失」問題を防ぎます。自動化により、ほとんどの取引をインポートし、レビューと分類のみを行うことができるため、メンテナンスは十分に実行可能です。時間の経過とともに、包括的な財務日記が構築されます。これは、友人との割り勘(資本勘定や未収金/未払金勘定を使用)、ローン償却、投資パフォーマンスの追跡など、必要に応じてこれらの分野に拡張することもできます。最も基本的なレベル(サンプルコードに示されているように)でも、Beancountは日常の支出、定期的な義務、長期的な目標(退職金貯蓄など)への進捗についての明確さを提供します。そして、プレーンテキストであるため、完全に制御できます。スクリプトを作成したり、クエリを実行したり、他のツール(フレンドリーなビューのためのWebインターフェースFavaなど)と統合したりできます。要するに、この設定は個人の財務を分析して信頼できるデータに変換し、面倒な作業にならないように十分シンプルに保ちます。
フリーランス、小規模ビジネスの運営、個人資金の管理など、状況に合わせてBeancount元帳を調整することで、プレーンテキストシステムの柔軟性とともに、体系的な複式簿記アプローチによる財務追跡の恩恵を受けることができます。これらの設定例は、基盤として構築できるコアパターンを示しています。ビジネスが成長したり、財務生活がより複雑になるにつれて、必要に応じて勘定科目表を拡張したり、高度な機能(予算、差異分析、多通貨処理など)を使用したりできます。鍵となるのは、示されているようなクリーンで論理的な構造から始め、一貫して取引を記録することです。それを実現すれば、Beancountは、業種や個人のシナリオを問わず、財務を理解し管理するための強力な味方となるでしょう。楽しい会計ライフを!