跨系统对账智能体

一家集团企业,订单在 ERP、发货在 WMS、回款在财务系统,三套系统各存一份数。月末对账要 5 个工作日,差异定位靠人肉比 Excel;老系统没有 API,数据取不出来。

行业
企业
客户规模
3 地 6 厂区 · 员工 5,400
交付周期
90 天上线
团队配置
1 Echo + 3 Delta
企业:跨系统对账智能体

上线后的变化

6 小时
月末对账周期
原为 5 个工作日
96.8%
差异自动定位率
定位到单据
0
未授权动作
关键动作人工 gate
¥260 万
年化人力释放
财务与运营

口径说明:以上为项目结项时的实测值,基线取自客户改造前的系统日志与人工记录。不同客户的起点不同,这些数字不能直接外推。

改造之前

原来的做法,和它卡住的地方

订单在 ERP、发货在 WMS、回款在财务系统,三套系统各存一份数;月底财务室灯火通明,人肉比 Excel 比一周。

具体卡在哪

  • 三套系统各存一份数,客户与商品主数据差异对三天,对完还可能再变
  • 月末对账 5 个工作日,差异定位靠 Excel 人工比,一条差异要翻半小时单据
  • 老系统没有 API,厂商要么不理、要么报价惊人,想自动化先卡在取数

交付过程

我们做了什么

顺序就是实际推进的顺序。第一步永远是先对齐口径,不是先接流程。

五件具体的事

  • 主数据对齐:客户、商品、组织以一套口径为准,差异清单化、逐条确认后冻结
  • 统一流水号:订单-履约-回款全链路一个号,端到端可追,差异定位到单据
  • RPA 补位:没有 API 的老系统,界面自动化取数,不破坏原系统、不动原厂商
  • 对账 Agent:按规则自动比对,差异生成待办,关键动作人工确认后才执行
  • 审计与观测:每一步留痕,跑偏可回放、可回滚,看板上看得到每一笔流转

项目结束时交付了什么

  • 运行在生产环境里的系统,不是演示环境
  • 带失败案例的评测报告,指标可复现
  • 运维手册(Runbook),财务与 IT 能照着独立处置
  • 架构文档与源码,不留技术依赖
  • 面向财务与运营的培训,以及 30 天陪跑

技术要点

几个决定成败的技术选择

同一个需求可以有很多种做法,下面是我们最终选的那几种,以及为什么。

统一流水号设计

一条业务一个号,从订单跟到回款。没有这个号,端到端对账就是三套系统的数字游戏。

RPA + API 混合取数

有 API 走 API,没有 API 的走界面自动化。老系统不改造、不升级,取数这条路先通。

关键动作人工 gate

涉及金额与状态变更的动作,不经人工确认不执行。自动化的底线是可控,不是放手。

全链路审计

每一次取数、比对、确认都留痕,可回放、可回滚。内审要查的时候,拿得出完整链路。

主数据治理统一流水号RPA 补位人工 gate审计留痕

“以前月底财务室灯火通明,现在六小时出对账结果,差异直接定位到单据。内审来查,链路当场放得出来。”

客户财务总监某集团企业 · 企业

适用边界

这个案例适合谁,不适合谁

照抄别人的方案是常见的踩坑方式。先说清楚边界,比事后解释便宜。

适合

多套业务系统并行、月末对账痛、老系统没有 API、想试点流程智能体的企业。

不适合

只有一套系统的企业 —— 没有断点,就没有自动化的空间。先长业务,再谈集成。

相关案例

其他三个案例