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が 付いているので、インポーターは推測ではなく同一性で照合できます — OFXコンバーターはそれをid:メタデータフィールドとして保存します。

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

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

詳細はセキュリティページをお読みください。

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

ほとんどの人には月次の頻度で十分です。不一致の追跡については フィルタリングと検索をご覧ください。

ネイティブに扱います。そしてこれは消費者向けファイナンスアプリに対する最大の利点の1つです。 すべての金額はその通貨を伴い、口座は同時に複数を持つことができ、換算は 価格には@、取得原価には{}を使って明示的に記録されるので、 為替レートの変動があなたの履歴を静かに書き換えることはありません。

背後で何かが変換されることはありません — 常に元の通貨と換算後の価値の両方が見えます。 言語構文、精度と許容範囲、 および簿記側の話についてはマルチカレンシー会計 をご覧ください。

ホスト型のBeancount.io台帳で対応資産にはライブ価格を使うか、 アップストリームのBeancountとFava用にローカルの価格ファイルへクォートを取得します。 ピッカーではクォート通貨を選び、管理されたインクルードをコピーできます。互換性のあるbeaバージョンも 管理されたインクルードに対応しています。セットアップガイドにその手順へのリンクがあります。

管理された価格は市場評価に影響し、取引金額や取得原価には影響しません。 同じ日付と通貨ペアについてはあなた自身の価格が優先されます。更新は障害時に 古いキャッシュされた価格を使用することがあり、後のクォートが欠落した過去の評価日を埋めることはできません。

購入を波括弧内の取得原価で記録します — 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はHaskellによる再実装で、親しみやすい CSVインポートルールとドキュメントで知られています。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は 読み込みのたびに完全な取引履歴から残高を再計算し、それは数十万件のエントリまで高速なままです。 それを超えると限界は読み込み時間ではなく編集とdiffの快適さです：includeで年ごとに分割すれば 個々のファイルは小さく保てますが、インクルードされたファイルは依然としてBeancountが全体を読み込み 再計算する1つの結合された台帳を形成するので、それはファイル整理の利便性であり、高速化でも 別々の帳簿を保つ方法でもありません。

増え続ける台帳の分割方法についてはマルチファイル対応をご覧ください。