MAKE + JODOO

使用 Make + Jodoo 进行 AI 发票异常审核

使用 Make 与 Jodoo 执行发票异常审核,返回异常类型、挂起原因、付款就绪状态、分配审核人、预算负责人、建议处理方案和优先级,并将结果存储为可跟踪的 Jodoo 记录。

使用统一的审核标准检查发票异常数据将异常类型、挂起原因、付款就绪状态、分配审核人、预算负责人、建议处理方案和优先级写入 Jodoo让负责人队列和跟进状态保持可见先用 Make 验证方案,再将工作流适配到生产数据源公开演示使用 Make 的 Run once 模式,因此截图可以展示 webhook bundle、模块气泡、操作次数以及场景历史中的 HTTP 响应。

视频演示

Make 演示中会发生什么

视频展示了来自 Atlas Packaging Co. 的 INV-2026-1048 因 PO 金额不匹配且缺少收货确认而进入工作流,随后由 Jodoo 存储运营记录。

  1. Custom webhook 接收申请

    来自 Atlas Packaging Co. 的 INV-2026-1048 因 PO 金额不匹配且缺少收货确认而进入工作流。

  2. Make 准备结构化审核字段

    工作流会明确保留异常类型、挂起原因、付款就绪状态、分配审核人、预算负责人、建议处理方案和优先级,而不是返回一段松散的文字。

  3. HTTP 模块写入 Jodoo

    已测试的运行会将审核结果发送到 Jodoo,并从桥接层接收一个 Jodoo 数据 ID。

  4. Make 验证过程可检查

    公开演示使用 Make 的 Run once 模式,因此截图可以展示 webhook bundle、模块气泡、操作次数以及场景历史中的 HTTP 响应。

  5. Jodoo 保留团队记录

    Jodoo 应用会存储供应商名称、发票编号、发票日期、发票金额、PO 编号、到期日和异常标记,供审核和跟进使用。

演示摘要

Make 审核申请,Jodoo 跟踪后续处理

这种实现方式适合希望使用可视化场景画布、Run once 测试和模块历史记录的运营团队。本页面会清晰展示可视化场景配置、真实运行过程以及 Jodoo 回写结果。HTTP 模块的证据也直观可见:方法、接口地址、请求体类型、解析后的响应和完成状态都可以查看,无需打开代码编辑器。

Make 场景

Make Custom webhook 接收示例载荷数据,HTTP 模块将结构化字段发送到 Jodoo。

结构化决策

工作流会为 INV-2026-1048 返回异常类型、挂起原因、付款就绪状态、分配审核人、预算负责人、建议处理方案和优先级。

Make 成功运行

Make 运行历史展示了 HTTP 模块完成情况、操作详情以及 Jodoo 数据 ID 响应。

Make 实现细节

先从 Custom webhook 开始,粘贴示例申请,让 Make 推断 bundle,然后再将决策字段映射到 HTTP 模块的请求体中。

发票异常方案细节

对于发票异常审核,Make 可以在基础回写之后,将 PO 不匹配、缺少收货确认以及预算负责人审批等情况分派到不同路径。

Jodoo 回写

Jodoo 会存储发票异常记录,并让下一步操作保持可见。

运营跟进

建议的下一步操作是挂起付款、申请收货确认,并请预算负责人批准差异。

可复用工具包

交付工具包包含手册、Jodoo 字段蓝图和 Make 工作流方案。

平台配置说明

Make 的专属特点

Jodoo 记录模型可以保持一致,但不同 AI 智能体 平台在搭建方式、测试视图和正式交接上各不相同。

  • 设置验证

    该验证使用 Run once,因此传入的 bundle 和 HTTP 响应都可见。

  • 操作路径

    HTTP 模块让方法、URL、请求体类型和响应解析过程都可检查。

  • 方案重点

    场景历史会以可视化方式记录操作、耗时和回写响应。

  • 生产规划

    生产规划应涵盖 webhook 负责关系、router、错误处理器和操作用量。

  • 证据细节

    公开演示使用 Make 的 Run once 模式,因此截图可以展示 webhook bundle、模块气泡、操作次数以及场景历史中的 HTTP 响应。

  • 运行证据

    HTTP 模块的证据也直观可见:方法、接口地址、请求体类型、解析后的响应和完成状态都可以查看,无需打开代码编辑器。

  • 搭建细节

    先从 Custom webhook 开始,粘贴示例申请,让 Make 推断 bundle,然后再将决策字段映射到 HTTP 模块的请求体中。

  • 实施路径

    当高价值合同、紧急发票或信息缺失的情况需要不同的 Jodoo 队列时,可在基础验证后使用 router。

  • 防护要点

    在将 Run once 验证转为正式启用的工作流之前,请检查操作用量、webhook 负责关系和场景调度。

  • 审核控制

    请在 HTTP 模块周围添加错误处理器,以便回写失败时可重试或转入人工审核路径。

  • 场景方案

    对于发票异常审核,Make 可以在基础回写之后,将 PO 不匹配、缺少收货确认以及预算负责人审批等情况分派到不同路径。

  • 工作流适配

    HTTP 模块的请求体应在明确映射的字段中保留挂起原因、付款就绪状态、异常类型和分配审核人。

工作流工具包

搭建同样的发票异常审核闭环

查看手册,复制工作流方案,并在适配 Make 工作流时使用 Jodoo 字段模型。

解决方案手册

您的团队可复用的内容

Make 处理可视化场景;Jodoo 存储发票异常审核字段,用于负责人队列、审核状态和跟进。

业务工作流Jodoo 字段模型智能体 提示词上线检查清单

可复用工作流

工作流负责判断,Jodoo 让工作持续推进。

  1. 01

    Custom webhook

    使用 INV-2026-1048 启动发票异常测试。先从 Custom webhook 开始,粘贴示例申请,让 Make 推断 bundle,然后再将决策字段映射到 HTTP 模块的请求体中。

  2. 02

    Make 场景

    Make Custom webhook 接收示例载荷数据,HTTP 模块将结构化字段发送到 Jodoo。

  3. 03

    HTTP 模块

    将结构化 JSON 发送到 Jodoo 回写桥接层。HTTP 模块的证据也直观可见:方法、接口地址、请求体类型、解析后的响应和完成状态都可以查看,无需打开代码编辑器。

  4. 04

    验证响应

    显示平台成功运行和 Jodoo 数据 ID。公开演示使用 Make 的 Run once 模式,因此截图可以展示 webhook bundle、模块气泡、操作次数以及场景历史中的 HTTP 响应。

  5. 05

    Jodoo 队列

    存储用于负责人审核、状态跟踪和跟进的字段。在将 Run once 验证转为正式启用的工作流之前,请检查操作用量、webhook 负责关系和场景调度。

工作流闭环

从 Make 发票异常审核到 Jodoo

  1. Custom webhook 先使用合成数据接收或启动发票异常审核。

  2. Make 应用聚焦的审核指令,并返回异常类型、挂起原因、付款就绪状态、分配审核人、预算负责人、建议处理方案和优先级。

  3. HTTP 模块将结构化输出发送到 Jodoo 回写桥接层,并接收一个数据 ID。

  4. 对于发票异常审核,Make 可以在基础回写之后,将 PO 不匹配、缺少收货确认以及预算负责人审批等情况分派到不同路径。

  5. HTTP 模块的请求体应在明确映射的字段中保留挂起原因、付款就绪状态、异常类型和分配审核人。

  6. 场景历史对 AP 很有用,因为每一张测试发票都会在一次可视化运行中保留其 bundle、路径、操作次数和响应详情。

  7. 在验证完成后,Make 可以增加用于发票批次的 aggregator、用于重复发票检查的数据存储,以及面向 AP 异常负责人的 Slack 或邮件模块。

  8. 先从 Custom webhook 开始,粘贴示例申请,让 Make 推断 bundle,然后再将决策字段映射到 HTTP 模块的请求体中。

  9. 当高价值合同、紧急发票或信息缺失的情况需要不同的 Jodoo 队列时,可在基础验证后使用 router。

  10. Jodoo 会创建发票审批工作流记录,并存储供应商名称、发票编号、发票日期、发票金额、PO 编号、到期日、异常标记、异常原因。

  11. 团队会审核队列、分配负责关系,并完成下一步操作:挂起付款、申请收货确认,并请预算负责人批准差异。

  12. 在将 Run once 验证转为正式启用的工作流之前,请检查操作用量、webhook 负责关系和场景调度。

  13. 请在 HTTP 模块周围添加错误处理器,以便回写失败时可重试或转入人工审核路径。

字段映射

将 智能体 输出转为 Jodoo 字段

智能体 或来源数据Jodoo 记录字段
源申请详情供应商名称、发票编号、发票日期、发票金额
审核决策字段异常标记、异常原因、编码状态、付款就绪状态、审批状态
工作流响应来源平台、原始工作流输出

AGENT 方案

提示词与结构化输出

Make 角色

审核一条发票异常审核申请,并返回 Jodoo 可存储、分派和汇报的结构化字段。先从 Custom webhook 开始,粘贴示例申请,让 Make 推断 bundle,然后再将决策字段映射到 HTTP 模块的请求体中。

审核说明

使用 INV-2026-1048 的示例上下文,判断异常类型、挂起原因、付款就绪状态、分配审核人、预算负责人、建议处理方案和优先级,并让建议的下一步操作保持具体。对于发票异常审核,Make 可以在基础回写之后,将 PO 不匹配、缺少收货确认以及预算负责人审批等情况分派到不同路径。

回写约定

通过 HTTP 模块发送可预测的 JSON 对象;Jodoo 每次运行都应接收相同的字段名。当运营团队希望通过画布、过滤器、router 和模块级运行历史来解释交接过程时,Make 很有帮助。

必需输出

返回异常类型、挂起原因、付款就绪状态、分配审核人、预算负责人、建议处理方案、优先级、source_platform、agent_confidence 以及用于审计上下文的原始工作流输出。

Make 控制项

在将 Run once 验证转为正式启用的工作流之前,请检查操作用量、webhook 负责关系和场景调度。请在 HTTP 模块周围添加错误处理器,以便回写失败时可重试或转入人工审核路径。记录清楚谁负责 webhook URL,以及谁有权限编辑承载生产申请数据的模块。

发票异常实现说明

对于发票异常审核,Make 可以在基础回写之后,将 PO 不匹配、缺少收货确认以及预算负责人审批等情况分派到不同路径。HTTP 模块的请求体应在明确映射的字段中保留挂起原因、付款就绪状态、异常类型和分配审核人。场景历史对 AP 很有用,因为每一张测试发票都会在一次可视化运行中保留其 bundle、路径、操作次数和响应详情。在验证完成后,Make 可以增加用于发票批次的 aggregator、用于重复发票检查的数据存储,以及面向 AP 异常负责人的 Slack 或邮件模块。

{
  "invoice_number": "INV-2026-1048",
  "vendor_name": "Atlas Packaging Co.",
  "invoice_amount": 18640,
  "po_number": "PO-7782",
  "exception_type": "PO 金额不匹配",
  "hold_reason": "金额不一致且缺少收货确认",
  "payment_readiness": "暂停付款",
  "approval_status": "例外评审",
  "assigned_owner": "AP 例外处理",
  "budget_owner": "Maya Chen",
  "recommended_resolution": "暂停付款并请求差异审批",
  "priority": "高"
}

JODOO 入门应用

发票异常入门应用

为您的团队适配发票异常审核工作流时,可使用此字段模型、视图和自动化。

包含字段

  • 供应商名称
  • 发票编号
  • 发票日期
  • 发票金额
  • PO 编号
  • 到期日
  • 异常标记
  • 异常原因
  • 编码状态
  • 付款就绪状态
  • 审批状态
  • 分配审核人
  • 预算负责人
  • 建议处理方案
  • 原始工作流输出

推荐视图

  • 异常审核
  • 付款挂起队列
  • 预算负责人审核
  • 可付款
  • 全部发票提交

自动化规则

  • 在 Make 返回结构化输出后创建一条 Jodoo 记录。
  • 将高优先级或异常记录移动到正确的负责人队列。
  • 当存在信息缺失或挂起原因时,通知建议的负责人。
  • 在审计上下文中保留原始工作流输出。

上线检查清单

上线前需要确认的事项

  • 在激活场景之前,先将合成数据发送到 Custom webhook。
  • 修改后重新打开 HTTP 模块,并确认已保存的 JSON 映射。
  • 使用场景历史确认状态、操作情况和响应请求体。
  • 仅在基础回写稳定后,再添加 router、过滤器和通知。
  • 在将 Run once 验证转为正式启用的工作流之前,请检查操作用量、webhook 负责关系和场景调度。
  • 请在 HTTP 模块周围添加错误处理器,以便回写失败时可重试或转入人工审核路径。
  • 记录清楚谁负责 webhook URL,以及谁有权限编辑承载生产申请数据的模块。
  • HTTP 模块的请求体应在明确映射的字段中保留挂起原因、付款就绪状态、异常类型和分配审核人。
  • 场景历史对 AP 很有用,因为每一张测试发票都会在一次可视化运行中保留其 bundle、路径、操作次数和响应详情。
  • 在验证完成后,Make 可以增加用于发票批次的 aggregator、用于重复发票检查的数据存储,以及面向 AP 异常负责人的 Slack 或邮件模块。

实施参考

为您的团队保留配置细节

工作流

从 Make 发票异常到 Jodoo 记录

Make 负责可视化场景处理;Jodoo 保留团队可筛选、分配和审核的记录。

  1. Custom webhook 先使用合成数据接收或启动发票异常审核。

  2. Make 应用聚焦的审核指令,并返回异常类型、挂起原因、付款就绪状态、分配审核人、预算负责人、建议处理方案和优先级。

  3. HTTP 模块将结构化输出发送到 Jodoo 回写桥接层,并接收一个数据 ID。

  4. 对于发票异常审核,Make 可以在基础回写之后,将 PO 不匹配、缺少收货确认以及预算负责人审批等情况分派到不同路径。

  5. HTTP 模块的请求体应在明确映射的字段中保留挂起原因、付款就绪状态、异常类型和分配审核人。

  6. 场景历史对 AP 很有用,因为每一张测试发票都会在一次可视化运行中保留其 bundle、路径、操作次数和响应详情。

  7. 在验证完成后,Make 可以增加用于发票批次的 aggregator、用于重复发票检查的数据存储,以及面向 AP 异常负责人的 Slack 或邮件模块。

  8. 先从 Custom webhook 开始,粘贴示例申请,让 Make 推断 bundle,然后再将决策字段映射到 HTTP 模块的请求体中。

  9. 当高价值合同、紧急发票或信息缺失的情况需要不同的 Jodoo 队列时,可在基础验证后使用 router。

  10. Jodoo 会创建发票审批工作流记录,并存储供应商名称、发票编号、发票日期、发票金额、PO 编号、到期日、异常标记、异常原因。

  11. 团队会审核队列、分配负责关系,并完成下一步操作:挂起付款、申请收货确认,并请预算负责人批准差异。

  12. 在将 Run once 验证转为正式启用的工作流之前,请检查操作用量、webhook 负责关系和场景调度。

  13. 请在 HTTP 模块周围添加错误处理器,以便回写失败时可重试或转入人工审核路径。

JODOO 记录

Jodoo 存储什么

工作流运行后,Jodoo 会保留稳定的发票异常字段:供应商名称、发票编号、发票日期、发票金额、PO 编号、到期日、异常标记、异常原因。

供应商名称发票编号发票日期发票金额PO 编号到期日异常标记异常原因编码状态付款就绪状态审批状态分配审核人预算负责人建议处理方案原始工作流输出

真实测试运行

一个 Make 工作流已将发票异常写入 Jodoo

这些截图使用合成数据,展示了 Make 配置、成功运行以及工作流创建的 Jodoo 记录。

Make 与 Jodoo 的发票异常审核配置

Make 场景配置

Make Custom webhook 接收示例载荷数据,HTTP 模块将结构化字段发送到 Jodoo。

Make 成功完成发票异常审核并回写 Jodoo

Make 成功运行

Make 运行历史展示了 HTTP 模块完成情况、操作详情以及 Jodoo 数据 ID 响应。

根据 Make 输出创建的 Jodoo 发票异常审核记录

Jodoo 回写

发票异常审核结果已写入 Jodoo,界面可见供应商名称、发票编号、发票日期、发票金额、PO 编号和到期日字段。

FAQ

常见问题

关于如何将 AI 智能体 平台与 Jodoo 记录、工作流和应用模板配合使用的解答。

这个 Make 发票异常审核是否经过端到端测试?

是的。该验证使用了合成数据、一次真实的 Make 运行,以及一张经过确认的 Jodoo 回写截图和证明清单。

为什么要用 Make 做发票异常审核?

当运营团队希望使用可视化场景画布、Run once 测试和模块历史记录时,可以选择 Make。随后由 Jodoo 保留可持续追踪的记录,用于审核和跟进。

这个 Make 实现与其他平台示例有什么不同?

公开演示使用 Make 的 Run once 模式,因此截图可以展示 webhook bundle、模块气泡、操作次数以及场景历史中的 HTTP 响应。先从 Custom webhook 开始,粘贴示例申请,让 Make 推断 bundle,然后再将决策字段映射到 HTTP 模块的请求体中。对于发票异常审核,Make 可以在基础回写之后,将 PO 不匹配、缺少收货确认以及预算负责人审批等情况分派到不同路径。

工作流运行后,Jodoo 会存储什么?

Jodoo 会存储供应商名称、发票编号、发票日期、发票金额、PO 编号、到期日、异常标记、异常原因、编码状态、付款就绪状态,以及用于审计上下文的原始工作流输出。

之后可以连接生产源数据吗?

可以。先从已验证的合成数据运行开始,等发票异常审核的结构稳定后,再接入表单、门户、收件箱、API 或内部系统。当高价值合同、紧急发票或信息缺失的情况需要不同的 Jodoo 队列时,可在基础验证后使用 router。

哪些内容应继续由团队审核?

工作流可以准备决策字段,但负责人仍应审核业务风险、付款或法务审批,以及最终运营决策。请记录清楚谁负责 webhook URL,以及谁有权限编辑承载生产申请数据的模块。

下一步

将发票异常转为可跟踪的后续处理

先从一次已验证的 Make 运行开始,再复用同样的回写模式处理相邻的审核队列和运营交接。在将 Run once 验证转为正式启用的工作流之前,请检查操作用量、webhook 负责关系和场景调度。