Clerked

快速结论

Clerked 是原 Mod AI 更名后的自主应付账款平台，主张由 AI clerk 从 AP 邮箱接收发票，一路处理数据提取、GL 编码、PO 匹配、审批、付款和 ERP 回写。它面向有一定发票量、多个实体或复杂 ERP 的财务团队，而不是个人记账工具。产品价值在于减少 AP 人员的重复录入与追单，让例外单据进入人工队列；风险也恰好来自同一处：它触及供应商身份、银行信息、会计科目、审批和真实资金流，属于高影响自动化。

因此，不建议用“touchless”理解成取消财务控制。正式部署应把 Agent 限制在已批准的权限内，保留制单、审批、放款角色分离，关键支付实行双人控制，并让供应商开户或银行账户变更走独立回拨验证。所有模型判断、人工覆盖、ERP 写入和付款动作都应形成不可随意修改的审计记录。公开网站隐私政策明确不覆盖产品数据，因此不能据此确认生产环境中的发票、ERP 和付款数据如何处理；采购前必须拿到适用于产品数据的 DPA、安全附件和子处理方清单。

核心功能

• AP 邮箱与发票处理：接收发票和供应商邮件，提取抬头、金额、税项、行项目、PO 与付款条件，并将异常交给人工处理。
• GL 编码与匹配：根据历史记录和 ERP 上下文建议总账科目，支持发票与采购订单、收货信息的二向或三向匹配；宣传准确率不能替代客户自己的抽样验证。
• 审批工作流：按金额、实体、部门、供应商或异常情况路由审批，可用自然语言表达规则，但最终生效规则必须经过财务与内控负责人复核。
• 付款编排：根据到期日、折扣和现金计划准备付款；银行账户变化、新供应商和大额支付应强制人工复核与双人授权。
• ERP 双向同步：官网列出 QuickBooks、NetSuite、Xero、SAP、Oracle、Workday、Dynamics、Sage Intacct 等集成，并称 ERP 保持系统记录源。
• 例外与审计：记录单据状态、匹配差异、审批和操作历史，为月结、审计抽样和供应商查询提供线索；日志保留与导出能力需在合同中确认。

适合人群

• 中型企业 AP 团队：发票量已让邮箱、手工编码和审批催办成为稳定瓶颈。
• 多实体或多 ERP 组织：需要统一入口，同时让各 ERP 继续作为会计记录源。
• 内控成熟的财务部门：已有职责分离、付款限额、供应商主数据验证和审计流程，能约束自动化权限。
• 愿意做分阶段上线的团队：先只读和建议，再开放低风险写入，最后才评估受控付款。
• 不太适合的人群：发票量很小、没有采购与审批制度、希望无人监督自动放款，或无法取得产品数据 DPA 与安全证据的组织。

使用场景

• AP 邮箱分流：识别发票、贷项通知、对账单和供应商问询，把无法确定的邮件送给专人。
• 发票录入与编码建议：提取多页单据和行项目，生成 GL 与成本中心建议，由会计确认后写入 ERP。
• PO 匹配与例外管理：比较订单、收货和发票，针对数量、价格、税费或重复单据差异创建处理队列。
• 审批与付款准备：按政策路由审批并生成付款批次，但将最终释放资金保留给独立授权人。
• 月结和审计支持：汇总待处理发票、拒绝原因、审批时间和人工覆盖记录，辅助完整性检查。

价格与版本

Clerked 是专有 B2B 软件，采用销售沟通和定制报价。官网曾展示过起步价格表述，但实际成本会受发票量、实体数、ERP、集成深度、付款能力、实施服务和支持级别影响，因此不能把营销页数字当作固定成交价。没有可验证的永久免费版本；采购前应要求包含实施、迁移、定制连接器、超额用量、支持、续约涨幅和退出导出的总价方案。

POC 不应只比较“每张发票成本”。建议建立真实样本集，覆盖无 PO 发票、部分收货、贷项、重复票、银行变更、跨实体和异常税项，测量直通率、错误逃逸率、人工处理时间和误付款风险。合同还要明确模型或规则更新后如何回归测试，以及失败时能否回退到人工流程。

国内访问与使用体验

Clerked 面向海外企业市场，本页按需要国际网络标记。对中国团队而言，能打开官网不等于适合处理境内票据或资金流程；中文发票、税务字段、本地银行通道、数据跨境和 ERP 本地化均需要单独验证。先用脱敏或合成数据做演示，不要在仅签署网站条款的情况下上传真实发票、供应商账户或付款文件。

截至核验日，公开网站隐私政策明确排除产品数据，只适用于网站访问与线索等范围，不能用来说明 Clerked 如何处理客户 ERP、发票、邮件、供应商、银行和付款数据。数据处理地点、保留与删除、加密、租户隔离、备份、事件通知、模型训练用途、子处理方、数据导出和 DPA 状态均应向厂商书面确认。公开材料只支持“正在推进/追求 SOC 2”这一谨慎表述，不能写成已经通过或持有有效 SOC 2 报告；采购方应索取当前证明并核验报告范围、期间和例外项。

优点

• 从邮箱到 ERP 与付款准备覆盖较完整，减少多个点工具之间的交接。
• 把标准发票与例外队列分开，有机会让 AP 人员集中处理真正需要判断的事项。
• ERP 集成目录较广，适合先检查现有财务栈是否在支持范围内。
• 自然语言规则便于业务表达政策，但仍可落回明确的审批和审计流程。
• 如果保留角色分离和双人控制，可在不取消内控的前提下提高直通处理比例。

不足

• 定制报价和实施依赖使总成本难以从官网直接判断。
• 生产数据 DPA、子处理方、保留期及 ERP/发票/付款数据政策无法仅凭网站隐私页确认。
• SOC 2 只能按“推进中”看待，不能在未取得报告前视为已认证。
• 自主付款属于高风险能力，配置或主数据错误可能直接造成财务损失。
• 实际准确率高度依赖客户票据、科目表、供应商历史和 ERP 集成质量。
• 中国发票、税务、银行和数据跨境适配缺少足够公开证据。

替代品对比

常见问题 FAQ

Clerked 和 Mod AI 是什么关系？

Clerked 是原 Mod AI 的新品牌与产品入口。本站保留旧条目为草稿档案，新公开条目使用 Clerked 名称和 clerked.ai 官网，不把二者当成两个不同产品。

Clerked 的价格是多少？

它采用销售沟通和定制报价，公开营销数字不能视为固定成交价。应按发票量、实体、ERP、集成、付款与实施范围取得完整报价。

Clerked 已通过 SOC 2 吗？

现有公开信息只支持其正在推进或追求 SOC 2，不能据此声称已经认证。采购方应索取最新报告或证明，并检查范围、审计期间和例外。

网站隐私政策能覆盖发票和 ERP 数据吗？

不能。公开网站政策明确排除产品数据；生产环境的发票、邮件、ERP、供应商和付款数据需要单独的 DPA、安全附件、子处理方与保留删除条款。

可以让 Clerked 自动批准并直接付款吗？

技术上产品强调自主流程，但治理上不应取消职责分离。新供应商、银行变更、大额或异常付款应设置独立验证、双人授权和可审计的人工放行。

如何做安全的试点？

先用脱敏样本做只读评估，再开放编码建议和低风险 ERP 写入。只有在权限、审计、回滚、供应商验证和双人付款控制全部验收后，才评估资金动作。

总结

Clerked 值得高发票量团队评估，但它不是普通效率插件，而是进入财务记录和支付链路的高影响系统。正确的采购顺序是先验证数据协议与安全证据，再做只读 POC，随后测试 ERP 写入与例外处理，最后才讨论付款。若厂商无法明确产品数据 DPA、SOC 2 状态、租户隔离、日志和退出机制，或者组织自身没有职责分离、双人控制与人工复核，就不应开放自主支付权限。