Beancount 常见问题解答：纯文本会计问题

大约五个概念，不需要学位。你需要五种账户类型（资产、负债、权益、收入、费用），理解每笔交易都在至少两个账户之间转移价值，以及交易必须平衡的规则。Beancount 会为你强制执行其余部分——它拒绝加载交易不收支平衡的文件，因此软件能捕捉到初学者在无意识中会犯的错误。

从 Beancount 简介开始，在浏览器标签页中打开词汇表，然后在快速入门中添加你的第一笔交易。

Beancount 完全不使用“借方”和“贷方”这两个词——它使用必须总和为零的有符号数。资金离开账户为负数，资金进入为正数，当交易的多个分录相互抵消时，该交易即有效。这与会计师使用的复式记账法相同，但去除了容易让新手混淆的术语。

如果你使用过传统会计软件，翻译过来就是：借方是正数，贷方是负数。请参阅语言语法参考了解如何编写分录，或参考借方和贷方详解以获得通俗易懂的会计背景知识。

因为资金总有来源，而零和正是将这一事实转化为错误检查机制的关键。如果你在杂货上花了 40 美元，这笔钱离开了银行账户——记录交易的两个方面意味着这两笔账必须相互抵消，任何一个金额的输入错误都会导致文件加载失败，而不是悄无声息地产出一个错误的余额。

这就是纯文本分类账比电子表格更值得信赖的原因：其结构本身具有自我检查功能。余额断言是相关机制，用于将你的分类账与实际情况进行核对。

在你的起始日期记录一笔交易，将每个账户的当前余额从 Equity:Opening-Balances 结转过来，然后添加一个 balance 断言来锁定它。你无需重建你的财务历史——选择一个起始日期，记录当天的余额，然后从此开始记录即可。

快速入门 中有一个完整的期初余额示例。

从粗粒度开始，只有当更细粒度的划分会改变决策时才进行拆分。二十个左右的账户一开始就足够了；如果你发现自己想知道“Expenses:Food”是否应该将杂货与餐馆分开，一个有用的检验标准是你是否真的会因知道这个拆分而采取不同的行动。

后续重命名和拆分在文本文件中只是查找替换操作，因此从简单开始成本很低。账户名称可以嵌套，因此你可以从一个大类别开始，之后将其拆分为子账户，而无需重写历史——如果你想复制一个结构，可以参考如何设计会计科目表。

电子表格无法告诉你它何时出错。纯文本会计强制执行复式记账，因此每笔交易都是自我检查的，并且只要文本文件存在，该文件就保持可搜索（grep）、可差异对比（diff）和可脚本化。你还能获得真实的版本历史：在你的分类账上执行 git log 可以精确显示更改了什么、何时更改以及为什么更改。

实际区别在涉及多个账户、货币或投资时显现出来，此时单式电子表格会悄无声息地偏离真实情况。请参阅透明且可审计的会计。

如果你只想知道自己在咖啡上花了多少钱，是的——电子表格就足够了。当你拥有多个账户、一笔抵押贷款、一个经纪账户或一种以上货币时，复式记账的价值就体现出来了，因为正是在这些情况下，单式记账会在不告知你的情况下丢失资金。

一种有用的思考方式是：复式记账是你财务的校验和。请参阅简介了解更多案例。

不。Fava 是一个基于同一文本文件的完整 Web 界面——提供资产负债表、损益表、图表和交易录入——而 Beancount.io 会为你运行它，并将你的分类账存储在云端。文本文件仍然是事实来源，因此你可以日常使用 Web UI，只有在需要时才使用终端。

请参阅用户界面功能了解界面的功能，或尝试实时演示。

大多数人导入 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 断言，其中包含对账单的期末余额和日期。如果你的分类账与银行不一致，Beancount 将拒绝加载文件，这将核对工作从手动比较转变为软件每次运行时都会自动检查的事情。

对于大多数人来说，每月核对一次就足够了。请参阅过滤和搜索以查找差异。

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

没有任何转换是在你背后进行的——你始终能看到原始货币和转换后的价值。关于记账方面，请参阅语言语法、精度与容差和多币种会计。

用大括号记录购买时的成本——10 AAPL {150.00 USD}——然后 Beancount 会分别跟踪每一批股票。当你卖出时，说明你正在减少哪一批股，资本收益会自动从计算中得出，而无需你手动计算。

Beancount 支持 STRICT、FIFO、LIFO 和 NONE 记账方法。平均成本记账法可以解析，但未完全实现——如果你的税务管辖区要求平均成本法，请计划使用插件或明确的批次来跟踪。请参阅库存管理。

与任何其他商品完全相同：加密货币是一个带有成本的单位，因此适用相同的批次和记账机制。用一种代币交换另一种代币是一笔单一交易，它减少一批代币并开立另一批代币，这也是你获得大多数税务机关希望报告的已实现收益的方式。

请参阅加密货币投资组合跟踪和现成的加密货币模板。

企业确实在使用它，包括拥有数十万笔交易的公司。它处理权责发生制会计、多实体结构以及会计师期望的报告。诚实的限制在于：没有多用户并发编辑，没有内置的开票 UI，也没有应付账款审批流程——它是一个分类账，而不是 ERP 系统。

请参阅行业特定设置和真实公司账簿展示开放分类账。

将它们分开——要么作为单个文件中的不同顶级账户树，要么作为两个通过 include 组合在一起的文件。混合使用会使企业的损益表失去意义，并使税务处理更加困难，而分开处理最初不会带来任何成本。

一旦企业拥有了自己的银行账户，两个文件通常是更清晰的选择。请参阅多文件支持。

将应收账款建模为资产账户，将应付账款建模为负债账户，然后在开具发票时记录发票，在收到付款时记录付款——这就是权责发生制会计，Beancount 直接支持。它所没有的是开票界面：它跟踪你应得的款项，但不会生成或发送发票。

关于报告方面，请参阅财务报告模板；关于工作示例，请参阅行业特定设置；关于概念，请参阅理解应收账款。

导出报告而不是分类账。你的会计师几乎肯定不想要一个文本文件——他们想要损益表、资产负债表和交易清单，你可以通过 Web 界面或使用查询生成 CSV 或 PDF 格式。

请参阅税务准备指南、财务报告模板和使用 SQL 查询以提取他们需要的具体数字。

三者都是纯文本复式记账系统，具有相似的文件格式。Ledger 是最初的也是最宽容的解析器；hledger 是 Haskell 重写版本，以其友好的 CSV 导入规则和文档而闻名；Beancount 拥有最严格的解析器，对投资、批次和多种货币的支持最强，并且拥有 Python 插件 API。

严格性是真正的权衡：Beancount 拒绝加载它认为有歧义的文件，这能及早发现错误，但代价是更挑剔。请参阅Beancount vs Ledger CLI 和 Beancount vs hledger。

原生不支持——这是一个真正的差距，而不是一个隐藏的功能。Beancount 内置的预算功能有限，希望严格使用信封法的人通常使用社区插件或将信封建模为账户。

如果信封预算是你主要的需求，请在切换之前阅读 Beancount vs YNAB。关于目前有效的方法，请参阅Beancount 中的预算。

可以。document 指令将一个文件链接到一个账户和日期，Web 界面允许你上传和浏览这些文档以及它们所属的交易。收据作为普通文件保存在磁盘上，因此它们与分类账本身一样可移植。

请参阅用户界面功能。

有——Beancount.io 发布了 iOS 和 Android 应用，用于在外出时查看你的分类账和捕获交易，这填补了大多数纯文本设置留下的空白。

对于无需应用快速捕获，许多人会记录一个粗略的备注，然后稍后将其核对到分类账中。

十年的个人财务数据大约是几兆字节，加载时间远低于一秒。Beancount 在每次加载时都会根据完整的交易历史重新计算余额，这在数十万条记录内都能保持快速；超过这个量，通过 include 按年拆分来保持流畅。

请参阅多文件支持了解如何拆分不断增长的分类账。