所有文章

如何停止通过电子邮件审批发票

星期二,一张供应商账单进入了共享收件箱。有人将它转发给部门负责人。负责人回复:“没问题。”财务在星期五支付了这笔款项。三周后,出现了一笔重复收费,却没有人能确认批准的是哪张发票、由谁批准,或那条回复是否针对正确的金额。

这就是通过电子邮件处理应付账款背后的运营风险。如果你想停止通过电子邮件审批发票,目标并不是增加提醒,或执行更严格的收件箱规则。目标是将每一项决定纳入受控工作流,让发票、审批人、状态和审批记录始终关联在一起。

为什么电子邮件不是可靠的发票审批系统

电子邮件是为沟通而设计的,而非财务管控。它将审批消息与发票附件分离,让责任归属难以辨明,也让财务难以确信正确的人审核了正确的文件。

随着发票数量和团队规模增加,问题会迅速扩大。创始人或许能通过收件箱审批少量账单。但对于拥有多个部门、固定供应商、采购负责人和付款期限的成长型企业,仅靠记忆和搜索邮件是不够的。

常见的问题是可以预见的:发票被发送给错误的审批人;审批人不在办公室,却没人知道账单正在等待处理;回复只写着“已批准”,没有指明供应商、金额或会计编码;原发票获批后,又收到修订版发票;由于到期日临近,财务尚未收到明确决定就付款。

这些问题并不一定是人员粗心造成的。它们是使用非结构化渠道处理受控流程的自然结果。

停止通过电子邮件审批发票后,会发生什么变化

正式的审批工作流让每张发票都有唯一的归档位置和当前状态。员工提交供应商、金额、发票详情和指定审批人。审批人在审批队列中收到清晰的待办事项,而不是又一串含糊不清的邮件。财务可以看到哪些发票待审批、已批准、已拒绝、已付款或部分付款。

这种可见性改变了日常决策方式。应付账款人员不必再问:“有人看到这个了吗?”部门负责人不必在预算会议前搜索收件箱。财务主管可以直接查看审批历史,无须从转发邮件中重新拼凑。

收益不仅是处理更快,更在于处理过程责任明确。每个人都知道自己需要做什么,财务也可以核实工作是否已经完成。

审批责任属于具体的人,而不是收件箱

共享的应付账款收件箱适合接收账单,但不应成为审批责任消失的地方。发票一旦进入流程,就应将其分配给对该项支出拥有审批权限的具名审批人。

对于某些企业,这个人是部门主管。对于另一些企业,则可能是预算负责人、项目经理或财务主管。合适的审批人取决于采购事项和内部政策。重要的是,分配结果必须明确且可见。

如果一张发票需要两项决定,就应明确先后顺序。例如,部门负责人可以确认货物或服务已收到,而财务确认预算是否充足以及是否具备付款条件。避免在没有顺序或责任归属的情况下,将同一张发票发送给多人。这种做法带来的不是管控,而是重复回复和延误。

发票与审批决定必须保持关联

审批记录应明确供应商、发票号码、金额、日期以及审核的版本,还应显示由谁批准或拒绝,以及操作时间。

当几个月后出现疑问时,这一点很重要。供应商可能追问未付余额,经理可能对某笔收费提出异议,外部会计师可能在审核期间要求提供证明材料。如果证据散落在收件箱、个人文件夹和聊天消息中,回答一个简单问题就会变成耗时的调查。

集中记录能让文档始终与交易关联。财务无须追着作出决定的人询问,就能看到审批决定。

先建立工作流,再确定例外情况

最有效的流程通常很简单。先建立能够处理大多数发票的常规路径,再定义有限的例外情况。不要从第一天起就围绕边缘情况设计整个工作流。

对于典型的中小型企业,标准路径是这样的:员工或应付账款团队成员提交发票,相应负责人审核,财务确认已具备付款条件,然后记录付款状态。流程可以高效,而不必随意。

根据人们能够一致应用的事实设置流转规则。实用的规则可以包括:

  • 承担该项费用的部门、项目或成本中心
  • 发票金额和审批限额
  • 供应商是新供应商、固定供应商还是受限供应商
  • 发票是否与合同、采购订单或周期性服务关联

让规则与风险相匹配。要求高管审批每一次常规软件续费,会拖慢业务,却不会增加多少保障。允许任何员工审批金额较高、来自不熟悉供应商的发票,则会造成相反的问题。审批层级应反映金额、类别和财务风险敞口水平。

明确审批人在确认什么

“批准”不应仅仅意味着“我认识这家供应商”。为审批人提供简短、实用的标准。他们应确认费用合理合法,货物或服务已收到或按合同约定应予提供,金额符合预期,且该笔收费属于其职责范围。

财务可以进行单独的核查,包括发票完整性、重复风险、付款条款、税务处理和可用文档。将业务确认与财务审核分开,比让一个人发现所有问题更能建立稳健的流程。

拒绝发票时,应要求说明原因。清晰的拒绝备注可以防止同一张账单在未说明需要修改什么的情况下,再次返回队列。

使用权限保护财务信息

并非每位员工都需要访问所有供应商发票、付款详情或审批记录。过于广泛的可见性可能引发隐私问题,也更容易让不适当的人员对敏感信息进行操作。

基于角色的访问控制让流程保持实用。团队成员可以提交发票并查看与自己相关的事项。审批人可以处理分配给自己的队列。主管可以监控部门活动。财务管理员可以管理整个工作区的工作流、付款状态和文档。

这种结构并不是为了让日常工作变得困难,而是将访问范围限制在各角色所需的信息之内。清晰的权限边界可以减少意外更改、加强保密性,并让责任追究更易落实。

将付款与审批分开跟踪

审批回答的是发票是否有效且获得授权。付款回答的是资金是否确实已从企业付出。将二者视为同一种状态会造成混淆,尤其是在账单已获批准、但被安排在之后的付款批次中支付时。

系统应清晰区分待审批、已批准、已拒绝、已付款和部分付款的发票。这样,财务就能获得实用的待付账款视图,部门负责人询问供应商是否已收款时,也能得到准确答复。

部分付款尤其值得关注。如果没有记录余额和付款历史,一张部分付款的发票可能在一个电子表格中显示为已结清,在另一个中却显示为未付。集中管理状态可以防止这种差异演变成供应商纠纷。

在工作进行时创建审计轨迹

审计轨迹不应成为月末的清理项目,而应在人们提交、审核、批准、拒绝发票以及更新付款状态时自动生成。

记录不必复杂,但必须可靠。财务应能够在同一位置看到发票来源、指定审批人、决定时间、备注、状态变更以及相关证明文件。

当职责发生变化时,不可篡改的审批记录尤其有用。如果经理离职,其决策历史仍应可供查阅。如果财务部门重组,查看以往的审批记录不应依赖于访问前员工的邮箱。

让采用新流程比沿用旧变通办法更容易

当员工将新流程视为额外的行政事务时,新流程就会失败。提交步骤必须快捷:输入供应商和金额,附上发票,选择审批人,然后发送到队列中。如果基本的录入耗时过长,人们就会继续转发附件,并通过电子邮件请求审批。

同时制定明确的政策:发票审批应在工作流中完成,而不是在电子邮件中。电子邮件可以通知某人有发票待处理,但正式决定必须记录在审批系统中。这为团队提供了一条简单的行为准则。

在最初几周,检查那些仍在流程之外收到的发票。这通常表明缺少某条流转规则、用户缺乏访问权限,或供应商的提交方式需要调整。应修正流程,而不是接受变通办法。

UTUMATE 正是围绕这种严谨的方法构建的:在一个工作区中,提供快捷的发票录入、明确分配的审批队列、受控访问、可审计的决定,以及清晰的已付款或部分付款状态。

电子邮件仍将在供应商沟通和付款问题处理中发挥作用,但它不应成为作出财务授权决定的地方。将决定转移到专为保留这些记录而构建的系统中,每张发票都会更容易处理、更容易核实,也更不容易丢失。