- 01起因是「未分类的记录越堆越多」
- 02机制的流程
- 03获取未处理的明细
- 04邮件搜索的技巧
- 05分类规则
- 06登记为经费
- 07定期排查「误入其他分类的经费」
- 08最终判断交给专业人士
- 09尝试后的感受
- 10适合这样的人
- 11总结
早上好，我是まさきん。
我有一个规模不大、一直在做的个人副业。经费的记账本身可以用会计SaaS完成，但「这笔银行卡消费到底是什么经费」，回忆起来其实挺费功夫。
于是我做了一个机制，让AI核对银行卡明细和邮件里的收据，把经费分类这一步也一并自动化。这次连API的调用方式，以及实际踩过的坑，都会一起介绍。
起因是「未分类的记录越堆越多」
把银行卡跟会计SaaS对接之后，消费明细会自动导入。但「这笔付款到底是什么」，光靠这些数据是看不出来的。结果还是要靠回忆去做分类。
记忆会一点点变淡。所以我决定，把「回忆」这个环节本身交给AI去做。
机制的流程
做的事情分为以下4个阶段。
- 从会计SaaS的API获取还没完成分类的银行卡消费明细
- 搜索金额相同、日期相近的订单确认邮件或收据邮件
- 把两者对照，确定具体内容
- 根据确定的内容，把经费分类，并作为交易登记到会计SaaS里
关键在于，光靠「明细」或者光靠「邮件」都不够，只有把两者对照起来，才能确定具体内容。
获取未处理的明细
用会计SaaS的API获取明细时，每条明细都带有表示处理状态的标记。要只针对未登记的明细进行处理，就用这个标记来筛选。
GET /api/1/wallet_txns
query: { company_id, start_date, end_date, limit: 100 }
返回的明细里，只有状态显示为「未登记」且未核销金额大于0的部分，才是需要处理的对象。已登记或设置为忽略的明细，会被排除在外。因为这类接口经常需要分页获取，我会把时间范围拆成多段分别确认，避免跨月的时候出现遗漏。
邮件搜索的技巧
如果直接把邮件正文原样交给AI读取，信息量太大，有时会达到Token上限。所以我会先缩小范围，再把内容交出去。
首先，用订单确认邮件或收据邮件的发件地址，做一个时间段的搜索。
search_threads query: "from:[email protected] after:2026/09/01 before:2026/09/30"
即便找到了符合条件的邮件，如果把正文整个交给AI，有时候还是会碰到Token上限。这种情况下，我会对保存下来的邮件文件做关键词搜索，只挑出写着金额或商品名称的那几行。
# 从已保存的邮件文件中,只筛选出金额和日期相近的示例
grep -l "3,980円" ./mail_archive/*.eml | xargs grep -l "2026-09"
用金额和日期这两个线索去缩小范围，候选就会减少到几件左右。缩小到这个程度之后，才把对应的部分交给AI去核对。很多邮件光靠标题或开头的摘要就够用了，只获取需要的范围是这里的窍门。
归入经费的支出里，也混着通信费这类固定支出。工作也会用到的手机费，是最容易让人纠结怎么分摊的一类。这么一想，重新审视一下资费方案，或许也是个办法。
分类规则
内容确定之后，我会分成以下3类。
| 分类 | 内容 | 处理方式 |
|---|---|---|
| 副业的直接经费 | 与副业直接相关的耗材、服务 | 附上业务分摊的说明,计入经费 |
| 参考书籍、资料费 | 用于理解业务的书籍等 | 作为一般资料费计入 |
| 个人支出 | 与副业无关的私人购买 | 排除在经费之外,作为业主借款处理 |
判断不清的情况，我不会勉强往经费这边靠。没有把握判断的支出，会先当作个人支出处理，并标记为日后需要重新review的对象。
登记为经费
分类确定之后，用会计SaaS的API作为交易登记。
POST /api/1/deals
body: {
company_id,
issue_date: "2026-09-15",
type: "expense",
details: [{
account_item_id: <经费科目的ID>,
amount: <金额>,
description: "◯◯耗材(附业务分摊说明)"
}],
payments: [{
amount: <金额>, date: "2026-09-15",
from_walletable_type: "credit_card", from_walletable_id: <银行卡的ID>
}]
}
这里有一个需要注意的地方。这个登记操作，在会计SaaS内部只是「新建一笔交易」，并不会自动跟原本未处理的明细关联，也就是核销。仅仅登记了交易，明细的状态依然是未处理。
所以登记完成之后，我一定会在会计SaaS的界面上，手动把明细和刚才创建的交易关联起来。如果省略这一步，同一笔支出就会被重复计入，这一点我格外留意。
定期排查「误入其他分类的经费」
即便做了自动化，分类出错也不会归零。所以我每个月会让AI排查一次，看看有没有本该归入副业、却被放在一般分类里没处理的记录。
具体做法是，用API获取损益表报告，找出那些不是计入副业专用科目、而是计入一般科目的经费。然后，再用交易清单API获取各科目的明细，根据摘要栏的关键词和金额的倾向，让AI列出那些「原本应该归入副业分类」的记录。
找到符合条件的交易后，用PUT替换科目。
PUT /api/1/deals/{交易ID}
body: { company_id, issue_date, type: "expense",
details: [{ id: <既有明细ID>, account_item_id: <正确的科目ID>, amount, description }] }
这里也有一个需要注意的地方。如果details里没有带上既有的明细ID，就会被当作新增而不是更新处理。一定要带上既有的ID，这是正确转账的前提条件。
排查出来的内容，我会自己确认一遍，只把需要的部分做替换。
最终判断交给专业人士
这一点我想反复强调。这个机制说到底只是提高「记账前的准备工作」的效率。最终的经费分类判断，以及分摊比例是否合理，我都遵从税理士等专业人士的判断。
AI的分类终究只是初步方案。尤其是涉及业务分摊的部分，我不会只靠自己判断，而是以向专业人士确认为前提来运行。
尝试后的感受
最省心的一点，是「这笔到底是什么付款」的回忆工作消失了。只要邮件这份记录还留着，具体内容的确定就可以交给AI。
另一方面，分类的最终确认我一定会自己过目。尤其是个人支出和经费之间的界线，我觉得单靠机械判断还是有风险的部分。
适合这样的人
- 副业或个人经营中银行卡支付的经费较多、记账总是被拖延的人
- 邮件里留有不少订单确认或收据的人
- 对会计SaaS的API对接和AI应用有一定熟悉度的人
总结
把银行卡明细和邮件对照起来核对，这个思路本身并不特别。但每次都自己动手做，还是交给机制去做，所花的功夫会有很大差别。
光靠API登记并不会完成明细的核销，把这类容易踩的坑也一并了解清楚，实际动手的时候就不容易卡住。在坚持最终判断交给专业人士的前提下，我觉得把准备工作这一部分顺利机制化了。
整理这些的过程中，通信费也成了重新审视的对象。工作也会用到的手机费，是分摊判断上最让人纠结的一项支出。既然如此，先把方案本身整理清楚，或许也是个不错的办法。
本文包含联盟营销广告。如果您通过本站链接申请相关商品或服务，我们可能会从合作企业获得报酬。此外，运营者是乐天集团的员工，也可能通过员工推荐计划获得报酬。文章内容与评价均基于运营者的真实体验与调查完成，与是否存在广告无关，但请您在阅读前了解上述关系。详情请参阅免责声明与联盟营销说明。 免责声明与联盟营销说明
本文包含机器翻译内容。正式条件请以乐天移动官方网站的多语言页面为准。
如果您对乐天移动的通信区域·信号状况有疑问，可以通过官方的 电波改善调查申请表 进行咨询。
