付款截图与已签名 CEP：你的对账任务能接受什么？

问题：图片不是原始记录

银行应用截图会显示金额、日期，可能还有追踪码。它可以被裁剪、编辑，或者根本属于另一笔转账。CEP（电子付款凭证）是一笔现有 SPEI 付款的原始电子凭证，可以带有签名以及把它绑定到唯一一笔交易的数据。读者要做的决定很具体：对账任务在把发票标记为已付之前，可以接受什么证据，又必须把什么留作未决。截图可以作为发起查询的线索，但不应成为任务所接受的依据。

产品检查什么，不检查什么

mx-cep 产品为已获授权的现有付款取得 CEP，并查看其签名与交易绑定。输入包括操作日期、追踪码、汇出和接收机构代码、账户、金额以及授权参考号。输出报告任务状态、原始证据可用性、签名状态和精确交易绑定。边界同样重要：它不发起转账，也不能证明当前账户控制权、身份或某笔对外付款是安全的。数据源访问限制可能延迟任务，因此结果可能在一段时间内保持待处理。商户执行需要当前能力、授权和已接受的报价；文档本身不是真实查证的证据。

假设场景与预期 fixture 输出

假设：某合成商户的一张发票显示一笔入账转账，并附有客户截图。任务提交操作日期、追踪码、两个机构代码、账户、金额和授权参考号。合成合约示例精确返回：status 为 pending，original_available 为 false，signature_status 为 not_checked，transaction_binding 为 not_checked，verified 为 false。本示例不会向任何提供方发出真实请求。正确的解读是：目前什么都没有被确认——原始凭证不可用，签名未检查，CEP 也未与发票匹配。发票保持开放，标注为等待证据，既不是已付，也不是欺诈。

为你的应用提出的接受规则

以下是建议的应用设计，不是产品已实现的行为。只有当 verified 为 true、original_available 为 true，且 signature_status 和 transaction_binding 都报告了你已明确映射的成功检查时，才把付款视为有证据。将绑定的交易与你自己预期的金额、账户、机构和日期逐项比对，而不是只信任单个标志。把 pending、不可用、not_checked 以及任何未知值都当作无定论。发货或放款的决定应作为你代码中独立的业务规则；一份匹配的 CEP 只说明付款发生过，不说明对方就是其所声称的人，也不说明向其付款是安全的。

不产生重复请求的失败处理

任务待处理时，把任务标识与发票及截止时间一起保存，然后用 get 读取状态，或用 recover 恢复任务，而不是为同一笔付款再提交一次请求。数据源访问限制带来的延迟是预期内的，不要把它变成拒绝。如果超过截止时间仍无结论，把发票转入人工复核并记录原因。如果绑定失败，标记为不一致交由人员调查；可能是输入有误，也可能是转账不对。绝不能让超时、错误或截图默认填补空缺。

接受检查清单

在对账中依赖它之前，请确认：上述合成输出被解读为等待证据，而非已付；verified 为 false 永远不会把发票标记为已付；待处理和不可用保持无定论；每次请求都记录全部六项输入和授权参考号；重复运行复用已有任务而不是创建重复任务；不一致进入复核；放行决定与付款证据分离；团队明白该 fixture 是合成合约示例，不是真实验收，在取得商户授权和已接受报价之前不假定任何真实能力。

检查这项功能

https://gridzen.ai/tools/mx-cep/ · 核对输入、输出与能力边界。以下命令只读取产品说明，不执行真实请求。

gridzen tools --product mx-cep

来源与范围

https://gridzen.ai/tools/mx-cep/ https://gridzen.ai/guides/current-capabilities/ 依据已检查的来源快照与本地模拟；建议的业务规则属于设计建议，不代表已证明的生产行为。内容使用 AI 辅助写作，并经过独立审稿。