跟做财务的朋友聊自动报销，几乎所有人第一反应都是「先把纸质票拍下来识别成文字」。真做起来会发现，识别只是最轻松的那一步。真正耗时间的是后面那几件小事：这张票是不是已经报过了、这张票的价税合计跟明细对不上、这张票的抬头写错了不能报、这个月一共多少张分别归到哪个项目。
这些活儿的共同点是：规则清楚、重复度高、但必须一笔一笔核——正是适合交给 Agent 的那类工作。这篇讲 OpenClaw 做「发票识别 + 报销整理」的完整一条线，从票怎么进来，到台账怎么出去。全程会强调一件事：Agent 负责整理和提示，最后一锤定音的权利仍然在人手里。
第一步：把票收进来，先解决三种入口
收票环节最常见的问题是入口太多、格式太杂。先把入口收成三条，后面的处理才谈得上标准化：
- 邮箱附件。电子发票最常见的到达方式。让 Agent 定期扫指定邮箱，把带「发票」「行程单」这类关键词的附件拉下来归档，其他邮件不碰。这一步和 OpenClaw 收发邮件 里的分类逻辑是同一套。
- 手机拍照 / 相册同步。纸质票和出租车票的场景。人拍完丢进一个约定好的目录，Agent 定时扫这个目录。
- 扫描件目录。有些公司有专门的扫描流程，只要盯着那个目录就行。
三条入口统一落到一个「待处理」目录，文件名保持原样，绝对不要在收票阶段改名——原始文件是唯一凭证，改名会让后面所有追溯变难。文件怎么按规则归档、重复文件怎么判重，站内 整理本地文件 里有可以直接复用的做法；识别 PDF 扫描件和图片里的文字属于基础能力，OpenClaw 怎么读取文件 那一篇把 PDF、图片扫描件的处理路径讲得比较细。
第二步：票面要素结构化，字段清单要一次定全
识别不是「把文字读出来」，而是把票面读成固定字段。字段清单如果一开始定得太少，后面每次加需求都要重跑全量，很折腾。建议直接定全：
- 票据标识：发票代码、发票号码、开票日期。
- 抬头信息：购买方名称、购买方税号。
- 销方信息：销售方名称、销售方税号。
- 金额信息：金额（不含税）、税额、价税合计、税率。
- 明细行：商品或服务名称、规格、数量、单价、小计。
- 其他：发票种类（增值税专票 / 普票 / 电子发票 / 行程单）、报销人、备注。
其中有一条必须做成硬校验：价税合计要等于「金额 + 税额」，同时要能被明细行的小计合计对上。这是识别错误最集中的地方——小数点看错一位、明细漏认一行、合计栏串到别的字段，都会在这里露出来。凡是对不上的票，不要静默通过，直接标成「待人工核对」扔到一边。
还有两个容易被忽略的差别：
- 电子发票 vs 纸质扫描件。电子发票（PDF）通常有文字层，直接抽字段几乎不会错；纸质扫描件要走 OCR，准确率明显下降，阈值要更严。所以「票源」本身应该作为一个字段存下来，方便后面对不同来源设置不同的信任级别。
- 同名但不同主体。「XX 科技」这种简称能对上十几家公司。校验抬头时不要做模糊匹配，要连税号一起比。
第三步：去重和查验，这两步不能省
去重是报销场景里性价比最高的一道防线。规则很简单：同一个「发票代码 + 发票号码」只能报一次。实现上也简单——把历史台账里所有发票号做成一个集合，新票进来先查一遍。
但有两个细节必须处理：
- 同一张票被拍了两次。照片可能来自不同人、不同时间，文件指纹不一样，但发票号一样。靠发票号判重就能拦下来。
- 跨期重复。上个月报过的票，这个月又混进来了。所以判重必须查完整历史台账，不能只查当期。
查验这一环更敏感。发票真伪查验涉及对外查询，属于「对外部系统有影响」的动作，必须留人工确认。稳妥的做法是：Agent 负责把待查清单整理好、把查询结果原样记录下来，但不自动提交、不自动重试。这和站内 客户可见动作怎么管 讲的是同一个原则——凡是能被外部看到的动作，最后一按要由人来按。查验失败或查询超时怎么处理，参考 失败升级规则怎么定，别让它默默重试一整天。
第四步：按规则归集，存疑的单独放
归类规则建议用三段式，命中优先级从上到下：
- 白名单优先。固定的供应商、固定的项目，直接映射到固定科目。占比最高、也最准。
- 关键词规则。按商品明细里的关键词匹配，比如「住宿」「餐饮」「出行」「办公用品」。注意要按明细行匹配而不是按销方名称，同一家酒店可能既开住宿又开餐饮。
- 金额与频次规则。小额高频的往「日常办公」归，大额的强制走人工。
关键是要有一条明确的「存疑」出口。规则命中不了、金额对不上、抬头不匹配的票，全部进一个待定区，由人来定，不要让 Agent 用一个「最像的」科目糊过去——归类错误的成本比多问一句高得多。存疑队列怎么设计、怎么避免任务卡在自动化里，转人工队列怎么设 有现成的思路。
第五步：出台账和报销单
台账是整条线的产物，也是后面所有核对的基础。字段建议包含：序号、开票日期、销方名称、发票号码、价税合计、税额、费用类别、归属项目、报销人、状态（已报 / 待报 / 存疑）、原始文件路径。
几个实用约定：
- 原始文件路径一定要写进台账。这样任何一笔都能一键回到原票，不需要再翻目录。
- 状态用固定枚举，不要自由填。不然月底统计「待报有多少」会变成猜谜。
- 导出 Excel 交给 Agent 做就行，读取、汇总、按项目分类统计这些活很成熟，站内 Excel 表格自动化 那一套可以直接套。
- 和记账对账打通。报销台账是费用账的上游，报表出来之后要和银行流水或账单对一遍，看有没有票报了款没到、或者款到了票没登记。这件事的做法在 自动记账与对账 里讲得比较完整，两篇连起来看基本能覆盖「票—账—款」这一整条。
三条安全边界，一条都不能松
第一，票面信息是高敏数据。发票上有税号、有开户行和账号、有业务往来金额。Agent 处理这些数据必须走最小权限：只能访问约定的收票目录和台账文件，不能顺手能读整个共享盘。权限怎么划、工具怎么白名单，权限管理怎么做 里有系统做法，别图省事给全权限。
第二，查验和提交必须留人工确认。上面已经说过一次，这里再强调：Agent 可以准备、可以记录、可以提示异常，但对外提交这类不可逆动作不要自动化。另外每一次处理都要留下可追溯的记录——哪张票、什么时候入库、识别出的字段、当时判断为什么归到这一类。审计字段怎么设计，审计查询字段怎么设计 里有很具体的清单，报销这种高频场景尤其需要。
第三，原始文件永不删除。无论识别成功还是失败，原始票据一律保留，台账里保留路径引用。这不是「以防万一」，而是财务场景的基本要求——只要有人问「这笔的依据是什么」，你必须三秒钟能翻出来。存储怎么规划、怎么跨机器搬迁不丢，参考 数据备份与迁移；如果想把整套流程固定成随叫随到的能力，接成 MCP 工具形态会更顺手，做法见 OpenClaw 接 MCP 工具。
优缺点和适合人群
优点：月底不再手工核；重复报销这种「低级但致命」的错误被机械挡掉；每一笔都能回到原票；费用按项目统计随时能出。
缺点：初期要把字段和归类规则定清楚，这段工作量不小；纸质票的识别准确率天花板明显，必须接受一定的复核率；规则之外的票仍然要人管。
适合：每月发票量在几十到几百张、有固定报销周期、票源相对稳定的团队或个人。量再大就该上专门的费控系统了；每月只有三五张票的话，手工反而更快。
总结
整条线压成一句话：把「重复但必须逐笔核」的活儿交给 Agent，把「不可逆」和「说不清」的部分留给人。五步照做就行——
- 三种入口收票，原始文件不改名。
- 字段一次定全，价税合计做硬校验。
- 发票号去重查完整历史，查验留人工确认。
- 三段式归类，存疑的单独放到待定区。
- 台账带原始文件路径，和记账对账打通。
最后一句实在话：这套东西的价值不在「省掉了手工」，而在「每一笔都有出处」。核对的时候能立刻翻回原票，比自动化本身更值钱。
