メインコンテンツへスキップ
Beancount.io Logo
業界別のセットアップ

業界別のセットアップ

フリーランサー、小規模ビジネス、個人財務の固有のニーズに合わせてBeancount台帳を調整します。このガイドでは、実践的なセットアップ、サンプルスニペット、そして効果的な財務追跡への洞察を提供します。

フリーランサー、小規模ビジネス、個人財務のための設定例

このガイドでは、さまざまなニーズに合わせてBeancount台帳を調整する方法を探ります: フリーランスの専門家、ブティック小規模ビジネス、そして個人の家計財務です。それぞれのシナリオには、独自の勘定科目構造と考慮事項があります。各セットアップの背後にある理論的根拠を説明し、Beancountのスニペット例を提供し、追跡を容易にする便利な機能（カスタムタグや自動インポートなど）を強調します。トーンは教育的でありながら親しみやすいものです– 開発者、技術に精通した専門家、または財務愛好家であるかどうかに関わらず、これらの例は、現実世界でBeancountを適用するのに役立ちます。

フリーランサー​

フリーランサー（ソフトウェア開発者やグラフィックデザイナーなど）は、しばしば複数のクライアントとプロジェクト費用を同時に管理します。シンプルなBeancountセットアップは、各クライアントからの収入、事業費（下請けに支払う人件費も含む）、そして税金用に確保したお金を追跡するのに役立ちます。目標は、不要な複雑さを避けつつ、フリーランス事業が成長するにつれて拡張できるように、シンプルさを保つことです。

フリーランサーの主要な勘定科目: フリーランスの台帳は、通常、事業財務と個人財務を分離します。例えば、次のようなものを使用するかもしれません:

  • 資産:事業:当座預金 – すべてのクライアント支払いと事業費のための事業用銀行口座です。
  • 資産:事業:税金積立 – 収入の一部を税金支払い用に確保するための普通預金口座です（雇用主があなたのために税金を源泉徴収していないため)。
  • 収益:クライアント:名前 – クライアントからの支払いのための収益勘定です。主要なクライアントごとにサブ勘定を作成するか（例えバ収益:クライアント:ACME)、単一の収益:フリーランス勘定を使用し、取引内でクライアント名をタグ付けすることができます。
  • 費用:事業:下請け – 下請け業者や外部委託作業への支払い用です。
  • 費用:事業:ソフトウェア（および旅費、消耗品などの他のカテゴリ）– 定期的な事業費（ソフトウェア購読、機器、クライアント先への出張など)用です。
  • 資本:オーナー引き出し – （任意)利益を事業から自分個人に移す取引を記録するためです。これにより、自分自身に支払うときに、事業資金と個人資金を区別するのに役立ちます。

理論的根拠: この構造により、事業関連のすべてのお金が専用の勘定で追跡されることが保証されます。各クライアントからの収入が記録され（上位クライアントを簡単に確認でき)、費用は税務申告時の控除のために分類されます。税金を別の資産勘定に確保すること（または未払税金の負債を記録すること)で、政府に支払うべきお金を誤って使ってしまうことを防ぎます。台帳はシンプルなままです: 新しいクライアントや費用カテゴリが発生した場合、すべてを再編成せずに新しい勘定やタグを追加できます。よくある落とし穴は、個人取引と事業取引を1つの勘定に混在させることです; 専用の事業用当座預金（および対応する資産勘定)を維持することで、照合とレポートがより明確になります。避けるべきもう1つの落とし穴は、税金やオーナー引き出しのための現金移動を記録し忘れることです– 税金積立やオーナー引き出しなどの勘定を使用することで、すべてのドルが説明されます。

Beancountの機能ハイライト: タグとメタデータは、フリーランサーにとって非常に便利です。例えば、プロジェクトや請求書番号で取引をタグ付けしたり、クライアントごとに別々の収益勘定を使用しない場合は、クライアント名をメタデータフィールドで記録したりできます。これにより、特定のクライアントやプロジェクトの取引を簡単にフィルタリングまたはクエリできます（例:#プロジェクトXでタグ付けされたすべての費用を合計するなど)．さらに、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
 
; Client income – payment for an invoice
2025-08-15 * "Invoice payment from ACME Corp"
  invoice: "INV-2025-08-15"
  Assets:Business:Checking       5000 USD
  Income:Client:ACME           -5000 USD
 
; Regular expense – e.g. software subscription for the business
2025-08-05 * "GitHub Subscription"
  Expenses:Business:Software       15 USD
  Assets:Business:Checking        -15 USD
 
; Contractor expense – paying a subcontractor for help
2025-08-20 * "Contractor payment – Jane Doe"
  Expenses:Business:Contractors   2000 USD
  Assets:Business:Checking      -2000 USD
 
; Tax withholding – moving money to tax savings
2025-08-31 * "Set aside Q3 taxes" #tax
  Assets:Business:TaxSavings     1500 USD
  Assets:Business:Checking     -1500 USD

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

  • 必要な勘定の開設: 上部で必要な勘定を（開始日付で)開設します。Beancountでは、各勘定が使用される前に開設されている必要があります– 未宣言の勘定への転記はエラーとなります– したがって、これらのopenディレクティブは必須であり、任意のスタイルではありません。資産:事業:当座預金と資産:事業:税金積立の勘定はUSD残高を保持します; 収益と費用の勘定は、取引通貨（この場合はUSD)を継承するため、openディレクティブで通貨を指定せずに残すことができます。
  • クライアントからの請求書支払い: _2025-08-15_に、請求書に対するクライアントからの支払い$5,000を記録する収益取引があります。収益:クライアント:ACMEを貸方記入し（複式簿記では収益は負の金額で増加します)、当座預金勘定を借方記入します。invoice: "INV-2025-08-15"というメタデータフィールドが含まれ、請求書番号を記録します – これは任意ですが、取引に追加情報を添付できることを示しています。また、この取引に#ACMEまたは#client-ACMEのタグを付けて、迅速なフィルタリングを容易にすることもできます。複数のクライアントがいる場合は、一般的な収益:クライアント勘定を使用し、このようなメタデータや支払人フィールドでクライアントを区別する方が、多数のサブ勘定を作成するよりも良いかもしれません。
  • 事業費（ソフトウェア): _2025-08-05_に、GitHub購読の$15の費用を記録します（おそらくプライベートリポジトリやその他のサービス用)．転記は費用:事業:ソフトウェアへ送られ、事業用当座預金を減少させます。このような少額の定期的な費用はタグ付けできます（例えば、以下の税金取引に#taxを追加しました; 同様に、毎月発生する費用には#recurringのようなタグを付けてもよいでしょう)。この場合、勘定名自体（ソフトウェア)が明確です。
  • 下請けへの支払い: _2025-08-20_に、フリーランサーは下請け業者（Jane Doe)に$2,000を支払いました。これは費用:事業:下請けの費用として記録され、当座預金から現金が出て行きます。下請け業者の名前を説明文（私たちが行ったように)に含めるか、メタデータフィールド（例:contractor: "Jane Doe")として含めることができます。これにより、誰にいつ何のために支払ったかの監査証跡が維持されます（税務申告や予算編成時に詳細が必要な場合に役立ちます)。
  • 税金積立への移動: _2025-08-31_に、フリーランサーはメインの当座預金から専用の税金積立口座へ$1,500を移動します。この取引には可視性のために#taxタグを付けています。これは費用ではありません（自分のお金を動かしているだけです)、したがって、2つの資産勘定間の移動となります。これを毎月または四半期ごとに行うことで、推定税金をカバーするための資金を蓄積します。実際に政府に税金を支払う時が来たら、費用（例:費用:税金)と税金積立（または当座預金)勘定からの控除を記録します。よくある落とし穴は、この移動をレポートで費用として扱うことです– 覚えておいてください、これは費用ではなく、予防的な割り当てです。実際の税務当局への税金支払いのみが費用（または、そのように追跡する場合は未払税金負債の減少)となります。

まとめ: フリーランサーのBeancount台帳は、シンプルさと明確さを重視します。事業に関連するすべての収入と支出が体系的に記録されます。意味のある勘定名と時折のタグ/メタデータを使用することで、クライアントごとや費用カテゴリごとのレポートを簡単に生成できます（例:クライアントごとの総収入、今年の下請けへの総支出など)．このセットアップは拡張可能です– 事業が進化するにつれて、新しいクライアントや費用カテゴリを追加できます。自動インポート（銀行取引を取り込むため)やプロジェクトや請求書用のカスタムタグ付けなどの機能により、Beancountはフリーランサーの簿記のオーバーヘッドを大幅に削減し、いつでも財務の明確な全体像を提供できます。

小規模ビジネス​

次に、小さなブティックeコマースビジネスを考えてみましょう– 例えば、手作り品を販売するオンラインストアです。このシナリオでは、棚卸資産管理、売上原価（COGS)、そしてオンライン決済プロセッサの処理などの複雑さが追加されます。Beancountは、思慮深い勘定科目構造と取引記録方法でこれらに対応できます。事業が在庫の製品を追跡し、オンラインプラットフォーム（決済にStripeを使用するShopifyなど)を通じて販売を記録し、一般的な事業費を記録するケースを使用します。

ブティックeコマースビジネスの主要な勘定科目: 基本的な銀行および費用勘定に加えて、小売事業の台帳には、在庫と売上の流れを追跡するための勘定が含まれます:

  • 資産:銀行:当座預金 – 事業の当座預金口座です（仕入先への支払い、運営費、そして決済プロセッサからの送金の受け取り用)。
  • 資産:Stripe:残高（または資産:PayPalなど)– オンライン支払いで回収されたがまだ銀行に届いていない資金のためのクリアリング勘定です。例えば、顧客がStripeで支払うと、お金がStripeアカウントに留まり、バッチで銀行に預け入れられる前にそのままになることがあります。
  • 資産:在庫:製品 – 製品のための在庫勘定です。各製品（または製品カテゴリ)をBeancountの商品として扱い、手元の数量を追跡できます。例えば、資産:在庫:ウィジェットは現在在庫にある「ウィジェット」アイテムの数量を、その原価で保持します。
  • 収益:売上 – 製品販売からの収益を記録します。複数の販売チャネルがある場合は、異なるチャネル用のサブ勘定を使用するかもしれません（例:収益:売上:オンライン vs 収益:売上:店頭)が、ここでは1つの売上収益勘定でシンプルに保ちます。
  • 費用:売上原価 – 売上原価（COGS)で、販売された在庫アイテムの原価基準を捕捉します。この勘定は、一定期間に販売された在庫が（事業主としてのあなたに)どれだけの費用がかかったかを効果的に示します。粗利益の計算のための主要な構成要素です。
  • 費用:手数料 – 決済処理手数料やプラットフォーム手数料用です（Stripe手数料、Shopify手数料、PayPal手数料などすべてここに記録できます)．必要に応じて、これをより詳細な勘定に分けることもできます（例:費用:手数料:Stripeと費用:手数料:Shopify)が、1つの勘定で取引手数料をすべて賄えるかもしれません。
  • 費用:運営 – COGSに直接関連しない一般的な事業費、例えバマーケティング、ウェブホスティング、ソフトウェア、発送消耗品などです。これらはサブ勘定に分けて（例:費用:マーケティング、費用:ウェブホスティング、費用:発送)異なるコストセンターを分析できます。
  • 負債:売上税 – （任意、該当する場合)事業が売上税やVATを販売時に徴収する必要がある場合、この負債勘定は徴収されたがまだ政府に納付されていない税金を追跡します。各売上は、税部分をこの勘定に分割して記録されます。これにより、徴収された税金が収益としてカウントされず、税務当局への支払い用に確保されることが保証されます。
  • 資本:オーナー資本 – （任意)オーナーの投資と留保利益を表します。事業が開始されたとき、オーナーによる初期資金提供はここに貸方記入されます（現金や在庫を提供した場合は、銀行や在庫への借方記入とともに)．また、オーナーが利益を取り出す場合（分配)、それもこの資本勘定に対して記録できます。これにより貸借対照表のバランスが保たれますが、日々の運営では、あまり頻繁には関与しません。

理論的根拠: このセットアップは、商品とお金の流れを分離します。在庫購入は、直ちに費用としてではなく、当初は貸借対照表（資産として)に記録されます。製品を販売したときのみ、その原価を費用化します（COGS、収益を関連費用と一致させ、適切な利益計算を行います)。売上からの収益は総売上価格で記録され、手数料は別途記録されるため、総収益と支払った手数料（式に純収益)の両方を確認できます。資産:Stripe:残高のようなクリアリング勘定を使用することで、預け入れの照合が容易になります– お金はStripeから銀行へ塊で移動し、その送金を混乱なく記録できます。新しいショップオーナーのよくある落とし穴は、在庫を適切に記録しないことです– 例えば、すべての在庫購入を即座に費用化してしまうことです。現金流量追跡にはそれで問題ないかもしれませんが、利益が歪みます: 在庫を仕入れる月は利益が少なく見え、販売する月は利益が多く見えます、たとえ在庫が以前に購入されたものであってもです。在庫資産勘定とCOGSを使用することで、コストを売上と一致させます。もう1つの落とし穴は、手数料や返金を会計処理しないことで、銀行やStripeの残高が記録された収益と一致しなくなる可能性があります。私たちは、手数料を明示的に記録し、Stripe資産勘定を使用してStripeが負っている、または支払った金額を追跡することで、それを回避します。

Beancountの機能ハイライト: Beancountでの在庫追跡は、商品とコストを処理する能力を活用します。各製品は商品シンボル（例:WIDGET)にでき、数量と単価の両方を記録できます。アイテムを販売するとき、どのコストロットを減少させるかを指定し、Beancountはそこから引き出します– 在庫とブッキング方法参照で完全なセットを確認してください。デフォルトのブッキング方法はSTRICTであり、ロットが曖昧でないことを要求します; だからこそ、例では{10 USD}で明示的に名前を指定しています。Beancountにロットを自動的に選択させるには（古い順)、openディレクティブで勘定をFIFOにオプトインします:open 資産:在庫:ウィジェット WIDGET "FIFO"。例では明示的なSTRICT形式を使用します。また、メタデータやリンクを使用して、売上と対応するCOGSエントリを結び付けることもできます（例えば、両方の取引で同じ注文番号を使用する、または売上と在庫減少に#注文1001のような共有タグを使用し、各売上に対応するCOGSエントリがあることを簡単にクエリしたりダブルチェックしたりできます)。さらに、自動インポートがここでも役立ちます: ShopifyやStripeの支払いレポートから売上データをインポートするスクリプトを使用したり、銀行明細をインポートして費用取引や支払いを捕捉したりできます。これらの反復的なデータ入力タスクを自動化することで、分析に費やす時間が増え、数字を入力する時間が減ります。

小規模ビジネス向け台帳スニペット例​

以下は、ブティックeコマースビジネスのための凝縮されたBeancount例です。在庫の購入、売上の記録（決済プロセッサ手数料を差し引いたもの)、そしてその売上の売上原価の記録を示しています。実際には、他の費用（プラットフォーム手数料、広告費など)も示された手数料例と同様に記録します。USDを通貨とし、在庫で商品として追跡する「ウィジェット」という製品を想定します。

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
 
; Purchase inventory (50 units of Widget at $10 cost each)
2025-03-10 * "Bought 50 Widgets from SupplierCo"
  Assets:Inventory:Widgets      50 WIDGET {10 USD}
  Assets:Bank:Checking        -500 USD
 
; Sale to customer (Order #1001 via online store, 2 Widgets sold)
2025-04-05 * "Sale Order #1001 (2x Widget via Shopify)"
  Assets:Stripe:Balance         58 USD   ; net payment received after fees
  Expenses:Fees                  2 USD   ; processing fee (Stripe)
  Income:Sales                 -60 USD   ; revenue for 2 Widgets (@ $30 each)
 
; Cost of goods sold for the above sale (2 Widgets at $10 cost each)
2025-04-05 * "COGS for Order #1001 (2x Widget)"
  Expenses:COGS                 20 USD
  Assets:Inventory:Widgets     -2 WIDGET {10 USD}

ステップバイステップで何が起こっているか:

  • 勘定の開設: 当座預金勘定、Stripe残高勘定、ウィジェット用の在庫勘定（商品WIDGETで宣言し、単位を追跡)、そして中核的な収益と費用の勘定（売上、COGS、手数料)を開設します。資産:在庫:ウィジェット WIDGETと宣言することで、この勘定が商品「WIDGET」の数量を保持することを示します。これにより、Beancountがそこに商品単位を期待することを認識し、それらの単位にコストを添付できるようになります。

  • 在庫購入: _2025-03-10_に、仕入先からウィジェットを50単位、各$10で購入し、合計$500のコストがかかります。取引は資産:在庫:ウィジェットに50 WIDGET {10 USD}で借方記入します。これは、商品WIDGETの50単位が、それぞれ記録されたコスト10 USDで、在庫勘定に追加されることを意味します。貸方記入は資産:銀行:当座預金 -500 USD（現金支出)です。ここでは費用勘定に直接触れていないことに注意してください; 購入を在庫資産として資本化しています。現在、貸借対照表には在庫に50ウィジェットが$500相当で表示されています。（残高レポートを実行すると、在庫勘定は50 WIDGET単位と$500の価値で表示されます。)

  • 売上の記録（注文 #1001): _2025-04-05_に、オンラインストアを通じて2ウィジェットの売上を記録します。説明文には明確さのために注文番号が含まれています。この取引には3つの転記が含まれます:

    • 資産:Stripe:残高 58 USD: 売上から受け取ったお金ですが、現在Stripeにあります（手数料差引後)．顧客が合計$60を支払ったとします; Stripeは$2の手数料を取り、$58が現在Stripeアカウントにあります（後で銀行に送金されます)．私たちは$58をStripeの資産として記録します。
    • 費用:手数料 2 USD: $2の手数料は事業費として記録されます。これにより、損益計算書がそのコストを反映し、Stripeの資産と手数料費用を合わせると、顧客の支払い総額と等しくなります。
    • 収益:売上 -60 USD: 売上から$60の収益を記録します。(収益勘定は貸方で増加するため、Beancountの表記では負の金額です。)

    この取引の後、正味の効果は: 収益:売上が60増加し、追加の$58資産（Stripeからの受取勘定)と$2の手数料費用が発生します。Stripeが後で$58を銀行に預け入れた場合、資産:銀行:当座預金 58 USD / 資産:Stripe:残高 -58 USDのような単純な送金を支払い日に記録します– これにより、資産がStripe勘定から銀行へ移動し、収益や費用への影響はありません（単なる資産の移動です)．上記ではその送金を示していませんが、実際の簿記では、すべてが送金されたらStripe勘定を$0に保つための重要なステップです。

  • 売上のCOGSの記録: また_2025-04-05_に、売却された2ウィジェットのコストを記録するための別の取引があります。費用:売上原価 20 USDを借方記入し、資産:在庫:ウィジェット -2 WIDGET {10 USD}を貸方記入します。これにより、在庫から2単位が除去されます（各単位は以前記録されたように$10のコストで、合計$20です)．{10 USD}を指定して、Beancountにどのコストロットから引き出すかを伝えます– この場合、2025-03-10に追加したロットと一致します。現在、在庫勘定には48ウィジェットが残り、関連するコストは$480です。$20はCOGS費用に移動し、損益計算書に表示され、それらの商品のコスト分だけ粗利益が減少します。（これを記録しないと、収益が費用に対して過大表示されます。)明確さのために別の取引を使用していますが、売上とCOGSを1つの複数行取引に組み合わせることも可能です。読みやすさと照合のために、示されているように分割することを好む人もいます（各COGSエントリを注文に明確に関連付けることができます)．また、説明文に注文番号をエコーして、このCOGSエントリが注文#1001に対応することを簡単に確認できるようにしています。在庫が関与する場合、各売上に対応するCOGSエントリがあることを確認することは良い習慣です– 欠落すると、在庫数量がずれたり、費用が過小表示されたりします。避けるべき落とし穴は、売上のために在庫を除去し忘れることです。これにより、貸借対照表に幻の在庫が残り、費用が過小表示されます。Beancountの在庫機能（{}コスト表記)を使用すると、手元にある以上に多くの単位を除去しようとすると（その場合ソフトウェアがエラーを出します)、それを捕捉するのに役立ちます。

まとめ: Beancountを使用する小規模ビジネスは、驚くほど堅牢な会計システムを維持できます。お金がどこにあるか、どこから来るか、そしてコストがどのように流れるかを追跡するように勘定を構造化することで、収益性の正確な全体像が得られます。私たちの例は、在庫と売上の処理方法を示しました; 他の取引も同様に記録します（例:インターネット請求書の支払い(費用:運営:インターネット vs 資産:銀行:当座預金)、融資や投資の受け取り(資産:銀行 vs 負債:融資または資本:オーナー資本)、または売上税の支払い(負債:売上税 vs 資産:銀行納付時)．鍵は一貫性です: 各タイプの取引を同じパターンで記録し、Beancountに帳簿のバランスを保たせます。自動データインポート（例えば、毎月のStripe手数料や銀行取引を取り込む)やカスタムタグ/リンク（売上と返金のような関連取引を相関させるため)などの機能により、システムは柔軟かつ効率的であり得ます。結果として、ビジネスが成長するにつれて拡張できる組織化された台帳が得られます– 新しい製品在庫勘定、新しい費用カテゴリ、または追加の収入源（例えば、新しいオンラインマーケットプレイス)を、システム全体を作り直すことなく追加できます。

個人財務​

最後に、個人または家計の財務にBeancountを使用することを考えてみましょう。このセットアップは、日々の費用、銀行口座、クレジットカード、融資、そして投資を管理する個人または家族向けです。ここでの重点は、お金がどこに使われるか（費用)、どこから来るか（収益)、そして**どのように貯蓄または投資されるか（資産と負債)**の追跡にあります。Beancountは、予算管理アプリを置き換えたり補完したりでき、透明でカスタマイズ可能な財務ビューを提供し、複式簿記の厳密さにより、二重計上や忘れが発生しないことを保証します。

個人財務の主要な勘定科目: 個人財務の台帳には、通常、さまざまな資産、負債、収益、そして費用の勘定が含まれます:

  • 資産:銀行:当座預金 – 収入の入金や請求書の支払いのためのメインの当座預金口座です。
  • 資産:銀行:普通預金 – 緊急資金や特定の目標のための普通預金口座です。（複数の普通預金や投資口座がある場合は、それぞれを資産勘定にできます。)
  • 資産:現金 – 費用に現金を使用する場合、引出しや現金支出を追跡するための現金勘定を持つことができます。
  • 資産:投資:ブローカー – 証券口座、退職401(k)/IRAなどの投資口座です。これらは、投資タイプごとにさらに分解するか、単に機関ごとに1つの勘定としてまとめることができます。例えば、資産:投資:バンガードIRAまたは資産:投資:ロビンフッドなどです。投資の追跡には、株式やファンド用の商品が関与する場合もありますが、これが詳細すぎる場合は、拠出額と口座残高を追跡するだけでよいかもしれません。
  • 負債:クレジットカード:名前 – クレジットカードごとに1つの勘定です（例:負債:クレジットカード:ビザまたは銀行名で)．カードでのすべての購入はここに記録され（同額の費用とともに)、カードへの支払いはこの負債を減らす送金です。
  • 負債:融資:名前 – 任意の融資（学生融資、住宅ローン,車ローン)は負債勘定で追跡できます。元金残高と各支払いを利息（費用)と元金（負債減少)に分割して記録します。これは高度な側面ですが、完全な財務全体像に重要です。
  • 収益:給与（および/または収益:賞与、収益:利息など)– 給与明細、賞与,利息収入,配当などを記録するためです。収益勘定により、さまざまな源からの総収入を確認できます。（給与明細で税金がすでに源泉徴収されている場合、当座預金への正味入金を収益として記録するか、総額と税金源泉徴収を費用または負債として記録するか – 異なるアプローチがありますが、個人の帳簿では、多くの人は簡素化のため正味支払額を収益として記録します。)
  • 費用: 通常、多数であり、あなたにとって意味のあるカテゴリに分けられます。例:費用:住居:家賃、費用:食費:食料品、費用:食費:外食、費用:公共料金:電気、費用:娯楽、費用:旅費、費用:税金、費用:その他 – あなたの支出習慣を反映する任意のカテゴリです。必要に応じて、細かくも大まかにもできます。勘定階層は集計に役立ちます（例:費用:食費は食料品と外食の両方を合計します)．一般的な慣行は、主要グループ（住居、食費、交通,医療など)の階層を持つことです。
  • 資本:開始残高 – 台帳を開始するときに勘定残高を初期化するために使用されます（すべての資産から負債を差し引いたものが、資本に記録された開始純資産と等しくなるように)．開始後は、資本:留保利益などを使用して累積純利益を表すこともできます（ただし、個人財務では、通常、単に収益から費用を差し引いたものを純資産にロールさせます)．資本勘定は、日々の運用ではあまり目に見えませんが、会計等式のバランスを保証します。

理論的根拠: 個人財務のセットアップは、財務生活を1つの一貫したシステムで捕捉することです。上記の各勘定は、異なる種類の財務を分離するのに役立ち、「今月の食費にいくら使ったか」という質問に答えられます（費用:食費:*を合計する、)「どれだけの借金が残っているか?」（負債勘定を確認する)または「純資産はいくらか?」（資産から負債を差し引く)．複式簿記の大きな利点は、ここでの正確さです: 例えば、クレジットカードに$100の食料品請求を請求すると、費用としてかつ負債の増加として記録します。後で、クレジットカードを支払うとき、銀行からカードへの送金を記録します– これは負債を減らしますが、食費費用を二重にカウントしません（すでに記録済みです)．複式簿記がない場合のよくある落とし穴は、クレジットカード支払いをそれ自体を費用として扱い、$100を実質的に二重にカウントすることです。Beancountは設計上それを防ぎます。避けるべきもう1つの落とし穴は、勘定の照合を怠ることです: Beancountでは、残高アサーションやbalanceディレクティブを使用して、例えば、台帳の当座預金残高が実際の銀行明細と一致することを保証できます。これにより、記入の欠落や重複を捕捉します。

Beancountの機能ハイライト: 個人財務では、自動インポートは取引量のために特に役立ちます。Beancountのインポーターフレームワークやコミュニティスクリプトを使用して、銀行取引、クレジットカード明細、さらには投資取引をCSV、OFX、APIソースからインポートできます。これにより、すべてのコーヒー購入を手動で打ち込む時間を削減できます。カスタムタグは、勘定が捕捉しない方法でデータをスライスするのに役立ちます。例えば、すべての休暇関連費用に#休暇2025とタグ付けします– 飛行機、ホテル,食事にかかわらず– その休暇の総コストを簡単にクエリできます。または、特定の費用に#控除可能とタグ付けして、後で参照するために税控除可能項目を追跡できます。定期的な請求書にタグ付け（例:#毎月)して、すべての購読と固定費を年次でレビューすることもできます。メタデータは、メモや領収書を添付するために使用できます（例:領収書: "path/to/file.jpg"で保存された領収書画像を記録、またはカテゴリ: "仕事費"で払い戻し可能項目を追跡)．タグとメタデータの柔軟性により、数十の余分な勘定を作成せずに、システムを個人の追跡ニーズに適応できます。

インポーターを書く前にコンバーターを試す

先月の銀行エクスポートをCSVからBeancountへのコンバーターに通すか、.ofx、.qfx、.qifダウンロードをOFX & QIFからBeancountへに通します。ほとんどの個人台帳ではそれで十分であり、カスタムインポーターが生成すべきエントリの形状がわかります。

個人財務向け台帳スニペット例​

以下は、個人の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
 
; Daily spending example (coffee on a credit card)
2025-09-10 * "Starbucks Coffee" #daily
  Expenses:Food:Coffee       5.50 USD
  Liabilities:CreditCard:Visa   -5.50 USD
 
; Recurring monthly bill (rent paid from checking)
2025-09-01 * "Apartment Rent September" #recurring
  Expenses:Housing:Rent    1200 USD
  Assets:Bank:Checking    -1200 USD
 
; Retirement contribution (transfer from checking to 401k investment)
2025-09-15 * "401(k) Contribution" #retirement
  Assets:Investment:401k    500 USD
  Assets:Bank:Checking     -500 USD

これらの取引を解釈しましょう:

  • 勘定の開設: 当座預金勘定、ビザクレジットカード勘定、コーヒー費用勘定（食費カテゴリのサブカテゴリの例として)、家賃費用勘定、そして401k投資勘定を開設します。実際の台帳では、使用予定のすべての勘定（普通預金、他の費用カテゴリ,収益など)を開設します。スニペットに必要なものだけに留めます。
  • 日々の費用 – コーヒー: _2025-09-10_に、$5.50のコーヒー購入が記録されます。費用は費用:食費:コーヒーに分類され、ビザクレジットカードで支払われたため、負債:クレジットカード:ビザを貸方記記入（増加)します。#日常タグが追加され、これが日々の裁量支出項目であることを示します– 後で、すべての日常裁量費をフィルタリングしたいかもしれません。この後、クレジットカード勘定は$5.50の残高を示します（ビザに$5.50借りがあることを意味します)．現金でこのコーヒーを支払った場合、取引は代わりに資産:現金を貸方記記入します（手元の現金を減少させます)．デビットカード購入であれば、資産:銀行:当座預金を貸方記記入します。仕組みは似ていますが、異なる勘定です。
  • 定期的な請求書 – 家賃: _2025-09-01_に、毎月の家賃$1200の支払いを記録します。これは当座預金から出て行き（資産:銀行:当座預金を貸方記記入)、費用:住居:家賃に分類されます。#定期的とタグ付けし、これが繰り返し発生する請求書であることを示します。完全な台帳では、毎月このようなエントリがあるかもしれません。（Beancountには自動繰り返し取引機能が組み込まれていませんが、スクリプトで実現するか、毎月コピーペーストするだけです。タグは、後で月を逃していないことを確認したり、1年分の家賃をすばやく合計したりするのに役立ちます。)一部のユーザーは、Beancountインポーターフレームワークを介した定期取引機能を使用してこれらを自動生成しますが、それはここでの範囲を超えた高度な使用法です。重要なのは、この取引がお金の行き先– 住居の費用– と銀行残高の減少を明確に示していることです。注意すべき落とし穴: 費用を分け合ったり、ルームメイトがいる場合、家賃の一部しか支払わないかもしれません; その場合、取引を自分の分と他人が支払う分に分割できます（他人があなたに支払う場合は、収益:払い戻しとしてその分を記録するかもしれません)．私たちの単純なケースでは、全額を支払います。
  • 退職拠出: _2025-09-15_に、$500が当座預金から401(k)投資口座に移動されます。これは費用ではなく、資産をある形態（現金)から別の形態（退職基金)に移すことです。取引は資産:投資:401kを借方記記入し、資産:銀行:当座預金を貸方記記入します。#退職とタグ付けし、明確さを図ります。この後、当座預金残高は500減り、台帳の401k口座残高はその500 USDが表す分だけ増加します（投資の追跡方法によっては、その後、その現金で投資信託単位を購入するかもしれません– それは投資勘定内での別の取引になります、例:ファンドのY価格でX株を購入し、現金が401k資産から出て行く)．基本的な個人台帳では、401kを普通預金のように扱い、定期的に残高を更新するか、このような拠出を記録し、成長のために価格クォートを使用するかもしれません。重要なのは、この取引が送金であり、費用ではないことです– 資産を築いています。多くの予算管理ツールは退職拠出を「費用」としてカウントします（当座預金から出て行くため)が、会計用語では、それは単に異なるポケットにお金を移しているだけです。この区別は、貯蓄率と支出を理解するのに役立ちます。

クレジットカード請求書の支払い取引がある場合、それは当座預金からクレジットカード負債への送金のように見えます（例:負債:クレジットカード:ビザ 100 USD / 資産:銀行:当座預金 -100 USD)．これにより、クレジットカード残高が減り（おそらく全額支払えばゼロに)、銀行残高もそれに応じて減少し、費用勘定への影響はありません– 購入時にすでに費用を記録済みだからです。クレジットカードをこのように処理することを覚えておくことは、正確な個人財務追跡に重要です。支払いにもタグを付けるかもしれません（#cc-paymentや類似のもの)または説明文に明細期間を含めることができます。

まとめ: Beancountでの個人財務台帳は、お金の追跡に規律と構造を課すのに役立ちます。勘定（および必要に応じてタグ)で取引を分類することで、有益なレポートを生成できます: カテゴリ別の月次支出,年次合計,どれだけ貯蓄したか,などです。複式簿記のアプローチは、すべてのドルが説明されることを意味します: ある勘定の残高が減ったら、それはどこかに行きました（別の勘定が増えます)．これはエラーを捕捉し、より単純な追跡ツールでよくある「行方不明のお金」問題を防ぎます。自動化により、ほとんどの取引をインポートし、レビューして分類するだけで、メンテナンスがかなり実現可能になります。時間が経つにつれ、包括的な財務日記が構築されます– 友達との費用の分割（資本勘定や未収/未払勘定を使用)、融資の償却の追跡、や投資パフォーマンスなど、必要に応じてこれらの分野に拡張することもできます。最も基本的なレベル（スニペットに示されているように)でも、Beancountは日々の支出、定期的な義務、そして長期的な目標（退職貯蓄など)への進捗についての明確さを提供します。そして平文テキストであるため、完全な制御があります: スクリプト化、クエリ、他のツールとの統合（Favaウェブインターフェースでの親しみやすいビューなど)が可能です。要するに、このセットアップは個人財務を、分析して信頼できるデータに変え、同時に雑用にならないように十分にシンプルに保ちます。

あなたの状況に合わせてBeancount台帳を調整することで– フリーランス、小規模ビジネスの運営、または個人資金の管理– 平文テキストシステムの柔軟性とともに、体系的な複式簿記アプローチの利点が得られます。これらの設定例は、構築できる中核的なパターンを示しています。ビジネスが成長したり、財務生活がより複雑になったりするにつれて、必要に応じて勘定科目表を拡張したり、高度な機能（予算、差異分析、複数通貨処理など)を使用したりできます。鍵は、クリーンで論理的な構造（示されたものなど)から始め、取引を一貫して記録することです。それが整えば、Beancountは、業界や個人のシナリオを問わず、財務を理解し管理するための強力な味方になります。ハッピーアカウンティング!

業界別のセットアップ

出典: https://beancount.io/ja/docs/industry-specific-setups