供应商付款：应付查询、付款申请与支付安排｜云上订货系统
云上订货 · 更新于 2026-10-08
供应商催款时，先说明今天结算哪些采购、已有多少付款正在处理，以及预付款如何使用，再安排实际支付。供方往来差额、采购待付、付款申请和付款单各回答不同的问题。本篇沿历史禽肉采购案例核对这些节点；图中为二〇二六年九月十四日历史操作画面，实际入口和审批规则按当前企业核对，抵扣与付款结果须回原单查验。
从供应商应付找到本次付款依据
在资金业务的供应商应付入口查指定供方，先固定企业、供应商、期间和币种，再看应付欠款、应收欠款、预付款、付款待审核及收款待审核。历史图首供方应付七百五十五元、应收四十六点五元、预付款一百元，两项待审核均为零。另一供方各项为零，因此当时顶部合计与首行相同；不能据此认为企业以后只有这一家欠款。
图1：历史供方往来读数，显示应付755元、应收46.50元、预付100元及结余负608.50元。
小计应付等于应付减应收，七百五十五减四十六点五为七百零八点五元；结余再以预付款减小计，得到负六百零八点五元。这是往来差额，不能直接填写成本次付款，也不证明退货款已到账或双方已经抵账。退货应收若已包含在汇总内，不要再减一次；拟抵账时回退货与采购原号核金额、有效状态及处理记录。
期间查询取采购和退货的提交范围，预付款显示当前余额，不应解释成该期间的期初或期末余额。应付筛选也不能按净结余正负猜测是否还有采购欠款。核对币种与单位后，列出到期原单、争议款、待审核款及已申请款，形成今天处理的采购清单；供方总欠款尚未核清时，不凭合计直接付款。
图2：供方往来差额与指定采购待付分别核来源，当前预付款余额不当期间末余额。
回原采购核收货与已经在处理的款
打开指定采购单，核供应商、仓库、原号、商品规格及结算约定，再查入库情况和付款情况。历史CG-20260914-0001显示已付款零、待审核零、待付款一百五十五元；其RK-20260914-0003已完成入库八公斤，入库金额一百二十四元。八公斤是该条入库记录，不能把入库金额当成已经支付的金额，也不能仅据八公斤推断整张采购的付款条件。
图3：历史同采购原号待付155元，关联入库八公斤、124元，收货和付款分别查看。
按合同或双方已确认的约定区分订货前付款、收货后结算与分批支付。部分入库时核实余货交期、短缺及退货处理，不为了结束催款自行把入库状态改成付款依据。原采购待付一般扣除已付和待审核金额；待审核只代表金额在处理，尚不能计为已付。若采购还有有效付款申请，普通批量付款可能暂不列出该采购，申请入口的可申请额还会扣除有效申请占用。
有款正在审核时，追到原付款号及经办人，查是否已支付、是否待审核、是否已经关联该采购。没有查到列表行，应先核供应商、日期、单据状态和申请记录，不把“没有待付行”当作无欠款。采购员提供原单和收货争议，财务接续资金记录；两边以同一原号交接，避免同一货款既从申请支付又从采购新增付款。
付款申请先核启用规则及预付款处理
需要先申请后安排支付的企业，在财务设置核付款申请流程是否开启，并按实际人员配置一至三级审核人。操作入口还受账号权限与企业规则限制。历史设置图的付款申请未勾选，审核人为空，预付款充值扣款审批也未勾选；这只能说明当时画面，不证明当前企业已经启用，也不能据此承诺所有企业都无须审核。
图4：历史申请开关、三级审核人及预付款审批字段，均按企业实际设置另核。
从供应商业务进入付款申请，确认供方与采购范围，填写支出类别、正数金额及采购分配，再锁定并提交。不能以普通请款描述代替采购关联；分配为空、类别缺失或金额越过可申请额时，先修正依据。申请成功后保留申请原号，查看详情中的当前审核节点和负责人，不凭按钮点击认为已审批通过。
含预付款的申请要特别查保存后的结果：申请保存时可能已进行预付款扣除，并更新原采购已付及关联记录，不能笼统写成审批通过后才扣余额。后续生成付款时，先核申请里已处理的预付款，避免再次抵扣或按全部申请金额追加线下款。申请需变更或作废时，由有权限人员按原流程处理，随后查退回记录、预付款余额及采购资金状态是否一致。
图5：申请占用、保存时预付扣除及后续审核支付分开核，资金是否变化须追原记录。
批量付款逐行分配并锁定本次金额
进入供应商批量付款，核本次列表期间和每张采购待付。普通批量入口初始可能把各行全部待付带入付款金额，不能只改顶部金额就忽略其他原单。按本次结算清单逐行调整，检查行金额合计与顶部本次金额一致，再核预付款和线下金额拆分；列表按采购提交时间排序，不等于系统自动只支付最早一张。
历史图列出九月十二采购待付三百元、九月十三采购待付三百元、九月十四采购待付一百五十五元，前两行金额为空，仅CG-20260914-0001行填八十元，并勾选锁定本次付款。图中没有显示顶部拆款，不能把这张图称为已经用预付款支付八十元或线下金额确定为零。
图6：历史三张原单分别显示逐行付款金额，仅指定行填八十元并已锁定；顶部方式拆分及保存后的有效结果仍须回原记录核查。
若当时可用预付款一百元，本次确实选择使用八十元，且没有其他资金变化，才可计算本次预付款八十、线下零。金额变化后重新核拆款和行分配，不能用计算代替页面最终值。单行不能超过对应待付，预付款不能超可用余额；若提示金额变化或保存失败，刷新原记录后重新核对，而不是重复点保存或把所有余款填满。
图7：原号分配、付款方式、锁定和保存结果的先后关系，八十元拆款仅为带前提的计算。
线下付款登记与采购关联分别完成
线下金额大于零时，核有效付款账户、实际付款人和付款时间，并按企业要求上传凭据、填写备注。流水号必填、唯一性、大额审核人及附件要求按已启用规则执行，不凭历史未勾选画面跳过当前限制。锁定后仍应核收款方、用途、金额和关联采购数量，确认登记内容与真实支付资料相符。
历史新增付款单图显示主账户、金额五十元、付款人、付款时间及“核对后关联采购单”的备注，附件标必填但暂无附件。画面未显示收款方、支出类别、最终付款号或审核状态，因此这里只说明登记字段；五十元表单不能并入前面八十元计划，不能认为这笔已经保存成功或核销到指定采购。
图8：历史独立五十元新增付款表单，缺附件且未展示最终状态，不作为八十元抵扣结果。
填写系统付款单用于记录业务，不会因为选择银行账户就自动完成转账。已有付款尚未分配到采购时，应走该付款的采购关联或核销，不能再新增同额付款。登记后查付款原号、审核状态和核销明细，核分配合计及未核销余额；采购待付未减少时先判断待审核、未关联或原单不匹配，避免把同一支付又充值成预付款。
双端接续前回查原采购与余额
付款或抵扣后，重新打开原采购，分别核已付、待审核、待付及付款记录，再查供方预付款扣款记录与余额。若原待付一百五十五元的采购有效抵扣八十元，且原预付一百元没有其他变化，待付才为七十五元、余额才为二十元。历史手机图显示这两个读数，但没有采购原号标题，不能独立证明前一笔八十元已生效。
图9：历史手机添加付款待付75元、预付余额20元，线下方式选中，只是提交前表单。
手机从采购添加付款，先核与PC接续的是同一原单，再填写本次金额。一次选择预付款或线下方式，不应假定系统自动把二十元预付与五十五元线下混合支付。余额二十元不能支持预付七十五元；需要分笔时先按可用方式完成一笔并回查结果，再依据新的待付继续。手机图备注有长度提示、附件最多四张，与PC独立表单规则可能不同，以各自当前页面为准。
图10：带前提的七十五与二十计算，接续须核付款状态、采购关联及预付扣款，不能从表单认定完成。
提交后无反馈或金额异常，先查原付款、申请与预付记录，再核原采购是否已有同额处理。待审核交审核人接续；未核销交财务核关联；收货或退货争议交采购与仓管核原依据。交接留下供方、采购号、申请或付款号、金额方式、当前节点及下一负责人，不让另一端再次支付同一款。
下一步学习
本篇完成后可继续学习：KC-000146、KC-000148、KC-000414。按上线学习路线顺序推进，遇到对应问题再回查。