付款核销失败或超应付：采购状态、付款余额与分配排查｜云上订货系统
云上订货 · 更新于 2026-10-08
从原付款单核销，不以供应商欠款代替余额
付款核销要把已经存在的付款单关联到采购单，先找到原付款编号，再核可核销金额。供应商应付里的批量付款可以新增付款并关联采购，资金、付款单里的核销处理原付款已有金额；两个入口共用部分表单，不能看见批量付款标题就断定此次会新增，也不能为解决核销失败再登记一次付款。
管理端只读打开资金、付款单，从原行“核销”进入付款单核销。付款单列表要求原付款单已完成、可核销金额大于零，并受付款编辑权限控制。原行没有核销入口时先核单据状态、余额和权限，不能跳到新增付款弹窗补一张单，也不能通过修改供应商或账户绕过原单状态。
图一是历史供应商应付页：应付欠款七百五十五元、预付款一百元、小计应付七百零八元五角、应收欠款四十六元五角、结余负六百零八元五角并列。它们不是某张付款单的可核销余额。应收与应付也不能未经原记录核对自行抵销；供应商总欠款大于付款原金额时，更不能把全部欠款填成这张原付款的本次核销。
记录原付款单号、供应商、账户、原付款金额、可核销金额和打开时间，核同一编号当前值。历史金额与现有余额不同，先找既有核销及占用记录，不以负结余绝对值或银行账户余额解释。历史画面不能证明当前付款余额或核销结果，当前权限、原付款字段与实际核销响应仍须按同一原单核对。
图1：历史供应商应付页并列欠款、预付款与结余，未显示某张原付款的可核销余额。
原单已完成与新增付款填写是不同结果
核销页顶部显示付款单号、单据状态、付款金额、付款账户、供应商名称和可核销金额，下面填写本次核销。原付款金额保留的是该笔登记金额，可核销显示的是尚可分配部分，二者相同也需要核原编号。待提交、待付款确认、待审核、已完成和作废是不同付款状态，不能把完成付款登记理解为已经审核完成或已全部核销。
历史新增付款弹窗显示账户、五十元金额、付款人和付款时间，备注写核对后关联采购单。画面没有证明原付款已完成，更没有证明这五十元已分给哪张采购。需要查看原付款详情及审核记录，不能依据填好表单或按过确定就计算可核销五十元；附件、付款时间等新增字段填齐也不能解除另一张原付款的状态限制。
核销记录还分待提交核销、待审核核销和已核销。相关核销提交会把金额从可核销移到核销中，并增加采购单待审核付款；审核完成才有另一组明细与占用变化。因此原单可核销减少但采购已付暂未增加，不足以判断资金丢失，先看该笔关联记录是完成还是仍待审核。
例如原付款二百元，已核销八十元，另有三十元核销中，下一次分配不能仅用二百减八十得到一百二十元。以原单当前可核销字段为准，另核核销中金额与采购待审核占用对应关系。发现原记录仍待审核，交接企业原流程和实际凭据；仍待审核的记录应按原流程处理，不通过反审核、撤销核销或另建付款单消除提示。
图2：历史新增付款弹窗填写50元及账户人时间，不能证明原付款已完成或已核销。
采购清单缺行，先核状态日期与付款申请
采购单未出现在核销清单里，先核是不是原付款对应供应商、同一企业、有效记录和允许付款状态。默认待付采购查询包含待入库、待入库部分和已完成，排除待提交、待采购审核、待作废和已作废。不是只有入库完成才可以列出，也不是采购单一经创建就能分配付款；采购审核与资金核销的状态各自核对。
清单按采购提交时间过滤，该查询起止边界包含等于，并按提交时间排序。采购收货日期、入库日期与采购提交时间不是同一字段。只查当天收货却遗漏前日提交的采购单，不能据此认定采购已经付清；先记录原筛选和提交时间，再只读核正确时间范围，不调整原采购时间来让它进入清单。
图三来自历史采购的入库情况页，原采购待付款一百五十五元、已付款和待审核均为零，画面中的入库流程不替代付款结果。入库金额、入库数量不能直接作本次付款金额；某张入库单已完成，也不等于该采购已结清或已完成原付款核销，须回原采购付款情况查资金关联。
还有一个会隐藏待付采购的条件：默认待付查询排除存在未作废付款申请关联的采购记录。该采购可能仍有待付金额，却由付款申请流程承接，不能把清单缺行写成没有欠款。申请查询另有扣申请金额及预付款的口径，不应移植为普通核销公式。保留原采购与申请编号和状态，交接已有申请，不作废申请、不重复申请，也不换供应商新增付款补验证。
图3：历史采购入库页显示待付款155元，入库结果与付款结果分开核。
待付扣审核占用，行上限与付款余额一起核
每张采购的本次分配先对它的待付金额，再核全部非零行合计不超过同一原付款可核销金额。原采购订单金额、已付款、待审核付款和待付是四个字段；不能把原订单金额直接当尚可支付金额。该采购待付口径不套用销售收款的包装物押金公式，也不将供应商应收欠款随意扣入采购行。
以采购金额五百元、已付一百元、待审核五十元为例，默认待付为三百五十元。若原付款仅可核销二百元，本次给这张采购二百元，才同时满足这组示例的行待付和原付款余额；分配四百元即使不超过五百元原金额，也已经超过三百五十元待付和二百元可核销。多张采购时合计还要再核，不能每行都小于二百就认定总额合格。
“付款金额不能大于订单金额”在直接核销保存中比较采购已付加本次分配与订单金额；另一提交路径比较已付、待审核加本次与订单金额。默认待付查询也扣待审核。这些检查并不完全相同，不能把一个提示改写成服务端已检查所有占用，也不能承诺表单通过就证明并发核销一定安全。
操作上保留原付款余额和各采购待审核记录，只分配原业务计划中的金额，每张采购在计划表中列一次，不拆重复行凑合计。这里是人工核对要求，不能据此承诺所有重复行、供应商或企业错误都会返回同一组提示。图四是金额关系算例；实际分配前须核当前占用，并核同时办理及保存后的原单结果；发现差异先查原单，不调小金额反复尝试。
图4：采购待付扣待审核占用；原付款可核销与每行待付均约束分配计划。
核每行金额再锁定，不只看自动分配说明
页面有“锁定本次付款”选项。该核销表单中，未锁定时采购行金额可编辑，锁定后行金额只读；确认前未勾选会提示“请勾选锁定本次付款”。锁定只表示此处确认方案固定，不表示核销已经成功，也不替代每行金额与原付款余额的比较。先核原单和计划行，再确认锁定状态，不能只看到输入框变灰就认为资金已经分配。
图五的历史批量付款清单有三张采购，订单金额及待付分别为三百、三百和一百五十五元，最后一行显示八十元输入，锁定选项已勾选。局部图展示待付、行金额与锁定位置，没有显示核销成功。该画面来自新增批量付款场景，不能用它证明当前原付款核销入口或结果；共同的行核对方法仍可用。
单行金额失去焦点后，超过采购待付可能被截回待付，累计超过原付款可核销时，后面的行可能变成剩余余额或者被清空，顶部合计与关联采购数随之重算。实际提示里出现“采购单核销不能大于采购单待收金额”，在本页仍应对应采购待付列，不能转去客户收款核销处理。确认前再核哪几行保留非零值，以及合计和订单数。
页面说明提到按供应商下单时间自动关联，但不能仅依据说明文字保证修改顶部金额就完整重分配所有行。该核销页面中，顶部与行金额处理还有不同分支，原付款资料来自列表传入；页内重载清单也不能证明原付款余额已重新查询。若改数后行与顶部不一致，保留改前改后值及原提示，回原付款只读查询，不连续点击确定。
图5：历史批量付款清单的三行待付、行金额与锁定选项，不是核销成功记录。
预付款与线下分项，别移植到原付款核销
新增批量付款可能同时使用供应商预付款和线下付款。页面会把本次总额拆为这两项，线下付款金额大于零时还核付款账户、付款时间和付款人，启用附件必填时核原附件。看到“请选择线下付款时间”或“付款附件必填”，先记录所在入口与实际分项；这些是表单条件，不是原付款可核销余额不足的同义提示。
例如两张采购待付分别一百八十和一百二十元，计划共付三百元，使用预付款一百、线下二百，这是新增批量付款的分项算例。新增批量付款保存会检查线下金额、预付款金额以及两者相加，都不能超过所关联采购的待付合计。线下与预付款各自都小于三百仍不够，还要核两项合计；不能把同一百元预付款既放进预付款又重复算成线下到账。
已有付款单核销则应从原付款出发。原单可核销二百元，不能因为供应商还有预付款一百元，就把该次既有核销可用额度解释成三百元。供应商预付款抵扣与原付款分配是不同资金来源，不能为了通过核销校验新充值、转余额或改原账户。图六分别列这两种操作，算例没有在系统新增付款或改变任何预付款余额。
已经填写金额和非零采购行仍提示“请填写本次核销金额”时，也要保留当前顶部、行金额、锁定与分项，不急于再填更大的数。核销提交前还取页面线下分项，不能仅凭输入框非空认定实际提交金额已经正确。分项初始化、输入重算及提交前的金额须在同一原付款单中分别核对；保留页面状态交接，不切换成新增付款或使用预付款强行绕过。
图6：新增批量付款的预付款加线下，与既有原付款可核销余额分别核。
核原付款与原采购的结果，不重复出款
确认弹窗写“将生成付款单并关联采购单”时，是新增付款；写“将在该付款单中关联采购单”时，是原付款核销。确认文字、原付款编号和实际采购清单要同时对齐。页面出现核销成功，也需要回同一原付款查看新关联明细与金额，不能仅以跳回付款列表或采购入库已完成代替核销结果。
直接核销的相关保存会新增已核销采购付款明细、增加采购已付、更新采购财务状态，再扣原付款可核销金额。用原付款可核销二百元、本次分配八十元作核对示例，完成后预期剩余一百二十元，目标采购已付应对应增加八十元；这是核对方向，不能证明当前原付款与采购已经形成这些结果。明细已核销与仍待审核应分别统计，不用原付款总额重复计入采购。
核销只建立既有付款与采购的资金关联，不证明银行此时又划出一笔钱，也不替代实际付款凭据。某张采购已付清，不代表原付款余额已全部核销；原付款没有余额，也不能仅凭这点断定所有采购都结清。核两边原编号、状态、明细与金额，才知道剩余的是待付采购、待审核记录还是未分配付款。
明确失败、超时或没有返回时，先只读查原付款与原采购是否已有本次关联，保留操作时间、原提示和分配表，不反复确定、不复制新增、不作废或撤销原记录补验证。交接原付款及供应商、账户、状态、最新可核销、采购提交时间与状态、待付及审核占用、申请关联、本次每行与合计和原结果，继续定位最先不一致处。当前部署及同数据核销结果仍待核对。
图7：按同一原付款、采购关联明细及状态金额查询结果，不靠重复出款验证。
下一步学习
原付款流程看付款单核销；收款的不同口径看收款核销失败或合计不符。