我从 2022 年开始使用 Beancount，2023 年开始开发 Beancount-Trans，并逐渐形成了一套自己的财务处理流程：以周期对账作为入口，通过批量解析、规则和 AI 减少重复劳动，再由人工处理真正需要判断的部分。相比单纯追求自动化，我更在意这套流程能否长期稳定地运行，以及持续积累的数据能否用于理解自己的财务。

从记账转向对账

随着账本逐渐积累，我越来越在意的不是如何记录每一笔交易，而是账本里的数字能否持续反映真实账户的情况。

因此，我没有选择每天逐笔记账，而是为不同账户设置对账周期，到期后通过待办核对余额。日常支付账户和银行卡通常按月对账，公积金等账户则可以按年处理。月度批量处理是我实践后最能接受的节奏，但不同账户不必采用相同周期。

这也和我的个人习惯有关。我一直是 Obsidian Tasks 和 GTD 的深度用户，习惯用待办管理事情。所以，我不是从理论上推导出财务应该由待办驱动，而是发现这种方式适合自己，也能长期运转。

对账待办会显示需要核对的账户及账面余额，让我不用记住每个账户何时需要检查，也不必每次重新考虑从哪里开始。真实余额与账面余额之间的差异，则推动我发现并处理问题。

我的月度财务处理流程

我将日常资金入口主要收敛在支付宝、微信和中国银行借记卡，内部划转等操作也尽量通过中国银行完成，以保留相应的账单记录。信用卡、水电燃气、储值卡和公积金等账户，则按照各自特点设置对账周期。

每个月月底，我会批量导出并解析当月账单，而不是每天逐笔导入。Beancount-Trans 根据关键词映射生成 Beancount 条目；如果一笔记录匹配到多个关键词，就通过 BERT 对候选映射进行语义分析，并选择得分最高的结果。重复记录、退款关联等情况也由工具提供相应的处理方式。

解析完成后，我回到对账待办，检查各账户的真实余额和账面余额是否一致。账单完整的账户通常在解析后就能对上；剩下的再逐一检查，补充遗漏记录或处理差额。我主要审核系统仍无法确定的交易，以及需要个人判断的情况。例如，同样是晚餐支出，可能是日常用餐、特意安排的体验，也可能是商务饭局。账单未必能体现这些意图，我会按需要补充标签。

有些账户没有完整、可导入的交易明细，储值卡就是一例。假设账面余额为 500 元，月底实际余额是 450 元，差额就会推动我继续处理。如果确认是某天的餐饮消费，我会按日期和用途补录交易；如果无法确定差额的性质，也可以先使用 Equity:Adjustments 这样的调整科目。利息等明确的小额变化则可以直接归类。

我不需要重新检查每一笔交易，而是先批量处理账单，再根据对账结果处理未对平或仍有疑问的部分。当本周期需要核对的账户都与真实余额一致时，这一轮工作就算完成。余额一致不能保证每个科目和标签都完全正确，但它提供了一个明确、可重复检查的完成条件。

我真正看重的是长期稳定

这套流程带来的最大收益，不只是导入账单更快，而是我不必每个月重新决定怎么记、记到什么颗粒度，也不用反复想该从哪里开始。需要处理的事情集中在对账待办里，批量解析和审核都围绕它展开。

长期来看，数据规范同样重要。如果同类支出每个月使用不同科目，商家名称、标签和描述也不断变化，即使账单都成功导入，历史数据仍然很难比较。只有持续采用相对稳定的科目、标签、商家和描述规范，账本才更适合观察趋势，也能为后续的 AI 分类与财务分析提供基础。

规则和自动化减少重复劳动，AI 辅助处理分类歧义，人工则判断那些依赖个人意图和上下文的问题。对我来说，关键不是某个环节有多智能，而是这些环节组成了一套可以反复运行的流程。

这套做法来自我自己的行为习惯，以及 Beancount-Trans 在长期使用中的逐步完善，不是所有人都必须照搬的标准答案。如今，它已经能够稳定地处理我的个人收入和支出，也让我逐渐把注意力从"如何把账记进去"，转向"如何让账本持续可靠地反映和帮助理解自己的财务"。