应付账款流程图（完整应付周期）
应付账款全周期流程图：发票在各渠道接收、供应商主数据核实、重复与采购订单核对、异常队列、付款批次与期末计提。
什么是应付账款流程图（完整应付周期）流程
应付账款是一项职能，而不是一队等待处理的发票。它负责的范围，是从一份供应商单据在某个渠道到达，到期末组织能够准确说出自己欠了谁、欠了多少的这一整段。这个跨度包含许多在“单张发票流程图”上永远看不到的工作：让供应商主数据保持可信，把异常队列当作一份受管理的积压来运营，编制并审批付款建议清单，在银行放款，把供应商认为你们欠的金额与你们总账上的金额核对上，以及为尚未处理的发票计提。
本模板刻意画得比单张发票宽，也刻意画得比采购窄。它不是一张发票审批图：单张发票经过录入、重复检查、三方核对、科目分配和按金额分级审批的路径，在这里被压缩成一个核对决策和一个预算负责人决策——发票审批流程模板会详细覆盖那条路径。它也不是采购流程：请购、寻源、采购订单开立和收货都发生在这张图开始之前，采购申请和采购订单模板会在那里接手。本页的深度落在审批之后——付款批次和期末结账，正是应付账款不再只是一个处理团队、而开始成为资金与控制职能的地方。
大多数应付职能会在五个可以预见的地方出问题，而这五个地方在这张图上都看得见。发票从没有人接入接收环节的渠道进来，于是重复检查根本看不到它们。供应商的银行信息仅凭一封邮件就被改掉。异常被丢进一个没有负责人、也没有账龄的队列，悄悄变成下个月的未入账负债。付款建议清单是按谁催得最凶来编的，而不是按到期日和付款条件。而期末计提漏掉了仍然躺在异常队列里的发票。这张图横跨五条泳道（供应商、应付会计、预算负责人、财务控制经理和资金部）和六个阶段，让上述每一个失效点都有一个具名的负责人，而不是笼统地归给“财务”。
本流程图涵盖的内容
本模板包含
- 覆盖整个应付职能而不只是一张发票的五条泳道：供应商、应付会计、预算负责人、财务控制经理和资金部；横跨六个阶段：接收、校验、科目分配与审批、异常队列、付款批次和期末结账。
- 多渠道接收：在任何检查开始之前，把所有到达路径汇入同一个队列，随后录入应付系统，这样任何渠道都无法绕过后面的控制。
- 把供应商主数据作为一个控制步骤：“供应商与银行信息是否已核实？”决策，带有一条“信息有变”分支通往“通过回拨确认银行信息变更”，之后发票才能继续往下走。
- 把重复检查放在所有核对和科目分配工作之前，并设有“重复发票已拦截并记录”的出口，让疑似重复的发票停在那里，而不是被悄悄删掉。
- “是否引用了采购订单？”这个分岔：有订单的发票走“订单、收货与发票是否一致？”，无订单的发票走预算负责人的“无订单发票是否批准？”决策；差异分支和争议分支都汇入同一个异常队列，在那里登记疑问、由供应商开出贷项通知单或更正发票，再由“疑问是否已解决？”把发票送回入账，或者终止于“发票已拒收并退回”。
- 单张发票的流程图永远到不了的付款周期和期末结账：“编制付款建议清单”、财务控制经理的“付款批次是否已批准？”决策及其退回建议清单的“修改”回路、资金部在银行的执行、应付会计发出的付款通知书、供应商对账单核对，以及“为未处理发票计提并结账”。
何时使用本模板
- 你们要编写或更新一份必须端到端覆盖整个职能的应付账款政策或 SOP——包括付款批次和期末结账，而不只是发票审批。
- 你们要组建或重组共享服务中心，应付会计向财务控制经理、再向资金部的交接必须写明，而不是靠默契。
- 你们要准备一次针对付款周期的审计或内部控制穿行测试，问题在于谁入账、谁批准付款批次、谁在银行放款。
- 在发生一次重复付款、一次错付，或一次试图变更银行信息的事件之后，你们要复核控制措施，需要说明控制点在哪里、由谁执行。
- 你们要为应付自动化、电子发票或 ERP 迁移划定范围，接收渠道、异常原因代码和付款日历必须在配置之前先达成一致。
运作方式
列出发票可能进来的每一个渠道
把它们全部写下来：共享邮箱、供应商门户、EDI、纸质邮件，以及直接寄给某位预算负责人或某个厂区的发票。任何一条没有接入接收步骤的路径，同时也跳过了重复检查，所以要么把它接上，要么把它关掉。记下哪些渠道是自动化的、哪些需要人工处理——积压就是在那里形成的。
把供应商主数据规则定下来
写明谁可以创建或修改供应商记录，以及谁核实银行信息变更、如何核实。要用主数据中原有的号码给供应商打电话，绝不用发票或变更申请上的号码；录入变更的人和批准变更的人必须分开。记录下由谁核实、何时核实、核对的是哪位联系人。
设定核对容差和无订单发票的路径
把你们真实的价格和数量容差写在“订单、收货与发票是否一致？”这个决策上，并写明哪些支出必须有采购订单。然后决定：一张本应有采购订单却没有的发票该怎么处理，让它成为一个有记录的例外，而不是预算负责人悄悄批掉的东西。
给异常队列配上原因代码和账龄
把单一的疑问步骤换成你们自己的原因代码——例如价格差异、无收货记录、无采购订单、交付有争议，或供应商信息缺失。为每个代码指定负责人，并按天数约定催办和升级的时点。一个没有负责人、没有账龄的队列，就是发票被遗忘的地方，也是期末意外的来源。
确定付款日历和付款批次的审批人
定下多久跑一次付款批次、建议清单如何筛选（到期日、付款条件、即将失效的现金折扣），以及哪些不纳入。然后写明谁审批建议清单、谁在银行放款，并让这两个角色与编制清单的人、以及任何能修改供应商银行信息的人分开。
商定期末要计提哪些内容
决定财务控制经理为哪些内容计提：已收到但尚未收到发票的货物和服务，加上仍在异常队列中未结的全部项目。商定这份清单由谁提供、在结账时间表的哪个节点产出，以及计提在下期如何冲回，让队列体现在账上，而不是藏在账后。
把这张图走一遍，并只保留一个已批准的版本
和一位应付会计、一位预算负责人、财务控制经理以及资金部一起复核这张图，把它改成他们实际在做的事，而不是政策上写的事。然后把商定的版本纳入版本控制，并从应付账款政策中链接过去，让大家依据现行的图工作，而不是依据旧培训材料里的一张截图。
常见问题
应付账款流程包含哪些步骤？
一个完整的周期是：从任一接收渠道收到发票并录入应付系统；确认供应商存在于已批准的主数据中，并核实任何新增或变更的银行信息；检查是否重复；判断是否引用了采购订单；有订单的发票与采购订单和收货记录核对，无订单的发票送预算负责人做科目分配和审批；把差异和争议转入异常队列，与供应商解决；已批准的发票入总账；编制付款建议清单；取得付款批次的批准；执行付款并发出付款通知书；核对供应商对账单；以及为期末尚未处理的发票计提。
应付账款流程和发票审批有什么区别？
发票审批是应付账款里的一个环节。它覆盖单份单据从收到到具备付款条件的过程：录入、重复检查、核对或科目分配，以及由与金额相称的合适人员审批。应付账款流程则是围绕这个环节的整个职能。它还包括让供应商主数据保持可信、把异常队列当作带负责人和账龄的积压来管理、把已批准的发票汇总成付款建议清单、取得付款批次的批准并执行、核对供应商对账单，以及为尚未处理的部分计提。如果你们只需要详细的审批路径，就用发票审批流程图；如果你们需要说明整个职能如何运转、资金实际在哪里流出，就用这一张。
应付账款应如何处理供应商银行信息变更？
把它当作一个控制步骤，而不是一次事务性更新。核实变更申请时，要用主数据中原有的号码给供应商打电话，绝不用申请里给出的号码，并且要找已知的联系人，而不是发邮件的那个人。录入变更的人和批准变更的人必须分开；记录下由谁核实、核对的是哪位联系人；在变更确认之前，暂停对该供应商的付款。要求改付款账户是一种反复出现的欺诈手法，它通常表现为一封看似可信的邮件，来自真实供应商的地址，或与之高度相似的地址——正因如此，核实必须在申请进来的那个渠道之外进行。
付款批次应该由谁审批？
由编制它的人以外的人审批，也要由能修改供应商银行信息的人以外的人审批。在大多数组织中，应付会计编制付款建议清单，财务控制经理或财务总监依据授权矩阵批准，资金部在银行放款——通常还要有第二位银行授权人做双重控制。审批人需要看到按银行账户和币种汇总的金额、被排除的项目，以及任何异常情况，例如新供应商或首次付款，而不只是一个付款笔数。让这三个角色彼此分开，正是审计员在穿行付款周期时会查看的职责分离。
应付账款为什么要在月末为未处理的发票计提？
因为权责发生制要在货物或服务被接收的期间确认费用，而不是在发票碰巧被处理的期间。结账时总有两类项目否则会被漏掉：已收到但尚未收到发票的部分，以及已经在公司内、但仍躺在异常队列或等待审批的发票。财务控制经理为两者都计提，让本期的成本和负债完整，并在发票入账时冲回计提。这也是异常队列的意义超出应付职能的原因：一个没有负责人、没有账龄的队列，会让计提变成一个估计，而不是一份清单。