Beancount 平行预算插件：当个人记账遇上事业单位平行记账

Sun, 10 May 2026 00:00:00 +0000

从「平行记账」说起

如果你接触过政府会计制度，一定对「平行记账」这个词不陌生。

2019 年起，我国行政事业单位全面实行新政府会计制度，核心变化就是建立 财务会计 与 预算会计 适度分离又相互衔接的「双体系」核算模式。简单说，就是同一笔经济业务，同时从两个维度反映：

财务会计 — 权责发生制，反映单位的资产负债和运行成本
预算会计 — 收付实现制，反映预算收支执行情况

这套模式有个形象的名字叫 平行记账。它在确保财务信息完整性的同时，又能直观看到预算执行进度——钱花到哪了、还剩多少、有没有超支。

什么？你说这是写给事业单位财务人员的，跟个人记账有什么关系？

别急。我在用 Beancount 做个人记账时发现，这种「平行」的思路，恰好能解决个人预算管理中长期困扰我的几个痛点。

Fava 自带预算功能的问题

Beancount 生态中，Fava 是最常用的 Web 前端。它确实自带了一套 budget 指令，但实际用过之后，槽点不少：

1. 不直观，学习成本高

内置的 budget 需要配合 bean-query 特定的查询语法才能看到预算执行情况。这意味着你没法在 Fava 的资产负债表上直接看到预算余额——你得再开一个单独的报表页面，还需要自己拼 BQL。

此外，budget 指令的语法固定，自定义灵活性差，例如只支持固定按照月份或者年为周期进行预算管理，不支持一次性预算或跨周期预算管理。对于装修这种一次性大额、餐饮这种每月定时充值的混合场景，内置 budget 没有一个直观的「周期开始自动充值、过往余额不累积」的展示机制。对于预算分类比较细的用户（比如我有餐饮、交通、购物、装修等多个预算），配置起来繁琐且不易维护。

3. 与账本体系割裂

最让我难受的是——预算信息是「外挂」的，不在标准的复式记账体系内。这意味着预算余额不是账户余额，不能通过 Fava 的账户树直接浏览，只能在Fava的支出页面中的某个子页面察看。没法用 bean-query 做自由查询，也没法和其他账户做交叉分析。

我们的方案：Beancount 平行预算

所以，我想能不能换一种思路——把预算本身做成账本的一部分。

受事业单位平行记账的启发，我开发了 beancount_parallel_budget 插件。核心思想就是：让预算像会计科目一样存在，用复式记账的方式管理预算执行。

账户体系

每一个预算类别，对应三个账户：

Equity:Budget:Expenses:{name} ← 记录该预算下的实际支出
Equity:Budget:Balance:{name} ← 预算余额（周期初=预算额，周期末=剩余）
Equity:Budget:Income:{name} ← 预算收入（周期初调整时的反向账户）

关键逻辑：每个支出交易发生时，插件自动在原有记账分录上追加两条平行分录，将支出金额同步记到 Expenses 和 Balance 账户。这就像一个迷你「预算会计」体系，与你的「财务会计」（即平时的收支记账）并行运作。

AI+Beancount 复式记账个人务实

Sun, 01 Jun 2025 21:30:28 +0800

AI+Beancount 复式记账个人务实

其实大概从本科以来，我一直在使用Beancount这个开源的复式记账工具来进行个人财务管理。但是之前记账实在是太繁琐和麻烦了，经常拖拖拉拉，记个大概。

改变发生在去年年底，从那时候开始，我开始引入大语言模型（LLM）来参与个人记账务实。从此，每个月的支付宝、微信和信用卡账单大概只需要十多分钟的就可以快速地导入进对账单。因此，2025年起我们的记账开始变得详细和完整，账本也更准确地反映出了个人财务状况。如今，我也有一些经验总结，希望做一个回顾和整理。

记账方案的顶层设计——权责发生制还是收付实现制

以往，大多数讲Beancount记账软件的博客通常会从单式记账（Single-entry Bookkeeping)和复式记账（Double-entry Bookkeeping）的区别谈起。但是今天，我想从一个更加深入也更本质的问题来谈起，因为这决定了我们账本的整体设计框架，也就是权责发生制和收付实现制。

简单回顾一下Beancount引入的复式记账，这引入了一个规则就是每一个交易（Transactions）均是由多个条目（Postings）来组成的，代表了资金的来龙去脉。在Beancount中，并非使用会计学中“借贷记账法”，而是简化为使用负数代表资金的来源（即贷方，Credit），正数代表资金的去向（即借方，Debit）。举一个简单的例子，假设你借给小明2000块钱，传统单式记账可能会记录一笔2000元的支出，而复式记账则同时记录这笔资金的从哪里来、到哪里去。：

2025-05-01 * "小明" "借款2000元"
 Assets:Bank:Cash -2000 CNY
 Assets:Receivables:XiaoMing 2000 CNY

这样，这一笔支出并不会记录为一笔支出（Expenses），而是记录为小明的应收账款中的金额。这样，你就知道这2000元并不是你这个月切实的消费，因此并不需要从个人的本月预算中省吃俭用出这2000元。

同样，当下个月小明连本带利归还2200元时，你的记账如下：

2025-06-01 * "小明" "还款2000元"
 Assets:Bank:Cash 2200 CNY
 Income:PnL -200 CNY
 Assets:Receivables:XiaoMing -2000 CNY

这代表着小明还清了钱，同时你的收益和损失收入（Profit & Loss， PnL）账户带来收益200元。因此，这个月你的净收益增加200元，而不是2200元。而你这个月也可以多消费200元（笑）。

从本质上看，Beancount的复式记账提供了更加灵活的记账能力，也因此引入了我们想要讨论的一个核心话题：是使用上面这个例子使用的权责发生制还是收付实现制来记账？让我来说明一下：

任何一个会计学教材都会跟你说，财务报表最重要的三大表是资产负债表（Balance Sheet）、利润表（Income Statement）和现金流量表（Cash Flow Statement），他们的主要特点如下：

资产负债表衡量了一个时刻的所有资产和负债的表格。资产负债表主要考察如下三类财务科目，资产（Assets）、负债（Liabilities）和所有者权利（Equity，或称净资产）。在Beancount中，引入了如下的会计恒等式：资产+负债+净资产=0。值得注意的是，在Beancount中，负债和净资产等贷方账户都使用负数来记账。
利润表衡量了一段时间内的收入、费用和净利润等情况，主要考察了如下两类财务科目支出（Expenses）和收入（Income）。利润表使用的是权责发生制来记录，即在这个交易产生权利和责任的那一天入账（例如发生交易、签订合同等）。假设你租房每个月房租是2000元，三个月一付。按权责发生制，则应该记录为在实际使用房屋的时候（即每个月），产生支付义务的时刻记账：

2025-03-01 * "房租实预缴"
 Assets:Cash -6000 CNY
 Assets:Prepaid 6000 CNY

2025-03-01 * "房租(按月发生)"
 Expenses:House 2000 CNY
 Assets:Prepaid -2000 CNY

2025-04-01 * "房租(按月发生)"
 Expenses:House 2000 CNY
 Assets:Prepaid -2000 CNY

2025-05-01 * "房租(按月发生)"
 Expenses:House 2000 CNY
 Assets:Prepaid -2000 CNY

; 当然，后面会介绍使用beancount-periodic插件更优雅地处理摊销的办法

现金流量表则衡量了一段时间内现金的流入流出情况。和利润表不同的是，现金流量表按照收付实现制来记账的，也就是在资金实际变动的那一天记一次账。上面租房的例子如果按照收付实现制，则应该记录为如下一笔：

2025-03-01 * "房租实缴纳"
 Assets:Cash -6000 CNY
 Expenses:House 6000 CNY

显然，权责发生制和收付实现制各有所长。从上面这个例子可以看出，权责发生制更容易方便我们进行中期和长期的个人财务管理。比如，将房租消费摊销到每一个月之后，你就清楚地看到每个月房租支出2000元。因此每个月的预算可能需要扣除这2000元。同时，基于收付实现制的现金流量表也同样重要，可以用于展示个人短期的现金压力。比如，当你身上只有7000元现金的时候，一次性支付6000元房租也势必会对个人现金流产生极大压力。

Finance on Lutong's Homepage

Beancount 平行预算插件：当个人记账遇上事业单位平行记账

从「平行记账」说起

Fava 自带预算功能的问题

1. 不直观，学习成本高

3. 与账本体系割裂

我们的方案：Beancount 平行预算

账户体系

AI+Beancount 复式记账个人务实

AI+Beancount 复式记账个人务实

记账方案的顶层设计——权责发生制还是收付实现制