企业官网建设流程全解析

付款单、发票和银行回单联查：字段口径与异常分支

三份记录对不上时，应先锁定业务标识和对账期间，再比金额、时间与关联关系，形成标明原系统来源及待确认项的差异清单。AI 负责受控查询与整理，财务人员负责差异判断、调账和付款等后续决定。

联调时分别记录付款单号、发票号、交易流水号、员工身份、来源系统与查询时间；缺少关联键时保留未匹配项，不能让模型猜测。

检查点 1：同一笔付款被三套记录分别记着

付款这件事从头到尾被三套记录分别记着，各有各的用途。ERP 关心的是业务流程走到哪一步：付款申请审批了没有、付款单生成了没有、应付账款核销了没有、暂估什么时候冲回。发票记录关心的是税务口径：什么时候收到、含税金额是多少、能不能抵扣。银行回单关心的是钱有没有真的动过：什么时候扣的、扣了多少、收款方是谁。

三套记录服务的目标不同，记录的时间点也不同步，对账工作就是这么来的。麻烦出在查询方式上：付款单在 ERP 里查，发票在收票或开票记录里查，回单在网银或资金系统里查，三处各有各的查询入口和筛选条件。有经验的会计靠手工在几份导出的表格之间比对，这是完全可行的做法，只是当供应商多、单据杂、跨月业务多起来之后，比对的量会迅速超过人力能稳定处理的规模。

三份记录 主要回答的问题 常见存放位置
付款单与应付核销状态 业务流程走到哪一步、这笔应付清了没有 ERP 付款单、应付账款、供应商往来
发票记录 税务口径与实际入账金额 进项收票记录、销项开票记录
银行回单与流水 资金是否真实收付、金额与日期 网银导出、资金系统、回单影像

三份记录缺一份都完不成核对，而把它们放在一起看，是人工最耗时的那一步。

检查点 2：常见不一致，分别要到哪里找证据

把差异先归类，查什么、到哪里查就清楚了。下面几类覆盖了付款对账中常见的差异形态；实际企业里字段由哪个系统保存，仍要看各自的系统建设情况。

差异现象 可能的成因位置 需要对齐的字段
金额差一点点 银行侧或发票侧 付款金额与银行实际扣款额、含税与不含税口径、手续费与汇差等可解释项
状态一边已清一边未清 ERP 核销动作与银行到账时间不同步 付款单核销时间、银行回单日期、是否落在同一对账期间
有付款无发票，或有发票无付款 票据流转与付款流程分属不同环节 发票号与付款单的关联关系、预付与暂估的处理方式
一笔付款对应多张发票 合并付款或分批开票 付款单与发票的对应关系是一对一还是一对多

这张表只列可能性，不代表其中任何一项已经发生，也不是结论。

差异金额往往很小，小到容易被当成尾差放过。金额小并不等于可以忽略，它可能是手续费这类正常项，也可能是入账口径本来就不一致。要分清这两种情况，得看原始单据，只看差异金额的大小说明不了什么。

检查点 3：一次核对按什么顺序走

按固定顺序核对，每一步都建立在上一步已确认的事实上，不容易越查越乱。

先锁定范围：确定一个供应商（或客户）、一段对账期间、一类单据。范围不锁定，后面的比较没有基准。
再把三份记录排到一起：优先用付款单号、发票号或银行交易流水号这类在两边都能找到的业务标识串联。找不到对应标识的部分单独列出来，这部分信息本身就是结论的一部分。
先比金额：统一含税与不含税口径之后再比，确认差额是否等于手续费、汇差等可以解释的项目。
再看时间：付款单的核销时间与银行回单日期是否落在同一对账期间，跨期业务的差异通常出在这里。
最后看关联关系：存在一笔付款对多张发票、预付与暂估并存的，确认对应关系由谁在 ERP 里维护、规则是否稳定。
汇总成差异清单：每行写清业务标识、三份记录各自的取值、记录来源系统、差异类型，并标明哪些已证实、哪些因权限不足无法核对。

这份清单同时是一张待办分工表。资金侧的时间差交给资金岗核实，发票侧的交给税务或收票岗，ERP 侧的关联关系交给应付会计确认。AI 把该找谁、该核什么整理出来，核实动作仍由对应岗位完成。

检查点 4：差异查出来之后，哪些动作必须回到人

查到差异只是把问题定位到了具体单据上，处置动作是另一回事，而这一层不适合交给模型自动完成。

调账、冲销、修改核销状态、补录发票，这些都是写操作。按已确认的产品能力，新增、修改、删除和审批默认要求员工确认后才生效。如果后续把处置动作也接入进来，比如由 AI 在原有 ERP 页面上预填调整凭证或核销说明，那属于页面预填，页面预填不等于提交成功，一切以页面回执或目标系统的实际结果为准。

需要守住的判断边界是：差异清单说明哪些记录彼此对不上，不等于认定哪一方有责任，也不等于对税务处理给出结论。这两类判断都有对应的岗位和外部规则，AI 提供的是核对过的事实与出处。

数据边界同样要写清楚：员工账号看不到的其他供应商付款、未授权的成本科目或跨期间数据，查询结果里应当写明「该部分证据缺失，需有权限的人补充」，不能用推算填满。星云 PLUS 采用两层权限判断，连接器只决定当前员工能否调用某项能力，功能权限与数据权限仍由目标系统按其账号规则最终判断，因此不同岗位拿到的同一份查询，数据范围本来就应该不同。

检查点 5：同一项对账能力，不同岗位看到的数据不同

应付会计关注付款单核销与供应商往来，资金岗关注银行实际收付与资金计划，成本或管理会计关注入账口径。用同一套查询能力服务这些角色时，最容易踩的坑是「一份结果发给所有人」。

按岗位收敛的做法是：把对账查询能力按员工、用户组或组织授权，同一项能力只发给需要它的角色；数据范围则继续由 ERP、资金系统各自按员工账号判断。这样应付会计看到的是付款与核销，资金岗看到的是银行收付，跨范围的数据不出现在查询结果里，无需先查出来再在界面上隐藏。

检查点 6：首个对账场景怎么验收

不要一上来就覆盖全部供应商，也不必先接完所有系统。选一个供应商、一段时间、一类单据，先把这条链路走通，再谈扩展。

验收项 要回答的问题 证据形态
结果可核查 差异清单与人工核对结果是否一致 取一组人工已核过的样本做对照，结论一致或差异有说明
权限与原系统一致 不同岗位通过 AI 看到的数据范围有没有被放大 与原系统中的可见范围逐项对照
确认机制到位 场景里的写操作是人工确认还是允许自动执行 逐项配置的记录，并以页面回执为准
审计可追溯 每次查询能否还原 能查出是谁、在什么入口、用了哪项能力、对哪个系统、结果如何，支持查询与导出
异常有表现 系统不可用、数据缺失或权限不足时是什么表现 结果明确提示，不静默返回空值

边界清晰的单场景，典型验证周期可以很短，但正式项目周期要以场景范围和系统条件评估为准，不作为承诺。

核对清单

联调表至少记录员工、能力、单据号、来源系统、时间、权限结果、审计标识和原系统回执。遇无权限、跨期、重复候选或回执不明，列明待人工核查。页面预填 ≠ 提交成功。

延伸阅读：官网完整原文