采购到付款（P2P）流程图（从需求到付款）
采购到付款端到端流程图：从识别出需求到供应商收到款项——请购、预算与授权审批、合同核查、开立采购订单、收货、三方匹配、无订单例外处理与付款批次。
运作方式
把泳道改成你们的组织
把申请人、预算责任人、采购、供应商、应付账款和财务换成你们真实存在的角色。只有在录入发票和放行付款的不是同一批人时，才把应付账款和财务分成两条泳道；如果一个人两件事都做，就合并它们，而不是在图里留一条从不做事的泳道。如果发票工作放在共享服务中心，就把它写出来。如果收货由仓库而不是申请人来做，就加一条仓库泳道，并把登记收货那一步搬进去。
把两道审批门槛都写成数字
“成本中心是否有预算？”和“是否超过授权审批权限？”在你附上数字之前都是空的。把授权审批权限表按岗位以金额发布，写明判定依据是订单金额还是合同全生命周期金额，并决定同一预算科目下已经占用的承诺如何计入。然后写下一项需求被拆成两张都不超限的订单会怎么处理——拆单以躲开下一级签字，是这道控制最常见的被绕过方式。
把三方匹配的容差定下来
把你们真实的数字放到“三方匹配是否在容差内？”上：价格同时设一个百分比和一个绝对金额上限，以较低者为准；数量的容差要比价格更紧。运费、关税、四舍五入和汇率差异要单独约定处理方式，因为它们造成的匹配失败远多于货物本身。写明谁可以强制通过一次失败的匹配，并把每一次强制通过都记录下来——没有留痕的强制通过，和根本没有这道控制没有区别。
为服务而不只是货物定义收货确认
“是否已登记收货或服务确认？”是把异常队列塞满的那道闸口：货物在卸货口有收货单，服务却常常什么都没有。指定由谁确认服务已经交付——通常是提出需求的申请人，而不是下单的采购员——并以订单的预计完成日期为起点设定期限。对里程碑或年度顾问费一类的合同，要决定按里程碑确认还是按期间确认，并把长期未确认收货的订单放进某个人的报表，好让它们在月结之前就被催办。
约定无订单的例外通道及其豁免
“是否批准事后补开采购订单？”是让“无订单不付款”真正可行的那一步。决定哪些类别确实可以豁免，例如水电燃气、房租、法定规费和部分专业顾问的固定聘用费，并在“发票上是否引用采购订单？”这道闸口就把它们排除掉，而不是一单一单去争。然后指定审批人——本该批准那张原始请购单的预算责任人，永远不是应付账款——并按部门每月报告事后补开的订单数量与金额，好让例外始终是例外。
和真正做这件事的人走一遍，然后发布一个版本
带着定稿的流程图，去找一位申请人、一位预算责任人、一位采购员、一位应付账款经办人，以及放行付款批次的那个人，按实际发生的情况修正它，而不是按制度写的样子。分别问他们：哪一步你们其实早就悄悄不做了。把“更新供应商与支出记录”里应当产出的指标定下来，然后发布该版本并保留此前的版本，让日后打开这张图的人知道自己看的是哪一版。
常见问题
采购到付款（P2P）流程包含哪些步骤？
一个完整的循环是这样跑的：识别需求；提交带规格说明和成本中心科目的请购单；确认预算可用；对照授权审批权限表核对金额，超出的向上升级；检查是否已有获批的合同或框架协议覆盖该需求，没有就走市场；向供应商发出采购订单；收到货物或服务并按订单登记收货；接收供应商发票，检查它是否引用了有效的采购订单、以及该订单下是否有收货记录；执行订单、收货与发票的三方匹配；把超出容差的差异作为异常与供应商解决；将匹配通过的发票入账；在付款批次中放行；更新供应商与支出记录，让下一轮寻源有据可依。难的从来不是这份清单。真正让循环断掉的，是那张没有人登记的收货记录，和那张背后没有订单的发票。
什么是三方匹配，容差应该定多少？
三方匹配是指只有在采购订单、收货记录和发票三者在品项、数量和价格上一致时才付款。定义是容易的部分，数字才是工作量。要求分毫不差会把几乎每一张发票都推进队列，所以价格差异要同时设一个百分比和一个绝对金额上限，以较低者为准；数量的容差要比价格更紧——价格上的小差额是一场四舍五入的争论，数量上的小差额是少了的货。运费、关税、四舍五入和汇率差异要单独写规则，它们造成的匹配失败远多于货物本身。然后要决定服务怎么办：服务往往根本没有可清点的收货记录，多数组织退而求其次，改用订单与发票的两方匹配，或者由申请人做里程碑确认。公布谁可以强制通过一次失败的匹配，并记录每一次强制通过：没有写下来的容差，每个经办人都会用得不一样；而没有留痕的强制通过，意味着即便这道控制真的起了作用，你们也拿不出证据。
“无订单不付款”在实际操作中意味着什么？
它的意思是，一张没有引用有效采购订单的发票不会被支付，而是退回供应商。理由是：没有订单，就没有谈定的价格，账上没有登记的承诺，也没有证据表明在费用发生之前有人有权批准过这笔支出。而在实际操作中，除非有两件事先定下来，否则一刀切的制度必然失败。必须有一份公布的豁免类别清单——常见的是水电燃气、房租、各类税费与法定规费，以及部分专业顾问的固定聘用费——在闸口处直接排除，而不是逐单去争。其余一切则必须有一条明确的例外通道：在本图中，没有引用订单的发票会走到预算责任人泳道里的“是否批准事后补开采购订单？”，于是本该提出请购的那个人不得不事后来批准它，这件事被记录下来，并按部门报告。没有这条通道，经办台就会自己悄悄补开订单，制度也就退化成了纸面文章。
本页与 ERP 版的采购到付款流程模板有什么不同？
两者是同一个循环，写给不同的读者。/zh/templates/采购到付款流程 上的那份模板，把这个循环拆成一组控制点，服务于内部控制评价与外部审计（在美上市的公司则对应 SOX 与 ICFR 的要求）：每一步的流程责任人、源系统、审批闸口和证据，正是审计师做控制测试时走查的形态。本页则是给真正跑这个流程的人看的运营流程——六条泳道、两段式审批闸口、容差决策、异常循环和无订单通道——而且它是写来让你们改成自己的门槛的，不是原封不动拿给审计师看的。两端的范围也不同：本图从识别出需求开始，到支出报告结束；而控制视角的那一版集中在财务报表认定所在的、从请购到付款的那一段。审计底稿用那一份，做流程用这一份。
该用这一份，还是用单独的采购订单与发票流程图？
当问题横跨多个阶段时用这一份，不横跨时用单阶段的那几页。本图把每个阶段压缩到下一个阶段真正依赖的那几步，因此能把整个循环放在一页里——当收货记录缺失、发票背后没有订单，或者没有人说得清从请购到付款究竟要多久时，你需要的正是这个。它比阶段页刻意要浅。如果你们要重新设计审批门槛和请购单的科目填写，/zh/templates/请购流程 讲得远比这里深。订单的开立与发出，看 /zh/templates/采购订单流程。卸货口、差异与承运商索赔，看 /zh/templates/收货入库流程。单张发票的处理路径，包括重复发票检查与科目分配，看 /zh/templates/发票审批流程。付款批次、对账单核对与期末计提，看 /zh/templates/应付账款流程。多数组织最后两样都有：制度里放这一份，作业指引里放阶段图。