Beancount 常见问题解答：纯文本记账问题

大概五个概念，而不是一个学位。你需要知道五种账户类型（资产、负债、权益、收入、费用），知道每笔交易至少要在其中两个账户之间转移价值，以及交易必须平衡这条规则。其余的 Beancount 会帮你强制执行 —— 任何数字对不上的交易都会被标记为错误，而不是被默默接受，所以软件能抓住新手本来会漏掉的错误。

从Beancount 简介开始，把术语表开在一个标签页里，然后在快速开始中加上你的第一笔交易。

Beancount 根本不用“借方”和“贷方”这两个词 —— 它用的是必须相加为零的有符号数字。钱离开账户是负数，钱进入账户是正数，当一笔交易的分录相互抵消时，这笔交易就是有效的。这就是会计人员所做的复式记账，只是把让新手困惑的术语去掉了。

如果你用过传统会计软件，翻译过来就是：借方是正数，贷方是负数。关于分录怎么写，看语言语法参考；关于会计背景的通俗讲解，看借方与贷方详解。

因为钱总是从哪里来的，而零和就是把这一事实变成错误检查的机制。如果你花 40 美元买杂货，这笔钱是离开了某个银行账户 —— 把两半都记下来就意味着它们必须抵消，任何一边的金额打错字都会被标记为错误，而不是悄悄产生一个错误的余额。

这就是为什么纯文本账本比一张支出电子表格更值得信任：结构本身就是自检的。余额断言是相关的机制，用来把账本和现实核对。

在你开始的那天记一笔交易，把每个账户当前的余额从 Equity:Opening-Balances 转出来，然后加一个 balance 断言把它锁定。你不需要重建自己的财务历史 —— 挑一个开始日期，把当天的余额照原样记下，然后从那里往前走。

快速开始里有一个完整的期初余额示例。

先粗一点，只有当更细的划分会改变某个决定时才拆分。二十来个账户起步完全够用；如果你在纠结“Expenses:Food”要不要把杂货和餐馆分开，有个实用的检验标准：知道这个拆分后，你会不会真的做出不同的举动？

以后重命名和拆分在文本文件里就是一次查找替换，所以从简单开始的成本很低。账户名可以嵌套，所以你可以先从一个宽泛的类别开始，之后再拆成子账户，而不用重写历史 —— 如果你想要一个可以照抄的结构，看如何设计会计科目表。

电子表格没法告诉你它什么时候错了。纯文本会计强制执行复式记账，所以每笔交易都是自检的，而且只要文本文件还存在，这个文件就一直是可 grep、可 diff、可脚本化的。你还能得到真正的版本历史：对账本跑 git log，就能看到确切改了什么、什么时候改的、为什么改。

实际的差别会在你有多个账户、多种货币或投资时显现出来，那时单式记账的电子表格会悄悄偏离真实情况。看透明且可审计的会计。

如果你只想知道自己在咖啡上花了多少钱，是的 —— 电子表格就够了。一旦你有好几个账户、一笔房贷、一个券商账户或者不止一种货币，复式记账就开始值回票价了，因为这些正是单式记账会悄悄丢钱而不告诉你的情形。

一个有用的想法是：复式记账是你财务的校验和。更长的论证看简介。

不用。Fava 是在同一个文本文件之上的完整网页界面 —— 资产负债表、利润表、图表、交易录入都有 —— 而 Beancount.io 帮你运行它，账本放在云端。文本文件仍然是唯一真相来源，所以你可以日常用网页界面，只在自己想用的时候才下到终端。如果你确实偏好终端，bea 命令行能创建、检查并报表同一个文件 —— 看 CLI 快速开始。

关于界面能做什么，看界面功能，或者试试在线演示。

大多数人会导入 80–95% 的交易，其余的靠手工录入。按可靠性从高到低大致是：从银行直接下载的 OFX/QFX、CSV 导出加导入规则、聚合器连接，以及 —— 只作为最后手段 —— 把 PDF 对账单转成 CSV。Beancount.io 的银行同步会帮你处理连接和分类。

做好为每家机构写或调整一条规则的心理准备：银行导出的 CSV 以不一致著称，而商户名里含有一个没转义的逗号是真实且常见的问题。自动化的路子看智能导入。

对于一次性的文件，有两个免费的浏览器转换器能在不上传任何东西的情况下完成机械的部分：CSV 转 Beancount 用于电子表格导出，OFX 和 QIF 转 Beancount 用于银行在完全不提供 CSV 时给的 .ofx、.qfx、.qbo 和 .qif 下载文件。

导入器会针对账本里已有的分录去重，按日期、金额和收款人匹配，并把任何模棱两可的地方标出来让你确认，而不是靠猜。通常的工作流会把不确定的导入标为待定，这样在它们成为永久记录的一部分之前你能先审阅。

OFX 在这方面比 CSV 更容易：每笔交易都带有一个银行在多次下载中保持稳定的 FITID，所以导入器可以按身份而不是靠推断来匹配 —— OFX 转换器会把它保留为一个 id: 元数据字段。

答案的另一半是转账：钱在你拥有的两个账户之间移动，会出现在两家银行的导出文件里。把它记成一笔带两条分录的交易就好。

不用 —— 对很多人来说，这正是使用纯文本会计的理由。你可以自己从银行导出 OFX 或 CSV，永远不用把凭据交给聚合器。如果你偏好自动同步，Beancount.io 使用的是银行认可的聚合器，而不是存储你的网上银行密码。

细节看安全页面。

为对账单的期末数字加一个 balance 断言，日期定在结账日之后的那一天。余额断言在其日期的开始时求值，所以第二天早上的断言才会包含截至对账单最后一天的所有交易。如果你的账本和银行不一致，bea check 会报一个 Balance failed 错误并以非零状态退出，这把核对从手工比较变成了软件每次运行都会检查的事情。

对大多数人来说每月一次就够了。要追查差异，看过滤与搜索。

原生支持，这是它相对消费级理财应用最大的优势之一。每笔金额都带有自己的货币，账户可以同时持有多种货币，换算会用 @ 表示价格或用 {} 表示成本明确记录下来，所以汇率变动永远不会悄悄改写你的历史。

不会有什么在你背后被换算 —— 你始终能同时看到原币种和换算后的价值。关于记账的部分，看语言语法、精度与容差和多币种会计。

对于托管在 Beancount.io 账本中的受支持资产，用实时价格，或者把报价拉取到本地价格文件供上游 Beancount 和 Fava 使用。选择器让你选择报价货币并复制托管 includes。兼容的 bea 版本也支持托管 includes；设置指南会链接到它们的说明。

托管价格影响的是市场估值，不是交易金额或成本基础。同一日期和货币对，你自己的价格优先。刷新在服务中断期间可能使用过期的缓存价格，而后来的报价无法填补缺失的历史估值日期。

用花括号里的成本记录买入 —— 10 AAPL {150.00 USD} —— Beancount 会分别追踪每一批。当你卖出时，你说明自己在减少哪一批，资本利得就会自动从算术中得出来，而不是要你手算。

Beancount 支持 STRICT、FIFO、LIFO 和 NONE 记账方法。平均成本记账能被解析，但没有完全实现 —— 如果你的税务辖区要求平均成本，就打算用插件或显式批次来追踪。看库存管理。

和任何其他商品完全一样：加密货币是一个带成本的单位，所以同样的批次和记账机制都适用。用一种代币换另一种，是一笔减少一批、开立另一批的单笔交易，这也正是你得到大多数税务机关想要申报的已实现利得的方式。

看加密货币投资组合追踪和现成的加密货币模板。

企业在用它，包括拥有几十万笔交易的公司。它能处理权责发生制会计、多实体结构，以及会计师期望看到的报表。诚实的局限是：没有多用户并发编辑，没有内置的开票界面，也没有应付账款审批流程 —— 它是一个账本，不是一个 ERP。

看行业特定设置和公开账本里真实公司账目的展示。

分开 —— 要么作为一个文件里两棵不同的顶层账户树，要么作为两个用 include 合并的文件。混在一起会让企业的利润表失去意义，让报税季更难熬，而分开几乎不花任何前期成本。

一旦企业有了自己的银行账户，两个文件通常是更干净的选择。看多文件支持。

把应收建模为一个资产账户，应付建模为一个负债账户，然后在开票时记下发票、收到款时记下收款 —— 这就是权责发生制会计，Beancount 直接支持。它没有的是开票界面：它追踪别人欠你多少，并不生成或发送发票。

报表方面看财务报表模板，实例看行业特定设置，概念看理解应收账款。

导出报表，而不是账本。你的会计师几乎肯定不想要一个文本文件 —— 他们想要利润表、资产负债表和交易清单，你可以从网页界面或用一个查询把它们生成为 CSV 或 PDF。

看报税准备指南、财务报表模板和用 SQL 查询，来拉取他们确切索要的数字。

三者都是纯文本复式记账系统，文件格式相似。Ledger 是最早的那个，解析器也最宽松；hledger 是用 Haskell 重写的实现，以友好的 CSV 导入规则和文档著称；Beancount 的解析器最严格，对投资、批次和多币种的支持最强，还有一个 Python 插件 API。

严格才是真正的取舍：Beancount 会拒绝加载它认为有歧义的文件，代价是更挑剔，收获是更早发现错误。看Beancount 对比 Ledger CLI和 Beancount 对比 hledger。

原生不行 —— 这是一个真实的缺口，而不是隐藏功能。Beancount 内置的预算能力有限，想要严格信封行为的人通常用社区插件，或者把信封建模成账户。

如果信封预算是你最看重的东西，换之前先读Beancount 对比 YNAB。至于今天确实能用的做法，看 Beancount 中的预算。

可以。document 指令把文件链接到一个账户和日期，网页界面让你上传并浏览这些文档，和它们所属的交易放在一起。收据就是磁盘上的普通文件，所以它们和账本本身一样可移植。

看界面功能。

有 —— Beancount.io 发布了 iOS 和 Android App，用来在移动中查看账本和记录交易，这正是大多数纯文本方案留下的缺口。

没有 App 也想快速记录的话，很多人会先记一个粗略的备注，之后再把它整理进账本。

十年的个人财务也就几兆字节，加载远不到一秒。Beancount 每次加载都会从完整交易历史重新计算余额，这一点一直到几十万条分录都还很快。超过之后，限制在于编辑和 diff 的舒适度，而不是加载时间：用 include 按年拆分能让单个文件保持小，但被 include 的文件仍然构成一个合并账本，Beancount 会完整加载并重新计算，所以这只是文件组织的便利，既不是提速，也不是用来分开记不同账目的办法。

关于怎么拆分一个不断增长的账本，看多文件支持。