「複式簿記」タグの記事が9件件あります

仕訳は複式簿記の根幹であり、Beancount では記述するすべての * 取引が仕訳となります。本ガイドでは、借方と貸方、調整仕訳、逆仕訳の要点を解説し、Beancount のプレーンテキスト構文へどのようにシンプルにマッピングできるかを示します。最小限の手間で正確な帳簿を保つ方法を学びます。

簡単なおさらい：仕訳とは？​

仕訳は金融取引の正式な日付付き記録です。借方 と 貸方 の形で表され、会計等式をバランスさせます。

$Assets = Liabilities + Equity$

複式簿記では、すべての取引が少なくとも二つの勘定に影響し、借方合計は貸方合計と等しくなります。このシンプルなルールが、損益計算書や貸借対照表といった下流の財務報告書を信頼できるものにします。

1 分でわかる借方と貸方​

借方と貸方は最初は混乱しがちですが、実はシンプルなルールに集約できます。「価値はどこから来たか？」（貸方）と「価値はどこへ行ったか？」（借方）です。

以下は主要な五つの勘定タイプが増加する際の対応表です。

Beancount での仕訳の書き方​

Beancount はシンプルで人間が読めるテキスト指示子を使って取引を記録します。各取引はすべての通貨（例：USD、EUR、AAPL 株式）について合計がゼロになる必要があります。合計が合わない場合、Beancount はエラーを出します。

以下はコーヒー購入の基本的な取引例です。

2025-09-10 * "Coffee Bar" "Team coffee"
  Expenses:Food:Coffee          18.00 USD
  Assets:Bank:Checking         -18.00 USD

二つのポスティング（勘定行）が合計でゼロになることに注目してください：$18.00 + (-$18.00) = 0。

タグ（例：#clientX）や リンク（例：^INV-2025-001）をナレーションに直接入れることで、検索性やエントリ間の接続が容易になります。

例として、請求書と支払いをリンクさせる方法を示します。

; まず、クライアントに送った請求書を記録
2025-09-15 * "Acme Corp" "Invoice 2025-001 #clientX ^INV-2025-001"
  Assets:AccountsReceivable   1000.00 USD
  Income:Consulting         -1000.00 USD

; 後で、支払いを記録し元の請求書にリンク
2025-09-28 * "Acme Corp" "Payment on ^INV-2025-001"
  Assets:Bank:Checking       1000.00 USD
  Assets:AccountsReceivable -1000.00 USD

#clientX タグでこのクライアントのすべての取引を簡単にフィルタリングでき、^INV-2025-001 リンクがエントリ間の接続を作り、レポートでたどることができます。

よく使う仕訳（コピー＆ペースト用）​

以下はビジネスで頻繁に使われる取引例です。Beancount 用にフォーマット済みです。

オーナーが現金を出資​

オーナーが個人資金を事業に投入します。

2025-01-01 * "Owner" "Initial capital contribution"
  Assets:Bank:Checking        10000.00 USD
  Equity:Owner-Capital      -10000.00 USD

消費税付き現金販売​

顧客が現金で商品を購入し、8% の消費税を含みます（後で税務当局に納付）。

2025-01-05 * "Walk-in Customer" "Cash sale with 8% tax"
  Assets:Cash                   108.00 USD
  Income:Sales                -100.00 USD
  Liabilities:Tax:Sales         -8.00 USD

売掛金（請求書）と回収​

サービスを提供し請求書を発行、後で支払いを受領。

2025-01-10 * "Acme Corp" "Consulting invoice ^INV-2025-002"
  Assets:AccountsReceivable   2500.00 USD
  Income:Consulting         -2500.00 USD

2025-01-30 * "Acme Corp" "Payment on ^INV-2025-002"
  Assets:Bank:Checking       2500.00 USD
  Assets:AccountsReceivable -2500.00 USD

クレジットカードでの経費​

会社のクレジットカードで事務用品を購入。

2025-01-12 * "OfficeMax" "Supplies on credit card"
  Expenses:Office:Supplies       75.00 USD
  Liabilities:CreditCard        -75.00 USD

給与（シンプルモデル）​

給与を計上し、税金の源泉徴収と銀行からの実際支払を記録。

2025-01-31 * "Payroll" "January wages and withholdings"
  Expenses:Payroll:Wages      2000.00 USD
  Liabilities:Taxes:Withheld   -400.00 USD
  Assets:Bank:Checking       -1600.00 USD

月次減価償却​

ラップトップなどの資産に対する月次減価償却費を記録。

2025-01-31 * "Depreciation" "Laptop, straight-line"
  Expenses:Depreciation          100.00 USD
  Assets:Equipment:AccumDepr    -100.00 USD

前払費用と月次償却​

保険料を年払いで支払った後、毎月の費用を認識。

; 1. 年間保険料を支払う
2025-01-01 * "InsureCo" "Annual insurance premium"
  Assets:Prepaid:Insurance     1200.00 USD
  Assets:Bank:Checking       -1200.00 USD

; 2. 1 月分の費用を認識
2025-01-31 * "InsureCo" "Amortize 1/12 of insurance"
  Expenses:Insurance             100.00 USD
  Assets:Prepaid:Insurance      -100.00 USD

前受収益と月次認識​

顧客が 3 ヶ月分のサブスクリプションを前払い。現金を受け取り、毎月収益を認識。

; 1. 前受金を受領
2025-02-01 * "Subscriber" "3-month plan prepaid"
  Assets:Bank:Checking           300.00 USD
  Liabilities:Unearned:Subs     -300.00 USD

; 2. 1 月分の収益を認識
2025-02-28 * "Recognition" "Recognize month 1 of 3"
  Liabilities:Unearned:Subs      100.00 USD
  Income:Subscriptions          -100.00 USD

貸倒引当金と償却​

未回収リスクに備えて引当金を設定し、実際に回収不能となった請求書を償却。

; 1. 売掛金の 2% を引当金として計上
2025-03-31 * "Provision" "2% of A/R for doubtful accounts"
  Expenses:BadDebt               200.00 USD
  Assets:AllowanceForDoubtful   -200.00 USD

; 2. 回収不能請求書を償却
2025-04-15 * "Write-off" "Customer XYZ invoice"
  Assets:AllowanceForDoubtful    150.00 USD
  Assets:AccountsReceivable     -150.00 USD

期末在庫と売上原価調整​

期間末に在庫評価を行い、売上原価（COGS）を調整。

2025-03-31 * "COGS adjustment" "Periodic inventory method"
  Expenses:COGS                4500.00 USD
  Assets:Inventory           -4500.00 USD

調整仕訳 と 逆仕訳​

調整仕訳 は会計期間末（月次・四半期）に、収益と費用を実際に発生した期間に合わせて正しく配分するために記録します。これには未払費用、前受収益、減価償却などが含まれます。

逆仕訳 は任意で、次期の初日に前期の特定の調整仕訳を完全に打ち消すエントリです。これにより、後続の現金取引を標準的な形で記録でき、負債勘定への分割記入を忘れる心配がなくなります。

例：光熱費の未払と逆仕訳​

1 月の光熱費は 1 月に費用計上したいが、請求書は 2 月に届くケースです。

; 1. 1 月末に見積費用を計上（未払）
2025-01-31 * "Accrual" "Estimate January utilities expense"
  Expenses:Utilities              500.00 USD
  Liabilities:Accrued:Utilities  -500.00 USD

; 2. （任意）次期初日に未払を逆仕訳
2025-02-01 * "Reversal" "Undo January utilities accrual"
  Liabilities:Accrued:Utilities   500.00 USD
  Expenses:Utilities             -500.00 USD

; 3. 2 月に実際の請求書が届いたら支払を記録
; 請求額は 520 USD。逆仕訳のおかげで
; 全額を費用勘定に直接記入できる。
2025-02-10 * "City Utilities" "Payment for January bill"
  Expenses:Utilities             520.00 USD
  Assets:Bank:Checking          -520.00 USD

注：上記例は最終支払を分割して記入する方法を示していますが、逆仕訳を使うと支払記入がシンプルになります。

Beancount 仕訳チェックリスト​

1. 日付（YYYY-MM-DD）と取引フラグ（*）で開始
2. 支払先 と 説明 を記入。検索しやすいように #タグ と ^リンク を活用
3. 少なくとも二行 のポスティングを入れ、各通貨で合計がゼロになるようにする
4. 勘定は五大区分 Assets, Liabilities, Equity, Income, Expenses のいずれかに属する正しい名前を使用
5. 必要に応じて document: "invoices/INV-2025-001.pdf" などの メタデータ を付加し、トレーサビリティを確保

よくある落とし穴（Beancount が助けるポイント）​

• 合計が合わないポスティング：借方・貸方がゼロにならないと Beancount はエラーを返します。未記入の金額は自動計算されます。
• 勘定の符号ミス：Income、Equity、Liabilities は貸方（負の数）で増加します。間違えるとレポートが不自然になりますが、バランスチェックが安全弁になります。
• リンク忘れ：請求書と支払いを結びつけないと未回収が把握しにくくなります。^リンク を一貫して使うことで監査可能な経路ができます。

次に読むべき情報​

• Beancount 言語とバランシングルール – 公式ドキュメントを深掘り
• 構文チートシート – すべての指示子を一覧化
• 借方・貸方入門 – 会計ルールが初めての方へ
• 調整・逆仕訳の詳細 – 理論と実践例

付録：会計用語 ↔ Beancount 用語マッピング​

この表を参考に、Beancount のテキスト構文で正しい借方・貸方の記入を行ってください。

財務諸表は魔法のように現れるわけではありません。それらは会計サイクルとして知られる、構造化され、反復可能なプロセスの最終成果物です。その原則は普遍的ですが、使用するツールによって体験は劇的に変わります。このガイドでは、強力なプレーンテキスト会計ツールであるBeancountに焦点を当てて、会計サイクルを解説します。

Beancountのテキストファーストなアプローチが、いかに面倒なステップを排除し、何を自動化すべきか、そしてどのレポートがあなたの財務健全性を最も明確に示してくれるかを見ていきましょう。🧑‍💻

TL;DR: Beancountのワークフロー​

• 記録と仕訳: すべての取引を、クリーンな複式簿記のエントリとして.beancountテキストファイルに記録します。
• 検証と照合: balanceアサーションを使用して台帳が銀行の明細と一致することを確認し、bean-checkを実行してエラーを検出します。
• レビュー: 簡単な健全性チェックのために、修正前の試算表を生成します。
• 修正: 未収、繰延、減価償却、その他の期末項目に関する仕訳を計上します。
• 再レビュー: 修正後の試算表をチェックして、すべてが正しいことを確認します。
• 公開と締め: 損益計算書、貸借対照表、キャッシュフロー計算書を生成します。Beancountではレポートが日付を認識するため、帳簿の締めはオプションです。

このフローは次のように視覚化できます：

ステップ1：取引の捕捉と記録​

これは基礎となるステップです。販売、購入、銀行手数料といったすべての財務イベントを記録する必要があります。Beancountでは、通常main.beancountと名付けられるか、年ごとに複数のファイルに整理された単純なテキストファイルに取引を作成することでこれを行います。

各取引は複式簿記のルールに従う必要があり、すべての転記の合計がゼロでなければなりません。Beancountはこれを強制します。

2025-08-10 * "Walmart" "オフィス用品の購入"
  Expenses:Office:Supplies      45.67 USD
  Assets:Bank:Checking         -45.67 USD

• プロのヒント: #project-phoenixや#client-acmeのようなタグを使用してデータに次元を追加します。これにより、後々のクエリやレポート作成が非常に柔軟になります。

照合作業の習慣 ✅​

正確性を保証するための最も強力な機能は、balanceアサーションです。明細期間の終わり（例：月末）に、勘定の残高がどうあるべきかを宣言します。

2025-08-31 balance Assets:Bank:Checking  12345.67 USD

もしその日までのAssets:Bank:Checkingに影響を与えるすべての取引の合計が12345.67 USDと等しくない場合、Beancountはエラーを発生させます。この単純なディレクティブが、あなたの台帳を自己監査ドキュメントに変えます。

過去のデータを入力している人のために、padディレクティブは、開始残高が最初のアサーションと一致するように、自動的にバランス調整用の取引を作成できます。

ステップ2：「台帳への転記」（これはおまけです！）​

伝統的な会計システムでは、まず「仕訳帳」に記入し、次に別の「転記」ステップでそれらの値を「総勘定元帳」にコピーします。

Beancountでは、あなたの.beancountファイルが仕訳帳と台帳の両方です。 取引を書いて保存した時点で、すでに転記は完了しています。別のステップはありません。この直接性が、プレーンテキスト会計の核となる利点です—見たままが得られるものです。

ステップ3：修正前試算表の準備​

修正を始める前に、簡単な「すべてが合っているか？」のチェックが必要です。試算表は、すべての勘定とその合計残高をリストアップした単純なレポートです。すべての借方残高の合計は、すべての貸方残高の合計と等しくなければなりません。

これは単純なクエリで生成できます：

bean-query main.beancount \
  "SELECT account, sum(position) GROUP BY 1 ORDER BY 1"

または、より視覚的なアプローチとして、Fava（BeancountのWebインターフェース）で台帳を開き、「試算表」レポートに移動します。貸方残高のある資産勘定や、奇妙な値を持つ費用勘定など、異常なものがないか探します。

ステップ4：修正仕訳の計上​

修正仕訳は、発生主義会計の下で正確な報告を行うために不可欠です。これにより、現金がいつやり取りされたかに関わらず、収益は稼得時に、費用は発生時に認識されることが保証されます。

一般的な修正には以下が含まれます：

• 未収（Accruals）: まだ請求していないが稼得した収益、または発生したがまだ支払っていない費用を記録します。
• 繰延（Deferrals）: 前払金を処理します。顧客が1年分のサービス料を前払いした場合、それを負債（Liabilities:UnearnedRevenue）として計上し、毎月その1/12を収益として認識します。
• 非現金項目（Non-Cash Items）: 資産の減価償却などを記録します。
• 訂正（Corrections）: 銀行フィードからの見逃し項目（少額の利息支払いなど）の修正や会計処理を行います。

例：未収収益の計上​

8月31日にプロジェクトを完了しましたが、請求書を送るのは9月になります。正しい期間（8月）に収益を認識するために、修正仕訳を行います：

2025-08-31 * "クライアントプロジェクト#1042の収益を未収計上"
  Assets:AccountsReceivable      3000.00 USD
  Income:Consulting             -3000.00 USD

例：減価償却の記録​

あなたの会社には資産の減価償却スケジュールがあります。期間の終わりに、費用を計上します：

2025-12-31 * "コンピュータ機器の年間減価償却"
  Expenses:Depreciation                  4800.00 USD
  Assets:Fixed:AccumulatedDepreciation  -4800.00 USD

ステップ5：修正後試算表の実行と検証​

修正仕訳を計上したら、再び試算表レポートを実行します。これがあなたの修正後試算表です。これは、財務諸表を作成するために使用される最終的な数値セットを提供します。

これはまた、Beancountに組み込まれている健全性チェックを実行する絶好のタイミングでもあります：

bean-check main.beancount

このコマンドは、すべての構文、貸借一致ルール、およびアサーションを検証します。何も出力されずに実行されれば、あなたの帳簿は機械的に健全です。

ステップ6：財務諸表の公開 📊​

これが成果です。修正後試算表の数値を使用して、主要な財務レポートを生成できるようになりました。Favaは、インタラクティブでドリルダウン可能なレポートを標準で提供するため、これを行う最も簡単な方法です。

• 損益計算書（P&L）: ある期間の収益と費用を示し、純利益または純損失を明らかにします。
• 貸借対照表: 特定の日付における、所有するもの（資産）と負っているもの（負債）、そして純資産（資本）のスナップショットです。
• キャッシュフロー計算書: お金がどこから来てどこへ行ったかを示すことで、期首の現金残高と期末の現金残高を調整します。

カスタムレポートには、Beancountクエリ言語（BQL）を使用できます。以下は月次損益計算書のクエリです：

-- 2025年8月の損益計算書
SELECT account, sum(position)
WHERE account ~ '^(Income|Expenses)'
  AND date >= 2025-08-01 AND date <= 2025-08-31
GROUP BY account ORDER BY account;

ステップ7：帳簿の締め（オプション）​

伝統的な会計では、「締め」のプロセスには、すべての一時勘定（収益と費用）をゼロにし、純利益を利益剰余金という資本勘定に振り替える仕訳を作成することが含まれます。これにより、翌年のために一時勘定が正式にリセットされます。

Beancountでは、このステップは通常不要です。 Favaのレポートは日付を認識します。2025年の損益計算書を要求すれば、2025年のデータのみが使用されます。残高が「繰り越される」ことはありません。ほとんどのユーザーは、残高をそのままにしておきます。

ただし、コンプライアンスや株主報告のために正式な締めを行う必要がある場合は、収益と費用の合計残高をEquity:Retained-Earningsに移動する簡単な年末取引で行うことができます。

実用的な月次締めチェックリスト​

Beancountを使用して毎月帳簿を締めるための、反復可能なチェックリストです。

• 記録: すべての銀行およびクレジットカードの取引をインポートします。現金経費やその他の項目を手動で入力します。
• 照合: すべての銀行口座、クレジットカード、ローン口座にbalanceアサーションを追加し、明細書と一致させます。
• レビュー: Favaで修正前試算表をスキャンします。奇妙な、または予期しない残高を調査します。古い未払いの請求書（Assets:AccountsReceivable）や支払い（Liabilities:AccountsPayable）がないか確認します。
• 修正: 未収収益/費用、繰延収益、および必要な訂正の仕訳を計上します。
• 検証: bean-checkを実行します。最終的な修正後試сан表をレビューします。
• 公開: 損益計算書と貸借対照表を生成します。利害関係者に送るか、記録のために保存します。
• 締め: ビジネスで必要な場合は、オプションで締め仕訳を実行します。その期間の.beancountファイルのコピーをアーカイブします。

Beancountが会計サイクルで優れている理由​

• 透明性と監査可能性: あなたの台帳はテキストファイルです。gitを使用して財務履歴をバージョン管理し、diffで変更を確認し、会計士と明確で曖昧さのない形式で共同作業できます。
• 完全なコントロール: あなたが勘定科目表を定義します。ソフトウェアベンダーの構造に縛られることはありません。あなたのデータは、オープンフォーマットで、永遠にあなたのものです。
• 比類なきパワー: SQLライクなクエリ（BQL）と豊富なWebインターフェース（Fava）の組み合わせにより、財務データを分析し、理解するための比類なき力を得られます。

すぐに始められるコピペ用スニペット​

シンプルな勘定科目表:

option "title" "私の個人台帳"
option "operating_currency" "USD"

;; --- 勘定科目 ---
1970-01-01 open Assets:Bank:Checking
1970-01-01 open Assets:AccountsReceivable
1970-01-01 open Liabilities:CreditCard
1970-01-01 open Liabilities:UnearnedRevenue
1970-01-01 open Equity:Owner:Capital
1970-01-01 open Equity:Retained-Earnings
1970-01-01 open Income:Consulting
1970-01-01 open Expenses:Office:Supplies
1970-01-01 open Expenses:Software
1970-01-01 open Expenses:Depreciation

便利なBQLクエリ:

-- 未払い残高のあるすべての顧客を検索
SELECT payee, sum(position)
WHERE account = 'Assets:AccountsReceivable'
GROUP BY payee
HAVING sum(position) > 0
ORDER BY sum(position) DESC;

時代を超越した会計サイクルを、Beancountのモダンでテキストベースのツールにマッピングすることで、堅牢で透明性が高く、長く使えるシステムを手に入れることができます。楽しい簿記を！

何十年もの間、ビジネス会計の世界は QuickBooks、Xero、FreshBooks といった閉鎖的な GUI ベースのシステムが支配してきました。これらは使いやすさと視覚的なワークフローを提供し、非技術的なユーザーに適しています。しかし、開発者やパワーユーザー、そして完全な透明性とコントロールを求める人々にとって、全く異なるアプローチが登場しました：Beancount.io です。

本記事では Beancount.io と従来の会計ソフトウェアを直接比較します。哲学、柔軟性、コスト、長期的な保守性という観点から主要な違いを分解し、どのシステムが本当に自分のニーズに合うかを判断できるようにします。

1. 哲学とワークフロー​

この二つのアプローチの最も根本的な違いは、コア哲学にあります。

Beancount.io
Beancount.io はプレーンテキスト会計という哲学に基づいて構築されています。すべての取引はシンプルなテキストファイルのエントリとして記録されます。この「コードとしての会計」モデルは、人間が読めてバージョン管理できる記録を優先します。財務データはベンダーにロックされることのない、永続的でオープンな形式で所有できます。コードエディタや Git、コマンドラインツールに慣れたユーザー向けに設計されたワークフローです。

従来のソフトウェア
従来の会計プラットフォームは GUI ベースでフォーム駆動です。ウィザードやドロップダウン、ビジュアルフォームを使ってデータを入力します。このアプローチは即時性とアクセシビリティを重視し、非技術的なユーザーが学習コストなく始められるようにします。ただし、データはベンダー所有のフォーマットやクラウドデータベースに保存され、別サービスへの移行時には複雑なエクスポート／インポートが必要になることがあります。

結論：完全なコントロール、データ所有権、透明性、そして自動化を重視するなら Beancount.io が明らかな勝者です。「クリックしてすぐに」始めたい場合は従来のソフトウェアが自然に感じられます。

2. 柔軟性とカスタマイズ​

ソフトウェアはどれだけ自分のニーズに合わせられるか？

Beancount.io
100 % スクリプト可能であることが Beancount.io の最大の強みです。Python とシームレスに統合でき、任意の API に接続したり、銀行フィードからデータを自動取得したり、複雑なルールに基づいて取引にタグ付けしたり、完全にカスタマイズしたレポートを生成したりできます。ベンダーが課す制限がないため、拡張性は実質的に無限です。

従来のソフトウェア
PayPal、Stripe、各種給与サービスなどの一般的なツールとの統合が用意されていますが、ベンダーの「壁の中」で動くことになります。カスタマイズはプラットフォームが許可する範囲に限られ、上位プランへのアップグレードやサードパーティアドオンの購入が必要になることが多いです。API は利用可能ですが、エコシステムのルールやレートリミットに縛られます。

結論：開発者や技術者にとって Beancount.io の柔軟性は比類がありません。標準的なプラグイン・アンド・プレイの業務フローを求める場合は従来ツールが適しています。

3. コラボレーションと透明性​

他者と協働し、記録を監査する方法が大きく異なります。

Beancount.io
コラボレーションは Git を通じて管理されます。財務元帳へのすべての変更が完全に透明で監査可能です。誰が、いつ、なぜ変更したかがコードレビューと同様に把握できます。分散チームで GitHub や GitLab をすでに利用している場合に最適です。さらに、レポートの数値はすべて元帳ファイルの行項目に遡れるため、計算がブラックボックスになることはありません。

従来のソフトウェア
組み込みのユーザー役割と権限でコラボレーションを行います。会計士やブックキーパー、ビジネスパートナーをウェブインターフェース経由で招待でき、リアルタイムで帳簿にアクセスできます。ただし、税金計算や自動残高調整など、一部の内部ロジックが不透明な「ブラックボックス」になることがあり、独自に検証しにくい点があります。

結論：細かな監査性とコードスタイルの共同作業を重視するチームには Beancount.io が最適です。従来システムは GUI でのリアルタイム共有に慣れた会計士向きです。

4. コストと所有権​

財務モデルとデータ所有権の概念は全く異なります。

Beancount.io
コアの Beancount ソフトウェアはオープンソースで無料です。支払うのはホスティング、インテリジェント自動化、プレミアム機能といった付加価値サービスのみ。シートごとのライセンス料はなく、チーム規模に応じてコストが増えることはありません。最も重要なのはベンダーロックインがゼロであること。テキストファイルの集合体であるデータは、好きな場所に好きな時に移動・編集・保存できます。

従来のソフトウェア
サブスクリプションモデルが主流で、月額または年額で課金されます。機能ごとに階層があり、ユーザー数や企業規模に応じた追加料金が発生することがあります。支払いを停止するとデータや機能へのアクセスが失われるリスクがあり、ベンダーロックインは長期的な重大リスクです。

結論：技術チームでデータ主権を重視するなら Beancount.io は長期的に圧倒的にコスト効果が高いです。従来ソフトは予測可能なサブスク費用ですが、長期的な依存を招きます。

5. 学習曲線と導入速度​

どれだけ早く使い始められるか？

Beancount.io
学習曲線は確実に急です。テキストベースの編集、基本構文の理解、Git などのツールに慣れる必要があります。しかし、投資した時間は大きなリターンを生みます。習得すれば、超高速で再現可能なワークフローが実現し、財務全体の深い理解が得られます。

従来のソフトウェア
非技術的なビジネスオーナー向けに設計されており、オンボーディングの摩擦が最小限です。数分で請求書作成や費用分類が可能です。ただし、カスタムレポート作成やマルチエンティティ会計といった高度機能を使いこなすには依然として相応の時間が必要です。

結論：強力なシステムを学ぶ覚悟があるなら Beancount.io が適しています。即効性と簡便さを求める非技術ユーザーには従来ソフトが向いています。

並列比較​

どちらを選ぶべきか​

最終的な判断は、チームのスキル、優先事項、ワークフローに依存します。

Beancount.io を選ぶべきケース

• 開発者、データアナリスト、技術志向のパワーユーザーである
• 完全な透明性、コントロール、長期的なデータポータビリティを最重要視する
• 会計を自動化し、独自のワークフローに深く統合したい
• 財務記録をソースコードと同等の厳密さで扱うことに抵抗がない

従来の会計ソフトウェアを選ぶべきケース

• 技術的なセットアップなしで、すぐに使えるビジュアルインターフェースが欲しい
• 会計士やチームメンバーに最小限のトレーニングでアクセスさせたい
• ベンダーがアップデートやコンプライアンスをすべて管理するマネージドサービスを好む
• 必要な統合が既製のアプリで十分にカバーできる

最後に​

Beancount.io は QuickBooks を「上回る」ことを目指すのではなく、根本的に異なる考え方を提示しています。会計をコードとして扱うことで、バージョン管理がソフトウェア開発にもたらしたような「完全な透明性、完全な再現性、究極のコントロール」を実現します。

同時に、従来の会計ソフトは即時の使いやすさと、非技術チーム向けの既製統合で依然として強みを持ちます。どちらが「全体的に優れている」かではなく、あなたのワークフロー、優先順位、財務データに対するコントロール欲求に最も合致する方を選ぶことが重要です。

Beancountのコア機能と哲学​

Beancountは、プレーンテキストファイルを使用して取引を記録する、オープンソースの複式簿記会計システムです。その核心において、Beancountはあなたの台帳を、シンプルで厳格な文法によって定義された_データセット_として扱います。すべての財務イベント（取引、勘定開設、商品価格など）はテキストファイル内のディレクティブ（指示）であり、Beancountはこれを解析してエントリーのインメモリデータベースに変換します。この設計により、複式簿記の原則が強制されます。つまり、すべての取引は勘定間で借方と貸方のバランスが取れていなければなりません。その結果、バージョン管理、検査、クエリが容易な、非常に透明性が高く監査可能な台帳が生まれます。

哲学 – 正確性とミニマリズム: Beancountの設計は、データの整合性とシンプルさを優先しています。その作成者であるMartin Blaisは、Beancountがユーザーが間違いを犯すことを前提とした「悲観的」なものであると述べており、そのため追加のチェックと制約を課しています。たとえば、Beancountは一度も追加されていない資産の削除を許可せず（負の株式保有や現金残高を防ぐ）、使用前にすべての勘定が開設されていることを強制できます。Ledgerの「仮想」または自動的にバランスが取られる転記の概念は欠けています。これは、完全にバランスの取れたエントリーを強制するための意図的な選択です。Beancountは、基本的な複式簿記が提供する以上のクロスチェックを行い、事実上**「正確性に徹底的にこだわる」**姿勢をとっています。この慎重なアプローチは、「自分自身をあまり信用していない」ユーザーや、ソフトウェアにエラーを検出してほしいと考えるユーザーにアピールします。

最小限のオプション、最大限の一貫性: Ledgerの無数のコマンドラインフラグやチューニングオプションとは対照的に、Beancountはミニマリズムを選択しています。グローバルオプションは非常に少なく、台帳ファイル外で取引のセマンティクスを変更するものはありません。会計に影響を与えるすべての設定（商品の取得原価計算方法や記帳の前提など）は、ファイル内のディレクティブまたはプラグインを介して行われ、レポートの生成方法に関わらず、同じファイルを読み込むと常に同じ結果が生成されることを保証します。この設計は、Ledgerの多くの調整項目とそれらの間の微妙な相互作用の複雑さを回避します。Beancountの哲学は、会計ツールは入力ファイルからレポートまでの一貫した安定した決定論的なパイプラインであるべきだというものです。これは、台帳をプログラムで順次処理できるディレクティブの順序付きストリームとして扱うことで実現されます。Ledgerが特別な構文として扱うもの（期首残高や価格ステートメントなど）でさえ、Beancountのデータモデルでは第一級のディレクティブであり、これがシステムを非常に拡張性の高いものにしています。

プラグインとクエリ言語による拡張性: BeancountはPythonで実装されており、処理パイプラインにカスタムロジックを注入するためのフックを提供します。ユーザーは、取引のストリーム上で動作するPythonのプラグインを作成できます（たとえば、カスタムルールを強制したり、自動エントリーを生成したりするため）。これらのプラグインはファイルが処理される際に実行され、ソースを変更することなくBeancountのコア機能を効果的に拡張します。Beancountには、台帳を分析するための強力なクエリ言語（SQLに触発されたもの）も含まれています。bean-queryツールは、解析された台帳をデータベースとして扱い、分析クエリを実行できます。たとえば、カテゴリ別に費用を合計したり、特定の受取人のすべての取引を抽出したりできます。Beancount 3.xでは、このクエリ機能はスタンドアロンのbeanqueryパッケージに移動しましたが、ユーザーの観点からは、依然としてSQLライクなクエリを介して柔軟なレポート作成が可能です。

プレーンテキストとバージョン管理: プレーンテキスト会計ツールとして、Beancountは_ユーザーコントロール_とデータの永続性を重視しています。台帳は単なる.beancountテキストファイルであり、どのテキストエディタでも編集できます。これは、あなたの全財務履歴が人間が読める形式で保存され、Gitや他のVCSに入れて変更を時系列で追跡できることを意味します。ユーザーはしばしば、すべての編集の監査証跡を維持するために（変更を説明するコミットメッセージと共に）Beancountファイルをバージョン管理下に置きます。このアプローチは、会計データ、特に個人や小規模ビジネスの財務は、透明で「将来も利用可能」であるべきだというBeancountの哲学と一致しています。つまり、独自のデータベースにロックされるべきではないということです。Martin Blais自身の言葉を借りれば、Beancountはコミュニティのためにシンプルで、永続的で、無料であるように作られた「愛情のこもった労働」です。それは2007年頃に最初に開発され、主要な書き直し（v1からv2、そして2024年のv3）を経て、ミニマリズムと正確性というコア哲学を維持しながら設計を洗練させてきました。

Beancountエコシステムのツール、プラグイン、拡張機能​

Beancountエコシステムは、コアの台帳機能を強化する豊富なツール、プラグイン、拡張機能のセットを成長させてきました。これらは、データのインポート、台帳の編集、レポートの表示、特殊な会計機能の追加をカバーしています。以下に、Beancountの世界における主要なコンポーネントとアドオンの概要を示します：

データインポートユーティリティ（インポーター）​

実用的な使用において最も重要なニーズの一つは、銀行、クレジットカード、その他の金融機関から取引をインポートすることです。Beancountはこの目的のためにインポートフレームワークとコミュニティ提供のインポートスクリプトを提供しています。Beancount 2.xでは、組み込みモジュールbeancount.ingest（bean-extractやbean-identifyなどのコマンドを含む）がPythonでインポータープラグインを定義し、ダウンロードした明細書に適用するために使用されていました。Beancount 3.xでは、これはBeangulpという外部プロジェクトに置き換えられました。Beangulpはbeancount.ingestから進化した専用のインポーターフレームワークであり、現在Beancount 3.0の取引インポートを自動化するための推奨方法となっています。これにより、外部ファイル（CSVやPDF明細書など）を読み取り、Beancountのエントリーを出力するPythonスクリプトやコマンドラインツールを作成できます。この新しいアプローチは、インポートロジックをBeancountのコアから切り離します。たとえば、古いbean-extractコマンドはv3で削除され、代わりにインポートスクリプト自体がBeangulpのCLIインターフェースを介して取引を生成します。

コミュニティによって提供された、さまざまな銀行やフォーマットに対応する既製のインポーターが数十も存在します。中国のAlipayやWeChat Payから、ヨーロッパの各種銀行（Commerzbank, ING, ABN AMROなど）、ChaseやAmexのような米国の銀行まで、世界中の金融機関向けのインポータースクリプトがあります。これらの多くは公開リポジトリ（多くはGitHub上）やbeancount-importersのようなパッケージに集められています。例えば、Tarioch Beancount Toolsプロジェクト（tariochbctools）は、スイスや英国の銀行向けのインポーターを提供し、暗号資産取引のインポートも処理します。別の例としてLazy Beancountは、一般的なインポーター（Wise, Monzo, Revolut, IBKRなど）のセットをパッケージ化し、簡単な自動化のためのDockerベースのセットアップを提供します。どの銀行や金融サービスを利用していても、誰かがそのためのBeancountインポーターを書いている可能性があります。そうでなくても、Beangulpのフレームワークを使えば自分で書くことができます。Pythonの柔軟性により、インポーターはCSV/Excelファイルの解析、OFX/QIFダウンロードの処理、さらにはAPIのスクレイピングを行い、標準化されたBeancount形式で取引を出力できます。

編集とエディタ統合​

Beancountの台帳は単なるテキストであるため、ユーザーは好みのテキストエディタやIDEを活用して管理することがよくあります。エコシステムは、この体験をよりスムーズにするためのエディタサポートプラグインを提供しています。多くの人気エディタには、シンタックスハイライト、勘定科目名の自動補完、リアルタイムのエラーチェックを追加する拡張機能があります：

• Emacs Beancount-Mode: Emacsのメジャーモード（beancount-mode）が利用可能で、.beancountファイルの編集をサポートし、シンタックスカラーリングやBeancountのチェッカーとの統合などの機能を提供します。バックグラウンドでbean-checkを実行することもでき、編集中に台帳のエラー（バランスの取れていない取引など）がフラグ付けされます。
• VS Code拡張機能: VSCode MarketplaceにあるBeancount拡張機能は、Visual Studio Codeユーザーに同様の利便性を提供します。シンタックスハイライト、金額の桁揃え、勘定科目/受取人の自動補完、さらにはファイル保存時のオンザフライでの残高チェックをサポートしています。Favaとの統合も可能で、VSCode内からFavaのWebインターフェースを起動できます。
• Vim、Atom、その他のエディタ用にもプラグインやモードが存在します。例えば、Beancount用のTree-sitter文法があり、これは現代のエディタでシンタックスハイライトを強化し、FavaのWebベースのエディタコンポーネントでも採用されました。要するに、あなたの編集環境が何であれ、コミュニティはBeancountファイルの編集を便利でエラーのないものにするためのプラグインを提供している可能性が高いです。

従来のエディタ以外での迅速な取引入力のために、Bean-addやモバイルアプリのようなツールもあります。_Bean-add_は、プロンプトやワンライナーで新しい取引を追加できるコマンドラインツールで、日付や勘定の提案を処理します。モバイルでは、Beancount Mobileというプロジェクトが、外出先で取引を入力するためのシンプルなインターフェースを提供します（例えば、携帯電話から現金の購入を記録するなど）。さらに、メッセージングを通じて取引を記録するためのBeancount Telegram Botも存在します。取引詳細を含むメッセージを送信すると、ボットがそれを台帳ファイルにフォーマットします。

Webフロントエンドと可視化ツール​

(Fava) Favaのウェブインターフェースは、Beancount用のインタラクティブなダッシュボードを提供し、勘定科目と残高のテーブルと共に、可視化（ここではカテゴリ別の費用のツリーマップとして表示）を伴う損益計算書などのレポートを特徴としています。

Beancountの代表的なフロントエンドは、モダンなWebインターフェースであるFavaです。Favaは、あなたのBeancountファイルを読み取り、ブラウザでリッチなインタラクティブ体験を生成するローカルWebアプリとして動作します。貸借対照表、損益計算書、時系列の純資産、ポートフォリオ保有状況、パフォーマンスチャート、予算など、豊富なレポート一式を標準で提供します。ユーザーはしばしば、他のプレーンテキスト会計ツールよりもBeancountを選ぶ大きな理由としてFavaを挙げます。たった一つのコマンド（fava ledger.beancount）で、テキストの代わりにグラフやテーブルで財務状況を閲覧できます。Favaは次のような機能をサポートしています：勘定のドリルダウン、受取人やタグによる取引のフィルタリング、クエリエディタ（Beancountクエリを実行し、ブラウザで結果を確認できる）、さらには台帳用の統合されたWebベースのエディタまで。非常に使いやすく、視覚的なインターフェースを好む人々にとってプレーンテキスト会計を身近なものにしています。

内部的には、FavaはPython（バックエンドはFlask）とJavaScript（フロントエンドはSvelte）で書かれています。独自のリリースサイクルを持ち、活発にメンテナンスされています。特筆すべきは、FavaがBeancountの開発に追随している点です。たとえば、Fava 1.30ではBeancount v3のサポートが追加され、内部で新しいbeanqueryおよびbeangulpパッケージを使用するように切り替わりました。（古い台帳のためにBeancount 2も引き続きサポートしています。）Favaの使いやすさへの注力には、Webエディタでの自動補完や、ダークモードとレスポンシブなチャートを備えた洗練されたUIなどが含まれます。また、Fava-GTKという派生プロジェクトもあり、これはネイティブアプリの感触を好むGNOME/LinuxユーザーのためにFavaをデスクトップアプリケーションとしてパッケージ化したものです。

Fava以外にも、他の可視化・分析オプションが存在します。Beancountのデータはテーブルとしてエクスポートまたはクエリできるため、ユーザーはJupyterノートブックやPandasのようなツールをカスタム分析に活用することがよくあります。例えば、あるユーザーは、カスタムレポートを準備するためにクエリインターフェース経由でBeancountからPandasのDataFrameにデータを引き出す方法を説明しています。特定のレポート用のコミュニティ提供スクリプトもあります。例えば、ポートフォリオ配分分析ツールや、支出対純資産の工程管理図などです。しかし、ほとんどの人にとって、Favaはコードを書かなくても十分すぎるほどのレポート機能を提供します。さらには拡張機能もサポートしており、新しいレポートページやチャートをFavaに追加するPythonファイルをドロップインできます。注目すべき拡張機能は、Fava内でエンベロープ予算管理を行うためのfava-envelopeです。全体として、FavaはBeancountエコシステムの中心的な可視化ハブとして機能しています。

コマンドラインユーティリティとスクリプト​

Beancountには様々なCLIツールが付属しています（特に古いv2ブランチに多く、一部はv3で整理されました）。これらのツールは、台帳ファイルを操作してチェックしたり、テキストやHTMLで特定のレポートを生成したりします：

• bean-check: ファイルの構文エラーや会計エラーをチェックするバリデータ。bean-check myfile.beancountを実行すると、不均衡、勘定の欠落、その他の問題が警告され、ファイルがエラーフリーであれば何も出力されません。
• bean-format: ソースコードにコードフォーマッタをかけるように、数値をきれいな列に揃えて台帳を整えるフォーマッタ。これにより、ファイルがクリーンで読みやすくなります。
• bean-query: 台帳に対してBeancountのクエリ言語を実行するための対話型シェルまたはバッチツール。カスタムの表形式レポートを作成するために使用できます（例：bean-query myfile.beancount "SELECT account, sum(amount) WHERE ..."）。
• bean-report: （v2の）多機能レポートジェネレータで、定義済みのレポート（貸借対照表、損益計算書、試算表など）をコンソールやファイルに出力できます。例えば、bean-report file.beancount balancesは勘定残高を出力します。（実際には、これらのテキストレポートの多くはFavaのより優れた表示に取って代わられています。）
• bean-web / bean-bake: localhostでレポートを提供したり、静的なHTMLファイルとして「ベイク」したりする古いWebインターフェース。これらはFavaが人気になる前に主に使用されていました。bean-webは、bean-reportが生成できるのと同じレポートの基本的なWebビューを提供していました。Beancount 3では、bean-webは削除されました（Favaが推奨されるWebフロントエンドとなり、優れた体験を提供するため）。
• bean-example: サンプルの台帳ファイルを生成するユーティリティ（新規ユーザーがBeancountエントリーのテンプレートを見るのに便利）。
• bean-doctor: 台帳や環境の問題を診断できるデバッグツール。

Beancount v3の時点で、これらのツールの多くがコアプロジェクトから移動されたことは注目に値します。コアのBeancountパッケージは効率化され、クエリエンジンやインポーターのようなツールはメンテナンスを容易にするために別々のパッケージ（beanquery, beangulpなど）に分割されました。例えば、bean-queryの機能は現在、別途インストールされるbeanqueryツールによって提供されます。ユーザーの観点からは、機能は引き続き利用可能ですが、モジュール化されただけです。Arch LinuxコミュニティはFavaを更新する際にこの変更に注目しました：FavaパッケージはBeancount 3.xをサポートするためにbeanqueryとbeangulpへの依存関係を追加しました。このモジュール化アプローチにより、コミュニティの他の人々がBeancountのリリースサイクルとは独立してこれらの補助ツールに貢献することも可能になります。

Beancountプラグインと拡張機能​

Beancountエコシステムの際立った強みはプラグインシステムです。Beancountファイルにplugin "module.name"という行を追加することで、台帳処理中に実行されるカスタムPythonロジックを組み込むことができます。コミュニティはBeancountの機能を拡張するために多くのプラグインを作成しました：

• データ品質とルール: 例として、複数の勘定を含む方程式をアサートできるbeancount-balexpr（例：資産A + 資産B = 負債X）、勘定を閉鎖する際に自動的に残高アサーションを挿入してゼロになることを保証するbeancount-checkclosedがあります。ファイル内の取引が日付順にソートされていることを保証するプラグイン（autobean.sorted）もあり、順序が違うエントリーを検出します。
• 自動化: beancount-asset-transferプラグインは、勘定間で現物移管のエントリーを生成できます（取得原価を維持したままブローカー間で株式を移動するのに便利）。別のautobean.xcheckは、Beancount台帳を外部の明細書と相互チェックして不一致を見つけます。
• 繰り返し取引と予算: Akuukisによる**「repeat」または補間プラグインは、繰り返し取引を定義したり、年間の費用を月々に分割したりすることができます。予算管理については、fava-envelope拡張機能（Fava経由で使用）がプレーンテキストでのエンベロープ予算管理手法をサポートします。また、Frank DaviesによるMiniBudget**もあります。これは、個人や小規模ビジネスの予算管理を支援するためにBeancountに触発された小さなスタンドアロンツールです。
• 税務とレポート: 税務会計を支援するプラグインもあります。例えば、キャピタルゲインを自動的に短期と長期に分類するものなどです。別のプラグイン（Justus Pendletonによるfincen_114）は、外国口座を持つ米国納税者向けのFBARレポートを生成し、Beancountデータが規制報告にどのように活用できるかを示しています。
• コミュニティプラグインリポジトリ: beancount-plugins（Dave Stephensによる）のようなキュレーションされたプラグインセットがあり、減価償却エントリーなどに焦点を当てています。また、beancount-plugins-zack（Stefano Zacchiroliによる）には、ディレクティブのソートなどの様々なヘルパーが含まれています。

プラグインに加えて、Beancountを取り巻く他のユーティリティツールは特定のニーズに対応しています。例えば、beancount-blackは、Blackコードフォーマッタに似た自動フォーマッタですが、Beancount台帳ファイル用です。前述のように、チャット経由で取引を追加するためのBeancount Bot（Telegram/Mattermost）や、macOSですばやくファイルに取引を追加するためのAlfredワークフローがあります。Pintoという名前のツールは、対話的な入力（強化版bean-addのようなもの）を備えた「超強化された」CLIを提供します。他のシステムから移行する人のために、コンバータも存在します（YNAB2Beancount、CSV2Beancount、GnuCash2Beancount、Ledger2Beancount） 。 要約すると、Beancountエコシステムは非常に広範です。以下の表1は、いくつかの主要なツールと拡張機能をその役割とともにリストアップしたものです：

Ledger、hledger、および類似システムとの比較​

Beancountは、プレーンテキスト複式簿記会計ツールのファミリーに属しており、その中でもLedger CLI（John Wiegley's Ledger）とhledgerが有名です。これらのシステムはすべて、プレーンテキストの台帳ファイルと複式簿記という中心的な考えを共有していますが、構文、哲学、エコシステムの成熟度において異なります。以下の表は、Beancount、Ledger、hledgerの主な違いを強調しています：

要約すると、Beancountは厳格さ、プラグインベースの拡張性、そしてユーザーフレンドリーなWebインターフェースで差別化を図っています。Ledgerは、コマンドライン純粋主義者や究極の速度を必要とする人々に好まれる、古典的で非常に柔軟なツールであり続けています（LedgerのC++エンジンは巨大なファイルでも非常に高速です）。hledgerは中間的な立場を提供します – Ledgerの機能の多くを備えつつ、もう少し構造化されており、公式にサポートされた（シンプルではあるが）Web UIがあります。3つすべてがプレーンテキスト会計の利点（監査可能性、Gitによるバージョン管理、プレーンデータ）を共有していますが、Beancountのエコシステム（特にFava）は、近年、平均的なユーザーにとってよりアクセスしやすくしたと言えるでしょう。一方、Ledger/hledgerユーザーは、セットアップの相対的なシンプルさ（Python不要）と長年証明された安定性を好むことがあります。最終的に、どれを選ぶかは個人の好みに帰着します：厳格な正確性と豊富なエコシステムを重視する人はBeancountに傾くことが多く、一方、リーンでターミナル中心のツールを求める人はLedgerやhledgerに固執するかもしれません。

Beancountの利用シナリオ​

Beancountは、個人の財務追跡だけでなく、（場合によっては）小規模ビジネスの会計にも使用できるほど多機能です。どちらのシナリオでも、中核となる複式簿記のアプローチは同じですが、規模や具体的な慣行は異なる場合があります。

個人の財務​

多くのBeancountユーザーは、個人または家庭の財務を管理するためにBeancountを使用しています。Beancountでの典型的な個人財務設定には、当座預金や普通預金、クレジットカード、投資、ローン、収入カテゴリ（給与、利子など）、費用カテゴリ（家賃、食料品、娯楽など）の勘定が含まれるかもしれません。ユーザーは日々の取引を手動で記録する（領収書、請求書などを入力する）か、前述のインポーターツールを使用して銀行の明細書からインポートします。Beancountが個人の財務にもたらす利点には、次のようなものがあります：

• 統合と分析: すべての取引を、数年間の財務履歴を表す単一のテキストファイル（または一連のファイル）に保存できます。これにより、長期的なトレンドを簡単に分析できます。Beancountのクエリ言語やFavaを使えば、「過去5年間で旅行にいくら使ったか？」や「月平均の食料品費はいくらか？」といった質問に数秒で答えることができます。あるユーザーは、Beancountに切り替えた後、_「財務データ（支出、寄付、税金など）の分析は、FavaまたはデータをクエリしてPandasのようなツールを使用することで些細なことになった」_と述べています。本質的に、あなたの台帳は意のままにクエリできる個人の財務データベースになります。
• 予算管理と計画: Beancountは予算管理システムを強制しませんが、実装することは可能です。一部のユーザーは、予算勘定を作成したり、fava-envelopeプラグインを使用したりして、エンベロープ予算管理を行っています。他のユーザーは、定期的なレポートを使用して支出を目標と比較するだけです。プレーンテキストであるため、Beancountを外部の予算管理ツールやスプレッドシートと統合するのは簡単です（データをエクスポートするか、クエリからCSV出力を使用する）。
• 投資と純資産の追跡: Beancountは、取得原価と市場価格の堅牢な処理のおかげで、投資の追跡に優れています。株式や暗号資産などの売買を原価の詳細と共に記録し、Pricesディレクティブを使用して市場価値を追跡できます。Favaは、時系列の純資産チャートや資産クラス別のポートフォリオ内訳を表示できます。これは個人の資産管理にとって非常に有用です – MintやPersonal Capitalのような商用ツールが提供するものと同様の洞察を、完全に自分の管理下で得ることができます。多通貨対応も組み込まれているため、外貨や暗号資産を保有している場合、Beancountはそれらを追跡し、レポート用に変換できます。
• 照合と正確性: 個人の財務では、銀行の明細書との照合がしばしば伴います。Beancountでは、残高アサーションやドキュメント機能を使用して定期的に勘定を照合できます。たとえば、毎月balance Assets:Bank:Checking <日付> <残高>というエントリーを追加して、台帳が月末の銀行明細と一致することを確認できます。bean-checkツール（またはFavaのエラー表示）は、一致しない場合に警告します。あるユーザーは、すべての勘定の月次照合を行っており、それが「異常な活動を捉えるのに役立つ」と述べています – これはBeancountが促進する良い個人財務の衛生習慣です。
• 自動化: 技術に詳しい個人は、Beancountで個人財務ワークフローの大部分を自動化しています。インポーター、cronジョブ、そしておそらく少しのPythonを使用することで、たとえば、毎日銀行の取引が取得され（一部はOFXやAPIを使用）、ルールによって分類されてBeancountファイルに追加されるようなシステムをセットアップできます。時間が経つにつれて、あなたの台帳はほとんどが自動更新され、必要に応じてレビューと調整を行うだけになります。Hacker Newsのあるコミュニティメンバーは、3年後にはBeancountの帳簿が「95%自動化」されたと共有しました。このレベルの自動化は、Beancountのプレーンテキストのオープン性とスクリプト機能のおかげで可能です。

個人の財務ユーザーは、データの完全な所有権（閉鎖される可能性のあるクラウドサービスへの依存がない – たとえばMintが廃止されたことへの懸念）と、すべてのデータを統合したときの洞察の深さから、スプレッドシートやアプリよりもBeancountを選ぶことがよくあります。学習曲線は簡単ではありません – 基本的な会計とBeancountの構文を学ぶ必要があります – が、公式ドキュメントやコミュニティのチュートリアルのようなリソースが新規参入者を助けます。一度設定してしまえば、多くの人が、常に明確で信頼できる財務状況の全体像を持つことに安心感を見出します。

小規模ビジネス会計​

小規模ビジネス（または非営利団体、クラブなど）でBeancountを使用することは、個人での使用ほど一般的ではありませんが、確かに可能であり、成功している例もあります。Beancountの複式簿記フレームワークは、実際には企業会計を支えるシステムと同じですが、専用の会計ソフトウェアが提供する高レベルの機能（請求書モジュールや給与計算統合など）の一部が欠けています。Beancountが小規模ビジネスの文脈でどのように適合するかは次のとおりです：

• 総勘定元帳と財務諸表: 小規模ビジネスは、Beancountファイルを総勘定元帳として扱うことができます。銀行口座、売掛金、場合によっては在庫の資産勘定、クレジットカード、ローン、買掛金の負債勘定、所有者資本の資本勘定、売上やサービスの収益勘定、そしてすべての事業費用の費用勘定を持つことになります。この台帳を維持することで、Beancountのレポートやクエリを使用して、いつでも損益計算書と貸借対照表を作成できます。実際、Beancountの組み込みレポートやFavaは、会計原則に完全に準拠した貸借対照表と損益計算書を数秒で生成できます。これは、小規模な事業が収益性、財政状態、キャッシュフローを評価するのに十分です（キャッシュフロー計算書は直接組み込まれていませんが、少しクエリをかければ導き出せるため）。
• 請求書と売掛金、買掛金: Beancountには組み込みの請求書発行システムはありません。ユーザーは通常、外部で請求書を処理し（例：Wordや請求書アプリで作成）、その結果をBeancountに記録します。たとえば、請求書を発行すると、売掛金を借方に、収益を貸方に記録するエントリーを作成します。支払いがあれば、現金/銀行を借方に、売掛金を貸方に記録します。こうして、売掛金勘定の残高を見ることで、未回収の売掛金を追跡できます。請求書（買掛金）についても同様です。専門の会計ソフトウェア（リマインダーを送信したり、メールと統合したりするかもしれない）よりも手作業が多くなりますが、完全に実行可能です。一部のユーザーは、Beancountで請求書を管理し、未払いの請求書を見逃さないようにするためのテンプレートやワークフローを共有しています（たとえば、メタデータやカスタムクエリを使用して未払い請求書をリストアップするなど）。
• 在庫または売上原価: 製品を販売するビジネスでは、Beancountは在庫の購入と販売を追跡できますが、規律ある入力が必要です。Inventoryと原価計算機能を使用するかもしれません：在庫を購入すると資産勘定が増加し（アイテムに原価が付加される）、それを販売すると原価が費用（COGS）に移動し、収益が記録されます。Beancountはロットの一致を要求するため、正しい原価で在庫を適切に減少させることを強制し、これにより、正しく行われれば粗利益計算が正確であることが保証されます。ただし、自動化されたSKU追跡などはなく、すべて財務レベル（数量と原価）での管理です。
• 給与計算と複雑な取引: Beancountは給与取引（給与費用、源泉徴収税など）を記録できますが、これらの数値を計算するのは外部または別のツールで行い、結果をBeancountに記帳することになります。非常に小規模なビジネス（例えば従業員1〜2人）では、これは管理可能です。たとえば、給与期間ごとに賃金、源泉徴収税、事業主税費用、支払現金などを分割した単一の仕訳を記録します。これを手動で行うことは、QuickBooksの仕訳入力で行うのと似ています – どの勘定に計上すべきかの知識が必要です。
• 複数ユーザーと監査: ビジネス環境での課題の一つは、複数の人が帳簿にアクセスする必要がある場合や、会計士がレビューする必要がある場合です。Beancountはテキストファイルなので、リアルタイムでの複数ユーザー対応ではありません。しかし、ファイルをGitリポジトリでホストすることで、コラボレーションが可能になります：各人が編集してコミットし、差分をマージできます。
• 規制遵守: 税務申告やコンプライアンスのために、Beancountのデータを使用して必要なレポートを生成できますが、カスタムクエリやプラグインが必要になる場合があります。インド政府のコンプライアンス報告用のコミュニティプラグインや、FinCEN FBAR報告用のプラグインの例を見ました。これは、努力すれば、Beancountが特定の報告要件を満たすように適合させられることを示しています。要件がシンプルな管轄区域（現金主義会計、または基本的な発生主義）の小規模ビジネスは、確かにBeancountで帳簿を維持し、税務申告用の財務諸表を作成できます。しかし、減価償却スケジュールや償却などの機能は、独自のエントリーを書くか、プラグインを使用する必要があるかもしれません（Dave Stephensの減価償却プラグインがその自動化を助けます）。一部の会計ソフトウェアのように「資産を減価償却する」をクリックするGUIはありません。減価償却を取引としてエンコードします（ある意味、これにより謎が解けます – すべてが検査できるエントリーです）。

実際には、多くの技術志向の小規模ビジネスオーナーが、QuickBooksの利便性よりもコントロールと透明性を好む場合、Beancount（またはLedger/hledger）を使用しています。Redditの議論では、取引量が限られている標準的な小規模ビジネス会計では、Beancountは問題なく機能すると指摘されました。制限要因は通常、快適さのレベルです – ビジネスオーナー（またはその会計士）がテキストベースのツールに慣れているかどうか。一つの利点はコストです：Beancountは無料ですが、会計ソフトウェアは小規模ビジネスにとって高価になることがあります。一方、公式サポートの欠如とDIYの性質は、ビジネスオーナーであり、かつ技術に多少詳しい人に最も適していることを意味します。プログラミングスキルを持つフリーランサーや個人事業主にとって、Beancountはクラウド会計サービスに頼らずに財務を管理するための魅力的な選択肢となり得ます。

ハイブリッドアプローチも可能です：一部の小規模ビジネスは、請求書や給与計算に公式のシステムを使用し、定期的にデータをBeancountにインポートして分析やアーカイブを行っています。こうすることで、両方の長所を得ることができます – 日常業務のコンプライアンスと容易さ、そして統合された洞察のためのBeancountのパワーです。

要約すると、Beancountは、ユーザーが商用ソフトウェアが自動化することを手動で管理する意欲があれば、小規模ビジネス会計を処理できます。それは高度な透明性を保証します – あなたは帳簿を自分で書いているので、深く理解できます – そして、勤勉なユーザーにとっては、完璧な帳簿を作成できます。個人ユーザーとビジネスユーザーの両方が、Beancountの中核的な強みから恩恵を受けます：信頼性の高い会計エンジン、完全な監査証跡、そして（スクリプトとプラグインを介して）独自のシナリオに適応する柔軟性です。家庭の予算を追跡する場合でも、スタートアップの財務を管理する場合でも、Beancountはそれを正確かつオープンに行うためのツールキットを提供します。

コミュニティと開発活動​

Beancountには熱心なコミュニティがあり、その開発の歴史はオープンソースでニッチながらも情熱的な性質を反映しています。以下に、そのコミュニティ、メンテナー、関連プロジェクトに関する主要なポイントを挙げます：

• プロジェクトのメンテナンス: Beancountの主要な作者はMartin Blaisで、彼は2007年頃にプロジェクトを開始し、複数のバージョンを通じてそれを導いてきました。開発は長い間、大部分が一人での努力でした（コミュニティからのパッチの貢献を除く）。Martinの哲学は、「まず自分にとって、そして他の人にとっても、最もシンプルで、最も永続的な方法で役立つ」会計ツールを作ることでした。この個人的な動機が、プロジェクトを愛情のこもった労働として継続させました。2025年現在、Martin Blaisは依然としてリードメンテナーですが（彼の名前はコミットに現れ、メーリングリスト/イシュートラッカーで質問に答えています）、Beancountを取り巻くエコシステムには、それぞれのプロジェクトで他の多くの貢献者がいます。

• GitHubとリポジトリ: ソースコードはGitHubのbeancount/beancountリポジトリでホストされています。プロジェクトはGPL-2.0ライセンスで、長年にわたり modest な数の貢献者を引きつけてきました。2024年半ばに、Beancount Version 3が新しい安定版ブランチとして正式にリリースされました。このリリースは、いくつかのコンポーネントを分割したことが含まれます。例えば、beangulpリポジトリ（インポーター用）とbeanqueryリポジトリ（クエリツール用）は、現在beancount GitHub組織の一部であり、やや独立してメンテナンスされています。メインのBeancountリポジトリは、コアの会計エンジンとファイルパーサーに焦点を当てています。2025年現在、BeancountのGitHubは活発なイシュー議論と一部の進行中の開発を示しています – 量は多くありませんが、イシューやプルリクエストが少しずつ寄せられ、バグ修正や機能の洗練のために時折更新が行われています。

• Favaの開発: WebインターフェースであるFavaは、別のプロジェクトとして始まりました（Dominic Aumayrによって作成され、2016年に著作権が登録されました）。独自の貢献者コミュニティを持ち、これもGitHubのbeancount/favaで公開されています。Favaのメンテナーと貢献者（近年の例ではJakob Schnetz, Stefan Otteなど）は、インターフェースを積極的に改善しており、数ヶ月ごとにリリースがあります。FavaのGitterチャット（Favaのドキュメントにリンクあり）とGitHubイシュートラッカーは、ユーザーと開発者が新機能やバグについて議論する場所です。プロジェクトは貢献を歓迎しており、CHANGELOGのメモが複数のコミュニティメンバーのPRに感謝していることからも明らかです。FavaがBeancountの開発と密接に連携していること（Beancount v3と新しいbeanquery構文への迅速なサポート追加など）は、両プロジェクト間の良好な協力関係を示しています。

• メーリングリストとフォーラム: Beancountには公式のメーリングリストがあります（以前はGoogle Groupsにあり、「Beancount」というタイトル、または一般的なLedgerリストで議論されることもありました）。このメーリングリストは知識の宝庫です – ユーザーは特定のシナリオをモデル化する方法について質問したり、バグを報告したり、ヒントを共有したりします。Martin Blaisはメーリングリストで詳細な説明と共に返信することで知られています。加えて、より広範なプレーンテキスト会計コミュニティと大きく重なっています。Ledger CLIメーリングリストではBeancountに関する質問もよく取り上げられ、plaintextaccounting.orgのフォーラムやsubreddit r/plaintextaccountingではBeancountのトピックが頻繁に登場します。これらのプラットフォームのユーザーは、比較、個人のセットアップの共有、新規参入者の支援などを行っています。コミュニティの全体的な雰囲気は非常に協力的です – BeancountユーザーはしばしばLedgerユーザーを助け、その逆もまた然りで、これらのツールがすべて同様の目標を持っていることを認識しています。

• チャットグループ: メーリングリストの他に、Plaintext Accounting Slack/Discord（コミュニティ主催）やFava Gitterのようなチャットチャネルがあります。これらはより非公式で、リアルタイムに助けを得たり、機能について議論したりする方法です。例えば、特定の銀行のインポーターがあるかどうかSlackで尋ねることができます。Matrix/IRCチャネルも存在します（歴史的にはIRCの#ledgerや#beancount）。主流のソフトウェアのコミュニティほど人口は多くありませんが、これらのチャネルには知識豊富な人々がおり、難解な会計の質問に答えてくれることがよくあります。

• 貢献者と主要なコミュニティメンバー: Beancountコミュニティでは、いくつかの名前が際立っています：

  • “Redstreet” (Red S): 多くのプラグイン（beancount-balexpr, sellgainsなど）を書き、しばしばサポートを提供する多作な貢献者。彼らはまた、インポータースクリプトのセットと、明細書を取得するためのbean-downloadというツールを維持しています。
  • Vasily M (Evernight): いくつかのインポーターフレームワークやbeancount-valuationのようなプラグインの作者であり、投資に関するFavaへの貢献もあります。
  • Stefano Zacchiroli (zack): Emacs用のbeancount-modeと独自のプラグインリポジトリを作成したDebian開発者。彼は学術的な場でもプレーンテキスト会計を提唱しています。
  • Simon Michael: 主にhledgerのリーダーですが、Beancountを含むplaintextaccounting.orgを運営しています。この相互交流が、BeancountをLedger/hledgerユーザーの注目を集めるのに役立ちました。
  • Frank hell (Tarioch): 特にヨーロッパの機関向けの主要なインポーターと価格取得ツールのセットであるTarioch Beancount Toolsの貢献者。
  • Siddhant Goel: Beancountについてブログを書いているコミュニティメンバー（例えば、v3への移行ガイド）で、いくつかのインポーターを維持しています。彼のブログ投稿は多くの新規ユーザーを助けてきました。

  これら多くの人々がコード、ドキュメント、フォーラムでのヘルプを提供し、比較的小規模ながらもエコシステムを活気あるものにしています。

• GitHubの統計とフォーク: BeancountのGitHubリポジトリは、数百のスター（関心を示す）とフォークを集めています。Beancount自体の著名なフォークは稀です – 「Beancountだが機能X付き」というようなよく知られた分岐フォークはありません。代わりに、ユーザーが何か違うものを望んだとき、彼らはプラグインを書くか、別のツール（hledgerなど）を使用するかのどちらかであり、Beancountをフォークすることはしませんでした。hledgerはLedgerの一種のフォーク（Beancountではない）と考えることができ、Beancount自体はLedgerのアイデアを独自に再考したものですが、Beancountのリポジトリ内に大きな分裂プロジェクトはありません。コミュニティは一般的にメインリポジトリの周りに集まり、コードベースを断片化する代わりにプラグインインターフェースを介して拡張してきました。これはおそらく、Martin Blaisが外部からの貢献にオープンであり（彼のドキュメントには外部の貢献とモジュールを認めるセクションさえあります）、プラグインアーキテクチャがほとんどの新機能のためにフォークを維持する必要をなくしたためでしょう。

• コミュニティリソース: コミュニティによって作成された、Beancountを学び、使用するための高品質なリソースがいくつかあります：

  • GitHub Pages上のBeancountドキュメント（およびMartinが維持しているソースのGoogle Docs） – 会計の理論とBeancountがそれをどのように実装しているかを含め、非常に包括的です。
  • 数多くのブログ投稿や個人的なメモ – LWN.netには「Counting beans… with Beancount」という記事があり、多くの個人ブログ（Awesome Beancountの「Blog Posts」セクションにリストされている）が経験やヒントを共有しています。これらは知識を構築し、新規ユーザーを引きつけるのに役立ちます。
  • トークとプレゼンテーション: Beancountはミートアップやカンファレンスで発表されてきました（例えば、Python/Beancountで財務を管理するに関するPyMunich 2018のトーク）。このようなトークはツールをより広い聴衆に紹介し、しばしばHacker Newsのようなフォーラムで関心を呼び起こします。

• 注目すべき関連プロジェクト: Favaの他に、Beancountに関連するいくつかの他のプロジェクトには独自のコミュニティがあります：

  • Plain Text Accountingサイト – Simon Michaelによって維持されており、すべてのそのようなツールに関する情報を集約し、人々がBeancountを含む様々なツールの使用法を共有するフォーラムがあります。
  • 金融ツールとの統合: 一部のユーザーはBeancountをビジネスインテリジェンスツールやデータベースと統合しています。例えば、あるGoogle Groupsのスレッドでは、カスタム関数を介してPostgreSQLとBeancountデータを使用する詳細が述べられています。主流ではありませんが、これはBeancountの能力を押し広げる（例えば、非常に大規模なデータセットや組み込みを超える複雑なクエリを扱う）コミュニティの実験精神を示しています。

要約すると、Beancountのコミュニティは、大規模なオープンソースプロジェクトのコミュニティよりも小さいものの、非常に熱心で知識が豊富です。プロジェクトは着実な改善の流れと非常に役立つサポートチャネルを享受しています。協力的な精神（インポーターの共有、プラグインの作成、質問への回答）は、2025年の新規参入者が会計システムをセットアップする際に、広範な先行作業とコミュニティの知恵に頼ることができることを意味します。開発はエコシステムの意味で活発です – Favaのリリース、プラグイン開発など – たとえコアの変更が時折であってもです。エコシステムの成長（数十のツールがリストされたAwesome Beancountリストが証明するように）は、Beancountをますます有能にする健全なコミュニティを物語っています。

最近の開発と今後の機能​

2025年現在、Beancountエコシステムは過去数年間で大きな発展を遂げており、将来の機能強化に関する議論も進行中です。以下に、注目すべき最近の開発と、今後の展望をいくつか紹介します：

• Beancount 3.0リリース（2024年）: Beancount 2.xが長らく標準であった後、バージョン3が2024年半ばに正式にリリースされました。これは、v3がコードベースの簡素化と近代化を意味するため、大きな節目となりました。Martin Blaisは、v3をシステムをさらに「再整理し、簡素化する」機会として構想していました。当初は大規模な書き直しと考えられていましたが、実際にはユーザーにとってのアップデートはそれほど破壊的ではありませんでした。主な変更は_内部的_なものでした：新しいパーサー、いくつかのパフォーマンス改善、そしてオプションのコンポーネントのコアからの抽出です。リリースは段階的に行われました（v3は2022年からベータ版でしたが、2024年7月までに推奨される安定版となりました）。Siddhant Goelのようなユーザーは、2.xから3.xへの移行は「ほとんど何事もなく」、ワークフローの変更はわずかだったと報告しています。

• モジュール化 – ツールの別パッケージへの移動: Beancount 3の大きな変更点の一つは、かつてモノリシックなリポジトリにあった多くのツールがスピンオフされたことです。例えば、bean-queryは現在beanqueryパッケージによって提供され、beancount.ingestはbeangulpパッケージに置き換えられました。bean-extractやbean-identifyのようなコマンド（インポート用）は、コアのBeancountから削除されました。代わりに、インポートにはスタンドアロンのスクリプトを使用するという哲学です。これは、v3にアップグレードすると、中央のbean-extract設定ファイルを持つのではなく、beangulpをインストールし、インポータースクリプト（各インポーターは基本的に小さなプログラム）を実行することを意味します。同様に、クエリはbeanqueryを介して実行され、これはBeancountコアとは独立してインストールおよび更新できます。このモジュール化アプローチは、メンテナンスを容易にし、コミュニティの貢献を促進するために設計されました。また、Beancountのコアをスリム化し、コアが純粋に解析と会計ロジックに集中できるようにし、付随的な機能は別々に進化できるようにしました。ユーザーの観点からは、アップグレード後、コマンドを調整する必要があります（例えば、beanqueryからbean-queryを使用するか、これを抽象化してくれるFavaを使用するなど）。Favaの変更履歴はこれらの変更を明確に記述しています：Favaは現在beanqueryとbeangulpに依存しており、Beancount 3と2でインポートワークフローを異なる方法で処理します。

• パフォーマンスの向上: パフォーマンスは、Beancountの設計を再検討する動機の一つでした。v3計画（Martinの「V3の目標」ドキュメントに概説）には、パーサーの最適化と、おそらく読み込みプロセスをより速く、より少ないメモリ消費にするものが含まれていました。2025年までに、これらの改善の一部は実現しました。逸話的に、非常に大きな台帳（数万の取引、または多くの株式取引）を持つユーザーは、最新バージョンでパフォーマンスが向上したと報告しています。例えば、「マイクロ投資取引」を扱っていてパフォーマンス問題に直面していたユーザーがGoogle Groupでこれらの懸念を表明しました – この種のフィードバックがv3に影響を与えた可能性があります。新しいパーサーはより効率的で、より明確な方法で書かれており、将来的には拡張される可能性があります。さらに、Fava 1.29は、台帳が変更された際の応答性を向上させるために、より効率的なファイル監視メカニズム（watchfilesライブラリを使用）に移行しました。将来的には、コミュニティは大規模な台帳をより迅速に処理するために増分解析（すべてを再処理するのではなく、ファイルの変更部分のみを再処理する）を探求するかもしれません – これはドキュメントで「Beancountサーバー/増分記帳」のアイデアとして示唆されていました。

• 投資追跡機能の強化: 投資とポートフォリオのレポートを改善するための継続的な作業が行われています。例えば、平均取得原価法対FIFOの扱いは詳細に議論されました。Beancountはロットマッチングを強制しますが、一部のユーザーは特定の管轄区域で平均原価を好みます。原価計算の記帳をより柔軟にするための提案と議論が存在します（おそらくプラグインまたはオプションを介して）。2025年現在、平均原価への組み込みスイッチはありませんが、v3の基礎（記帳の再設計）により、プラグインが実装しやすくなっています。税金を最小限に抑えるためにどのロットを売却すべきかを提案できるコミュニティプラグイン「Gains Minimizer」がリリースされ、投資周りで構築されている高度なツールの種類を示しています。Favaも、ポートフォリオサマリー拡張機能（収益率計算付き）などの機能を追加しました。今後の機能としては、この領域でさらに多くのものが期待できます：おそらく自動化されたポートフォリオリバランシングの提案やリスク分析で、これらはBeancountデータを読み取る外部ツールとして提供される可能性が高いです（データはすべてそこにあるため）。

• 新しいプラグインと拡張機能: プラグインエコシステムは継続的に成長しています。最近の注目すべき追加には以下があります：

  • 予算報告ツール – FavaのUIを使用しない場合のためのシンプルなCLI予算レポーターなど。
  • 暗号化とセキュリティ – Favaをオンラインでホストし、台帳を保存時に暗号化できるfava-encryptセットアップが導入され、財務をセルフホストする懸念に対処しました。
  • 生活の質を向上させるプラグイン – autobean-format（ファイルを解析して再出力することで、より多くのコーナーケースを処理できる新しいフォーマッタ）や、エディタへのbeancheck統合（Emacsのflymake）など。

  将来的には、コミュニティはプラグインを通じてギャップを埋め続けるでしょう。例えば、より多くの税関連プラグインが見られるかもしれません（一部のユーザーはウォッシュセールの計算や特定の地方税レポートのようなもののためのスクリプトを共有しています）。

• 可能性のある今後の機能: イシュートラッカーやメーリングリストでの議論に基づくと、いくつかのアイデアが視野に入っています（保証されているわけではありません）：

  • 時間解像度: 現在、Beancountは取引の日付のみを追跡し、タイムスタンプはありません。時間（株式取引や同日取引の順序付けのため）を追加することについての質問がありました。Martin Blaisは、物事をシンプルに保つために、日以下のタイムスタンプはスコープ外であると明示的に決定しました。これはすぐには変わらないでしょう – したがって、今後のバージョンではおそらく時間解像度は追加されず、時間が必要な場合はナレーションや勘定に組み込むというスタンスを維持するでしょう。
  • GUI編集機能の強化: Favaは継続的に編集能力を向上させています。よりフル機能のWebエディタ（自動提案、おそらく新規取引のためのフォームベースのエントリー）の可能性があります。Favaのエディタでtree-sitterを使用する基礎は築かれました。Favaは単なるビューアではなく、より強力なエディタになり、多くのタスクでテキストエディタを開く必要性を減らすかもしれません。
  • より良い複数台帳サポート: 一部のユーザーは複数のBeancountファイルを維持しています（異なるエンティティ用、または個人用とビジネス用を分けるため）。現在、ファイルのインクルードは可能ですが、制限がありました（インクルードされたファイル内のプラグインなど）。最近、外部台帳を安全にインクルードするためのプラグインautobean.includeが作成されました。将来的には、複数ファイル設定の第一級サポートが見られるかもしれません – おそらく複数のファイルを持つBeancount「プロジェクト」の概念（これはVSCode拡張機能のbeancount.mainBeanFile設定のような機能によって示唆されています）。これは、複数エンティティの簿記を実行している人や、台帳をモジュール化したい人を助けるでしょう。
  • リアルタイムまたは増分計算: 台帳が大きくなるにつれて、レポートを迅速に再計算する能力が重要になります。実行し続け、取引が変更されると結果を更新するBeancountサーバーのアイデアがあります。これはFavaの最適化として、またはエディタプラグインがクエリできるデーモンとして現れるかもしれません。おそらく将来のFavaリリースでは、巨大な台帳に対してUIをよりレスポンシブにするために、継続的に実行されるBeancountプロセスを活用するでしょう。
  • ファンド会計 / 非営利団体の機能: Beancountでのファンド会計に関する機能強化提案がありました。非営利団体には（制限付き資金対非制限資金のような）会計ニーズがあり、これらはBeancountのタグや勘定階層でモデル化できる可能性があります。議論はまだ組み込み機能には至っていませんが、より多くの非営利団体がBeancountを採用すれば、これが新しい能力（おそらく文書化されたベストプラクティスやファンド残高追跡用のプラグイン）を推進するかもしれません。

• 長期的な展望: Martin Blaisは、Beancountの将来は、コアをよりエンジン的なものにし、より多くの機能をプラグインに移行させることにあると示唆しました。これは私たちが見ているもの（v3でのモジュール化）と一致しています。したがって、哲学的な意味での「今後の機能」はより大きな拡張性です – おそらくプラグインが新しいディレクティブタイプを定義したり、制御された方法で構文を拡張したりすることさえ可能にするかもしれません。そうなれば、Beancountのコアは比較的小さく安定したままで、エコシステムがほとんどの新機能をアドオンとして提供することになります。これにより、プラグインマーケットプレイスや、ユーザーが選べるようにプラグインのより中央集権的なリストが生まれるかもしれません（Awesome Beancountリストはその始まりです）。

結論として、2025年のBeancountエコシステムは活発で進化しています。Beancount 3.0のリリースは最近の大きな出来事であり、プロジェクトの基盤が将来にわたって堅固であることを保証しました。パフォーマンス、ツール、ユーザビリティ（特にFavaを介して）の改善は、参入障壁を下げ続けています。Beancountはある程度の専門知識を必要とするツールであり続けますが、これらの開発のおかげで、数年前よりもはるかにアクセスしやすくなっています。今後の機能は、コア哲学への抜本的な変更ではなく、体験の洗練 – より速いパフォーマンス、より良い統合、そして特殊な拡張機能 – に焦点を当てるでしょう。コミュニティの軌道は、Beancountがプレーンテキスト会計の中心として成熟し続け、複式簿記の厳格な力と現代のソフトウェアの利便性のバランスをとることを示唆しています。あるユーザーがHacker Newsで冗談めかして言ったように、プレーンテキスト会計はあなたの財務を理解する上で「超能力」を与えてくれます – そして、Beancountの最近および将来の改善は、それらの超能力を誰もがより簡単に使いこなせるようにすることを目指しています。

情報源: Beancountドキュメントおよびリポジトリ、Favaドキュメント、Martin Blaisによる「A Comparison of Beancount and Ledger」、Awesome Beancountリソースリスト、ユーザー体験およびコミュニティレポート

皆さん、こんにちは！本日のブログでは、シンプルさとパワフルさで多くの人に愛されている複式簿記ツール Beancount の世界に迫ります。特に、重要な概念である 売掛金 と 買掛金 の2つについて解説します。

これらの用語を正しく理解することは、Beancount（あるいは任意の複式簿記システム）を効果的に使う上で不可欠です。初心者の方でも安心してください。一つずつ丁寧に説明していきます。

売掛金と買掛金：基本​

会計において 「売掛金」 と 「買掛金」 は、金銭の債権・債務を管理するための用語です。

• 売掛金 は、他者が自分に対して支払うべき金額（受取債権）を指します。
• 買掛金 は、自分が他者に対して支払うべき金額（支払債務）を指します。

例を見てみましょう。

1. 売掛金（Accounts Receivable, A/R）：書店を経営していて、顧客がクレジットで本を購入したとします。その本代金は顧客から受け取るべき「売掛金」になります。
2. 買掛金（Accounts Payable, A/P）：逆に、出版社から新刊を仕入れたが、まだ支払っていない場合、その未払金は「買掛金」になります。

Beancount では、これらは対応する勘定科目で管理されます。これにより、任意の時点で自分の財務状況を正確に把握できるのです。

Beancount で売掛金・買掛金を設定する​

Beancount ファイルの構造は、シンプルでも複雑でも自由に設計できます。売掛金と買掛金を管理するには、資産（Assets） と 負債（Liabilities） の下にそれぞれ専用の勘定科目を作成すると良いでしょう。

1970-01-01 open Assets:AccountsReceivable
1970-01-01 open Liabilities:AccountsPayable

取引の記録​

売掛金側（受取側）​

勘定科目を作成したら、売掛金・買掛金に関わる取引を記録します。例を見てみましょう。

2023-05-29 * "Sold books to customer on credit"
  Assets:AccountsReceivable  100 USD
  Income:BookSales          -100 USD

この取引では、顧客が 100 USD をクレジットで購入したため、売掛金 が 100 USD 増加し、同時に 売上 が -100 USD（収益の減少）として記録されます。実際に現金が入ってきていないので、バランスが保たれます。

顧客が支払ったときは次のように記録します。

2023-06-01 * "Received payment from customer"
  Assets:Bank:Savings        100 USD
  Assets:AccountsReceivable -100 USD

ここでは、銀行口座 に 100 USD が増え、売掛金 が同額減少します。

買掛金側（支払側）​

買掛金も同様の原理ですが、符号が逆になります。

2023-05-30 * "Bought books from publisher on credit"
  Liabilities:AccountsPayable  200 USD
  Expenses:BookPurchases     -200 USD

出版社からクレジットで本を仕入れたため、買掛金 が 200 USD 増加し、同時に 経費 が -200 USD として記録されます。

支払いが完了したら次のように記録します。

2023-06-02 * "Paid off debt to publisher"
  Liabilities:AccountsPayable -200 USD
  Assets:Bank:Checking        200 USD

まとめ​

売掛金と買掛金は、あらゆる会計システムの核となる要素です。正確に追跡することで、財務状態を包括的に把握できます。

ここで紹介したのは出発点に過ぎません。Beancount はさらに高度な機能も備えています。本記事が概念の理解に役立ち、実務での活用の第一歩となれば幸いです。
それでは、楽しい会計ライフを！

本日のブログ記事では、ビジネス向けのBeancount元帳を分解し、このプレーンテキストの複式簿記システムの複雑さを理解できるようにします。

まずはコードから見ていきましょう：

1970-01-01 open Assets:Bank:Mercury
1970-01-01 open Assets:Crypto

1970-01-01 open Equity:Bank:Chase

1970-01-01 open Income:Stripe
1970-01-01 open Income:Crypto:ETH

1970-01-01 open Expenses:COGS
1970-01-01 open Expenses:COGS:Contabo
1970-01-01 open Expenses:COGS:AmazonWebServices

1970-01-01 open Expenses:BusinessExpenses
1970-01-01 open Expenses:BusinessExpenses:ChatGPT

2023-05-14 * "CONTABO.COM" "Mercury Checking ••1234"
  Expenses:COGS:Contabo                               17.49 USD
  Assets:Bank:Mercury                                -17.49 USD

2023-05-11 * "Amazon Web Services" "Mercury Checking ••1234"
  Expenses:COGS:AmazonWebServices                  14490.33 USD
  Assets:Bank:Mercury                             -14490.33 USD

2023-03-01 * "STRIPE" "Mercury Checking ••1234"
  Income:Stripe                                   -21230.75 USD
  Assets:Bank:Mercury                              21230.75 USD

2023-05-18 * "customer_182734" "0x5190E84918FD67706A9DFDb337d5744dF4EE5f3f"
  Assets:Crypto                                         -19 ETH {1,856.20 USD}
  Income:Crypto:ETH                                      19 ETH @@ 35267.8 USD

コードの理解​

1. 口座のオープン: コードは1970-01-01に一連の口座をオープンすることから始まります。これには資産口座（Assets:Bank:Mercury と Assets:Crypto）、資本口座（Equity:Bank:Chase）、収益口座（Income:Stripe と Income:Crypto:ETH）、および費用口座（Expenses:COGS、Expenses:COGS:AmazonWebServices、Expenses:BusinessExpenses、Expenses:BusinessExpenses:ChatGPT）が含まれます。

2. 取引: 次に、2023-03-01 から 2023-05-18 の間に行われた一連の取引を記録します。

   • 2023-05-14 の取引は、Mercury Checking ••1234 から CONTABO.COM へ $17.49 の支払いを表しています。これは費用（Expenses:COGS:Contabo）として記録され、Assets:Bank:Mercury 口座からの同額の減少が対応します。

   • 同様に、2023-05-11 の取引は、同じ銀行口座から Amazon Web Services へ $14490.33 の支払いを表しています。これは Expenses:COGS:AmazonWebServices に記録されます。

   • 2023-03-01 の取引は、STRIPE からの収入が Mercury Checking ••1234 に入金され、合計 $21230.75 となります。これは収入（Income:Stripe）として記録され、銀行口座（Assets:Bank:Mercury）に加算されます。

   • 最後の取引（2023-05-18）は、顧客からの 19 ETH の暗号通貨取引を表しています。これは Assets:Crypto と Income:Crypto:ETH に記録されます。{1,856.20 USD} は取引時点の ETH の価格を示し、@@ 35267.8 USD は 19 ETH の取引総額を示しています。

すべての取引において、複式簿記の原則が維持されており、Assets = Liabilities + Equity の等式が常に成立することが保証されています。

最後に​

この Beancount 元帳は、財務取引を追跡するためのシンプルでありながら堅牢なシステムを提供します。最後の取引で見られるように、Beancount は暗号通貨のような非伝統的資産も扱える柔軟性を持ち、デジタル化が進む金融環境における有用性を示しています。

この分解が、ベテランの会計士であれ、個人の財務管理を始めたばかりの初心者であれ、Beancount の構造と機能をより深く理解する手助けとなれば幸いです。次回のブログ記事では、さらに高度な Beancount の操作について掘り下げていきますので、お楽しみに。

例の勘定名​

Assets:US:BofA:Checking

勘定タイプ​

Assets          +
Liabilities     -
Income          -
Expenses        +
Equity          -

商品​

CNY, EUR, CAD, AUD
GOOG, AAPL, RBF1005
HOME_MAYST, AIRMILES
HOURS

ディレクティブ​

一般構文

YYYY-MM-DD <Directive> <Parameters...>

勘定の開設と閉鎖​

2001-05-29 open Expenses:Restaurant
2001-05-29 open Assets:Checking     USD,EUR  ; Currency constraints

2015-04-23 close Assets:Checking

商品の宣言（オプション）​

1998-07-22 commodity AAPL
  name: "Apple Computer Inc."

価格​

2015-04-30 price AAPL   125.15 CNY
2015-05-30 price AAPL   130.28 CNY

メモ​

2013-03-20 note Assets:Checking "Called to ask about rebate"

ドキュメント​

2013-03-20 document Assets:Checking "path/to/statement.pdf"

取引​

2015-05-30 * "Some narration about this transaction"
  Liabilities:CreditCard   -101.23 CNY
  Expenses:Restaurant       101.23 CNY

2015-05-30 ! "Cable Co" "Phone Bill" #tag ˆlink
  id: "TW378743437"               ; Meta-data
  Expenses:Home:Phone  87.45 CNY
  Assets:Checking                 ; You may leave one amount out

ポスティング​

  ...    123.45 USD                             Simple
  ...        10 GOOG {502.12 USD}               With per-unit cost
  ...        10 GOOG {{5021.20 USD}}            With total cost
  ...        10 GOOG {502.12 # 9.95 USD}        With both costs
  ...   1000.00 USD   @ 1.10 CAD                With per-unit price
  ...        10 GOOG {502.12 USD} @ 1.10 CAD    With cost & price
  ...        10 GOOG {502.12 USD, 2014-05-12}   With date
  ! ...   123.45 USD ...                        With flag

残高アサーションとパディング​

; Asserts the amount for only the given currency:
2015-06-01 balance Liabilities:CreditCard  -634.30 CNY

; Automatic insertion of transaction to fulfill the following assertion:
2015-06-01pad Assets:Checking Equity:Opening-Balances

イベント​

2015-06-01 event "location" "New York, USA"
2015-06-30 event "address" "123 May Street"

オプション​

option "title" "My Personal Ledger"

その他​

pushtag #trip-to-peru
...
poptag  #trip-to-peru
; Comments begin with a semi-colon

Discover the Magic of Plain Text Accounting with Beancount

Beancountで実現するプレーンテキスト会計の魔法を発見しよう

はじめに​

会計がもはや困難な作業でなくなる世界へようこそ。今回は、強力で柔軟、かつ直感的なプレーンテキスト会計ツール Beancount をご紹介します。Beancount は、財務を透明でシンプルに管理できるアプローチを提供し、あなたが資金をコントロールできるよう支援します。

本ガイドでは、Beancount の基本を解説し、コアコンセプトを説明し、シンプルでありながら強力な機能をご案内します。この記事を読み終える頃には、Beancount の全体像が把握でき、財務生活を整理・分析する準備が整っているはずです。

Beancount とは？​

Beancount は、Martin Blais が作成したオープンソースのプレーンテキスト会計システムです。John Wiegley の Ledger システムに触発され、個人や小規模事業の財務をプレーンテキストファイルで管理できる堅牢で信頼性の高い手法を提供します。Beancount を使えば、収入・支出・投資などを簡単に追跡できます。

なぜ Beancount なのか？​

プレーンテキスト会計は、従来のスプレッドシートや専用ソフトに比べて以下のような利点があります。

• 透明性：Beancount のファイルは人間が読める形式なので、財務データの理解や監査が容易です。
• 柔軟性：好きなテキストエディタやバージョン管理システムを使って、ニーズに合わせて自由にカスタマイズできます。
• ポータビリティ：デバイスを問わずアクセス可能で、システム間の移行や他者との共有も簡単です。
• 将来性：プレーンテキストは普遍的に互換性があるため、技術が変化してもデータは残ります。

Beancount のコアコンセプト​

Beancount を効果的に使うには、以下の概念を理解することが重要です。

• 取引 (Transactions)：収入、支出、口座間の振替など、財務イベントはすべて取引として記録されます。
• 勘定科目 (Accounts)：取引は資産、負債、収益、費用などの勘定科目に紐づきます。
• 複式簿記 (Double‑entry bookkeeping)：Beancount は複式簿記を強制し、すべての取引が借方と貸方でバランスします。
• ディレクティブ (Directives)：取引の定義や勘定科目のオープンなど、さまざまな財務イベントを指示するための構文です。

Beancount の始め方​

以下の手順で Beancount を使い始めましょう。

• Beancount をインストール：お使いの OS 向けインストール手順に従ってインストールします。
• Beancount ファイルを作成：拡張子 .beancount のテキストファイルを作ります（例：my_finances.beancount）。
• 勘定科目を定義：open ディレクティブで取引に使用する勘定科目を作成します。
• 取引を記録：txn ディレクティブで財務取引を記録します。

あるいは https://beancount.io にサインアップしてください。以下はプレーンテキスト会計の例です。

例 1：基本的な取引​

2023-04-01 open Assets:Checking
2023-04-01 open Expenses:Groceries

2023-04-10 txn "Grocery Store" "Buying groceries"
  Assets:Checking         -50.00 USD
  Expenses:Groceries       50.00 USD

この例では、Assets:Checking と Expenses:Groceries の 2 つの勘定科目をオープンしています。2023 年 4 月 10 日に、食料品購入（$50）を取引として記録し、`Assets:Checking` が$50 減少（借方）し、Expenses:Groceries が $50 増加（貸方）します。

例 2：収入と支出の取引​

2023-04-01 open Assets:Checking
2023-04-01 open Income:Salary
2023-04-01 open Expenses:Rent

2023-04-05 txn "Employer" "Salary payment"
  Assets:Checking       2000.00 USD
  Income:Salary        -2000.00 USD

2023-04-06 txn "Landlord" "Monthly rent payment"
  Assets:Checking       -1000.00 USD
  Expenses:Rent          1000.00 USD

この例では、Assets:Checking、Income:Salary、Expenses:Rent の 3 つの勘定科目をオープンしています。4 月 5 日に給与 $2,000 を記録し、`Assets:Checking` が$2,000 増加（貸方）し、Income:Salary が $2,000 減少（借方）します。4 月 6 日に家賃$1,000 を支払い、Assets:Checking が $1,000 減少（借方）し、`Expenses:Rent` が$1,000 増加（貸方）します。

例 3：口座間の振替​

2023-04-01 open Assets:Checking
2023-04-01 open Assets:Savings

2023-04-15 txn "Bank" "Transfer from Checking to Savings"
  Assets:Checking       -500.00 USD
  Assets:Savings         500.00 USD

この例では、Assets:Checking と Assets:Savings の 2 つの勘定科目をオープンしています。4 月 15 日に、チェック口座から貯蓄口座へ $500 を振替える取引を記録し、`Assets:Checking` が$500 減少（借方）し、Assets:Savings が $500 増加（貸方）します。

これらの例は、Beancount の複式簿記システムの基本概念を示しています。取引を正しく記録することで、財務活動の正確な記録を保ち、レポートを生成して財務状況を把握できます。

レポートの生成とデータ分析​

Beancount には、バランスシートや損益計算書などの財務レポートを生成する強力なツールが同梱されています。また、Web ベースの UI である Fava を使えば、財務データを視覚化・操作できます。https://beancount.io は MIT ライセンスの下、Fava をベースに構築されています。

結論​

Beancount でプレーンテキスト会計の力とシンプルさを体感してください。コアコンセプトを理解し、本ガイドの手順に従えば、個人や小規模事業の財務管理を容易かつ正確に行えるようになります。Beancount に慣れたら、さらに高度な機能やカスタマイズを探求し、独自のニーズに合わせたシステムを構築できます。

支出の追跡、将来の計画、財務習慣の洞察など、何を目指すにせよ、Beancount は柔軟性と透明性を提供し、目標達成をサポートします。その使いやすさから、Beancount は財務管理の在り方を変革し、あなたが財務の未来をコントロールできるようになるでしょう。

さあ、プレーンテキスト会計の旅に出発しましょう。煩雑なスプレッドシートや複雑なソフトウェアにさようならを告げ、Beancount の世界へようこそ。楽しい会計ライフを！

現代の簿記が重要な理由​

まだスプレッドシートで投資を管理していますか？スプレッドシートは汎用性がありますが、投資ポートフォリオが拡大するにつれて扱いにくくなり、ミスが起きやすくなります。そこで登場するのが Beancount.io です。エンジニアと金融ミニマリストを念頭に置いて設計された、株式や暗号通貨ポートフォリオの管理に特化した洗練されたが使いやすい投資トラッキングプラットフォームです。強力な機能と直感的なインターフェースを組み合わせ、投資トラッキング体験を効率化します。

複式簿記：正確性の基盤​

Beancount.io は、世界中の金融機関で採用されている実績のある複式簿記の原則に基づいて構築されています。このシステムは、シンプルでありながら強力な概念――すべての金融取引は完全にバランスしなければならない――を通じて数式的な正確性を保証します。

複式簿記では、各取引は少なくとも二つのエントリ――借方（+）と貸方（-）――を異なる勘定科目に記録します。この組み込みの検証システムにより、バランスが取れない取引を記録することは事実上不可能となり、財務記録の正確性と信頼性が保たれます。

1970-01-01 open Income:BeancountCorp
1970-01-01 open Assets:Cash
1970-01-01 open Expenses:Food
1970-01-01 open Assets:Receivables:Alice
1970-01-01 open Assets:Receivables:Bob
1970-01-01 open Assets:Receivables:Charlie
1970-01-01 open Liabilities:CreditCard

2019-05-31 * "BeancountCorp" "Salary of May 15th to May 31st"
  Income:BeancountCorp               -888 USD
  Assets:Cash                         888 USD

2019-07-12 * "Popeyes chicken sandwiches" "dinner with Alice, Bob, and Charlie"
  Expenses:Food 20 USD
  Assets:Receivables:Alice 20 USD
  Assets:Receivables:Bob 20 USD
  Assets:Receivables:Charlie 20 USD
  Liabilities:CreditCard -80 USD

上記二つの例から分かるように、すべての取引は会計等式を満たす必要があります。

Assets = Liabilities + Equity(aka Net Assets)

Beancount の構文（Martin Blais）と、Jakob Schnitzer が開発した Web プロジェクト Fava を使用してこのサイトを構築しています。取引のいずれかの足がゼロに合計されていない場合は、即座に警告が表示されます。

これで台帳の正確性をどのように保証しているかが分かりますね。では「勘定科目」とは何でしょうか？

勘定科目の理解：水バケツのたとえ​

財務勘定科目を相互に接続された水バケツのシステムと考えてみてください。お金はバケツ間を水のように流れます。このたとえにより、複式簿記が直感的に理解できます：ある勘定科目から別の勘定科目へ資金を移すことは、バケツからバケツへ水を注ぐことと同じで、システム全体の水量（資金）は一定のままです。

Beancount.io では以下の5種類の勘定科目が用意されています。

1. Income — 金額は常に負（借方）です。収入が発生すると「Income」勘定が借方に記録され、資産勘定にクレジットされます。
2. Expenses — 金額は常に正（貸方）です。支出が発生すると資産または負債から「Expenses」勘定へ資金が流れます。
3. Liabilities — 金額は正またはゼロです。クレジットカードの残高など、増減がサイクルする負債が該当します。
4. Assets — 金額は正またはゼロです。現金や不動産など、所有する資産の価値がここに記録されます。
5. Equity — 純資産です。システムが自動的に計算します。Equity = Assets - Liabilities で、あなたの富の程度を表します。

上記キーワードでカスタマイズした勘定科目を開設できます。

1970-01-01 open Assets:Cash
1970-01-01 open Assets:Stock:Robinhood
1970-01-01 open Assets:Crypto:Coinbase
1970-01-01 open Expenses:Transportation:Taxi
1970-01-01 open Equity:OpeningBalance

商品を使った高度な投資トラッキング​

Beancount.io は株式から暗号通貨まで、さまざまな投資を正確に追跡できます。複雑な投資シナリオの例を見てみましょう。たとえば、2014 年に 1 ビットコイン 100 USD で 10 ビットコインを購入した場合は次のように記録します。

2014-08-08 * "Buy 10 Bitcoin"
  Assets:Trade:Cash -1000.00 USD
  Assets:Trade:Positions  10 BTC {100.00 USD}

そして 3 年後にそれらを 1 ビットコインあたり 10,000 USD の価格で売却した場合は次のように記録します（@ 10,000.00 USD が単価を示します）。

2017-12-12 * "Sell 2 Bitcoin"
  Assets:Trade:Positions                   -2 BTC {100.00 USD} @ 10,000.00 USD
  Assets:Trade:Cash                          20,000.00 USD
  Income:Trade:PnL                          -19,800.00 USD

同じ取引を @@ 20,000.00 USD と書くと、合計 20,000 USD の価格で売却したことを意味します。

2017-12-12 * "Sell 2 Bitcoin"
  Assets:Trade:Positions                   -2 BTC {100.00 USD} @@ 20,000.00 USD
  Assets:Trade:Cash                          20,000.00 USD
  Income:Trade:PnL                          -19,800.00 USD

取引のすべての足（-2 BTC {100.00 USD} を含む）は常にゼロに合計されます。

{100.00 USD} のコストタグは重要です。なぜなら、同じ商品でも取得価格が異なる場合があるからです。

100 BTC {10.00 USD, 2012-08-08}
10 BTC {100.00 USD, 2014-08-08}

プロセスを簡略化したい場合は、勘定科目を FIFO または LIFO で開設できます。FIFO は「先入れ先出し」、LIFO は「後入れ先出し」を意味します。米国では IRS が FIFO を使用して損益と税金を計算します。

1970-01-01 open Assets:Trade:Positions "FIFO"

その後、-2 BTC {} のように省略形で売却指示を出すと、Beancount が自動的に FIFO 戦略を適用し、最も古い商品を売却します。

Beancount.io の始め方​

Beancount.io は、テキストベースの取引記録を包括的な財務諸表（損益計算書、貸借対照表、試算表）に変換するモダンなクラウド型金融管理プラットフォームです。プレーンテキストファイルの信頼性と強力な可視化ツールを組み合わせることで、財務生活を正確にコントロールしながら、投資パフォーマンスに関する貴重なインサイトを得られます。

Beancount.io で金融の旅を始めましょう ― プロモーション期間中は無料！