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

大约五个概念，不需要学位。你需要五种账户类型（资产、负债、权益、收入、费用），理解每笔交易都在至少两个账户之间转移价值，以及交易必须平衡的规则。Beancount 会为你强制执行其余部分——它会将任何数字不匹配的交易标记为错误，而不是静默接受，因此软件能捕捉初学者可能遗漏的错误。

从Beancount 简介开始，在标签页中打开术语表，并在快速入门中添加你的第一笔交易。

Beancount 完全不用"借方"和"贷方"这两个词——它使用必须总和为零的有符号数字。资金离开账户为负数，资金进入为正数，当分录相互抵消时交易有效。这与会计师使用的复式记账相同，只是移除了让新手困惑的词汇。

如果你用过传统会计软件，转换关系是：借方是正数，贷方是负数。参见语言语法参考了解分录的写法，或借方和贷方详解了解用通俗语言解释的会计背景。

因为钱总是有来源，而零和就是把这一事实变成错误检查的手段。如果你花 40 美元买杂货，那笔钱从银行账户离开了——记录双方意味着两者必须相互抵消，任何一个金额的打字错误都会被标记为错误，而不是悄悄产生错误的余额。

这就是为什么纯文本账本比费用电子表格更可靠：结构本身是自检的。余额断言是检查你的账本与现实相符的相关机制。

在开始日期记录一笔交易，将每个账户的当前余额从Equity:Opening-Balances转移，然后添加一个balance断言来锁定它。你不需要重建你的财务历史——选择一个开始日期，按当天的余额为准，然后从那里继续。

快速入门详细介绍了完整的期初余额示例。

从粗略开始，只有当更细的划分会改变决策时才拆分。大约二十个账户足以开始；如果你发现自己想知道"Expenses:Food"是否应该区分杂货和餐厅，有用的测试是知道这个区分后你是否真的会采取不同的行动。

以后重命名和拆分就是文本文件中的查找替换，所以从简单开始的成本很低。账户名称可以嵌套，所以你可以从宽泛的类别开始，以后拆分为子账户而无需重写历史——参见如何设计会计科目表如果你想复制一个结构。

电子表格无法告诉你什么时候出错了。纯文本记账强制执行复式记账，所以每笔交易都是自检的，而且只要文本文件存在，文件就能保持可搜索、可比较和可脚本化。你还能获得真正的版本历史：在账本上执行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错误并以非零状态退出，这把核对从手动比较变成每次运行时软件都检查的事情。

每月一次的频率对多数人来说足够了。参见过滤和搜索查找差异。

原生支持，这是它相对于消费金融应用的最大优势之一。每个金额都带有货币单位，账户可以同时持有多种货币，转换通过@表示价格或{}表示成本来显式记录，因此汇率变化永远不会悄悄重写你的历史。

没有任何转换在你背后进行——你总是同时看到原始货币和转换后的价值。参见语言语法、精度与容差和多币种会计了解记账方面。

使用花括号中的成本记录购买——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应用，用于在移动中查看账本和捕获交易，这是大多数纯文本设置留下的空白。

不应用快速捕获时，许多人会记下粗略笔记，稍后将其核对到账本中。

十年的个人财务数据只有几兆字节，加载时间远低于一秒。Beancount 每次加载都会从完整交易历史重新计算余额，这在数十万条记录中依然保持快速。超过这个范围，限制在于编辑和对比的舒适度，而不是加载时间：按年份用include拆分可以保持单个文件较小，但包含的文件仍然形成一个组合账本，Beancount 会完整加载和重新计算，所以这是一种文件组织上的便利，而不是加速或保持独立账簿的方式。

参见多文件支持了解如何拆分不断增长的账本。