财务与会计精选

重复付款稽核代理

找出你的精确匹配控制永远抓不到的付款

版本 2发布于 2026年9月2日

8条硬性规则: 它绝不能做的事，每次运行都强制执行
5条移交规则: 它停下并把工作交给人的条件
8个输出字段: 结构化的结果，而不是一段需要反复阅读的文字
≤7步每次运行: 有界的工作：最多 5 次工具调用，由运行时强制执行

设计上即为只读。该智能体没有任何发送、支出、发布或提交的途径。当这一限制本身就是产品时，取消它就等于取消了信任其输出的理由。

版本 2 的实时接线图。工具节点是这个智能体被登记可以调用的能力——除此之外什么都跑不起来。

概览

重复付款是任何财务职能中最可靠地能追回的钱，而几乎每个组织都有。这不是因为粗心——现有的控制只抓得住最简单的那种情况。

应付账款系统会拦住同一供应商同一发票号被付两次。那道检查是精确匹配，而重复付款几乎从来不是精确匹配的。发票既通过邮件来了一次，又通过邮寄来了一次，一次被录成「INV-4471」，一次被录成「4471」。同一个供应商用略有差别的名称建了两次档，于是系统看到的是两个供应商。一张贷项通知被冲在了错误的发票上，让本该冲掉的那一张仍然挂着，然后被再付一次。一张发票既按预付冲销、又按采购订单付了一次。一批付款在银行退回后被重跑，成功的那一半又出去了一次。

这些每一种都能通过精确匹配的控制，而每一种，对一道比对金额、日期接近程度和供应商身份（而不是比对编号字符串）的检查来说都是可见的。

价值的另一半是时间窗。供应商不会主动报告被多付了——那笔贷项就挂在他们账上，如果合作在它被用掉之前结束，这笔钱就没了。

这个智能体把它们找出来，并给你证据。它自己什么也不追回，也不联系任何供应商：要钱回来是一场与你所依赖的人之间的对话。

价值

不用谈判就把钱拿回来

它本来就是你的，而且证据无可争辩。

点名控制上的缺口

这样下一次是被预防，而不是事后被发现。

趁还能追时追回

挂在一个已停止往来的供应商账上的贷项，通常就是没了。

功能说明

按实质匹配，而不是按编号字符串
「INV-4471」和「4471」是同一张发票。任何应付系统里的精确匹配控制都会看成两张。
找出重复的供应商档案
同一供应商用略有差别的名称建了两次。系统看到两个，什么也拦不住。
抓住冲错的贷项通知
贷项冲在错误的发票上，让本该冲掉的那一张仍然挂着，然后被再付一次。
识别重跑的付款批次
银行退回后重跑的一批，其中成功的那一半又出去了一次。
按「还追得回来」排序
一个仍有持续业务量的活跃供应商追得回来。一个已经停止往来的，则是难得多的一场对话。
自己什么也不追回
它不联系任何供应商，也不提出任何主张。要钱回来是一场对话，不是一笔交易。

这会改变什么

这会如何改变你的一周

它接手的工作: 找出被付了不止一次的发票。
目前由谁完成: 应付系统里的重复检查，而它只抓得住精确匹配。
多久一次: 除了那道自动拦截之外，从来不做。
通常的人工投入: 编号、供应商档案和贷项通知都必须先规整，才谈得上比对。

为什么偏偏是财务与会计。真正的重复付款从不精确匹配——这正是它们能通过的原因。「INV-4471」和「4471」、同一供应商建了两次档、一批重跑的付款。而供应商从不主动报告被多付了。

无人值守运行
由你或某个事件启动，然后自行完成。没有什么需要等人坐到工位前。
每一次都是同一标准
第两百件与第一件用同一把尺子衡量。一致性正是人做不到长期保持的部分。
它无法自行采取行动
重复付款稽核代理没有任何发送、支出或承诺的途径。正是这个限制，让依据它的输出行动是安全的。

运行方式

该智能体通过 PROMIVO 运行时在服务器端运行。每次运行都会逐步记录，每次工具调用在执行前都会进行权限检查。

1输入按智能体的输入结构进行校验
2模型claude-opus-5，并自动回退
3工具extract_structured_data
4权限自动执行 READ 级操作；更高的等待你批准
5输出符合输出结构的结构化结果
6日志记录 token、耗时和每一个步骤

演示

演示数据Illustrative sample output, abridged.

输入

{
  "period": "24 months to Aug 2026",
  "currency": "USD",
  "payments": [],
  "dateProximityDays": 90
}

输出

{
  "escalate": true,
  "disclaimer": "An analysis of your own payment records. No supplier has been contacted, no claim raised, nothing offset or reversed, no supplier records merged, and candidates marked needs-checking are reported with the reason they may be legitimate rather than presented as findings.",
  "duplicates": [
    {
      "amount": 18400,
      "payments": [
        "PAY-40218",
        "PAY-41776"
      ],
      "supplier": "Nordvale Supplies",
      "daysApart": 47,
      "mechanism": "duplicate-supplier-record",
      "confidence": "high",
      "controlGap": "The supplier master allows a second record with the same bank details and tax identifier.",
      "recoverability": "live-supplier",
      "whyItMightNotBe": "Nothing. Same amount, same invoice date, same net reference once formatting is stripped."
    },
    {
      "amount": 2260,
      "payments": [
        "PAY-38112",
        "PAY-38119"
      ],
      "supplier": "Harbour Freight",
      "daysApart": 0,
      "mechanism": "rerun-batch",
      "confidence": "high",
      "controlGap": "A batch was rerun after a partial bank rejection. Nothing excluded the payments that had already succeeded.",
      "recoverability": "live-supplier",
      "whyItMightNotBe": ""
    },
    {
      "amount": 1450,
      "payments": [
        "PAY-29940",
        "PAY-31002"
      ],
      "supplier": "Meridian Print",
      "daysApart": 31,
      "mechanism": "exact-repeat",
      "confidence": "needs-checking",
      "controlGap": "",
      "recoverability": "live-supplier",
      "whyItMightNotBe": "Meridian bills a fixed monthly retainer at exactly this amount. This may be two legitimate months rather than a duplicate. Reported rather than filtered out, because a missed duplicate costs more than a check."
    }
  ],
  "supplierGroups": [
    "NORDVALE SUPPLIES LTD and Nordvale Supplies Limited share a tax identifier and bank account. Two records, one supplier — and every duplicate check ran within each record separately."
  ],
  "totalIdentified": 84200,
  "escalationReason": "One duplicate is 18,400, above threshold, and two supplier records share bank details without sharing a name.",
  "controlGapsSummary": [
    "Reference formatting is not normalised before the duplicate check, so 6 of 11 findings were invisible to it.",
    "The supplier master permits duplicate bank details.",
    "Payment batches can be rerun without excluding successful lines."
  ],
  "recoverableFromLiveSuppliers": 71400
}

使用条件

集成

无需集成。

开始之前

付款与发票历史：供应商、编号、金额、日期、采购订单
供应商主数据
贷项通知及其冲销方式
需要全量访问套餐或更高

使用场景

定期应付账款复核

先跑过去两年，然后按月跑。

系统迁移之后

那正是重复供应商档案被成批制造出来的地方。

审计之前

审计师会抽样去找的那条发现，先自己找出来。

付款批次失败之后

重跑是否把成功的那一半付重了。

价格

全量访问

通过您的 PROMIVO 订阅按月计费，可随时取消。

运行会消耗您套餐中的智能体执行次数与 token 额度。参见套餐限额

常见问题

它会去把钱要回来吗？

不会。它绝不联系供应商，也不提出主张。要钱回来是一场与你所依赖的人之间的对话，而语气属于人。

这和我们应付系统里的重复检查有什么不同？

那种是按发票号和供应商做精确匹配。真正的重复付款几乎从不精确匹配——这正是它们能通过的全部原因。

它会产生误报吗？

会有一些，这是刻意的。一笔金额相同、付给同一供应商的合法周期性费用看起来就像重复付款，因此它给出置信度和理由，而不是悄悄把它们过滤掉。漏掉一笔重复付款的代价，高于多查一笔。

评价

客户运行过该智能体后，评价功能将开放。

需要这个智能体换一种做法？

告诉我们要改什么，我们的团队会为您的业务规划一个定制版本。

定制此智能体