笔者在实际工作中遇到过很多业务线的产品和业务同学，每次与财务（含产品经理）同学打交道就觉得头疼，听不懂财务同学在讲什么，搞不清楚结算和核算的区别。好不容易确定了结算流程，最后发现应该是自营模式，结果是按平台模式确定的方案，导致方案变更又要从头聊。笔者财务工作出身，后转入业务线做产品经理，根据实际工作经验总结了一份“结算宝典”供相关同学学习。
适合阅读人群：
跟结算人员打交道比较头疼的同学。
本文目标：
从整体到部分，结构化的去认识和了解结算。
能够有条理的设计结算产品方案。
阅读后与结算相关岗位（含业务及产品）打交道不那么头疼（完全不疼是不可能滴）。
本文范围：
主要是讲解国内最通用最核心的结算逻辑，其他如：预付款结算以及跨境结算等，不在本篇文章范围内涉及。
正文：
毛主席说：做结算不懂业务是耍流氓的行为。所以，在本篇总结里面，我会通过什么是结算、结算必懂的那些名词儿、结算三要素三个方面来进行讲解。
一、什么是结算
通俗的来说，广义的结算是指：用户支付订单款到商家收到货款的过程。
狭义的结算仅指：用户支付订单款以后，订单款从支付公司或电商公司给到商家账户的过程。（见上图）
本篇要讲的就是狭义的结算。
注意：结算一定是有交易背景的，如果只是单纯的给对方账户打一笔钱过去，只能叫转账，不能叫结算。我们经常在香港警匪片里面看到的两伙黑社会头目见面会说，钱带了吗？货带了吗？一手交钱，一手交货。这就是典型的（线下）结算。搬到线上，是由银行及有类似金融机构来完成用户与商户之间的资金结算。
二、支付和结算里必懂的那些名词儿
很多同学觉得概念这个东西并不重要，但是在实际工作中，经常会出现滥用名词的现象，导致的结果就是沟通出现歧义，直接后果就是工作效率低下。
举个栗子：
有一次在工作中，我跟业务同学说需要在某年某月某日前开通一个店铺，结果这位同学开通了一个银行账户回来，最后当然是又重新去开了一个店铺，之前做的工作都白费了，而且业务上线也延期了！
温馨tips：以下的名词，是根据工作中高频词汇进行汇总。如果清楚这些概念的同学可以直接跳过往下看“三、结算三要素”哦。
1. 银行及银行账户
银行随处可见，每个成年人也都有银行账户。在此不多解释。
2. 支付公司及支付钱包
支付公司：
对标银行，跟银行是干兄弟，央妈是银行的亲妈，是支付公司的后妈。这样的地位落差导致支付公司能做的事情范围远远不如银行兄弟，主要定位是小额资金结算。
典型代表：支付宝。
支付钱包：
对标银行账户，主要是装载资金的载体以及结算的工具。公司和个人在支付公司开立账户，如果要进行收付款转账，都需要使用支付钱包。
典型代表：支付宝钱包。
3. 公司、部门、店铺
公司：在工商局注册的一个法人（但不是人），主要用途是对外合作。与其他公司签合同，在银行开户，收付款，开发票，都要以公司的名义进行。
部门：用于划分公司的业务职责以及管理公司员工，主要用途是对内管理。上面公司签合同，银行开户等活动，都不能用部门的名义。
关于公司和部门的区别，可以再参考下图理解下：
注：互联网公司的部门架构跟传统公司的架构差异较大。传统公司的架构往往是每一个公司下面会设有销售部、财务部、人事部等，如果有50个公司，则会有50个销售，财务部和人事部。部门与公司有非常强的从属关系，而互联网公司的部门架构，则与公司没什么强关联，可能一个部门的业务会涉及到几个公司主体。笔者当年从传统行业转到互联网行业也是懵逼了好久！
店铺：商家在电商公司开立的门店。可以对标下线下的商城，商家可以在商城租一个实体门店，在里面摆各种商品出售；到了线上，店铺变成了虚拟的状态。原理其实与线下店铺一样。
4. 清算、二清、结算、核算
清算：指银行间清偿债权债务的行为。注意这里是银行之间。
举个栗子：用户在某电商平台购物（电商平台使用A支付公司收单），使用工行银行卡支付订单款1000元，工行将1000元转给支付公司账户，这个过程就是清算。
二清：顾名思义，二次资金清算。支付机构把资金经过一次清算给了没有支付牌照的平台，该平台又通过二次资金清算把钱结给他的商家。在这个中间，平台会沉淀大量资金形成资金池，这个平台的行为就属于二清行为。（央行的文件里会将二清细分为：信息二清和资金二清，这里是指资金二清）
核算：会计术语，主要是对于公司经营活动结果的记录，比如：公司采购商品入库，买入固定资产，向银行借款，支付货款，取得收入等等，都需要进行核算。
注：
以上解释均为通俗的解释，意在让读者能够理解含义，官方解释还请出门右转找隔壁度娘。
清算和结算详细解释可以参考知乎的文章《银行业务中的清算和结算分别是什么样的过程》
三、结算三要素
前面提到过，笔者在实际工作中遇到过很多同学，刚遇到结算的问题就直接切入流程，费尽力气把流程确定了，结果发现业务模式不对，对接的部门和人都不对，要推倒重聊。
所以，设计结算产品，可以分为战略层、范围层和结构层三个层面（如下图）。要从下至上，一个层面一个层面进行分析，切记不可操之过急。
注：这里借用《用户体验要素》理论对结算进行分层，如果不了解《用户体验要素》的同学可以在人人上搜一下，好多分享这个理论的，个人推荐可以看下梁宁老师《产品思维30讲》里面也有讲到过用户体验要素的理论和栗子。
1. 战略层（以实物为栗）
首先是战略层，也是最重要的层面。在这个层面要做的是确定业务模式。
从财务角度来看，业务模式分为两个大类：自营模式和平台模式。其中，自营模式可以细分为纯自营和厂商直送；平台模式可以分为纯平台和代转采。
区分自营和平台业务类型的三个条件：货物所有权、开发票方、资金是否过电商公司。
如下图：
（1）自营–纯自营模式
纯自营模式，即先采后销。电商公司先采购商品入库，再进行销售。这是最传统的自营模式。
流程如下：
电商公司采购商品
电商公司商品入库
这里货物所有权归属于电商公司、发票由电商公司给用户开具，资金流过电商公司。
注意，这里用户下单和支付与给供应商结算货款顺序并列，实际上两者并没有严格的先后顺序。有可能用户还没下单，货款已经结算给供应商；或者用户已下单支付，但账期没到，所以暂时不给供应商结算。
这里面关键在于“账期”结算——即采购商品时与供应商约定好结算的日期，到了结算的日期，无论商品是否销售，都需要把货款结算给供应商。（当然也有到了账期没卖出去给商家退货的，主要还是看双方谁比较强势，规则掌握在强者手中）
举个栗子：
老王3.10从隔壁供应商马乐采购一批手机，约定6.1结算货款。那么，6.1无论老王是否把手机卖出去了，都要把钱给马乐。
（2）自营–厂商直送模式
自营-厂商直送模式。顾名思义，在电商公司下单，厂家直接送货。
流程如下：
用户下单。
电商公司从供应商采购商品。
供应商直接发货给用户。
这里货物所有权归属于电商公司、发票由电商公司给用户开具，资金流过电商公司。
注意，这里跟纯自营模式最大的区别是，纯自营是先采购再销售；而厂商直送模式是先有用户下单，再进行销售，也称之为“以销定采”。
（3）平台–纯平台模式
平台—纯平台模式，即：只提供平台服务。
流程如下：
用户下单支付，订单款收至支付公司。
平台商家发货。
这里的货物所有权归属于平台商家、发票由平台商家给用户开具，资金流不过电商公司。
注意：平台模式下，电商平台不能代收代付货款，否则会有二清违规行为，被发现后果非常严重，收款和结算均需通过支付公司完成。
（4）平台-代转采模式
平台-代转采模式，顾名思义，代理销售转为采购。
流程如下：
平台商家商品进入电商公司仓库。
用户下单支付。
电商公司从平台商家采购货物。
电商公司给用户发货。
这里的货物所有权归属于电商公司、发票由平台商家给用户开具，资金流不过电商公司。
下面对上述业务模式进行一下总结（注意自营和平台业务的区分）：
注： 平台-代转采模式现行阶段还是会有些分歧，虽然从包装上来看像是自营。但是，整个模式与纯自营还是有些差别，在国内业务以及核算按自营业务处理。但按照美国会计准则来评估，仍认定为平台业务，在调整会计报表时，也会调整为平台业务。文章下面提到的自营和平台，主要是指纯自营模式和纯平台模式。
2. 范围层
部门是承载职责的架构，系统是实现业务的手段，无论部门和系统怎样变，其实都是围绕着职责。在范围层里面，最重要的也是职责，其次是部门和系统。
（1）职责范围
按照职责划分，最核心的三块就是：计费、结算和收付款。
计费：即计算应该跟商家结算的金额。
结算：这里最主要的是风控，如果订单款经过电商公司的话，则审核是一个必不可少的一个化解，需要在这个环节根据业务情况设置不同级次的审批流，以确保资金安全。同时会有一些风控的措施确保资金安全。
收付款：审核过了以后，最终就是执行收款和付款的环节了。
当然，上述的职责只是是结算里面最核心的部分，也是完成结算必不可少的部分。
对于一些公司来讲，一个新的业务如果要上线，除了结算以外还要符合核算、经分考核和税务等要求才能够上线。所以就业务角度来讲，上述都是影响业务上线的条件。
注意，关于职责的划分，不同的公司划分不可能完全一样，但整体都大同小异。
（2）部门范围
部门的设置，是根据职责确定之后来划分的。上述职责分为三块，通常可以将部门也设置为三个，即：计费、结算和收付款。
当然，这个并不是绝对的，有的业务线可能计费和结算是分开的，也有的计费和结算是合并在一个部门。
这里要说明的是：如果是自营类的业务，那么货款是由本公司的资金部门来完成；如果是平台类业务，由于二清合规要求货款不能过平台，则收付款的职责不在本公司，应该是在支付公司或其他有清结算资质的银行机构。
（3）系统范围
结算相关系统的设置，按照职责的划分，可以分成两个大块：结算核心和周边系统。
结算核心包括：计费系统、结算系统、收付款系统/支付（公司）系统。
周边系统包括：商家系统、合同系统、发票系统和核算系统等。
结算核心系统，是结算产品工作必须涉及到的系统，而周边系统，有些是不必要的、弱相关或者可以是暂时线下支持的。如：核算系统与结算行为基本无关，但是在很多公司都依赖系统化，并且也是业务上线的前置条件之一，所以在此也划到周边系统里。emmm，如果不考虑的话，核算的同学会找麻烦滴。
注意，上面的系统范围（也可以称为系统架构）是根据笔者实际工作中列出，但并非一蹴而就。平时与一些想了解结算的同学沟通，很多一上来就问如何搭建结算系统架构。其实无论2C还是2B，都是从一个点开始，随着业务的发展然后才慢慢演变成最后适合业务的架构。直接上来就搭建一套高大上的系统架构，大都华而不实，中看不中用。
3. 结构层
战略层和范围层确定后，接下来自然进入到结构层：流程层面。
在结构层，也是很有讲究的——系统流程是基于业务流程，而业务流程则是基于资金流程。
结算的流程设计，跟2C流程很大的不同是：2C主要侧重用户体验，而结算流程里面合规是非常重要的因素，所以资金流是重中之重。
（1）资金流
按照上述自营和平台业务两类，资金流也分为两类：
① 自营资金流
② 平台资金流
在这里，两者的区别是订单款是否过电商公司，这个在上面已经提及，这里不再赘述。
资金流最主要关注的是合规风险，电商及互联网公司由于交易量巨大，容易形成资金池，之前媒体也报道过有互联网公司违规挪用用户资金的情况。所以，在这里平台型公司尤其要关注合规风险。
（2）业务流程及逻辑
业务流程，即结算的业务流程，为了完成资金结算而需要执行的操作。根据业务模式，分为自营结算业务流程和平台结算业务流程。
① 自营业务流程
② 平台业务流程
在平台业务流程里，由于货款资金不能过电商公司，所以计费完成后，直接对接支付公司给商家结算货款。 不过如果涉及到跟商家收取佣金等款项，也会涉及到上面自营业务流程。
虽然结算流程分为自营模式和平台模式，但是其中也有相似之处，在这里抽象一下统一进行讲解。
a. 计费
自营业务和平台业务的计费依据不同，自营是根据采购单结算，平台是根据订单结算。
但总的来说具有相似性，可以总结为3W1H。即：When-什么时间计费，Who-谁给谁结算，What-结算哪些费用，How much-结算多少钱。
When：什么时间计费。
——计费时点与业务强相关，不同品类、结算方向不同，计费时点也有所不同。
自营业务计费依据为采购单，计费时点为采购单的账期，如：3.1采购一批货物总计1000万元，约定5.31还款，在5.31前须进行对账，在5.31完成结算。
平台业务计费依据为订单，不同的业务账期也有所不同，通常分为：实时、T+1、周结、半月结和月结。
如：实物通常是在用户pin里【确认收货】按钮被点击时触发计费。当然【确认收货】按钮如果用户不主动去点，到了特定的期限系统会代用户点击。
笔者之前从事机票行业，计费时点根据不同业务进行区分。像航司直营业务，由于航司要求机票款实时结算，则票款需要在用户支付后即进行计费并结算给航司；代理商模式是在给用户出票完成后开始计费；自出票业务则是在导入国际航协的账单进行对账的时候开始计费。
这里要注意，计费时点务必与商家确认一致。计费时点看起来貌似很简单，但在笔者的身边，就发生过公司与商家计费时点不一致导致账对不上的情况。
Who：谁给谁结算。
——指哪个销售主体给哪个商家结算。一般来讲大的公司集团旗下都不止一家公司，而公司也会从法务合规、税收筹划和当地政府优惠政策等角度考虑，根据不同的业务种类使用不同的主体与商家进行结算。这些信息通常在业务刚上线会由法务和税务部门确定，商家入驻时在商家系统维护好对应关系。在计费的时候，从商家系统获取对应的结算公司主体和商家信息。
What：结算哪些费用。
与商家结算，资金流可能是轧差结算，也可能是收支两条线，但具体结算的费用肯定是要列出明细的，如：货款、佣金、返点、罚款、优惠券、促销等等。
需要注意的是：给商家结算的明细与公司内部要求的会有些不同。
拿货款举栗：在没有促销和优惠券等的情况下，给商家结算货款=公司内部货款=订单款，但如果有促销，则给商家结算货款=公司内部货款+促销。
How much：给商家结算多少钱。
这个是基于上面的What来进行计算的，确定了计费的明细，需要根据与商家确定的规则来进行计算每条明细具体的金额是多少。这个是在计费里面的核心，也是最复杂的地方。
这里主要关注三个方面：
计费的维度：按订单还是按订单里商品的维度计费，这个要看公司的计费规则，以及是否有商家有特殊要求。
如：1张机票订单里面有3张机票，是按照整个订单总金额结算还是分别结算3张机票的钱。
计费的规则：即如何计算应结的金额。
仍以机票为栗：一张机票通常包含机票款、机建费、燃油附加费，机票佣金，保险款、保险佣金、行程单配送费、行程单配送佣金、促销、优惠券。（按订单维度结算）
促销费=单品促销*促销数量（我司促销按照商品维度，所以需要单品促销金额*促销的数量）
优惠券费用=订单的优惠券费用（我司优惠券按照订单维度）
应结机票货款=（机票款+机建费+燃油费）*数量（机建费和燃油费与机票款一同结给商家）
注意：如果促销费和优惠券费用由公司承担，则应结货款为上面计算公式；如果促销费用和优惠券费用由商家承担，则应结机票货款还要减掉促销费和优惠券费用。
机票佣金通常分为两种：一种为按比例计算；一种为按舱位计算。
按比例计算：机票佣金=机票票款*佣金比例
按舱位计算：机票佣金=成人机票对应舱位佣金*票量+儿童机票对应舱位佣金*票量+婴儿机票对应舱位佣金*票量（这种佣金实操会比较复杂，因为不同的航司，舱位不同，舱位的佣金也不同。有些会区分乘客类型，有些不区分，这里明白意思即可，不需细究）
应结保险货款=保险票价*数量（保险的价格一般固定不变，都是提前维护在系统里面）
保险佣金=在系统维护的佣金（保险佣金一般会提前跟保险公司确定具体的价格，也一并随保险款项维护在系统里面。）
计费规则概括来讲，就是基于应结的费用明细项，掰开揉碎了按照与商家确认好的规则进行计算。这里务必要与业务同学多沟通，多了解业务，才能保证准确性。
计费对账及调整：对账的节点并不是唯一的，也要根据业务实际情况。
在笔者实际工作中，有的业务是在计费的节点进行对账，还有的业务是在结算完成后对账，差错在下个账期进行调整。这里需要人工在系统内找到错误的费用项录入调整明细进行调整。
当然，除了上述要素，还有比如：订单号、商品数量、收付款方向、结算币种等，每个公司根据业务情况有所不同，根据公司具体情况确定就好。
小结一下：
计费的逻辑与业务强相关，要对业务进行理解，从行业整体了解业务种类，每种业务的特点，不同业务的差异等，才能够抽象出共性的计费逻辑并设计好计费的业务和系统逻辑。不同业务计费的具体逻辑不同，但是道理是相通的。
b. 结算
结算可以总结就为Yes or No，即是否可以付款。在这里自营和平台业务的差异较大，下面分开来讲。
自营模式：
资金流会经过电商公司，在这个环节主要关注以下逻辑。
结算账期：自营的结算账期在采购商品的时候即已确定，双方签字画押约定一个固定的黄道吉日进行结算。
生成结算单：自营的账期是固定的日期，在到达账期前会由人工或者系统对应结的采购单进行勾选，生成结算单。结算单由n个采购单组成，n>=1。
结算对账：生成结算单后，业务或结算员需要核对结算单货款的应结商品数量、金额、退货等信息是否有问题。另外，如果商家有返点，在我司投放广告等需要一起结算，也需要一并进行核对。
商家确认：公司内部对账完成后，需要商家在商家后台核对并确认。
差错调整：如果公司或商家对账发现有差异，需要进行差错调整。这里的做法是会给业务人员开个手工录入的权限，将差异录入系统并对差异原因进行说明。调整之后，结算金额应与商家最终确认的金额一致。
发票核销：如果结算条件为先票后款，则需要在供应商开具发票，并将发票核销后才能进行下一步结算；如果结算条件为先款后票，则发票核销在结算完成之后进行核销。
风控校验：这里做的校验主要是合同号是否有误，结算主体与合同主体是否一致，结算账期、结算方式是否有误，结算是否倒挂（应收商家金额>应付商家金额）。如果发生倒挂，要通过系统以及邮件进行预警，提醒对应采销人员及时关注并进行后续处理。
审批流：上述环节完成后，进入审批环节。在我司，不同的业务条线，不同金额大小，对应的审批级次也不一样。审批流这个东西被所有公司所诟病，如果是线上审批还好，发个微信或邮件催下就好了；如果是线下审批，要拿着打印的单子到处找各个领导审批，如果领导不在就比较头大了。审批流在制定时一定要慎重，审批流过少会增加风险，过多会降低结算效率。
平台模式：
资金流不经过电商公司，同时对于结算时效要求较高，以实时结算和T+1为主，所以该模式下不会生成结算单，也没有电商公司审核的环节，由计费系统直接对接支付公司完成结算。
不过在结算环节仍然会有风控的校验，主要监控是否跟商家有倒挂的情况发生。在结算中会发生退款涉及到需要把商家货款扣回，以及应收商家佣金等情况。在结算时，为了降低资金风险，会监控是否有倒挂情况，如果发生倒挂情况，会将商家的钱包进行冻结，同时通知计费系统暂停结算。
涉及给商家开具佣金发票，由商家在商家系统申请即可，但并不作为结算的前置条件。
c. 收付款
在这个环节，主要是收付款的“执行”环节，可以总结为Just do it。这里也要区分自营和平台业务分别说明。
自营业务收付款：
保证有足够的资金支付：这里属于资金部门资金管理的部分，一般大型公司不会把所有的资金都存在银行，会对富余的资金做些理财和投资，以保证资金收益最大化。通常会把所有资金归集到总账户，到付款的时候再跟总账户进行请款完成货款结算。这里属于资金运营管理范畴，不在此展开。
保证货款能够及时结算：结算单到收付款环节会按照资金侧的格式生成收付款单，上面会有对应的付款日期，资金侧需要按照对应的付款日期执行付款即可。
直连付款：传统的付款方式需要进入银行网银操作，效率非常低下。我司的资金部门，会将内部的资金收付款系统与银行和支付公司进行直连，到付款的节点，直接人工点击【付款】按钮或设置系统自动触发【付款】按钮，即可完成付款。当然，按钮是人工还是系统触发，可以根据公司情况自行设置。
对结算的资金能够及时准确记录：完成收付款后，还需要实时根据收付款记录进行逐条记录，为现金流管理和现金流分析提供决策依据。这里属于资金内部管理范畴，做结算的工作了解即可。
结算方式：自营模式下为轧差模式——即应收金额和应付金额相抵后按照差额结算。如：电商公司应付商家100万，电商公司应收商家5万，则最终给商家结算95万。注意这里并不是绝对的，有些大公司要求收支两条线的，也会分应收和应付单独进行结算。
平台业务收付款：
平台业务资金流不过电商公司，所以在这个收付款环节，可以是计费系统对接资金收付款系统，也可以由计费系统直接对接支付公司。
注意，这里有个风控点是：支付系统会做两个校验——该订单是否收过款；该订单的结算金额是否小于等于订单款金额。
另外，平台模式的结算方式为收支两条线，这里需要符合央行监管的要求。如：应付商家10万货款，应收商家0.1万佣金，则需要将10万货款结算到商家账户再把0.1万佣金扣收回来。
d. 其他：记会计账、记资金账、记经分账、开发票。
记会计账：对于业务经营活动结果进行记录。
记资金账：简单的说就是账户的资金收支流水情况。
记经分账：记录公司和部门的业绩。如：公司赚了1000万，其中600万是A部门赚的，400万是B部门赚的。
开发票：涉及到销售行为需要开具发票，可以线上开具电子发票或者线下开具纸质发票。
以上属于财务的范畴，但是并不属于结算范畴，大概了解即可。
(3) 系统流程及逻辑
业务流程和逻辑确定后，接下来就是设计产品系统方案了，业务流程和逻辑制定后，系统流程和逻辑也就好确定了。
不同的业务计费结算流程会有差异，以下拿笔者工作中涉及到的机票代理商正、逆向计费结算系统流程及逻辑为例。（平台业务，T+1结算）
由于业务属性较强，所以对于图中意会即可，具体实务可结合本公司实际情况制定产品方案。
另外，笔者在业务线产品部，并不负责后续财务系统。所以，系统流程和逻辑主要讲解计费部分，财务系统部分略。
机票代理商计费结算流程——正向：
机票代理商计费结算流程——逆向：
四、总结
上面主要通过结算的战略层（业务模式）、范围层（职责、部门和系统）、结构层（资金流程、业务流程和系统流程）三个层面讲解了结算产品工作的思路。
第一步，在战略层先确认业务模式是自营还是平台。
第二步，根据战略层在范围层确定结算的职责、涉及到的部门架构以及系统范围。
第三步，根据战略层和范围层，在结构层依次确定资金流程，结算业务流程和系统流程。
设计结算产品，一定要严格按照这个层次，自下而上的一层一层进行设计，否则后果会很严重。
要做好结算产品工作，除了产品思维，还要同时站在业务视角和财务视角来分析产品，视角不同，思维也不同。
业务侧最关注的是业务能够顺利走通；而财务侧最关注的是合规。两者往往会有冲突，比如：一项业务，现行法律法规可能没有那么完善，那么财务部门评估起来往往会趋向于保守，建议不做或建议的流程会很繁琐。但公司之间竞争是非常激烈的，业务部门则希望能够尽可能的简化，策略上也会更加激进。导致方案反复沟通反复确认而迟迟不能达成一致。
做结算产品，最重要的是能够在业务和合规间做一个平衡。不能一味追求业务发展不顾风险，也不能一味只追求合规，而限制业务前行。毕竟业务都没有了，财务自然也就不存在了。
文章末尾，要特别感谢倩姐、老胡和盈超提供的宝贵意见，感谢郝老师的认可。
在写这个的过程中真是耗费了很多元气，从结构到内容，到里面的一些细节，反复修改了好多遍。最终成稿后，能够像标题《写给业务线产品的结算宝典》一样能够帮助到有需要的同学，能够得到认可，也感到非常欣慰。只是要吐槽下，郝老师的红包只有0.01元实在是太抠了！！！
