メインコンテンツへスキップ

業種別Beancount勘定科目表の設定例

フリーランサー、中小企業、家計向けのBeancount勘定科目表の例を、各勘定科目の理由と元帳スニペット付きで紹介します。

フリーランサー、中小企業、個人向け財務のための設定例

このガイドでは、フリーランスのプロフェッショナル、小規模なブティックビジネス、そして個人の家計という異なるニーズに合わせて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
 
; 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ディレクティブは必須であり、任意のスタイルではありません。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勘定を使用し、そのようなメタデータやPayeeフィールドに依存してクライアントを区別できます。
  • 事業経費(ソフトウェア): _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 – 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がそこから引き出します — 完全なセットについては在庫とブッキング方法を参照してください。デフォルトのブッキング方法はSTRICTで、ロットが明確である必要があります。そのため、例では{10 USD}で明示的に名前を付けています。Beancountにロットを自動的に選ばせる(古いものから順に)には、openディレクティブで勘定をFIFOにオプトインします: open Assets:Inventory:Widgets WIDGET "FIFO"。例では明示的なSTRICT形式を使用します。メタデータまたはリンクを使用して売上と対応する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
 
; 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用の在庫勘定(単位を追跡するためにコモディティWIDGETで宣言)、および主要な収入と経費の勘定(Sales、COGS、Fees)を開設します。Assets:Inventory:Widgets WIDGETを宣言することで、この勘定がコモディティ「WIDGET」の数量を保持することを示します。これにより、Beancountがそこにコモディティ単位を期待することを認識し、それらの単位にコストを添付できます。

  • 在庫購入: _2025-03-10_に、在庫を購入します — サプライヤーからWidgetを1つ10ドルで50個、合計500ドル。取引はAssets:Inventory:Widgetsに50 WIDGET {10 USD}を借方記入します。これは、コモディティWIDGETの50単位が、それぞれ10 USDの記録されたコストで、在庫勘定に追加されることを意味します。貸方はAssets:Bank:Checking -500 USD(現金支出)です。ここでは経費勘定に直接触れていないことに注意してください。購入を在庫資産として資本化しています。これで貸借対照表には、在庫に合計500ドル相当の50個のWidgetがあります。(残高レポートを実行すると、Inventory勘定は500ドル相当の50 WIDGET単位を示します。)

  • 売上の記録(注文#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の表記では負の金額になります)。

    この取引後、正味の効果は: 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_に、販売された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ドルを二重に数えることです。Beancountは設計上それを防ぎます。避けるべきもう1つの落とし穴は、口座の照合を怠ることです:Beancountでは、残高アサーションやbalanceディレクティブを使用して、例えば台帳の当座預金残高が実際の銀行明細と一致することを確認できます。これは欠落または重複したエントリを捕捉します。

強調すべきBeancount機能: 個人財務では、取引量が多いため自動インポートが特に役立ちます。Beancountのインポーターフレームワークやコミュニティスクリプトを使用して、銀行取引、クレジットカード明細、さらには投資取引をCSV、OFX、またはAPIソースからインポートできます。これにより、すべてのコーヒー購入を手動で入力する時間が減ります。カスタムタグは、勘定ではできない方法でデータをスライスするのに役立ちます。例えば、フライト、ホテル、食事のいずれであっても、すべての休暇関連の経費に#vacation2025をタグ付けします — その後、その休暇の総コストを簡単にクエリできます。または、後で参照するために税控除対象項目を追跡する必要がある場合、特定の経費を#deductibleとしてタグ付けします。定期的な請求書(例: #monthly)にタグ付けして、すべてのサブスクリプションと固定費を年に一度レビューすることもできます。メタデータは、メモや領収書を添付するために使用できます(例えば、receipt: "path/to/file.jpg"で保存された領収書画像があることを記録したり、払い戻し可能な項目を追跡する場合はcategory: "Work Expense")。タグとメタデータの柔軟性により、数十の余分な勘定を作成することなく、システムを個人の追跡ニーズに適応させることができます。

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

先月の銀行エクスポートをCSV to Beancountコンバーターで、または.ofx、.qfx、.qifのダウンロードをOFX & QIF to 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

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

  • 勘定の開設: 当座預金、Visaクレジットカード勘定、Coffee経費勘定(食費のサブカテゴリの例として)、Rent経費勘定、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_に、月々の家賃1,200ドルの支払いを記録します。これは当座預金から出て行き(Assets:Bank:Checkingを貸方記入)、Expenses:Housing:Rentとして分類されます。これが繰り返しの請求書であることを示すために#recurringをタグ付けしました。完全な台帳では、毎月これとまったく同じエントリがあるかもしれません。(Beancountには自動定期取引機能が組み込まれていませんが、スクリプトで実現したり、毎月単純にコピー&ペーストしたりできます。タグは、後で1か月を逃していないことを確認したり、1年分の家賃を素早く合計したりするのに役立ちます。)一部のユーザーは、Beancountインポーターフレームワークを介して定期取引機能を使用してこれらを自動生成しますが、これはここでの範囲を超えた高度な使用法です。鍵は、この取引がお金がどこに行ったか — 住居の経費 — と減少した銀行残高を明確に示すことです。注意すべき落とし穴:経費を共有したりルームメイトがいる場合、家賃の一部だけを支払うかもしれません。その場合、取引を自分の分と他の誰かが支払う分に分割できます(他の人があなたに支払う場合は、他の分をIncome:Reimbursementsとして記録する可能性があります)。私たちの単純なケースでは、全額を支払います。
  • 退職拠出: _2025-09-15_に、500ドルが当座預金から401(k)投資口座に移動されます。これは経費ではなく、ある形態(現金)から別の形態(退職資金)への資産の移動です。取引はAssets:Investment:401kを借方記入し、Assets:Bank:Checkingを貸方記入します。明確にするために#retirementをタグ付けしました。この後、当座預金残高は500減少し、台帳の401k口座残高は500 USDが表すものだけ増加します(投資の追跡方法に応じて、その後その現金で投資信託の単位を購入するかもしれません — それは投資口座での別の取引になります。例えば、ファンドのX株をY価格で購入し、現金は401k資産から出ていきます)。基本的な個人台帳では、401kを単に貯蓄口座のように扱い、定期的に残高を更新したり、このような拠出を記録したり、成長のために価格引用を使用したりするかもしれません。重要なことは、この取引が送金であり、経費ではないということです — それはあなたの資産を構築しています。多くの予算ツールは退職拠出を「経費」として数えますが(当座預金から出ていくため)、会計用語では、それは単に異なるポケットにお金を移動しているだけです。この区別は、貯蓄率と支出を理解するのに役立ちます。

サポートされている証券の単位として記録された投資の場合、Live Pricesはホストされた台帳で評価引用を維持できます。現金のみの退職残高はフィードから証券市場価値を得られません。実際の保有を記録し、その購入コストを明示的に保ってください。

クレジットカード請求書を支払う取引があった場合、それはCheckingからCreditCard負債への送金のように見えます(例: Liabilities:CreditCard:Visa 100 USD / Assets:Bank:Checking -100 USD)。これによりクレジットカード残高が再び下がり(全額支払った場合はおそらくゼロに)、銀行残高がそれに応じて減少し、経費勘定に影響を与えません — 購入時にすでに経費を記録しているためです。クレジットカードをこのように処理することを覚えておくことは、正確な個人財務追跡にとって極めて重要です。支払いにもタグを付ける(一部は#cc-paymentなどを使用)か、明確にするためにナレーションに明細期間を含めるかもしれません。

まとめ: Beancountの個人財務台帳は、お金の追跡に規律と構造を課すのに役立ちます。勘定(およびオプションでタグ)で取引を分類することで、洞察に富むレポートを作成できます:カテゴリ別の月次支出、年間合計、いくら貯蓄したか、など。複式簿記アプローチは、すべてのドルが説明されることを意味します:ある勘定の残高が下がれば、それはどこかへ行きました(別の勘定が上がる)。これはエラーを捕捉し、より単純な追跡ツールでよくある「お金が見つからない」問題を防ぎます。自動化により、ほとんどの取引をインポートし、それらをレビューして分類するだけで、メンテナンスが非常に実行可能になります。時間の経過とともに、包括的な財務日記を構築します — 友人との請求書の分割(資本勘定または未払/未収勘定を使用)、ローンの償却の追跡、投資パフォーマンスなど、それらの領域に拡張することを選択すれば、それらも処理できます。最も基本的なレベルでも(スニペットに示されているように)、Beancountは日常の支出、定期的な義務、長期的な目標(退職貯蓄など)への進捗について明確さを提供します。そしてプレーンテキストなので、完全に制御できます:スクリプト化、クエリ、または他のツール(使いやすいビューのためのWebインターフェースFavaなど)との統合が可能です。要するに、このセットアップはあなたの個人財務を分析して信頼できるデータに変えながら、面倒にならない程度にシンプルに保ちます。

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

このページを共有する

Xで共有Hacker Newsで共有Redditで共有LinkedInで共有

このページは役に立ちましたか？

業種別Beancount勘定科目表の設定例

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