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