如何创建发票审批工作流
如何围绕三方匹配搭建发票审批工作流：三份单据会以哪几种方式对不上、每一次更正各自回到哪一行，以及用泳道把职责分开。
发票审批工作流把供应商发票与采购订单、收货单核对一致，把每一处不一致送回真正能解决它的那一步，并按金额限额来控制付款。
简而言之
- 三方匹配才是那道控制。它后面的金额限额只决定由谁签字。
- 无采购订单的发票既没有订单也没有收货单，它的控制只能来自别处。
- 两种例外很少从同一行重新进入，而选在哪里正是设计本身。
- 重复筛查属于记账之前，而不是入账之后。
- 职责分离要么在泳道上看得见，要么就只是制度里的一句话。
不一致才是这条流程的本体
一条发票审批工作流要核对三份单据，而它们由三方在三个不同时点写成：供应商开的发票、采购提出的采购订单，以及收货人登记的收货单。三者一致时没有什么可决定。天真的画法把这次核对塞进一个叫“匹配”的方框，于是它失败的那五六种方式无处安放——而应付账款一周的时间恰恰都花在这些情形上。
没有采购订单、价格高于订单、少发了货、没人登记收货单、同一张发票来了两次：这五种情形才是这条工作流存在的理由，而每一种都需要决定它从哪一行重新进入。不是要不要回来，而是回到哪里。两种例外很少属于同一个重新进入点，而把它们全都退回同一个步骤的工作流，正是发票一边挂着逾期滞纳金、一边等着谁来拍板的原因。
下面的示例是一条应付账款流程，从三份单据走到一笔付款，横跨六个阶段和四条泳道。“向供应商提出疑问”被两种不同的拒绝共同指向——一次匹配失败，以及一位不肯签字的预算负责人——因为两者都由同一场对话来回答。而一次以更正收场的疑问，会把发票交回采购订单分叉之前，红字发票在那里可以把它整个换到另一条臂上。
从三份单据到一笔付款
从收到发票到付给供应商的十九行。先按一切正常时走的那条路读一遍，再看例外从哪里重新进入。
记账之前先筛一遍
对这份单据的第一个判断，是一个可以直接把它扔掉的判断：“是否为重复发票？”在任何记账动作之前就通向“冻结并标记为重复”。随后“发票上是否有采购订单号？”按单据类别而不是按答案分流——“有订单”打开匹配，另一条臂紧随其后。
不匹配的那条臂只有一行
无订单那条臂只有一行。“分摊到成本中心与总账科目”就是它的全部，也是目前唯一落在“预算负责人”泳道里的一行——没有订单也没有收货单可以核对，它的控制是一位指名的记账人而不是一份单据。“匹配是否在容差内？”和它之后的三行只服务于有订单那条臂。
一个步骤，两种拒绝
“疑问是否已解决？”的“否”通向“将发票退回供应商”，于是这个回环有了出口，而不是只有绕圈。“预算负责人是否批准？”的“否”同样通向第 9 行——一个步骤如今承载着两种互不相干的拒绝：应付账款做不成的匹配，以及成本负责人不肯接受的开支。
职责在泳道上现形
结尾处要读泳道而不是方框——“应付账款”入账，“财务经理”放款，而给它记账的那条泳道两件事都不做。“是否超过审批限额？”是全图唯一一处两条臂在下一行就重新合并的分叉，它只增加一次会签，别无其他。
运作方式
先把例外情形列出来
把发票不能顺利通过的每一种理由都写下来：没有采购订单、价格高于订单、数量不足、没人登记收货单、法人主体错了、重复。这份清单才是这条工作流真正的内容，而且它比人们想的要短——五六种情形就占了应付账款队列的绝大部分。
决定每种例外从哪里回来
在每一种情形旁边写上它回到的行号，并且预料到答案各不相同。回到最早的那个步骤——它的答案有可能因为这次修复而改变：更正后的价格要回到采购订单分叉之前，因为红字发票可以改变发票落在哪条臂上。而一张没人登记的收货单不改变上游任何东西——那是等待，不是回环。
把顺序录成行
每一行的“方框文字”就是一个方框，它的“连线至”单元格填它通向的行号。先把一切正常时的直通路径录进去，例外留到下一遍。因为一次连接就是一个行号而不是一条画出来的线，把漏掉的步骤补插进去在排版上不花任何代价。
把检查变成带标签的决策
凡是在提问的行都变成菱形：把“形状”改成决策，并把每个标签改写成一个只凭手上单据就能回答的问题。答案按位置与行号配对，填进“连线文字”。容差数值属于采购订单流程，不属于应付账款：悄悄把它放宽，就等于改掉了一道没人批准过的控制。
把例外路径指回去
把每种例外的返回行号填进提出它的那个决策的“连线至”列；在这个编辑器里，一个向后的行号就是一个回环的全部。发票确实就此停下的地方，把“形状”设为拒绝，让这条路径有意地终止。然后把这些向后的行号读一遍——三四个是流程，十个是队列。
先分泳道，再送去审批
在“垂直泳道”列里给四条泳道命名——供应商、应付账款、预算负责人、财务经理——阶段填进“水平泳道”列。一条既提出开支又放出付款的泳道，就是一个控制缺口。分享链接之前先把图表审批掉，这样匹配有争议时，应付账款可以指着那个已获批准的容差说话。
应避免的错误
先审批，后匹配
在发票完成匹配之前就送给预算负责人，等于让他确认一次自己从未经手的交付。他凭信任签了字，差异在入账之后才浮出来，而这次更正会变成一张没人去追的红字发票。
把每一次不匹配都推给供应商
“匹配是否在容差内？”的“否”有两个互不相干的原因：供应商开错了，或者没人登记收货单。只有第一个才该由他们来修——两者都往外推，只会白白花掉两周，然后发票原样退回来。
把无采购订单的发票当成异常
房租、水电、专业服务费和订阅费永远不会带采购订单。它们没有自己的路径，就被硬塞进匹配、匹配失败，于是每个月按设计重新填满例外队列。
同一条泳道既提出又批准
提出这笔开支的人，不能同时是授权把这笔钱付出去的人。泳道让这一点变得可以检验，而制度里的一段文字做不到：如果同一条泳道出现在两端，这道控制就不存在。
创建你们的发票审批流
把发票示例打开成您自己的图表，逐一决定每一种例外重新进入的那一行。
相关指南
常见问题
无采购订单的发票应该怎么处理？
给它一条自己的路径。无采购订单的发票没有订单、也没有收货单可供匹配，因此控制只能来自别处：由对该预算负有问责的人记账，再加上服务确已收到的证据。这个分叉属于校验之后紧接着的位置，于是无订单那条臂由预算负责人记账，然后并入同一套按金额分派的审批路由。反过来，把每一张发票都硬推进三方匹配，只会造出一个基本由房租和订阅费组成的每月例外队列。
供应商发票应该由谁批准？
由承担这笔费用的成本中心的预算负责人批准，超过授权审批权限表设定的限额时再加一位审批人——而且两者都不能是提出这笔开支或维护供应商主数据的那个人。应付账款负责校验、匹配和记账，它不做批准。这种分离与层级无关：确认货物确实到货，和授权把钱付出去，是两项不同的检查，一个人同时做两件事是去掉了一道检查，而不是把两道合并成一道。
怎样避免重复支付发票？
用两把钥匙筛查，而且要在任何记账动作之前筛。供应商加发票号能抓住老实的重发；总额加发票日期能抓住那种把单号重新录入时加了前缀或漏了一个零的副本。位置和检查本身同样重要：在校验环节抓到的重复是一份被冻结的单据，入账之后才抓到的则是一张必须去索要的红字发票。多数重复并不是供应商在催款——而是同一张发票来了两次，扫描一次、邮件一次，两次都被录了进来。
发票应该在入账之前还是之后批准？
当这次批准本身就是产生这笔费用的授权时，先批准，这通常是无采购订单发票的情形，因为发票就是这笔承诺的第一份记录。而当采购订单已经承载了批准，与它匹配才是那道控制，入账可以先行，付款放行另设一次审批。绝对不能发生的是同一笔金额被两位审批人各批一次，而他们都以为匹配是对方检查过的。