供应商月底催款，采购员上午提了一张五十元付款单；下午换班的人没看到这张待提交单，又按同一张采购单上传另一份请款资料。财务如果只核“供应商确实有应付”，两张申请都可能通过，银行实际付两次。重复请款并不总是有人故意造假：分批到货、分次付款、先打预付款、退货抵款或人员交接不完整，都会让下一位申请人以为原款尚未处理。避免多付的关键不是看到一张供应商发票就付款，而是把本次申请定位到哪张采购、哪个付款阶段、之前哪些金额已付或正等待审核，以及凭据是否指向同一笔资金。
本篇引用系统中一组可核对画面：某供应商往来汇总有采购应付755元、采购退货应收46.50元、预付款100元；另有一张五十元付款单，先显示“待提交”，后来显示“已完成”。这些数字可以说明为什么同一个供方同时有采购、退货、预付款和普通付款，但不能简单宣称“755－46.50－100－50就是本次可付金额”。预付款是否已经用于指定采购、退货是供方退款还是抵账、五十元付款是否关联原单，都须逐条核。本文重点建立付款前的防重复关口，不以往来总额替代每张采购的可付款判断。
从原采购和实际履约定付款边界，不用供应商总余额直接填请款
采购员先打开供方原采购，核供应商主体、商品、规格、数量、单价、付款约定及交货节点。原采购有二十公斤、实际仅验收八公斤时，若合同约定按验收付款，本次申请只能按已经满足的节点和有效金额判断；未到十二公斤继续跟催或调整，不因供方账单催得急就作已到货。若约定有预付款，先确认预付条款、已经付的比例及剩余节点；若发生采购退货，先分清未到取消和已收后退，两者对库存与资金的处理不同。单靠发票、采购总额或系统顶部的应付汇总，都不足以独立确定“今天可以付多少”。
管理端供应商应付页把一个供方的应付欠款755元、退货相关应收46.50元、预付款100元分列，顶部还有不同口径汇总。该页适合财务定位供方与风险范围，却不能把“结余负608.50元”理解为本次付款申请的上限：它是往来口径的汇总结果，未说明每张采购的到货、合同节点、预付款指定用途和历史付款归属。采购提交申请前应把待付采购单号写清，财务再从汇总下钻到原单和明细。
图1：供应商汇总用于发现应付、退货与预付款并存；本次可付仍要逐张采购核有效履约和已用资金。
一张请款说明“一次付款的用途”，金额相同也要看阶段
采购提出本次五十元申请时，至少要交代原采购编号、供方公司、付款事项、对应商品或批次、约定付款节点、已验收或已达到的条件、本次申请金额和供方收款账户。若是十万元采购的第二期款，备注不能只写“二期”；要写明首期何时付了多少、此次为何到期、付后还剩多少。对方发来的收款账号若与原合同不同，需按企业制度核变更依据，不让一张新账号截图单独推翻原合同信息。线下银行转账、现金支付和预付款余额使用也应分开，因为它们对应的支付凭据和余额变化不同。
现有管理端付款单界面可填付款账户、付款金额、付款人、付款时间与备注，并提示添加附件。画面示例填五十元，备注写着“核对后关联采购单”，这恰好说明备注只是一条提示，不能替代已经完成的采购关联。若采购来源还没确认，审核前应退回核实；不要先把付款单批了，再等付款后才问“五十元对应哪张采购”。附件如果是供应商催款单，还应查原合同与验收；如果是银行付款凭据，则要核它是不是历史已经支付的同一笔。
提交前做“双重查重”：既查已付款，也查在途申请
重复请款最容易漏掉的是尚未付款、却正在审批路上的申请。采购和财务应在付款单列表按供应商、原采购、金额、申请日与凭据检索三种状态：待提交或待审核、已审核待实际付款、已完成并已付款。仅查银行历史只能发现已经出钱的重复；仅查系统完成单，又会漏掉另一张正等审批的五十元申请。若同一采购同一期节点有两张申请，无论申请人不同、附件文件名不同，先暂停后一张，核它们是否指向同一批货和同一张催款单。若确是两笔不同的分批付款，要在两张申请中写明各自的到货批次、到期条件及额度，审核人才有辨别依据。
图片展示这张五十元付款单保存后的状态为“待提交”，付款凭证已附，供应商和主账户可见。待提交不等于已付款，不能拿它减少供应商应付；但它是防重复的重要信号：下一位员工再请款时必须先查到它，确认是否属于同一来源，再决定补充原单、作废错误申请或另起不同付款。若简单认为“还没审核就当不存在”，两张单可能先后进入审批，给付款人造成两次执行的机会。
图2：待提交付款单尚不是已付资金，却必须进入同采购同阶段的查重范围；审核前应补齐原采购关联。
审核人按原采购重算“还能付多少”，不能把汇总数机械相减
假设供方报本期采购755元，又有退货46.50元和预付款100元。有人会写“还要付608.50元”，这在没有核历史用途时只是危险的算式：预付款一百元可能已有八十元抵了指定采购，仅余二十元；退货46.50元可能是供方承诺下期抵款，或者另行退现金，不能同时作为本期抵扣与待收退款。还可能有一张五十元普通付款已给供方，但尚未关联到这三张采购，或者已经在某张采购的待付里体现。审核人需要把每一项标成“哪张采购的哪一次有效抵扣”，再决定本次可付，而不是把几个汇总数字直接相加减。
可操作的审核顺序是：先列出本次涉及的原采购、合同付款节点与实际验收；再核原采购的退货或取消；然后查预付款是否已经使用、余额还在不在；再查所有已完成付款与待审核申请；最后看本次申请金额加上已有支付是否超出该采购在当前节点的可付范围。若来源号为空，附件只是供方总账单，或者备注写“以后关联”，审核人应退回补资料。大额付款可按企业权限让采购负责人确认实物和价格，财务负责人确认资金与往来，付款执行人核收款账户和凭据。流程设置能帮助岗位流转，但不能替任何岗位判断一笔货是否真正到齐。
下面的关口图把同一张采购的请款分成“旧资金、在途审批、当前有效可付”三个篮子。它强调申请金额不是一个孤立数字：只有原单与节点确定、历史付款及待审单均已核，才能把本次五十元放进可执行的范围。若三项中有一项不明，就暂停付款并让对应岗位补证据；暂停不是拒绝供方，而是防止以后重复付后再追讨。
图3：同采购同阶段先看原单和履约，再查已付与在途申请，最后确定本次可付；有未解差异就退回补证。
付款执行与审核完成分别留痕，回头核原单未付和银行流水
付款单审核通过后，付款执行人还要确认企业实际银行或支付渠道已经成功付款，并保留唯一流水或有效支付凭据。若银行支付失败、款项退回或仍在预约状态，不能只凭系统“已完成”三个字宣称供方已经收到。若供方已经收到款，而系统记录仍待审或未关联，财务也不能再支付一次“补齐系统流程”。先把原付款证据与系统单据配对，按正确流程补完归属，再回查原采购待付变化。
示例中五十元付款单后来显示“已完成”，页面还列出制单、确认和审核时间。它与前一张“待提交”画面对应同一个单号，是同一张付款单的状态变化，而不是两笔五十元款。做月结时不应把它们相加成一百元。完成后还要核该款真正对应哪张采购、供应商往来是否只计入一次、银行是否只有一条实际付款流水；若系统附件是付款凭证图标，也要打开核凭据内容和银行状态，不能只看有附件就默认款项属实。
图4：同一单号由待提交到已完成只算一次付款；审过单后仍需核实际银行付款和采购归属。
已经重复付款时，别用第二笔采购单“吸收”错误
若财务发现银行真向供方付了两笔同额款，第一步查两条银行流水是否都成功、收款账户是否相同、分别对应哪两张系统付款单。若其中一张只是系统重复录入而银行只付一次，应纠正系统重复记录并保留操作与复核链路；若银行确实付了两次，要与供方确认多付款的处理：退回原账户，或在双方确认后作为明确的后续采购预付款。不能为了让账面看起来平衡，虚建一张采购单或把第二笔款挂到另一个尚未到货的订单上。这样会把重复付款风险变成虚增采购和库存，后续更难追。
供方愿意退回时，财务记录应收回的款、预计日期和实际退款凭据，关注能否按约回到企业原资金账户；供方建议抵下次采购时，采购和财务需确认新采购是否真实存在、合同是否允许、预付款余额如何体现。无论哪种方式，原两张付款及银行流水不能删除，业务原因和处理结果要可追溯。若员工已将两张系统付款单各核销到不同原采购，先找出错误的那一笔，再按制度调整关系，不用再造一条反向“负付款”让审计链断裂。
月度复盘可抽查三类高风险场景：分批到货付款、预付款与尾款并存、同一采购多人交接请款。每一类至少抽一张原采购，让采购、仓库、财务各自给出有效已到、已付和本次可付，再比对供方账单和银行支付。重复申请率、待审核金额、已付款未关联采购笔数、供方退回多付款的周期，比“本月付款总额”更能反映控制是否生效。系统能够把采购、供应商往来、付款单状态和凭据放在可查询链条上；企业仍要把付款依据、审批权限和银行执行结果落实到具体岗位，才能真正避免一笔采购被付两次。