前段时间见了一位客户。

客户的诉求是：想实现凭证自动生成入账，减少财务手工做账，提高效率。

这本来是很多企业财务信息化里一个很典型的需求。尤其是业务量上来之后，订单、出入库、收付款、费用、退款这些数据越来越多，如果还靠财务人员手工整理、判断、录入，不仅效率低，差错率也高，月底结账压力也会越来越大。

我们当时给客户建议的是一个相对完整的中台方案。结果客户第一反应：太重了，潜台词是太贵了。

客户接着问了一句：

能不能不要上什么中台，就在现在这个业务系统里，开发一个“自动生成凭证”的功能？

从客户的角度来想似乎很自然：

·我已经有业务系统了；

·我现在只是想解决“生成凭证”这个点；

·那为什么不直接在现有系统上补一个功能？

·这样看起来又快，又省钱。

如果只看眼前，这个思路确实有吸引力，在一个系统实现业务与财务的连接，不用多个系统跳转。

但如果从财务信息化建设的角度来看，我一般不会不这么建议。不是说完全不能做，而是它往往是在用短期省事，换长期被动。

​

一、凭证自动化，本质上是“业财规则承接”

很多企业一提到自动凭证，以为就是：

业务系统里有单据，点一下，自动生成一张会计凭证。

这句话只说对了一半。

因为“自动生成凭证”从来都不是简单的技术动作，它背后其实包含三层内容：

第一层，是业务数据怎么取。

取订单、出库单、入库单、收款单，还是结算单？不同业务场景，取数基础不一样。

第二层，是财务规则怎么定。

什么时候确认收入？什么时候结转成本？退款怎么冲？平台佣金怎么处理？预收、暂估、税额、往来科目怎么挂？要不要考虑多会计准则？涉及汇率、内部交易如何处理？这些都不是技术人员随手写几行代码就能真正处理好的。

第三层，是后续怎么扩展和维护。

今天你可能只想做销售凭证，明天可能要做采购凭证、库存凭证、费用凭证；

今天只对接一个账套，明天可能变成多组织、多公司、多准则；

今天业务模式比较单一，明天可能增加新渠道、新平台、新结算方式。

所以，凭证自动化本质上不是“开发一个按钮”，而是要建立一套业务到财务的转换规则体系。

这也是为什么，很多企业一开始觉得“这个需求很简单”，做完半年后就开始发现越来越别扭：

规则越来越多，例外越来越多，改一次牵一发动全身，最后谁都不敢动。

二、为什么“直接在业务系统里开发凭证功能”听起来省事，实际容易把路走窄

我当时跟客户打了一个比方，客户也比较容易理解。

我说，假设我们现在已经买了一件上衣，但还缺一条裤子。那当然有几种办法：

·一种办法，是单独去买一条裤子，和上衣搭配起来穿；

·另一种办法，是直接在上衣上改装出一条裤子。

如果只看“先穿上”，第二种方法好像也不是不行。

但问题是，一旦这样做了，裤子和上衣就彻底绑死了。

以后你想换裤子，不方便；

想换上衣，也不方便；

想再加件外套，可能也不协调。

本来应该是分层组合的东西，被硬生生做成了一个整体，短期看像节省，长期看其实牺牲的是灵活性。关键是业务是敏态的，而财务相关变化缓慢，一个变化频繁的事物与一个不怎么变化的事物强行捏在一起，这个组合体本身就是个问题。

财务自动凭证也是一样。

如果把凭证逻辑直接写进业务系统里，最直接的结果就是：财务规则和业务流程强耦合。

这种耦合会带来几个非常现实的问题。

1. 业务一变，凭证规则就跟着改

企业的业务不是一成不变的。

销售模式会变，结算模式会变，组织架构会变，核算要求也会变。

一旦凭证逻辑是嵌在业务系统里的，后续每次业务调整，都可能要去动财务逻辑；反过来，财务规则变化，也可能影响业务系统原本的稳定运行。

本来是两个相对独立的问题，最后被绑成了一个问题。

2. 业务系统的软件开发商未必擅长财务核算

很多业务系统在订单、库存、生产、发货、流程管理上做得不错，但这不代表它在会计规则、凭证模型、核算口径、税务衔接上也同样专业。

表面看只是“生成凭证”，实际涉及会计科目体系、辅助核算维度、借贷逻辑、期间控制、冲销规则、异常回写、审计留痕等一整套机制。

如果这些能力原本不是系统设计重点，后面做出来的功能，往往能用，但不好用；能跑，但跑不远。术业有专攻，做B端产品的不一定能搞定财务产品，财务产品经理这个岗位虽然小众但门槛较高，得懂会计懂业务懂产品，是个复合型人才。

3. 后续接新系统、新场景，扩展成本很高

一开始可能只想从一个业务系统生成凭证。

但企业发展到一定阶段，通常不会只有一个系统：

·电商有电商系统；

·供应链有供应链系统；

·费用有费控系统；

·资金有银企系统；

·以后还可能上MES、WMS、CRM。

如果每个系统都自己做一套凭证生成逻辑，看起来是“各自解决”，实际上会形成很多套分散规则。

到最后，财务口径越来越难统一，系统之间也越来越难协同。

4. 看起来省了建设费，实际增加了维护费

很多企业在立项时最关注的是“第一次要花多少钱”，但真正长期消耗预算的，往往不是建设，而是维护。

直接在业务系统里开发，前期报价可能低一些，但后面每改一次规则、加一个场景、调一个接口、修一个异常，都要持续投入。

而且这种投入往往零散、反复、难评估。几年下来，未必便宜。

三、中台的价值，是“把变化接住”

很多企业一听“中台”两个字，就本能觉得大、复杂、投入高。

这种顾虑我完全理解。因为市场上确实有一些中台项目，做得很重，最后企业感受也不好。

但这不代表中台思路本身有问题。

关键不在于叫不叫中台，而在于你有没有给企业留出一个承接变化的层。

企业做财务自动化，难点的不是现在需求复杂，而是未来需求一直变。

所以真正有价值的，不是“今天先把凭证做出来”，而是“明天业务变化时，不需要推倒重来”。

一个合理的中间层，至少应该解决几件事：

·把业务数据和财务规则隔开；

·把规则配置和系统开发隔开；

·把单一场景和多场景扩展隔开；

·把当前系统和未来系统接入隔开。

这样做的好处是，业务系统还是专注做业务，财务规则在相对独立的层面管理。

以后新增凭证类型、新增核算维度、新增组织、新增系统对接，都不会每次去大动业务系统本体。

这才是信息化建设里最重要的一点：

不是为了今天跑起来，而是为了明天改得动。

阅读原文：https://mp.weixin.qq.com/s/PjNpkVzuAq22EbZpK7ggsw