上回用 beancount 来手工记账是 2018 年的事，当时想要这么做的原因是贵厂的 Waze Carpool 项目当时并没有提供非常方便理解的记账系统，因此结合每月的对账单和 Waze 记录的数据来统计一下相关的数据，同时也把手中的现金一类没有对账单的小额资金给管起来。 后来又逐渐加入了一些其他的类似 PayPal 之类的付款记录，但是随着疫情的发展，到 2020 年初的时候已经不再有新的记录，慢慢也就把记账的事情给搁置下来了。

今年出于计算个税的需要，我又重新开始了记账。最初的想法是只把工资单的自动导入做好， 但后来想到既然 #来都来了 索性就把相关的解析全都做了好了。

我目前使用的导入工具是贵厂员工维护的 beancount-import。 目前我使用的金融机构大致上可以分为三类：第一类是提供了 OFX （有些银行或券商称作 Quicken， 导出一个 QFX 文件，这是 Intuit 扩展的一种 OFX 格式）格式的导出，主流银行多半属于此类； 第二类是不提供 OFX 但是提供某种格式的 CSV，这包括了 PayPal、Discover，以及某些credit union； 第三种是两种格式都不提供。

除此之外，工资单的 PDF 如果包含规整的文本数据的话，也可以使用该工具导入。

简便起见，我在导入时只处理了2022年以来的数据。不过，一些跨越多年的财务数据，例如房贷还款， 仍然需要做一些更好的处理（目前的做法是未做按月的明细记账， 而是以年为单位记录汇总的利息和本金偿还记录）。在整理数据的过程中，我发现银行在关闭账户之后， 往往就不再提供访问对账单或是税表的功能了。

目前发现的问题主要有：

1. 银行提供的数据描述不适合人类理解。例如，它可能会将一笔交易记录为 COSTCO WHSE #0423 而不是容易理解的 Costco, Sunnyvale CA。这属于可以用 sed 轻易解决的问题。
2. 有些银行的 FITID 是不唯一的，多次相关交易会使用同一个 FITID，这会给数据处理带来一定的困难。
3. 贵厂工资单的格式发生了变化，需要使用这个 PR。
4. 太平洋瓦斯及电力公司提供的数据明细很多，但其 PDF 是点阵字而不是可以比较容易解析的文本。目前还没找到很好的方法来处理这些数据。
5. 涉及外币及基金的交易有舍入误差的问题。目前是使用 @@ XX.XX USD 的方法强行抹平，但这种做法存在一定的隐患（因为这样一来美元部分的帐目平了，但持仓数据可能由于录入问题导致不平）。此外，beancount在处理基金交易时的计税单位处理存在一些bug（使用 FUND { price USD } 语法时，后续的扣费交易有时无法对应到正确的计税单位）。

除此之外，并非所有交易的明细都可以从银行获得。一些机构可能使用了赊帐-缴费，比较具有代表性的是学校、 电力公司。我目前的做法是给这些机构分别设置了一个 Liability 账户。以 PG&E 为例， 我目前的做法是将耗电 (KWH) 作为一种货币，这样相关的记账类似于：

  Expenses:Energy:Electricity:Power                38.01100 KWH @@ 15.69 USD
    comment: "12/17/2021 - 12/31/2021 Peak"
  Expenses:Energy:Electricity:Power                29.59900 KWH @@ 7.42 USD
    comment: "12/17/2021 - 12/31/2021 Part-Peak"
  Expenses:Energy:Electricity:Power              202.578000 KWH @@ 30.20 USD
    comment: "12/17/2021 - 12/31/2021 Off-Peak"

最终这些费用会从一个叫做 Liabilities:Utilities:PGE 的账户中支出。这样一来，相关的 PayPal 交易（从 Liabilities:PayPal 到 Liabilities:Utilities:PGE 的付款）和信用卡交易 （从信用卡的 Liability 账户到 PayPal 账户的付款）就可以直接从银行数据中导入了。

下载银行的数据可以用 Selenium 来大部分实现自动化。

我目前暂时还没有研究如何把 Costco 的小票数据导入进来，因此大部分非药物的交易仍然只是简单的一笔 Grocery expense，这会给数据带来一些误差（例如，本应计入消费税的部分可能也算作 grocery expense 了）。

话说回来，正如 yegle 说的：数豆子的伟大之处就在于帮助人们意识到自己没几个豆子可以数。