付款申请卡在审批中：审批层级、当前审核人与单据变化核对｜云上订货系统
云上订货 · 更新于 2026-10-08
从原申请审核记录找当前层，不只看未完成
付款申请卡在审批中，先按原申请编号查询，不以等了多久或“未完成”三个字判断哪位审核人遗漏。管理端从资金、付款申请单进入原记录详情，先核收款方、申请人、申请时间、申请原由、源采购单、线下支付及预付款，再核一、二、三级审核人、时间和备注。付款申请的审核与后面的付款确认、付款审核是不同操作。
普通付款申请列表中，原申请未完成、未强制完成且一级审核人为空时显示一级审核；一级已有记录、二级为空才显示二级；二级已有记录、三级为空才显示三级。每层还分别受该层审核按钮权限控制。三层都已有记录仍未完成，可能已经进入添加付款及后续资金阶段，不应再催一级审核。这里说的是列表入口条件，不能据此保证当前所有审核入口均已满足层级与权限要求。
图一把原记录与下一步核对项对应起来。审核人字段表示该层已经留下的记录，不是下一位待办人员名单；下一个审核人需另核企业该层设置及实际用户资格。先排除已驳回、已作废或强制完成，再沿空缺层级查，避免把历史已审核姓名误当还需要再次确认的人。
列表默认按未完成筛选，待审核和待付款是额外查询选项。待审核查询看三层是否有空缺，待付款查询另比较申请线下金额与已付款，不能把筛选名称当成数据库中独立的审批节点。核原创建日期、申请人筛选和仅看本人权限，记录缺行时不重新申请。历史截图与规则说明不能证明当前审批结果，企业入口、人员权限及原申请实际返回仍须分别核对。
图1：原申请状态、各层审核记录与当前入口逐项对应；仅为层级规则示意，不表示本次申请待办状态。
本层按钮权限、审核名单与账户状态分别核
当前层已经确定后，再核谁可以接手。财务设置中的付款申请单有流程启用开关和一、二、三级审核人选择，每层可选择多位；它与原单已审核人员记录不是同一字段。员工岗位是财务、账号启用、能够看到申请列表，都不足以独立证明可以执行某一层审核，需对该层按钮权限及企业保存的人员配置逐项核对。
图二是历史员工列表的角色、账户状态局部，显示超级管理员和启用。它没有显示付款申请审核名单或当前原单，所以不能据此认定这名员工就是一级、二级或三级审核人。先核企业实际员工身份及授权，再交接原申请；不要为使按钮出现临时给超级管理员、改岗位或启用别人的账号，也不要换申请人重建同一业务。
“无一级审核权限！”“无二级审核权限！”或“无三级审核权限！”应分别记录原层级、当前用户及原设置，不合并成不能付款。页面还分别检查人员名单并使用已加载的设置：设置已保存并不保证已打开的申请标签立即读取新名单。名单中能找到本人却仍报无权限，也要保留配置和提示的对应关系，不能仅说重新登录一定解决。
名单匹配与审核权限须按当前账号实际提示核对，不能承诺在设置中选中某人就一定允许审核。发现当前列表没有本层按钮，先核原层已经完成、单据状态及按钮授权；有按钮但被名单提示拦截，则保存原账号与设置时点交接定位。不通过跳过页面、构造请求或修改原审核记录解决人员差异，核的是同一企业原流程。
图2：历史员工角色与启用状态局部，不显示当前付款申请审核名单。
普通与其他采购申请分开看，关闭层级仍核记录
付款申请流程设置有两组：付款申请单设置、其他采购付款申请单设置，各自包含审核一、审核二、审核三，再连接添加付款和完成。普通供应商批量申请按普通申请类型保存。原申请来自其他采购业务时，应看另一组设置；不能用普通申请只开一级，推断所有其他采购也只需一级。
图三用普通申请的一开、二关、三开说明对应审批规则：一级已有记录后，二级关闭时在原保存或审核触发的自动流程中补二级记录，再等待启用的三级。不是从一级直接抹去二级字段，也不表示三级自动完成。三层关闭时可能自动补齐三层；反过来某层开启，就不能仅因下层关闭而认为前层已跳过。
相关自动层级处理发生在保存申请和每次申请审核之后，并使用当时企业对应类型的设置；不能据此认为系统会定时催办或每天重新处理旧申请。关闭层级也可能留下审核人和时间，自动分支沿同一审核方法写入当前操作用户，所以不能仅凭姓名判断该用户曾手工点击那一层。需要结合原层设置、申请类型、操作时点及备注来解释。
层级设置有修改时，先保存原设置与原单各层记录的前后关系，不为疏通旧单临时关闭审批。设置保存本身不作为既有申请已经逐单重新处理的证明，不能承诺关闭后所有卡单自动推进；集团关联设置还可能影响所属店铺，不能把流程调整当作只影响眼前一单。开关示例仅说明记录含义，不表示当前企业已变更设置或补齐审批记录。
图3：普通申请一开、二关、三开的流程算例：关闭二级补记录，启用三级仍待核。
审批前核全部原采购，不把勾选当成缩小范围
出现“存在未勾选的单据，请全部勾选后再进行审核”，卡点在审核确认前的原采购清单核对。申请审核窗口显示原申请号、申请金额、线下申请金额、预付款申请金额、收款方、申请原由，以及关联采购的线下申请、采购号、单据状态、制单人、仓库、备注、订单金额和预付款申请。先核这些原行，再判断是不是缺少勾选。
图四以两张采购分别申请三百元和二百元，总额五百元作核对表。若原计划含预付款一百元，则线下四百元加预付款一百元等于本次申请五百元；预付款和线下是分项，不能把五百再加一百解释成六百。审批前比较原采购与申请分项，而不是看某个供应商总欠款大于五百就跳过逐行审核。
全选或逐行全部选中后，页面才进入最终确认；勾选只是确认已核原清单，不会把仅选中的采购子集另存为缩小后的审批申请。最终审核提交使用原申请编号、修改时间、审批类型与备注，没有提交一份新的所选采购金额清单。因此不应为了放行去勾一张无关采购，也不能承诺取消某行就不会审批原申请中的该业务。
打开原采购详情核状态、金额及原申请关联是否仍一致，已作废采购行变灰也不是自动排除审批的证明。原清单缺行、金额变化或关联错误，先保留原申请和源单编号交接，不在窗口中硬凑全部勾选、不新增采购或新申请替代旧关联。申请保存要求采购清单非空，但不能把曾保存成功等同所有原采购今日仍适用。
图4：两张原采购申请合计500，线下400加预付款100；全勾核原清单，不缩小审核范围。
单据变化与备注分开核，刷新后不反复审批
审核窗口打开时读取原申请详情，提交携带该时点修改时间。提交的窗口时间非空且与原记录不同时，返回“数据已被修改，请刷新页面”，并带修改冲突状态。这是原数据时点不一致，不等同没有本层权限，也不表示银行付款失败。保留旧窗口编号、层级、金额、原由和提示，再重新查询原记录。
图五按打开窗口、原记录变化、原错误和重新查询排列核对项。刷新后先比较申请分项、采购清单及各层人员时间，不仅看按钮还在就立即重试。备注修改、资金关联或其他业务更新都有可能影响原单时点，不能据此认为每种变化都会触发相同的修改时间检查，也不能保证该检查阻止全部同时审批。
该页面的二级审核备注会带入一级备注，三级带入二级备注；最终确认框可核本次备注，长度限制一百字。备注相同不证明重复审核，备注空也不独立证明审核未做；看本层人员与时间。关闭最终确认回到清单时，原待填备注会清空，重新打开先核已有备注与本次意见，不把历史意见直接当成新的付款凭据。
“审核有误，请刷新后重试”对应不能识别的审核类型，不应统一解释为金额超限。对于空白窗口、按钮无反馈或未出现业务提示，记录实际页面时点和原申请，不编成同一错误。当前并发审核、修改时间更新和重复提交后的原申请结果仍需核对，未确认前保持待核；不反复确定，不用驳回、作废或强制完成来消除未知状态。
图5：修改冲突、备注带入和原审核返回分别核，不把刷新当作审批已经成功。
三级通过之后还核付款单，结算状态不代替出款
三层审批已记录后，原申请可能仍显示未完成，并转到添加付款。添加付款入口还要求未强制完成、有三级记录、剩余申请金额大于零及新增付款权限。按钮不出现时核原线下及预付款、已付、正在付款金额与原状态，不只看“三级审核成功”。剩余额度不是供应商银行余额，也不能为出现入口另加一笔预付款。
图六来自历史付款单流程，展示提交、付款确认、付款审核和完成，其中付款确认节点关闭。它是付款单自己的流程，没有展示付款申请的三层审核，不能拿来证明申请一级、二级、三级已经开启或通过。审批卡点在原申请哪层，付款卡点在所关联原付款哪阶段，需要分别查原编号和记录。
原申请详情中有付款记录，列出付款单号、金额、付款制单人、付款审核人和付款状态；预付款记录另列金额、时间、状态与备注，采购记录另列已付及待审核。待确认付款与待审核付款仍是未完成资金阶段，不能因申请审核备注已写齐就要求供应商认为线下款已经到账。历史流程也不作为当前企业的节点设置证据。
还有一种易误判的情况：申请使用预付款时，相关申请保存可能在审批前就扣供应商预付款、增加采购已付并形成原关联记录。原申请尚未审完不等于资金关联必然为零。只读核已有预付款记录和原采购，后续付款不重复计算已扣部分。不能因申请未完成就推定资金没有变化，也不据此作废重建或重新出款。
图6：历史付款单的提交确认审核完成流程，不等于付款申请一级二级三级流程。
原申请原付款一起核结果，不以强制完成补证
完成排查要对同一原申请核当前结算状态、各层审核人和时间、申请分项、已付与正在付款，再对关联原付款及预付款、原采购明细核资金结果。图七把节点完成和资金完成分开：某层审核成功通常增加该层记录，不能据它宣布全部审批、实际出款与采购结清同时完成。
列表的付款状态还可能在没有关联付款记录、但申请结算已完成时显示完成值；因此只见付款状态“已完成”不足以证明有一张真实线下付款单。查看实际付款编号和详情，预付款也核其独立记录。强制完成标记另有专门入口，该强制完成操作会把申请状态改为完成，不自动补一张已付款单；不能用该按钮作为卡单恢复或实际付款证明。
明确失败时查原层是否已有记录，超时或没有返回时同样先查原申请，不重复确认。原层记录刚增加但列表仍旧、或下一个关闭层级尚未按预期补齐，保留原记录和当时设置交接，不重建申请、不补资金、不删除审核历史。驳回备注与作废是其他业务动作，不是刷新方式，也不能为核流程制造新的不可回退结果。
交接资料包括脱敏原申请及采购、付款编号，申请类型和原创建时间，当前空缺层、原审核记录及意见，企业各层启停与名单保存时点，实际用户按钮权限，清单勾选和原金额差异，修改冲突或原返回，已有付款及预付款状态与占用。按最先不一致处定位，分别交接审批与资金负责人。当前名单判断、旧单设置与并发审批结果仍需按原申请核实际记录，规则说明或历史图片不能代替当前审批与资金结果。
图7：核原申请、原付款及预付款、原采购；强制完成状态不代替实际付款记录。
下一步学习
审批后资金关联核对见付款核销失败或超应付；原付款操作见付款单核销。