業界固有の設定

フリーランサー、中小企業、個人金融向けの構成例

このガイドでは、フリーランスのプロフェッショナル、小規模なブティックビジネス、個人の家計など、さまざまなニーズに合わせて 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

何が起こっているのかを分解してみましょう。

• 上部で必要なアカウントを open します（開始日付き）。 これは 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）アカウントからの控除を記録します。 よくある落とし穴は、この移転をレポートの費用として扱うことです。これは費用ではなく、単なる予防的な割り当てであることを忘れないでください。 IRS / 税務当局への実際の税金の支払いのみが費用になります（または、税金の負債をそのように追跡する場合は、税金の負債の削減になります）。

概要: フリーランサーの 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:Online 対 Income:Sales:InStore）にサブアカウントを使用できますが、1つの販売収入アカウントでシンプルに保ちます。
• Expenses:COGS – 販売された商品の原価。在庫アイテムの原価を把握します。 このアカウントは、期間中に販売された在庫の原価を効果的に表示します（ビジネスオーナーとして）。 これは、売上総利益を計算するための重要な要素です。
• Expenses:Fees – 決済処理手数料およびプラットフォーム手数料（Stripe の請求、Shopify の手数料、PayPal の手数料など、すべてここで記録できます）。 必要に応じて、これをより詳細なアカウント（たとえば、Expenses:Fees:Stripe および Expenses:Fees:Shopify）に分割できますが、1つのアカウントでトランザクション手数料すべてを賄うことができます。
• Expenses:Operating – マーケティング、Web ホスティング、ソフトウェア、配送用品など、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 * "サプライヤーCo から 50 個のウィジェットを購入"
  Assets:Inventory:Widgets      50 WIDGET {10 USD}
  Assets:Bank:Checking        -500 USD

; 顧客への販売（オンラインストア経由の注文番号1001、2 個のウィジェットが販売されました）
2025-04-05 * "販売注文番号1001（Shopify 経由の 2x Widget）"
  Assets:Stripe:Balance         58 USD   ; 手数料を差し引いた後の純支払い額
  Expenses:Fees                  2 USD   ; 処理手数料（Stripe）
  Income:Sales                 -60 USD   ; 2 個のウィジェットの収益（それぞれ 30 ドル）

; 上記の販売の売上原価（2 個のウィジェットをそれぞれ 10 ドルのコストで）
2025-04-05 * "注文番号1001 の COGS (2x Widget)"
  Expenses:COGS                 20 USD
  Assets:Inventory:Widgets     -2 WIDGET {10 USD}

ステップごとに何が起こっているかを以下に示します。

• アカウントの開設: 当座預金口座、Stripe 残高口座、ウィジェットの在庫口座（ユニットを追跡するために商品 WIDGET で宣言）、およびコア収入および費用アカウント（販売、COGS、手数料）を開設します。 Assets:Inventory:Widgets WIDGET を宣言することにより、このアカウントが商品「WIDGET」の数量を保持することを示します。 これにより、Beancount はそこに商品ユニットを期待することを認識し、コストをそれらのユニットに添付できます。

• 在庫購入: 2025-03-10 に、サプライヤーから 50 個の Widget をそれぞれ 10 ドルで購入し、合計 500 ドルかかります。 トランザクションは、Assets:Inventory:Widgets に 50 WIDGET {10 USD} で借方記入します。 これは、商品 WIDGET の 50 ユニットがそれぞれ 10 USD の記録されたコストで在庫アカウントに追加されることを意味します。 貸方は Assets:Bank:Checking -500 USD (現金の支出) です。 ここでは費用勘定に直接触れていないことに注意してください。購入を在庫資産として資本化しています。 現在、貸借対照表には 50 個の Widget が在庫に合計 500 ドル相当あります。 (残高レポートを実行すると、在庫アカウントには 50 WIDGET ユニットが 500 ドル相当で表示されます。)

• 販売の記録（注文番号1001）： 2025-04-05 に、オンラインストアを通じて 2 個の Widget の販売を記録します。 ナレーションには、わかりやすくするために注文番号が含まれています。 このトランザクションには、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 の表記では金額が負になります)。

  このトランザクションの後、正味効果は次のようになります。収入:販売が 60 ドル増加し、58 ドルの追加資産 (Stripe からの受取額) と、手数料の 2 ドルの費用です。 Stripe が後で 58 ドルを銀行に入金する場合、Assets:Bank:Checking 58 USD / Assets:Stripe:Balance -58 USD のような単純な送金を支払日に記録します。これにより、資産が Stripe アカウントから銀行に移動し、収入または費用に影響を与えません (単に資産をシフトするだけです)。 上記の送金は示されていませんが、Stripe アカウントをすべて送金したら 0 ドルに保つためには、実際の簿記では重要なステップです。

• 販売の COGS の記録: また、2025-04-05 に、販売された 2 個の Widget のコストを記録するための別のトランザクションがあります。 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 対 Assets:Bank:Checking)、ローンの受け取りまたは投資 (Assets:Bank 対 Liabilities:Loan または Equity:OwnerEquity)、または売上税の支払い (Liabilities:SalesTax 対 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" を指定したりします)。 タグとメタデータの柔軟性により、追加のアカウントを多数作成せずに、システムの個人的な追跡ニーズに適応させることができます。

個人金融レジャースニペットの例

以下は、典型的なトランザクションをいくつかキャプチャした個人の 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) 拠出"