企业支付结算数字化建设思考
这几年做了不少企业支付结算解决方案，作为产品专注于支付结算领域参与了从售前、业务方案、产品设计、开发交付到推广运营落地再迭代的完整生命周期，随着案例增加和自我认知更新，继之前2篇企业支付结算文章后有必要再做迭代更新。
一、支付，结算，清结算和企业结算概念要清晰
支付：字面意思就是一方付钱一方收钱的过程。基于交易，由买方付钱，卖方收钱，买方消耗自己拥有的资产，权益或债务（理论上只要卖方认可，一切皆可支付，本质上是信任机制下的凭证转移），完成交易支付，包括付款和收款；
结算：交易维度有实际的资金（或资金等价物）转移，财务维度做相应的债权关系转移；
清结算：可以拆解为清分，清算和结算。
- 清分：一笔交易，记录各参与方基于这笔交易的应收应付（以用户在淘宝上下单使用支付宝成功支付为例，1个是淘宝作为交易平台会做清分（平台分账），计算出商家货款和平台佣金（如有优惠活动，需要增加优惠分账的逻辑）；另1个是支付宝作为收单机构，计算出渠道费用和商户落账金额）；
- 清算：专指金融机构之间通过备付金或准备金做资金转移；银联或网联作为有清算资质的金融机构，记录本次收单支付涉及各金融机构（一般由收单方、银联/网联、卡方）的金额，并通过大小额等专项通道对接央行，最终由央行完成各金融机构之间专户的资金清算；
- 结算：最终由金融机构完成对商家，淘宝法人主体的资金结算，完成最终的资金结算收款。
企业支付：企业作为买方或买方基于自有资金参与付款和收款，按卖方对象类型是否为企业可分为公对公和公对私支付；
- 性质：公对公支付涉及企业对公账户资金转移，公司名义开设，包括基本户、一般户、专用户等；公对私涉及的是企业将资金从对公账户转移到个人账户，这可能是因为股东分红、员工工资发放、费用报销等情况。
- 用途：公对公转账通常涉及商业合作、货款结算等正规商业活动，资金往来透明度高，监管严格；公对私转账可能涉及个人消费、储蓄等，操作更为灵活，但也更容易涉及挪用公款、偷税漏税以及洗钱等风险。
- 监管程度：公对公的资金往来一般是有据可查的，银行的监管不那么严格；公对私因为可能涉及上述风险，银行对此监控较严，需要提供相关资料。
- 风险：公对公的风险相对较低，因为涉及的是正规商业活动；公对私可能涉及多种风险，包括挪用公款或偷税漏税等。
企业结算：企业和服务方做资金结算，完成收入支出，必须满足企业的财务核算规则：交易信息流，资金流，销项进项发票必须做到可一一核算，相互匹配关联；
凭证：分为交易原始凭证和记账凭证，订单，小票，出库单，发货单，发票，高铁票等都是我们常见的交易原始凭证；记账凭证根据原始凭证填制，记载经济业务简要内容，确定会计分录，作为记账依据的会计凭证。
对账：账证实（交易账务，交易凭证，实物/资金）的核对，本质上是为了确保同一个事务的数据描述在不同业务或系统下记录一致而进行的相互之间的一致性比对（对比的对象可以是单据或账户，对比的维度可以是明细，总数或计算后的统计数据）；
账单：统计账证实流水，周期性的生成流水清单，便于买卖双方按需了解和确认交易，收付和履约等相关情况；
渠道和路由：支付结算需要有处理来源，谁提供处理服务谁就是渠道，有多条支付结算处理源时，就需要做路由，基于路由规则（静态或动态规则）明确走哪条渠道实现支付结算。
二、企业经营和财务要有认知
2.1 企业经营
我们把企业经营按管理到执行从上到下，拆分为战略，经营模式，业务能力和流程，然后基于和支付结算业务的关联度，重点放在业务能力和流程上面。
战略：支付结算作为企业业务交易的一环，可弱化对企业战略的洞察要求，了解即可。
经营模式：
- 熟知企业的经营模式，在行业中的定位和价值；
- 熟知主营业务特别是核心业务的完整流程，是怎么产生收入，支出和利润的；
- 熟知和上下游怎么做业务往来和收付结算。
业务能力和流程：梳理出企业经营中和上下游及内部的核心业务能力，这里以制造类企业为例梳理了主业务能力，和业务对象，业务流程，企业组织架构的关系（这点对后续业务架构，数据架构设计，系统上下文串联非常重要）。
2.2 财务认知
财务：财务这块，之所以单独拎出来，主要是考虑到：
- 企业作为法人组织，需要严格的在国家和企业自身财务规则下经营业务，做到合规；
- 财务作为企业专业职能（监督，核算，并提供财务数据支撑企业业务决策），和支付结算息息相关；
- 财务相关的职能部门，是企业支付结算业务的主要业务对象，涉及职能管理，组织协作，流程管理，最终实现业务和财务的流程闭环。
作为企业支付结算产品经理，个人认为对财务的认知，思维上需要对企业的经济活动有财务角度监督和核算的思维；专业上对初级会计内容要有基本熟知，可以和财务人员做方案沟通，下面是个人梳理的支付结算产品要懂的财务知识。
三、业务方案
基于企业经营业务能力，对象和流程梳理，可以梳理出完整的收付款业务能力，对象和流程，并结合企业实际业务场景和数字化程度，形成完整的企业支付结算业务架构。
下面按业务目标，业务场景，业务架构来具体说怎么形成业务方案。
3.1 业务目标
支付结算产品定位上用来更好的支撑企业完成交易收钱和付钱的闭环（业务交易闭环，财务监督和核算闭环）；有效并灵活的支撑交易在线（满足企业服务可以灵活的触达B端和C端用户，特别是新业务的在线交易）；通过搭建标准的支付结算服务，可做快速技术对接，不再需要烟囱式的开发，降本增效；当企业经营业务不断通过标准的支付结算服务产生交易数据，可以不断的产生从交易，支付结算，发票到账务的完整数据，以实现数据赋能业务打好基础。
3.2 业务场景
从业务模式的角度看，其实就是业务参与方的利益分配，我习惯用交易对象的角度来锁定业务，分为双方交易和多方交易（双方交易的多个组合），双方交易好理解：就是交易的生命周期中只有买方和卖方2方参与并完成（比如街道上摆菜摊的大妈，我付现金买菜）。
多方交易理解为：交易的生命周期中有多方参与，形成了多个“双方交易”才能完成交易闭环，最典型的就是电商业务。
以淘宝为例，涉及的参会方一般会有平台、商家、快递公司、用户、收单支付机构等。
明确完交易对象，可以更好的理解涉完成一个交易场景，涉及多少交易业务，理解基于交易怎么做支付、分账、结算、发票和税要怎么走。
下图是典型的BBC平台交易：
3.3 企业结算方式
一般分为按单/合同结算和对账结算，按单结算主要是电商场景，交易订单完成履约闭环后，结算给商家对应的订单货款（可提现）；对账结算主要是企业之间的结算，需要周期性的生产账单进行账证实的核对，完成核对后确认账单并进行付款结算，比如我们常说的日结，月结，企业越大，溢价权越高一般结算周期更长。
企业间交易使用先货后款为多（有自己的授信体系，详细可见企业数字化系列——授信业务数字化设计），很品牌溢价权的则喜欢现款后货，收取预付款；另外除了支付现金外，在大宗交易场景，存在很多票据支付的情况。
3.4 业务架构
业务架构的核心作用是在了解完企业所有的经营业务，对象和流程后，可以梳理清楚所需的完整业务能力，并未后面的产品设计打好业务框架。
下面支付结算业务架构覆盖了一般企业全渠道业务在线运作所需的支付结算业务：
四、产品设计
基于业务架构，切入场景，搭建产品架构，并按领域驱动设计方法论对支付结算产品架构做领域划分和中心设计。需要对底层的数据和基础技术有系统性了解。
4.1 领域设计
业务需要边界，产品和开发设计都需要边界，这是我理解的领域概念，作为支付结算产品，就应该做好支付结算领域内的事，什么都做就等于什么都没做，好的领域设计要确保独立性和可扩展。
我把领域设计分成2个维度，横向的业务领域，通过定义不同的业务对象做区分；纵向的架构领域，通过分层来解耦业务对象处理问题的复杂性（业务驱动领域设计，so不是业务领域，分层设计越多越好，比如只通过微信小程序试点自营商城业务，为了快速验证业务，只需要能做微信小程序支付足以）。
4.2 业务需要闭环
当了解了企业客户的整体业务和后面的战略规划后，就可以规划需要做哪些业务领域的设计来支撑当前业务，又满足后面的可扩展（需要平衡效率和成本，分的越细，技术上分布式事物的一致性设计越复杂，产品上看新业务的验证和打磨更关键）。
支付结算领域，正常都会分为支付，清结算，对账，账户，计费和财务集成，下面拿一笔企业交易的整体流程形成完整的业务上下游闭环。
其中：
- 支付核心是支付订单，主要是明确交易的支付来源，收付款方，金融，支付方式和最终执行支付的处理源（支付渠道）；
- 清结算核心是结算单，主要是明确基于交易的应收应付，结算的渠道做资金结算；
- 账务核心是账户（一般涉及到金融端的银行结算户，支付机构的支付账户，交易端的账簿）；
- 对账核心是对账单，涉及对账数据（账证实）的接入，清洗，对账处理，差异处理，账单输出；
商户就是参与到交易的交易对象，基本分为个人，企业和个体户，账户都需要关联到对应的商户下面（按账户权限做商户认知，比如收单特殊商户需要做实体认知）。
4.3 领域架构设计
我理解的业务架构，通过层级来定义同1个业务的输入和输出边界，通过模块来定义同一层的不同能力或者服务，比如很多架构都会有应用层，逻辑层或物理层等。
对于支付结算领域来说，个人习惯应用层，逻辑层到核心层的3层或2层设计，应用层做服务的输出，逻辑层做业务解析和领域内的逻辑处理，核心层定义业务对象的核心能力和属性。
以聚合支付服务为例，应用层就是标准的聚合支付服务接口输出，外部应用通过调用接口获取聚合支付服务，获取到支付的业务订单数据后做业务解析，明确收付款方，支付方式等信息，通过支付路由规则明确支付方式对应的渠道。
有些场景（比如组合支付）还涉及逻辑的处理（组合支付需要基于主支付订单，拆分多条支付渠道流水，并要求所有的支付渠道流水成功才算组合支付成功），核心层就是拿着明确的支付方式，支付渠道，收付款方和金额等信息调用支付渠道做最终的支付处理。
业务驱动支付产品设计。
五、平台运营
企业支付结算平台只是工具，要给企业带来价值，需要有业务主人（一般需要由专职财务，产品和市场业务人员组成专项组织）基于平台的功能和对外服务做运营推广，迭代优化和数据服务赋能企业管理层决策。
5.1 运营推广
运营主要包含企业金融资源对接，支付结算渠道管理，异常数据监控。支付结算平台搭建后，只有不断的服务好新的业务场景，才能不断给企业产生价值。推广过程主要包含：
- 输出平台可以提供的支付结算渠道资源和服务功能清单（API接口清单），明确自己的定位，能提供哪些服务，解决哪些问题；
- 了解新场景交易模式，支付结算场景及需要解决的痛点；
- 基于推广场景需求提供支付结算解决方案，协同业务，财务还有金融渠道方做方案确认，一般财务会从监管和账务维度做评估，金融渠道会从资金监管维度做评估；
- 提供对应的支付结算接口清单做对接说明，进入开发联调测试阶段；
- 协同业务，财务还有金融渠道方做上线方案确认，执行上线。
注意点：
1）基于自身定位，需要明确业务，财务，金融渠道和支付结算平台的边界，一旦涉及平台范围外的需求，产品层面需要和项目经理或相关领导确认，该走什么流程就走什么流程；
2）作为多方参与集成开发，接口说明和联调测试非常重要，尽量在前期就把问题暴露出来；
3）上线方案必须多方一起确认，可能涉及历史交易数据迁移；
4）早期支付结算平台搭建，可以弱化风险管控，主要针对异常交易数据做监控，主要是：
- 推广的交易场景一般都是企业内部子公司业务，业务可管控；
- 企业财务目标和规则基本一致（过不了是不让开发的）；
- 资金监管由金融机构管控；
5.2 数据服务
随着支付结算平台推广的交易场景增多，会源源不断的产生支付结算数据，可以通过几种形式输出数据服务：
1）周期性的输出各种类型的支付结算数据报表供企业财务和业务方查看；
2）提供数据给企业统一的数据平台（数据中台，数据湖，数据仓库等）；
3）监控异常数据，输出异常数据分析报表，来优化产品，对接更安全有效的支付结算渠道，优化业务交易和财务中可能存在的风险；
4）提供统一的上下游交易数据核对服务。
5.3 迭代
支付结算平台准守MVP产品的迭代思路，以满足切入的具体场景需求来定义搭建的服务能力。
迭代的整体思路按平台的纵向专业能力和横向推广能力推进，其中专业能力按各领域中心自身规划需要的完整服务能力迭代，横向主要结合业务场景推广会对接更多的金融资源，提供更多的支付结算服务选择。
5.4 支付结算数字化案例
这里还是以HE集团为例，作为国内最大的几家家电企业之一，企业战略上开始从传统分销到赋能分销商，直接触达终端客户提供零售服务的转型，通过企业数字化，实现库存在线，交易在线，资源在线，营销在线和组织在线，以更好的支撑服务多元的交易场景，尝试新的服务业务，通过标准化业务获取完整的有效数据，并驱动数据赋能业务。
支付结算以开发平台的产品形态，统一对接金融和企业授信，返利等资源，输出标准的支付结算和账户服务来满足2B,2C的不同交易场景。
六、业财一体
业财一体的核心在于业务对企业经营要有财务思维，你可以理解为企业所有的经济活动，理论上都可以按财务规则翻译并做账务处理，因此不是说企业数字化后才开始有业财一体，而是之前企业业务和财务割裂，很多企业只有到算总账时候才发现不是业务没有账，就是记账业务说不清楚，分析起来也是因为统计口径不同，错误百出。
同时财务只注重管控，做的是核销的人力活，特别是月底结账，出季度年度报表的时候，苦不堪言，因此业财一体的另一个核心在于财务要对企业经营心里有底，从财务管控到财务经营，赋能业务。
支付结算平台一般切入企业全渠道销售场景，上下游分别有具体的业务交易履约和财务账务，资金结算场景，是业财一体非常好的切入点和基础服务，让各种交易凭证（订单、出入库单、发票、下票等），资金支付结算流水，记账凭证可以基于具体的交易场景和节点自动关联，完成核算。当然也可以从财务主数据管理，搭建统一的预算费用平台等切入点出发，逐步实现业财一下化。
七、总结
企业支付结算产品从战略角度是企业数字化转型的一环，因此整个产品规划和设计的核心依赖于企业数字化战略和搭建方法论（比如企业架构框架TOGAF），同时从专业角度，企业结算，财务基础和中国支付清结算体系又是必须要账务的，最后才是基于企业的实际经营情况出解决方案，迭代落地。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
