早上好，我是まさきん。
freee会计里的未处理明细越积越多，核销迟迟没有进展。这种状态在我这里持续了一段时间。于是我定下了把它改成每月一次自动班次的设计，把决定的内容记在这里。
※本文为发布时的信息，最新条件请以官方网站为准。
- 大约18条未处理明细，连续6次每周检查，条数都没有变化
- 我认为手停下来的原因不在条数，而在于里面混着拿不准的明细
- 核销班次定在每月5日早上7:30，在家里的Mac上运行
- 明细分成3类。能确定的部分每月合并成1个任务，拿不准的明细和贷款还款逐条建任务(每月最多15条)
- 向会计软件登记这一步由人来做。目前只是定下了设计，还没有开始实现
未处理明细连续6次没动
我用freee会计给自己小规模经营的副业记账。银行账户和信用卡的明细会自动导入。剩下的只要确认再登记就行，本来应该是这样的。
可是未处理的明细，有大约18条一直留在那里。我每周检查时都会看条数，它连续6次都没有变。
每周都在看，却不见减少。我觉得这已经不是一句“太忙了”能解释的了。看的机会是有的，手却没有动起来。
手停下来的原因是拿不准的明细
停滞的原因，也许并不是条数太多。我是这么想的。
18条里面，有些明细看起来马上就能登记。另一方面，也混着每次打开都要想半天的明细。是业务支出还是家庭支出?收据在哪里?就是这一类明细。
拿不准的那一条排在最前面，手就停在那里了。排在它后面的简单明细，也跟着一起留了下来。所以我想，把它们混在一起排着，大概就是问题所在。
关于明细的分类，还有一篇商场的信用卡明细不显示店铺名时怎么分类的文章。这次讲的是在那之前的一步，也就是顺序和分法。
与现有核对机制的分工
用AI把明细和邮件互相核对的机制，我已经在另一篇文章里整理过了，就是用AI核对副业经费的机制。核对的具体做法交给那一篇。
这篇文章讲的是它的外围。什么时候运行?在哪里运行?从哪一步开始交给人?说的就是决定这三件事的经过。
即使有了核对机制，如果启动的契机是“想起来的时候”，那就坚持不下去。我那6次正是如此。所以要把它做成定期的班次。
记账原则上要每天做
先确认一下前提，也就是“每月集中做一次到底行不行”这一点。
日本国税厅的《生活税务信息》里是这样写的：为了正确计算所得并申报，需要把每天的交易情况记到账上；账簿和文件需要保存一定的期间。原则始终是每天记账。
所以我并不认为“每月记一次账就可以”。明细的导入和每周的检查，会和以前一样继续下去。改成每月一次的，只是对拿不准的明细做判断的那个场合。
- 官方的表述是“把每天的交易情况记到账上”，并不是说每月记一次账就行
- 月度核销班次，是为了判断积压下来的拿不准的明细而设的场合
- 对自己的记账方式感到不安时，请向税理士或税务署确认
月度核销班次定下来的事
先把定下来的事列出来。
- 运行的地方放在家里的Mac上
- 每月5日早上7:30执行，第一次是下个月5日
- 把未处理的明细分成3类
- 能确定的部分，每月合并成1个汇总任务
- 拿不准的明细和贷款还款，每条明细建1个任务
- 用明细的ID防止重复，每月以15条为上限
- 向会计软件登记这件事本身由人来做
每一条都还停留在“定下来了”的阶段。还没有实现，也没有运行的结果。这部分写在最后讲后续安排的那一节。
明细的3个分类
设计的核心，是明细的分法。
| 分类 | 例子 | 由谁处理 | 任务的形式 |
|---|---|---|---|
| 可以直接确定提案的部分 | 核对得上、科目也没有疑问的明细 | 由人集中确认后登记 | 每月1个汇总任务 |
| 需要判断的明细 | 拿不准是业务还是家用的支出、找不到收据的支出 | 由人逐条判断 | 每条明细1个任务 |
| 贷款还款 | 每月还款的扣款 | 由人逐条确认 | 每条明细1个任务 |
能确定的部分，不逐条建任务，而是合并成1个。没有疑问的明细如果拆成10个任务，只会把任务列表塞满而已。
反过来，拿不准的明细要一条一条分开。我想做成只需要考虑“这一条怎么办”的形式。前后要是还排着别的明细，恐怕手又会停下来。
把贷款还款单独列为一类，是因为它和其他支出要确认的内容不一样。它也是每个月必定会来的东西。所以不把它混进拿不准的明细里，而是做成固定形式的任务。
防止重复与每月15条的上限
逐条建任务的话，会冒出两个担心。
一个是重复。上个月的任务还留着，这个月的班次又跑了一遍，同一条明细就会多出一个任务。所以用明细的ID当记号。如果已经有相同ID的任务，就不再新建。
另一个是数量。拿不准的明细要是一下子变成几十个任务，光看到就不想打开了。因此逐条建立的任务，以 每月15条 为上限。
15这个数字并没有什么深刻的依据，只是为了不让任务列表被塞满而定的参考值。运行起来如果不合适，我打算再调整。
登记由人来做的界线
交给AI的，只到核对和提案为止。向会计软件登记这件事本身，由我在画面上操作。
理由有两个。一个是这和freee会计的思路一致。官方帮助里介绍的流程，是先确认针对明细推测出的内容，然后再登记。
自动登记规则也有两种。按官方帮助的说明，可以选择把设定的内容作为交易自动填入，还是自动登记。前者是“推测”，后者是“登记”。我的3个分类，也许就是把这种区分照搬到了任务的形式上。
| 处理方式 | 是否进行到登记 | 人的确认 |
|---|---|---|
| 用规则“推测” | 不进行(只填入候选内容) | 确认后登记 |
| 用规则“登记” | 进行 | 登记之前没有人工确认 |
| 这次的核销班次 | 不进行(只到核对和提案) | 确认后登记 |
另一个理由是API方面的情况。即使用API创建了交易，明细那一侧仍然会以未处理的状态留着。根据用户的反馈，据说存在这样的现象。现在是否依然如此，我没有确认过。
所以我没有采用“只靠API就把核销做完”这个前提。如果设计成最后一步由人在画面上完成，我想就不太容易受这一点影响。
运行的地方是家里的Mac
运行班次的地方，定在家里的Mac上。云端的定时任务不建。
流程分三段。到了时间，macOS的launchd负责唤起；被唤起的shell脚本做好准备；然后在其中以无界面方式运行Claude Code。所谓无界面，是指不显示对话画面，用 claude -p 传入一次性指令的用法。
| 比较的方面 | 家里Mac的无界面运行 | 云端的定时任务 |
|---|---|---|
| 能看到的文件 | Mac里的文件夹 | 在我的环境中看不到家里Mac的文件夹 |
| 停止运行的条件 | 电源关闭时，要等到下一个指定时间才会执行 | 这次没有调查 |
| 睡眠期间 | 唤醒时执行(Apple资料中的记载) | 这次没有调查 |
| 这次的判断 | 采用 | 不建 |
Apple面向开发者的资料里，有关于launchd指定时间的说明。预定时间正处于睡眠状态时，会在唤醒时执行；电源关闭时，要等到下一个指定时间才会执行。内容大致如此。
不过，这份资料是很久没有更新的存档。现在的macOS是否还是同样的行为，需要在自己手边确认。“每月5日”这种指定该怎么写，也要在实现的时候确认。
关于定时执行的限制，还有一篇Cloudflare Workers免费额度的Cron Trigger上限的文章。在哪里运行，我感觉每次都是最先起作用的因素。
先决定运行位置的理由
在细化这个设计的过程中，我绊了一跤。
从云端的工作环境里，看不到家里Mac的文件夹。我想确认现有的机制是什么样的，却够不到那里。最后是通过别的途径确认的。
这里学到的是顺序。不先决定运行的位置，连确认都推进不了。比起要自动化什么，先要把“从哪里能看到什么”弄清楚。下次做类似的东西时，我也打算从这里开始。
这种对“机制放在哪里”的重新审视，放到家庭的固定支出上也许是一样的。每个月必定要付出去的通信费之类，往往定下来之后就一直没有动过。
月度日程
一个月的流程是这样安排的。
| 时间 | 要做的事 | 负责 |
|---|---|---|
| 每天~每周 | 导入明细并确认条数 | 人(和以前一样) |
| 每月5日 7:30 | 核销班次运行，把明细分成3类并建立任务 | 自动 |
| 5日以后 | 确认1个汇总任务并登记 | 人 |
| 5日以后 | 把拿不准的明细和贷款还款的任务逐条处理掉 | 人 |
5日是月初稍后一点的日子。早上7:30运行的话，当天之内就能打开任务。
账簿的保存年限与家事关联费
拿不准的明细，追究到底大多会归结为两个问题：凭证还留着吗?能说是业务支出吗?
凭证这一边，保存期间是有规定的。日本国税厅的《生活税务信息》(令和8年度版)里，把蓝色申报情况下的保存期间列成了表格。
| 需要保存的东西 | 保存期间 |
|---|---|
| 账簿(分录账、总分类账等) | 7年 |
| 决算相关文件(损益表、资产负债表等) | 7年 |
| 现金存款交易等相关文件(收据、存折等) | 7年(前年的前一年的事业所得和不动产所得金额在300万日元以下时为5年) |
| 其他文件(账单、报价单、交货单等) | 5年 |
把找不到收据的明细放进“需要判断”一类，就是出于这个原因。我觉得这不是一句“以后再找就行”就能放过去的东西。
能不能说是业务支出这一边，则涉及家事关联费的概念。按日本国税厅“税务问答”的说明，家庭生活上的费用不能计入必要经费。不过，有时一笔支出会同时关系到家庭和业务两方面，这就是家事关联费。
能计入必要经费的，只有有限的一部分：根据交易记录等，能够明确区分出确为业务直接所需的金额。资料里是这样写的。这部分我没有只凭AI的提案来决定，而是放进了由人来看的分类。
接下来的工作
剩下的工作有两项。
- 实现之后，用dry-run把本月的部分跑一遍(到月底为止)
- 在实现的一开始，先确认从Mac这一侧有没有读取邮件收据的途径
dry-run是一种试运行方式，不实际建立任务，只看结果。3个分类的分法和自己的感觉是否一致，要在正式运行之前先看一看。
把第2项放在最前面，是出于在运行位置上绊过跤的经验。核对需要邮件里的收据。如果发现从Mac上读不到，就得回头修改设计了。
第一次班次预定在下个月5日。运行的结果，等拿到数字之后再另外写。
常见的失败与陷阱
把拿不准的明细和简单的明细混在一起排着。 我认为我那6次就是这个原因。在最前面的一条上停下来，后面简单的明细也会跟着留下。
把所有明细都逐条建成任务。 连没有疑问的明细也拆开，就会被任务的数量压倒。所以我把能确定的部分合并成了1个。
把运行位置往后放。 不先确认从哪里能看到什么就开始设计，到了确认阶段就会卡住。
把每月一次的班次误当成“每月记一次账”。 官方的原则是每天记账。月度班次是做判断的场合，并不是要降低记账的频率。
以只靠API就能做完为前提来搭建。 有反馈说，登记之后明细仍会以未处理的状态留着。我觉得留出由人在画面上收尾的余地会更安心。
- 是否数过未处理的明细有多少条、已经几周没有变化
- 是否分清了停滞的原因是条数还是拿不准的明细
- 是否确认了从运行班次的地方能看到所需的文件和邮件
- 是否把能确定的部分和需要判断的部分做成了不同形式的任务
- 是否定好了防止同一条明细重复建任务的记号(明细的ID等)
- 是否定好了每月交给人处理的条数上限
- 是否定好了由谁向会计软件登记的界线
- 是否以照常继续每天记账和每周检查为前提
常见问题
Q. 每月只核销一次也没有问题吗?
日本国税厅的表述是“把每天的交易情况记到账上”。写着每月一次就可以的官方说明，我没有找到。所以导入和每周的检查会继续。改成每月一次的，只是判断拿不准的明细的那个场合。
Q. 为什么是每月5日早上7:30?
这样安排，是取月初稍后一点的早上。早上运行的话，当天之内就能打开任务。如果不合适，打算运行之后再调整。
Q. 只用自动登记规则不够吗?
对于形式固定的明细，我觉得规则很合适。不过，留在我手头的是拿不准的明细。规则决定不了的东西，我感觉需要一个由人逐条去看的场合。
Q. 为什么不让AI一直做到登记?
因为官方帮助里的流程，就是先确认推测内容再登记。是业务还是家用的判断，我也希望最后由自己来把握。AI只做到核对和提案。
Q. 家里的Mac在睡眠的话，班次还会运行吗?
按Apple的资料，睡眠期间到了预定时间的话，会在唤醒时执行。电源关闭的话，要等到下一个指定时间才会执行。因为资料比较旧，现在的macOS上的行为要在实现时确认。
Q. 每月15条的上限是怎么定的?
是为了不让任务列表被塞满而定的参考值，并不是有依据的数字。运行之后再调整。
Q. 效果怎么样?
还不知道。这篇文章是定下设计这个阶段的笔记。第一次班次预定在下个月5日，结果会在那之后再写。
Q. 能不能计入经费，是由这个机制决定的吗?
不是。这个机制做的，只到把明细分类并交给人为止。税务上的最终判断，请向税理士或税务署确认。
参考的官方信息
- 记账、账簿等的保存与蓝色申报(日本国税厅《生活税务信息》)
- No.2070 蓝色申报制度(日本国税厅)
- No.2210 必要经费的知识(日本国税厅)
- 通过“自动经理”登记交易(freee帮助中心)
- 设置明细的自动登记规则(freee帮助中心)
- Scheduling Timed Jobs(Apple Developer 文档存档)
- Run Claude Code programmatically(Claude Code 文档)
总结
我认为未处理的明细之所以不动，是因为里面混着拿不准的明细。所以要把能确定的部分合并起来，只把拿不准的明细逐条交给人。预定每月5日早上7:30，在家里的Mac上运行。
目前只是定下了设计，还没有运行。如果你也对着积压的明细动不了手，不妨先数一数“拿不准的明细有几条”，怎么样?
每个月必定要付出去的钱，同样分开来看一看，也许看法就会不一样。通信费等固定支出，方便的话也请打开明细看看。
本文包含联盟营销广告。如果您通过本站链接申请相关商品或服务，我们可能会从合作企业获得报酬。此外，运营者是乐天集团的员工，也可能通过员工推荐计划获得报酬。文章内容与评价均基于运营者的真实体验与调查完成，与是否存在广告无关，但请您在阅读前了解上述关系。详情请参阅免责声明与联盟营销说明。 免责声明与联盟营销说明
本文包含机器翻译内容。正式条件请以乐天移动官方网站的多语言页面为准。
如果您对乐天移动的通信区域·信号状况有疑问，可以通过官方的 电波改善调查申请表 进行咨询。
