プレーンテキスト会計（Plain Text Accounting, PTA）
(plaintextaccounting.org)- Plain Text Accounting（PTA） は、プレーンテキストファイルに会計データを記録し、Ledger、hledger、Beancount のようなコマンドライン志向のツールで処理する方式であり、このサイトは関連資料を一か所に集めたポータル
- コミュニティ活動は Matrix/IRC、フォーラム、Reddit、Lemmy、Hacker News、Mastodon、X、Bluesky などに分かれており、質問・ニュース・プロジェクト別の会話を複数の経路で追うことができる
- 学習資料は、アプリ比較、公式ドキュメント、会計の基礎、入門書、チートシート、クックブック、FAQ、スライド、動画として整理されており、PTA を初めて使う人でも段階的に取り組める
- アプリのエコシステムは Ledger、Beancount、hledger を中心に複数の実装と機能マトリクスを提供しており、代表的な 3 つのツールはそれぞれ C++/Python/Haskell ベースで、2025〜2026 年のリリース記録がある
- インポート・変換、エディタープラグイン、請求書、価格取得、レポーティング、時間記録、UI、ワークフロー、ライブラリまでつながっており、プレーンテキスト会計データをさまざまな作業環境に組み込める
PTA の概念と plaintextaccounting.org の役割
- Plain Text Accounting は、プレーンテキストファイルと Ledger、hledger、Beancount のような効率的でコマンドライン志向のソフトウェアを使って簿記と会計を行う方式
- plaintextaccounting.org は PTA コミュニティの ツール、ドキュメント、実践例 へのポータルの役割を果たす
- サイトのリポジトリアップデートを受け取ることができ、財務レポートと支援案内もあわせて提供される
コミュニティと議論チャンネル
- リアルタイム会話は Matrix の
#plaintextaccounting、plaintextaccounting Matrix space、Libera Chat の#plaintextaccountingIRC チャンネルへとつながっている - 議論とニュースは複数の公開チャンネルに分散している
- PTA forum
- /r/plaintextaccounting
- lemmy.world/c/plaintextaccounting
- Hacker News の plain text accounting 関連 stories/comments 検索
- Mastodon の
#plaintextaccounting、#ledgercli、#hledger、#beancount - Twitter/X、Bluesky の検索とハッシュタグ
- Stack Exchange では
ledger-cliとhledgerのタグおよび検索リンクが提供されている - プロジェクト別メーリングリストとチャット、
This Week In Hledgerもリンクされている
ドキュメントと学習資料
- アプリ比較 資料には、PTA アプリ一覧、機能マトリクス、「どの PTA アプリを選ぶべきか」という FAQ、Syntax Quick Reference が含まれる
- アプリ公式ドキュメントとして Ledger、hledger、Beancount、rustledger、Ledger(Go)、Tackler、pta のドキュメントがリンクされている
- 会計の基礎 資料には、PTA FAQ、hledger の Accounting basics/links、Beancount の Double-Entry Counting Method、「Accounting for Computer Scientists」などが含まれる
- 入門資料は出発点ごとに分かれている
- チートシート、クックブック、FAQ、スライド、動画資料も別セクションとして整理されており、動画セクションには YouTube で PTA 動画を見つけにくいというメモがある
主要 PTA アプリと機能比較
- PTA を始める際には、サイトに列挙されたアプリのうち 1 つ以上を試すことができ、一般的にアプリ間での データ移行 が可能
- 現在の主要アプリ一覧には複数のプロジェクトがまとめられている
- 過去または非アクティブなプロジェクトは、placc、budget-cli、mynt、awk-pta、pta、blossom、.Net Ledger、monescript、Penny、UMM、cl-ledger などとして別に整理されている
- Ledger、hledger、Beancount の 機能マトリクス は 2024-09 時点で更新されており、ユーザーインターフェース・インストール・ヘルプ・入出力形式・コマンド・設定・拡張性・勘定科目名・予算・チャート・価格取得・クエリ・検証などを比較している
- 代表的な違いは、ツール選定にすぐ影響する項目に集中している
- CLI は Ledger の
ledger、hledger のhledger、Beancount のbeanqueryがリンクされている - 容易なインストールと設定は Ledger/hledger では
yes、Beancount ではnoと表示される - hledger は text/html/csv/tsv/fods/beancount/sql/json の出力形式を提供する
- Beancount の検証は常に厳格と表示され、Ledger と hledger は設定可能とされている
- CLI は Ledger の
ソフトウェアエコシステム
- AI セクションには、hledger を使うローカルファーストのマルチモデル AI エージェント
accountant24、hledger と Obsidian vault で Claude Code をエージェント層として使う設定記事が含まれる - 代替ディストリビューション・設定として Full-fledged hledger、hledger-flow、Lazy Beancount、hledger-youtube-business、rtrLEDGER、docker-finance が整理されている
- データ変換・インポート は大きな比重を占め、Ledger と hledger の組み込み CSV 変換のほか、Beancount v2 の import ツール、
banks2ledger、beancount-import、beancount2ledger、hledger2beancount、ledger2beancount、plaid2textなどが列挙されている- GnuCash、Intuit/QuickBooks/QIF、KMyMoney、YNAB から *ledger または Beancount へ移行するツールも別のサブセクションに整理されている
- データ生成ツールは、価格トランザクション、減価償却、利息、定期取引、キャピタルゲイン／ロス postings などを作る作業に使われる
- エディタープラグインは Emacs、JetBrains IDE、Nano、Sublime、TextMate、Vim、VS Code 向けに分かれている
- 例:
ledger-mode、beancount-mode、hledger-mode、vim-ledger、vim-beancount、hledger-vscode、vscode-beancount
- 例:
- フォーマットツールとして
beancount-black、beancount-black web app、hledger-fmtが列挙されている - 請求書ツールとしては、hledger timedot ファイルから請求書を生成する Go ツール
kairosが紹介されている
UI、レポーティング、ワークフロー、ライブラリ
- 価格取得 ツールには、Beancount の
bean-price、hledger-stockquotes、ledger-get-prices、pricehist、Yahoo Finance ベースの株価・為替取得ツールなどが含まれる - レポーティングツールは、予算、資産分析、差分レポート、内部収益率、チャート、Sankey、PDF 出力、キャピタルゲイン計算などへ広がっている
- 時間記録ツールは、org、Taskwarrior hook、Toggl CSV、timeclock 変換および hledger ベースの時間記録例を含む
- ターミナル UI は
hledger add、hledger-ui、hledger-iadd、bean-add、ledger xact、puffin、regdelなどにより取引の入力・照会・編集を支援する - GUI、Web、モバイル UI も個別ツールとしてリンクされている
- Web: fava、hledger-web、Paisa、BeanHub
- モバイル: Beancount Mobile CE、beancount-mobile、NanoLedger、cashier、cone、MoLe
- GUI: fruit-credits、Ledgera、Prudent、Surebeans など
- ワークフローセクションでは、CSV から hledger journal を生成したり、Docker ベースで伝統的金融・暗号資産の財務を追跡・レポートしたりする構成を扱う
- ライブラリセクションには、Beancount パーサー、BeanHub API、hledger-lib、hledger-web JSON API、node-hledger、pyhledger など、PTA ファイルをパース・照会・レポート・連携するための開発用コンポーネントがまとめられている
1件のコメント
Hacker Newsの意見
即時の厳密な分類を求めるシステムは、人によっては合わない。以前働いていた会社では、まず iPhoneのメモに
-50 Alice tools、+20 Bob returned loanのように短く書き、あとでスクリプトが日付・キーワード・相手・内部分析項目をパースして複式簿記のテンプレートに変換する2段階方式を使っていたスクリプトが解釈できなかった項目は手動で分類し、必要ならルール一覧に追加していた。また、Alice と Bob が同じ語彙を合わせる必要がないように、人ごとの対応表も用意していた
お金が動くたびに、列に並んでいたり運転中だったり会話中だったりする人が
Cat1:cat2:cat3のような形式を毎回埋めるとは想像しにくい。結局また短いメモやチャットに戻るか、1日の終わりではなくおそらく週末に「思い出して」埋めようとする可能性が高いテキストベースのツールなら、iPhoneのメモを受け取って ledger 形式に変換するスクリプトをつなぐなど、望むワークフローを自由に作れるので、不満として見るのは少し不思議に感じる
四半期ごとに銀行口座、クレジットカード、Zoho から CSV をダウンロードし、Ruby スクリプトがメモ欄を見て ledger ファイルに変換する。スクリプトと結果は少しずつ手直しが必要だが、95% 以上は自動化されている
おまけに、銀行から受け取った残高と一致するか、項目が現在期間内にあるかといった 整合性チェック も ledger ファイルに追加している
自営業を始めた瞬間からほぼ20年間 ledger-cli を使ってきたが、完璧ではないにせよ非常に満足している。すべてがプレーンテキストなのでスクリプトで処理でき、VIM で読めて、データも簡単に取り出せる
現在運営中の会社の1つの ledger ファイルは、2016年以降の取引を含む 2MB のプレーンテキストだ。勘定科目や分類を非常に細かくすることには大きな価値を感じなかったが、全体を追跡するにはなくてはならない道具だった
ledger のようなツールが使う 複式簿記 を学ぶのも楽しく、振り返れば難しくはなく、一生役立つ技能のように感じる
勘定科目・分類戦略としては、カナダ歳入庁が税務申告書で求める費用分類に合わせる方法を使っている。最初はホスティング費用、試作・製造費用のような論理的分類を作っていたが、数年間 CRA 分類に再マッピングしていくうちに、最初から税務分類に合わせておくほうが年末申告をずっと簡単にすると気づいた
データが SQLite ならはるかに簡単に実装できただろうが、そうするとテキストエディタで直接修正する利点は失われる
LLM のおかげで、プレーンテキスト会計を継続するのがずっと楽になった。特に銀行明細を hledger に取り込む際、手入力を避けるのに役立っている
銀行取引を hledger の勘定科目にマッピングする JSON ファイルを使っていて、新しいマッピングのない取引があると Python スクリプトが Claude 用のプロンプトを生成する。Claude は勘定科目一覧を見て新規取引のマッピングを提案し、それに基づいて hledger の仕訳を返す
その後、別のスクリプトがその月の銀行取引の hledger 仕訳をきれいに出力し、数分手直しして確定する。以前なら脆い正規表現と条件分岐の塊になっていたはずのマッピング指示も、自然言語 で書ける
Beancount を使いながら学ぶ過程、データ取り込みツールを書くこと、会計を自分で触る体験を楽しんだ。ただ、最後にデータを取り込んでからほぼ1年が経っていて、毎月やろうと思っていても、自動化がかなり進んでいてさえ 30〜60分かかるので面倒だ
モバイル確認まで必要になって、結局あきらめた
自分も取り込みをしなくなって1年ほど経っていて、復活させるには数日に分けて1か月分ずつ上げていくように細かく区切る方法しか思いつかない
https://plaid.com/
個人と複数の LLC の記帳・会計に ledger を使っている。ターミナルに慣れていて CLI を使いこなし、vim や emacs、sed/awk の基本、bash/python/perl/ruby でのスクリプティングをよくするなら、ledger と 複式簿記 を学んで移行したほうが、今のやり方よりずっと満足できる可能性が高い
取引をすばやく取り込むには reckon が便利: https://github.com/cantino/reckon
includeで問題を分割するのもよい。bal --dcは米国の会計士には少しなじみがあるかもしれないが、ledger の負数の扱い方を正しく理解していないことが多く、むしろ DR/CR スタイルに変換するスクリプトをいくつか書くほうが簡単だった。相手にした会計士たちがどれほど抽象化を扱えないのか見て驚いた1 つだけ付け加えるなら、Makefile か似たもので全部まとめておけということ。アカウントごとに取引ファイルが多く分かれていて、正しいファイルを include するコマンドは長くなりがちだ
各種グラフや要約スクリプトも、正確な構文を毎回覚えていられないが、make を使えば
make cashflow,make balance 'A=Checking',make balance-plot 'A=retirement'のように呼び出せるLedger を基本チュートリアル以上の、より複雑な状況で効果的に使うための 実践レシピ を何本も書いた: https://felixcrux.com/blog/ledger-practices
銀行取引を取り込むときは、まず相手先名義の勘定に割り当て、スクリプトが
ledger printで相手先ごとの第 2 の仕訳ファイルを作り、元取引を反転させたうえでUnknownプロジェクトとUnknown分類のサブアカウントに一時的に入れるその後、帳簿担当者が取引を特定の請求書に対応付けて
Project:Category勘定に割り当て、必要なら 1 回の支払いを複数のプロジェクト/分類に分割する。すべての銀行取引ジャーナルと相手先ジャーナルを含めれば、ledger balで記帳処理が完了したか確認できるプレーンテキスト会計はすばらしいが、多くの人にとって最大の障壁は銀行データを 標準形式 でダウンロードすることだと思う
銀行は CSV や Excel を超えるものを積極的にはサポートしないだろうし、Yodlee や Plaid のようなデータ集約プラットフォームはオープンソースや趣味ユーザーにやさしくない
以前、Wesabe(https://en.wikipedia.org/wiki/Wesabe) という会社が、デスクトップで銀行同期を行うソフトウェアを作っていた。Mint.com に事実上押し負けたが、そのアプローチはいまでも印象に残っており、オープンソースでも実現できそうに思える
まだ使ったことはないが、SaaS の記帳会社の銀行連携の問題を数日にわたって 4 時間も手伝わされたあとなら、喜んで時間をかけてみる気になる
取引を照合するたびに、中身も見られず自分でも直せないシステムと格闘することになる。もう、払った労力に見合う価値があるのか疑わしくなってきたし、まともな道具さえあれば CSV を自分で扱うほうがよさそうだ。ちなみにその会社は「よくあること」だとして返金もしなかった
lint もあり、結果が気に入ればスクリプトを保存していつでも再取り込みできる。株式のようなものを追跡するときには商品価格のダウンロードにも対応している
チャートは自分の好みには十分汎用的ではないのでデータを別の場所に出力しているが、データ入力用としては優秀だ
そのため PDF をダウンロードしてデータを抽出しているが、必要以上に苦痛だ。機械が読みやすい PDF を提供するには、取引フィールド 3〜4 個と、日付・残高のような明細フィールド数個を、脆いヒューリスティクスなしに抜き出せるような簡単な規則に従うだけでよい
ブランド入りで人間に読みやすい PDF と、機械に読みやすい PDF は両立する
そのデータを処理して会計システムに入れるつもりだったが実行できず、その後スマートフォンが壊れて Tasker のアクションも失ってしまった。もう一度実装する気力は残っていない
関連ドメインはまだそのまま残っている。2023 年の記事: https://news.ycombinator.com/item?id=36022005、2021 年の記事: https://news.ycombinator.com/item?id=28420797、2016 年の記事: https://news.ycombinator.com/item?id=11164330
この概念へのほかの言及は https://hn.algolia.com/?q=Plain+Text+Accounting でも見られる
他の人たちがプレーンテキスト会計ツールを実際にどう使っているのか気になる。支出習慣を把握して行動を変えるために使っているのか、費用・収益・純資産の追跡用なのか、あるいは整然としたプロセスそのものに魅力を感じているのか知りたい
この話題を見るたびに、完全に没頭したい衝動と、以前の試みを継続できなかった後ろめたさが同時に湧く。今は個人元帳を1か月半更新しておらず、後ろめたさのほうが大きい
結局、自分がなぜこれを使うのか確信がないので、時間がたつと取引を記録するためだけに記録している感じになる
業務経費も似たようなものだ。機材やサービスの費用を自分のカードで支払い、あとで報告して現金や振込で返してもらう。ただし、一部の国や事業体では通用しない
個人的な日常支出は、銀行記録と経験ですでに分かるので、会計までやる必要はない。感情的な動機ではなく、金銭的な動機が必要だ。会計をやめると友人が酒代で数百ドル無駄にしたり、会社がHDMIケーブル1本をただで持っていってしまったりすると分かっていれば、ためらわず金額を入力できる。個人会計がうまく続かないのは、失うものがお金ではなく分析だけだからだ
Wiseの取引取り込みや為替レート追跡のような工程を自動化するスクリプトもいくつかある。ただ、日々の個人的な支出や予算管理に使うほどの規律はない
毎日、外食にどれだけ無駄遣いしたかを確認し、その金額をインデックスファンドに入れていた場合の複利効果を計算してみることで、外食習慣を減らすのに大いに役立っている。顧客売掛金と実際のキャッシュフロー、予想収入ベースのキャッシュフローも区別して見られる
貯蓄口座残高を「投資目標40%、贈り物1%」のように頭の中で分けて見るようにしたら、大きな残高を見て衝動的に使ってしまうことが減った。資産増加、分類別支出の増減をチャート化し、その変化が生活にとって純効果があったかどうかをメモしてWebページにダンプするプログラムもあり、毎年次の計画を立てるときに使っている
ledgerファイルをExcelに変換して会計士に年間の税務申告用として送るPythonスクリプトもある。事業用のledgerファイルは別にしていて、自分で直接手作業管理はせず、会計士ソフトウェアからデータを書き出して自宅で独自に計算している
事業では、売上増加に応じて支出がどう増えるかを予測するキャッシュフロー予測、部門別支出の外れ値検知、採用を増やすべきかマーケティング支出を増やすべきか、ROICのような指標計算に使っている
複式簿記は、銀行明細を取り込んでledgerを生成したあと、会計上の不一致を見つけるのに役立つ。裁量支出、従業員福利厚生、事業投入費のように用途別の勘定を分け、主口座から毎週入金されるようにして異常がないか確認している
以前、会計士が透明性のある説明をせず、架空経費を帳簿に載せて税金を大きく節約したように見せかけた結果、法廷に行くことになり、多額の罰金と延滞加算金を払ったことがある。今では会計士を鵜呑みにせず、必ず再確認している
Stripe、銀行明細、会計士の帳簿などを取り込む自動化スクリプトが多くあり、Pythonで突き合わせて不一致を探している。プログラマーの自分にはプレーンテキスト会計がよく合っていて、hledgerの上に何年もかけて自分専用のシステムを積み上げてきた