公司财务每个月要处理几百张报销单，每次月底看到财务同事对着Excel手动核对发票，我都替她眼睛疼。有次她吐槽说“一个员工把奶茶发票报成办公用品，我真没看出来”，我就想能不能做个自动化的报销审核助手。
一开始自己写脚本，用Tesseract OCR识别发票，然后调一个免费的发票验真API。结果识别出来的金额经常把“1”和“I”搞混，验真接口也不稳定，动不动超时。更崩溃的是，公司报销规则几乎每个月都在调——出差餐补从80涨到100，住宿标准分城市三档。每次改规则都得改代码、重新部署、还要担心引入新bug。搞了两个月，脚本勉强能用但维护成本太高。
后来去看Dify和Coze，它们做知识库问答很顺手，但报销流程是一个典型的“输入-处理-判断-输出”多步流水线。而且财务数据敏感，必须私有化部署。正愁的时候，在开源社区刷到一个项目，支持私有部署，还有可视化工作流。节点化设计让我眼前一亮：OCR识别、API调用、条件判断、数据库写入、消息通知——全都能拖拽连线。
我花了一天搭了个智能报销助手。流程：员工上传发票图 → 图像预处理（提高清晰度） → OCR抽取字段 → 税务接口验真 → 规则校验（金额上限、品类白名单、发票日期） → 自动填单 → 推送到财务系统 → 企业微信回执。整个过程不用写后端代码，全在画布里完成。
印象最深的是有一次财务说“能不能加一个重复报销检测，同一个发票号不能报两次”。我加了一个“历史发票号缓存”节点，每次验真通过后把发票号存到本地KV里，下次进来先查重。前后改了不到二十分钟，保存就生效。以前这种功能少说要半天。
槽点也有。画布里节点一多，连线密得跟蜘蛛网似的，有次我把条件判断的分支连反了，导致金额超标的单子反而通过了，幸好测试阶段发现了。还有复杂逻辑比如多张发票合并报销，需要循环累加金额，工作流配起来比写代码费劲。但单张发票的场景是真香。
这个报销助手跑了快一个月，财务同事说现在每天只需要处理异常单，正常单全自动过。老板问我花了多少人力，我说大半天搭流程，后面偶尔改改规则，他一脸不信。我觉得可视化工作流特别适合那些“规则经常变、流程相对固定”的内部工具，不用每次改需求都从头部署。
最后问问大家：你们在做发票识别、报销自动化时遇到过什么坑？发票版式乱、OCR精度低、还是接口限流？评论区来交流一下。
