Beancount FAQ: プレーンテキスト会計に関する質問

必要なのは学位ではなく、約5つの概念です。5つの勘定科目タイプ（資産、負債、資本、収益、費用）、すべての取引が少なくともそのうちの2つ以上の間で価値を移動させるという考え方、そして取引が釣り合わなければならないというルールが必要です。Beancountは残りをすべて強制します — 数値が合わない取引を黙って受け入れる代わりにエラーとしてフラグを立てるので、ソフトウェアが初心者が見逃しがちな間違いを検出します。

Beancount入門から始め、用語集をタブで開いておき、クイックスタートで最初の取引を追加してください。

Beancountは「借方」や「貸方」という言葉をまったく使いません — 合計がゼロになる符号付き数値を使用します。アカウントから出ていくお金は負、入ってくるお金は正、そして仕訳が相殺されたときに取引は有効になります。これは会計士が行う複式簿記と同じもので、初心者を混乱させる用語を取り除いたものです。

従来の会計ソフトウェアを使ったことがある場合、変換は次のとおりです：借方とは正の数値であり、貸方とは負の数値です。仕訳の書き方については言語構文リファレンスを、平易な英語での会計の背景については借方と貸方の説明をご覧ください。

なぜなら、お金は常にどこかから来るものであり、ゼロサムこそがその事実をエラーチェックに変えるからです。食料品に40ドル使った場合、そのお金は銀行口座から出ていきました — 両方の半分を記録するということは、2つが相殺されなければならないということであり、どちらかの金額の入力ミスは、静かに間違った残高を生み出す代わりにエラーとしてフラグが立てられます。

これが、プレーンテキストの元帳が支出のスプレッドシートよりも信頼できる理由です：構造自体が自己検証的です。残高検証は、元帳を現実と照合する関連メカニズムです。

開始日に、各口座の現在の残高をEquity:Opening-Balancesから移動させる取引を記録し、それを確定させるためにbalance検証を追加します。財務履歴を再構築する必要はありません — 開始日を選び、その日の残高をそのまま受け入れ、そこから先に進みます。

クイックスタートでは、完全な期首残高の例を説明しています。

大まかに始めて、より細かい区分が意思決定を変える場合にのみ分割してください。約20の勘定科目で始めるには十分です。「Expenses:Food」が食料品とレストランを分けるべきかどうか迷った場合、有用なテストは、その区分を知ったことで実際に何か異なる行動を取るかどうかです。

後で名前を変更したり分割したりするのはテキストファイルでの検索と置換なので、シンプルに始めるコストは低いです。勘定科目名は入れ子になるため、広いカテゴリから始めて後でサブ勘定科目に分割しても履歴を書き換える必要はありません — 構造をコピーしたい場合は勘定科目表の設計方法をご覧ください。

スプレッドシートは、自分が間違っているときにそれを知らせてくれません。プレーンテキスト会計は複式簿記を強制するため、すべての取引が自己検証され、ファイルはテキストファイルが存在する限りgrep可能、diff可能、スクリプト可能であり続けます。また、本当のバージョン履歴も得られます：元帳に対するgit logは、何がいつなぜ変更されたかを正確に示します。

実際的な違いは、複数の口座、通貨、または投資がある場合に現れます。単式のスプレッドシートは静かに真実から逸脱していきます。透明で監査可能な会計をご覧ください。

コーヒーにいくら使ったかだけを知りたいなら、はい — スプレッドシートで十分です。複式簿記がその価値を発揮するのは、複数の口座、住宅ローン、証券口座、または複数の通貨を持った瞬間です。なぜなら、それらはまさに単式追跡があなたに知らせずにお金を失う状況だからです。

有用な考え方：複式簿記は財務のチェックサムです。より長い議論は入門をご覧ください。

いいえ。Favaは同じテキストファイル上の完全なウェブインターフェースです — 貸借対照表、損益計算書、チャート、取引入力 — そしてBeancount.ioはあなたの元帳をクラウドで実行します。テキストファイルは依然として信頼できる情報源であり、日常的にはウェブUIを使用し、必要なときだけターミナルに降りることができます。 ターミナルを好む場合は、bea コマンドラインが同じファイルの作成、チェック、レポートを行います — CLIクイックスタート を参照してください。

インターフェースでできることについてはUI機能をご覧になるか、ライブデモをお試しください。

ほとんどの人は取引の80〜95%をインポートし、残りを手入力します。信頼性の高い順に：銀行からの直接のOFX/QFXダウンロード、CSVエクスポートとインポートルール、アグリゲーター接続、そして — 最後の手段としてのみ — CSVに変換されたPDF明細書。Beancount.ioの銀行同期が接続とカテゴリ分類を処理します。

機関ごとにルールを作成または調整することを想定してください：銀行のCSVエクスポートは有名なほど一貫性がなく、エスケープされていないカンマを含む加盟店名は実際にありがちな一般的な問題です。自動化されたパスについてはスマートインポートをご覧ください。

一回限りのファイルについては、2つの無料ブラウザコンバーターが何もアップロードせずに機械的な部分を処理します：スプレッドシートエクスポート用のCSV to Beancount、そして銀行がCSVを一切提供しない場合の.ofx、.qfx、.qbo、.qifダウンロード用のOFX & QIF to Beancountです。

インポーターは、元帳にすでにあるエントリに対して重複排除し、日付、金額、受取人で照合し、あいまいなものは推測せずに確認用にフラグを立てます。通常のワークフローでは、不確かなインポートを保留としてマークし、恒久的な記録の一部になる前にレビューします。

OFXはこれをCSVよりも簡単にします：すべての取引には銀行がダウンロード間で安定して維持するFITIDが含まれており、インポーターは推論ではなくIDで照合できます — OFXコンバーターはこれをid:メタデータフィールドとして保持します。

答えのもう半分は振替です：自分が所有する2つの口座間でのお金の移動は両方の銀行のエクスポートに表示されます。2つの仕訳を持つ単一の取引として一度だけ記録してください。

いいえ — そして多くの人にとって、これこそがプレーンテキスト会計を使う理由です。あなた自身で銀行からOFXまたはCSVをエクスポートでき、アグリゲーターに資格情報を渡す必要はありません。自動同期を好む場合は、Beancount.ioはオンラインバンキングのパスワードを保存するのではなく、銀行公認のアグリゲーターを使用します。

詳細はセキュリティページをご覧ください。

明細書の締め日の翌日の日付で、締め値に対するbalance検証を追加します。残高検証はその日の開始時に評価されるため、翌朝の検証には最後の明細日までのすべての取引が含まれます。元帳が銀行と一致しない場合、bea checkはBalance failedエラーを報告し、非ゼロで終了します。これにより、照合作業は手動比較から、ソフトウェアが実行するたびにチェックするものに変わります。

月次サイクルでほとんどの人には十分です。差異の追跡についてはフィルタリングと検索をご覧ください。

ネイティブに処理し、これは消費者向け金融アプリに対する最も強い利点の1つです。すべての金額は通貨を保持し、口座は同時に複数の通貨を保有でき、変換は@（価格）または{}（コスト）で明示的に記録されるため、為替レートの変動があなたの履歴を黙って書き換えることはありません。

何も背後で変換されません — 元の通貨と変換された値の両方が常に表示されます。言語構文、精度と許容差、そして簿記側については複数通貨会計をご覧ください。

購入を波括弧でコストを付けて記録します — 10 AAPL {150.00 USD} — するとBeancountが各ロットを個別に追跡します。売却時には、どのロットを減らすかを指定し、キャピタルゲインは手計算ではなく自動的に算術から導き出されます。

BeancountはSTRICT、FIFO、LIFO、NONEのブッキングメソッドをサポートしています。平均原価法のブッキングは解析されますが完全には実装されていません — 税務管轄で平均原価が必要な場合は、プラグインまたは明示的なロットで追跡する計画を立ててください。在庫管理をご覧ください。

他のコモディティとまったく同じです：暗号通貨はコストを持つ単位であり、同じロットとブッキングの仕組みが適用されます。あるトークンと別のトークンの交換は、1つのロットを減らし別のロットを開く単一の取引であり、これがほとんどの税務当局が報告を求める実現損益を得る方法でもあります。

暗号通貨ポートフォリオ追跡と既成の暗号テンプレートをご覧ください。

ビジネスでも使用されています。数十万件の取引を持つ企業を含みます。発生主義会計、複数エンティティ構造、会計士が期待するレポートを処理できます。正直な限界は、マルチユーザー同時編集、組み込みの請求書UI、買掛金の承認ワークフローがないことです — これは元帳であり、ERPではありません。

業種別セットアップと実際の会社の帳簿を示すオープン元帳をご覧ください。

分けてください — 1つのファイル内の別々のトップレベル勘定科目ツリーとして、またはincludeで結合された2つのファイルとして。混在させるとビジネスの損益計算書が意味をなさなくなり、確定申告の時期が難しくなります。分離は初期コストがゼロです。

ビジネスが独自の銀行口座を持ったら、通常は2つのファイルの方がきれいです。マルチファイルサポートをご覧ください。

売掛金を資産勘定科目として、買掛金を負債としてモデル化し、請求書を発行したときに記録し、支払いが到着したときに記録します — これは発生主義会計であり、Beancountはそれを直接サポートしています。しかし、請求書インターフェースはありません：あなたが支払われるべき金額を追跡しますが、請求書を生成または送信しません。

レポート面については財務報告テンプレート、実際の例については業種別セットアップ、概念については売掛金の理解をご覧ください。

元帳ではなくレポートをエクスポートしてください。会計士はほぼ間違いなくテキストファイルを望んでいません — 彼らが望むのは損益計算書、貸借対照表、取引リストであり、これはウェブインターフェースまたはクエリからCSVまたはPDFで生成できます。

税金申告ガイド、財務報告テンプレート、そして彼らが求める正確な数値を引き出すためのSQLによるクエリをご覧ください。

3つすべてが同様のファイル形式を持つプレーンテキスト複式簿記システムです。Ledgerはオリジナルで最も寛容なパーサーです。hledgerはフレンドリーなCSVインポートルールとドキュメントで知られるHaskellの再実装です。Beancountは最も厳格なパーサーと、投資、ロット、複数通貨に対する最も強力なサポート、そしてPythonプラグインAPIを備えています。

厳格さが本当のトレードオフです：Beancountはあいまいだと判断したファイルの読み込みを拒否し、初期のエラーを検出しますが、その代償としてよりうるさいです。Beancount vs Ledger CLIとBeancount vs hledgerをご覧ください。

ネイティブではありません — これは隠れた機能ではなく、実際のギャップです。Beancountの組み込み予算機能は限られており、厳格なエンベロープ動作を求める人々は通常、コミュニティプラグインを使用するか、エンベロープを勘定科目としてモデル化します。

エンベロープ予算が主な目的なら、切り替える前にBeancount vs YNABをお読みください。現在機能するものについては、Beancountでの予算管理をご覧ください。

はい。documentディレクティブはファイルを勘定科目と日付にリンクし、ウェブインターフェースでは関連する取引と一緒にそれらのドキュメントをアップロードして閲覧できます。レシートはディスク上の通常のファイルとして残るため、元帳自体と同じくらいポータブルです。

UI機能をご覧ください。

はい — Beancount.ioは元帳の閲覧と移動中の取引捕捉のためのiOSおよびAndroidアプリを公開しています。これはほとんどのプレーンテキストセットアップが開いたままにしておくギャップです。

アプリなしでの簡単な捕捉には、多くの人が大まかなメモを記録し、後で元帳に照合します。

10年分の個人財務は数メガバイトで、1秒未満で読み込まれます。Beancountは各読み込みで完全な取引履歴から残高を再計算し、それは数十万エントリまで高速のままです。それを超えると限界は読み込み時間ではなく、編集と差分の快適さです：includeによる年分割は個々のファイルを小さく保ちますが、含まれるファイルは依然としてBeancountが完全に読み込んで再計算する1つの結合された元帳を形成するため、これはファイル整理の利便性であり、速度向上や別々の帳簿を維持する方法ではありません。

成長する元帳の分割方法についてはマルチファイルサポートをご覧ください。