交易过程中或者完结以后，记账工作就开始了，账务作为支付交易的基础设施非常重要，其关键并不是设计本身，而是账务的设计理念、规范和原则。本文将详细介绍账务相关系统的设计方法，并从账务原理、账户子系统、热点账户、账户合并、会计日切原理、营销类账务处理、清结算的账务实现模型等10方面了解账务及账户的相关内容。现代支付的底层就是账务，无账务不支付，无账户不资金。既然账务这么重要，那么搭建一套适合自己的账务核心是非常重要的从场景中的需求出发理解账务的本质，搞懂客户、客户的场景、客户在场景中的诉求，懂用户才能做出好产品，一切系统设计来源于需求
首先是基于外部客户的账务诉求看账务服务，账务是要服务的不同客户面对的业务和诉求，为他们提供针对性的支付等各类解决方案；搞清楚这一点，可以更懂自己的客户，提供更符合市场余额的“账务和账户产品”
![]()
然后是基于内部客户的账务诉求看账务服务，主要就是清结算业务、内部运营诉求和财务核算诉求，内部业务依赖的账务和账户类型与客户支付和资金处理诉求存在差异；了解内部业务及诉求，可以为内部业务运转提供高效的“账务和账户服务”
![]()
所以说，基于客户诉求抽象和构建账务核心的服务矩阵
![]()
任何设计都要先俯视全局，一切从总架构出发，在总架构的指引下完成局部建设，账务全局架构非常关键的一点就是与外围系统所建立的往来关系。
所有相关的外围系统，例如交易系统、支付系统、清结算系统等本账号之前的文章均做了详细的解析，将“各业务系统，业务系统产生的记账种类，账务核心”等内容整理到一张架构图中来阐明这种浑然一体的全局关系。
![]()
1.2.1记账离不开外围驱动
如图中各个系统都产生相应的记账业务，然后调用账务核心的记账服务，根据各类记账接口协议提交业务流水明细，例如：
1.2.2账务服务为记账提供接口
账务系统采用统一记账接口也可以，所有业务的记账请求都请求这个接口。但是，因为未来要给商户出具账单，各类记账所需要的参数信息存在差别，所以可以为不同记账种类设定差异化的记账接口，例如收单类记账、打款类记账、结算类记账、鉴权类记账等等，并在记账接口模块维护这些记账协议，可以方便新增和调整这些记账协议。
业务记账数据通过指定接口提交至账务系统以后，账务系统需要先生成业务流水进行存储。因为不能业务数据不落地直接生成记账凭证，需要原样保留原始凭证；更不能让业务用记账凭证的格式提交数据，那不是业务系统该做的事情。以收款记账为例（下同）来串联这个流程，下表是收款业务流水，信息做了简化，一共2笔订单，数据编码都是2001类型，另外还有商户编号、交易金额、时间、支付金额、手续费、业务产品等维度的信息。
![]()
1.2.3记账需要凭证规则
业务流水生成以后，账务事务控制基于记账规则，生成相应的记账凭证，我们先看2001收款类流水的记账凭证规则，包含2张凭证规则，一张时本金的入账凭证“借记清算往来，贷记商户待结算”，另一张是手续费的转账凭证“借记商户手续费，贷记平台手续费收入”。
![]()
1.2.4凭证生成
通过规则可以看出来，会生成2张凭证，并且其中002号凭证的03行需要进行单边的资金处理，实时更新商户手续费账户，生成的2张凭证如下表所示。
![]()
1.2.5实时资金处理
002号凭证的03凭证行需要进行资金处理，请求账户子系统进行资金处理生成账户明细，以支出的形式入账到商户的手续费账户中，并登记入账前后的账户余额。
![]()
1.2.6定时凭证汇总
因为电商类企业收款业务数量巨大，因此往往需要对明细凭证行进行汇总，以便向会计提交数据时不至于数据量过大，而会计分录数据可以向原明细凭证进行关联追溯；对收款凭证进行汇总得到汇总凭证
1.2.7单据关系
外围系统驱动账务登记，整个链条上会产生一系列的单据，业务系统有业务单据，提交至账务核心以后账务系统也会生成一些单据，这些单据之间的关系如下图所示
2.账户子系统
账户是根据会计科目设置的，具有一定格式和结构，用于反映会计要素的增减变动情况及其结果的载体，而账户体系是支付交易的基础，就像电池对于手机，油罐对于加油站，心脏对于人体，是管理账户的信息化系统。现代电子支付离不开各类账户的参与，又因为支付体系中存在众多机构参与者，因此也必将存在种类繁多的资金账户，要想悟透支付，参透账户体系非常重要。从不同的视角看，账户有不同的分法，例如从财务视角，账户可分为资产类、负债类、所有者权益类、损益类、共同类等；因为要研究支付，所以我们更关注跟支付相关的账户，也就是跟货币-银行存款相关的账户，这类账户又可以从账户用途或者机构归属去划分。从账户用途的角度去划分，在整个清结算链路上可以将账户划分为“存款账户、中间过渡户（清算往来、已清算、待结算）、客户虚拟账户等”。从机构归属的角度去划分，又可以分为央行清算账户、银行结算账户、支付机构支付账户、普通企业虚拟账户等。而每个机构的账户又可以进行二次多级分类，例如银行账户又可以分为个人结算账户、企业结算账户；支付机构的账户可以分为个人支付账户、企业支付账户；而银行个人结算账户又可以分为一二三类户。金融监管的本质实际上是对不同机构的不同类型的账户进行个性化监管，例如银行的个人结算账户和单位结算账户分别适用于不同的监管条例；而个人结算户的一类二类三类户又拥有不同的账户交易权限。如此富有层次的账户体系，支撑起了如此庞大的支付清算体系，使得各类资金在不同机构、不同账户之间进行流转，也正因为有这么庞大的账户体系，现代支付的实现才成为可能。根据账户用途的不同，可以将账户分为如下5类：客户账户、结算过渡户、清算往来户、已清算应收付账户、XX存款户；各类机构会基于实际情况选择设定这5类账户中的一种或者多种用于自己的清结算业务，其中客户的账户就是我管别人的钱，而XX存款就是我的钱被管在XX那。在不同的机构，这5类账户的性质会有所不同，例如对于银行来说客户账户就是个人或企业结算账户，属于资金账户，而存款多指在央行的存款或者在其他金融机构开立的存款账户。对于支付机构来说，客户账户就是支付账户，而存款多指存放在央行的备付金存款账户的资金。同样清算往来账户登记的也有差别，支付机构的清算往来是指与网联银联的往来；而交易平台的清算往来指的是交易平台与支付机构的支付往来。有了对于账户的这个基本原理的认知，再理解各类机构的账户设定就容易多了。支付账户可以分为个人支付账户和企业支付账户；该账户实际上是一种虚拟记账账户，真实的资金存放在央行。企业支付账户多是用于登记其商户的代收预付的款项，最终会结算至企业绑定的同名银行单位结算账户中。个人支付账户主要是用于零售消费使用，可以通过绑定的个人银行结算户进行资金充值，同样也是一个虚拟记账账户，真实的资金也存放支付机构在央行的备付金账户中。银行结算账户也就是我们所熟悉的银行卡的底层账户，可以分为个人结算账户和单位结算账户，这类账户是整个社会的金融基础，个人存款、消费等的资金存放处。央行的账户与支付比较密切的就是三方备付金账户以及银行和网银联的清算账户，跨机构支付清算在这些账户之间完成最终的资金清算。断直连以后，网银联为支付机构在其前置系统内开设清算用途的虚拟账户，用于央行备付金的映射管理、机构间清算往来登记、可用额度管理。这里的所有余额都只是虚拟记账，是机构间交易的清算结果，真实的资金存放在各机构在央行的备付金账户中，只有在结算场次将各机构的清算净额提交央行完成最终清算以后，央行备付金余额才会发生变动。2.2账户系统概述
在开始学习账户系统之前，先看账户的基本结构，标准的账户应包含以下内容:从业务视角来看账户，账户可以理解为是用于记录某个主体、某类型资金的余额、以及余额变动明细的数据载体，所以账户应该包含3个最基本的信息。账户余额：这个账户有多少钱。
账户流水：这个账户资金进进出出的明细记录。
账户交易：怎么把钱放进去，怎么把钱取出来。
抓住了上面的3个关键点，也就抓住了账户设计的核心了。基于这3个点去构建账户的辅助内容，比如账户主体、账户种类、账户余额结构、账户流水的字段、账户的功能权限、账户的出入账、账户其他服务（账户开通、注销、冻结、解冻、余额流水查询）等。2.2.1账户种类
与科目分类相同，账户可以分资产类账户、负债类账户、损益类账户、共同类账户。从业务的视角看，可以基于业务场景对账户进行分类和命名，比如商户的结算款会结算到商户结算账户，支付公司在银行开的账户叫备付金账户，断直连之前备付金账户又分存管户、收付户、汇缴户；按主体类型可以分个人账户、企业账户；按账户的功能又可以分为会员子账户、商户子账户、中间担保户等，下图某监管类账户的子账户种类设置。通过账户的命名基本就知道了这个账户是干什么用的。就像某人有10张卡，其中一张是存放工资的卡叫工资卡。基于业务命名，目的是为了更容易识别账户的用途。账户无论叫什么名字，都要包括账户余额、账户流水、账户交易这几项；无论银行卡叫什么名字，其本质都是银行卡。所以账户的本质属性并不会随着账户名称的改变而改变，设计方法也基本相同。不同的是附属内容存在区别，例如支出账户只能打款不能收款，中间担保账户余额不能为负等，账户权限可能不同、主体归属不同、交易特点不同等2.2.2账户系统功能结构
先从整体上了解账户系统的基本功能，一个基础的账户系统应该至少包含账户配置、账户管理、账户信息管理、账户权限、账户交易等模块。账户主体：这个账户是谁的，个人的？企业的？还是内部业务线的？
账户结构树：就像商品类目，由于账户种类繁多，有时也需要一个结构树分类结构。
账户类型：账户的分类；
账户名称：对账户的命名；
账户余额：账户所记录的资金数量；
账户流水：账户的资金变动记录；
账户服务：对外提供的账户能力，如账户开通、注销、入账、扣账、调账等；
账户是一个底层服务，基于账户提供的服务可以构建很多资金解决方案提供给不同场景、不同人员或者上层产品使用，整个解决方案蓝图如下图。最底层是账户的基础能力，包括主体管理、账户管理、余额管理、交易管理等，是账户封装各类服务的能力基础。基础账户基础服务可以向外提供一个API矩阵，将账户能力包装成服务接口提供给上游各方，例如主体变更、账户开通、信息查询、交易服务、冻结解冻等。然后就是基于账户服务而封装出来的各类资金解决方案，如结算业务、对公结算业务、其他种类的结算业务、财务处理等。在业务层就可以产出如钱包、收银台、对公结算平台等用户产品，提供给用户和商户、内部财务人员或运营人员使用的产品工具。账户需要归属于一个主体，也就是谁的钱、谁的债。主体可以是个人人，可以是公司，可以是一个组织，主体是一个具有基本特征的可定义的对象。2.3.1主体的定义
广义的主体，基于对象出发，可以认为主体就是自然界存在的实体物质或者虚拟的对象，如一个人是一个主体，一个公司是一个主体陈天宇宙，一个组织是一个主体，公司的一条业务线是一个主体，公司的一个部门也是一个主体，一个城市也是一个主体，一座房子也可以是一个主体。账户的主体可以是广义的，比如一个城市的GDP因为可以通过一个统计报表得到，所以也可以为每个城市设置一个GDP账户，那么这个账户的主体就是一座城市。因此，只要是一个可以被定义的对象，我们就可以将它作为账户的主体来管理，就可以为之开通某种意义上的账户，账户也可以是广义的，不只是金钱余额，也可以是水量余额，电量余额，好感度余额等等。从而广义账户就可以认为是一个可以记录数量和数量变化历史的工具。狭义的主体，回归账户主体本身，就是账户的归属对象；最常见的主体分类就是个人和企业；如银行卡的主体有个人主体和法人主体。一个公司为了经营分析或者管理的需要，又会虚拟出更多的主体类型，比如营销账户的主体可以是业务线、部门或者一个小组，来记录部门和小组的预算以及预算的消耗情况。从央行的角度看，清算账户的主体就是网联、银联、各商业银行、各城市处理中心、各特批处理机构；站在银行角度看银行账户的主体就是个人、企业、支付机构等；站在一个普通企业看账户主体就是个人用户、企业用户、内部业务线、子公司等。2.3.2主体的生成和管理
对于一个平台而言，其账户系统的主体无非有以下几种：个人用户：具有身份证或者手机号等唯一识别标识的一个自然人个体；
企业用户：具有企业信用编号唯一识别标识的一个法人主体；
内部主体用户：内部的子公司主体或者业务线主体或者某部门；
在创建主体的同时就需要定义每一类主体的唯一识别ID。在开户的时候，需要使用这个唯一识别ID作为账户主体的唯一识标识。个人的唯一ID可以是身份证，在开银行卡的时候就是用的身份证ID作为个人的唯一识别ID，在办理社保的时候也是用身份证ID作为身份的唯一识别ID；唯一ID的条件就是能够唯一识别这个主体，其中：个人的唯一ID可以是身份证、手机号、社保号、一个平台的userID，其他的在这个平台的唯一ID；企业的唯一ID可以是统一社会信用编号，也可以是对公户的卡号等；如果企业入驻了一个平台，那么这个平台为这个企业生成的企业编码也可以唯一识别这个企业。唯一ID的用途是唯一识别这个主体，但有时候可能这个主体的唯一身份ID不够用，比如这个人在淘宝即是个人用户又是商家用户，那么他在开户时可能就不能只用身份证了，而是用个人身份的userID 和商户身份的 bussid。为了安全起见，平台需要核查主体的身份，像去银行开户需要本人到场+身份证核验；二类户的开通需要多要素鉴权识别主体身份的合法性。对于企业来说可以通过企业的营业执照、法人签字、盖章或者对公户小额打款来验证企业的真实身份怎么管理这些主体呢？一个平台的各主体信息一般是放在用户中心，用户中心去调用账户中心为主体开通相应的账户。用户中心存储着主体的基本信息，比如ID信息、属性信息、权限信息、关系信息等。要新增信息就增加字段即可，也可以将信息进行分类，每一类记录到不同的表中，比如身份信息、认证信息、账户开通信息等，如下表所示。生成了主体信息以后，就可以通过人工方式开户，也可以通过上游系统调用开户接口为主体开通相关账户，例如通过接口开通账户传入了以下信息：主体ID：123；
ID类型：userid；
用户类型：个人；
用户姓名：张三；
账户类型：佣金账户；
开户成功后账户系统首先会在账户主体表中插入主体的基本信息。根据主体ID可以去账户表查询开通的所有账户，基于开户请求我们在账户中心表为主体创建对应的账户，账户中心表中要有主体的唯一ID。账户中心经过上述一系列的处理后，账户就开通成功了，然后将开户结果返回给开户请求方。从上面的开户过程可以看出来，账户和主体之间有复杂的对应关系，主体和账户以及与账户主表与各类子表之间有复杂的对应关系，主体与账户是一对多的关系，一个主体可以开通多个账户，每一个账户又会关联余额表、权限表、流水表等多张表，主体的开户ID去关联账户的账户ID，账户ID去关联账户的余额表中的余额、权限表中的权限。设计账户前需要了解账户的基础结构，所面对的业务不同，就意味着需要的账户结构就会存在差异，可以从账户的复杂程度将账户结构分成简单结构和复杂结构。2.4.1账户结构
账户结构一方面是账户本身的结构有什么组成，另方面就是账户与账户之间的构成关系。简单的账户结构可以分为单类型账户和多类型账户，单类型账户是只有一个类型的账户，整个账户系统只有一类账户，或者有多个类型的账户，但账户层级只有一级，本质上依然很简单，很容易管理。随着业务的复杂度增加，各类功能性需求以及业务需求增加，简单的账户结构变得不够用了，难以支撑更复杂的业务模型，例如每个业务线都要推出一种红包营销形态，有保险业务线的红包，也有游戏业务线的红包，而红包又被拆分成了现金红包、虚拟币红包，这种情形下红包账户结构就成了多层级的复杂账户结构。某些监管类账户的结构更加复杂，不仅存在多层级的账户关系，还从业务层面对账户进行了分组，如下图所示，是具有众多子账户的账户结构，协同完成资金的监管和分账职能。2.4.2余额结构
余额结构就是账户的余额如何划分，就像火锅可以分一个锅、鸳鸯锅、九宫格；同样，账户作为一个“资金容器”，其内部依然可以划分成多个存储空间，按照账户余额的种类可以将账户分成简单余额结构和复杂余额结构。只有一个余额的余额结构是简单余额结构，比如微信钱包的余额只有一个，陈天宇宙。复杂余额结构是指账户的余额被拆分成了多个余额。因为资金清算周期或者业务流转节点多，亦或者其他风控要求，需要对账户余额进行复杂的处理操作，比如有的能提现，有的不能提现。常见的复杂余额结构如表所示的具有三个余额属性的账户余额结构。这种结构存在一个核算恒等式：总余额=冻结余额+可用余额，基于这样的结构，可以对账户余额进行一些复杂的处理，比如发的红包7天后才能提现，那么红包入账户时就可以先入冻结余额，7日后解冻到可用余额。2.4.3账户结构关系
账户可以分多级，余额可以分多块，那么他们之间有什么关系呢？可以用下面的公式表达。了解了账户主体、账户结构、账户余额结构以后，就可以设计出账户表的基本字段了，大体上应包含这几部分信息：账户主体信息、账户结构信息、余额信息、账户状态信息；除了核心字段以外，其他想展示的字段可以去相关表中查询，比如主体信息，可以用主体ID去主体表中查询。开通了账户以后，账户里就会有存入和存出、充值和提现、转账和消费；此时账户就会流动起来，就有了生命力；那么在不同的交易场景里就需要关注“费用”，一笔收支有多少钱，是什么费用，账户的记账才清晰。2.5.1交易场景
任何一笔收支的发生都依托于一个或多个场景，例如用户出行在某打车平台叫了一辆快车，张师傅接了单子，路程从立水桥南到奥森公园；这就是一个交易场景，可以称为”快车打车场景“，在这个场景里我们可以知道用户是谁、在哪儿打的车、什么车型、起步价多少、每公里单价多少、司机是谁等信息。如果车到了超过了4分钟，用户不用车取消了订单，用户就需要支付一个取消费用，这又是一个新的场景，可以称为“超时取消场景”。将平台的所有交易场景进行枚举，如果要新增场景，那么要预先在场景中心申请场景编号，才能开展上线业务。2.5.2费用项
在上述的场景中，就会发生交易，因此会产生一系列的费用，例如打车单的相关费用费用包括下面这些，完单后要给司机做结算就有了订单结算费用，平台要抽取一定服务费就有了平台服务费用，如果是在高峰期，要给司机发一些补贴，就有了高峰补贴费等等。费用就是站在业务角度定义资金的业务属性，基于业务侧的费用我们可以关联到后续的财务科目，费用是从业务发生那一刻就产生，而且最后可以关联到会计科目的核算内容。2.5.3计算
计算业务场景中产生的费用需要一个强大的计费系统，例如上一小节中的场景，在下单前需要进行费用的预计算，用户选择起点和终点后预先计算可能需要的订单费用；在订单进行中需要实时计算费用，订单结束后需要计算出本单实际产生的费用。从图中可以看出来订单总费用包含三部分：起步价+里程费+时长费；你可能会问，一个订单为什么要拆成这么多费用呢？简单想一下，这三个费用的特点，而且这三个费用在不同的城市，不同的时段，不同的用户，不同的车型都会发生变化，所以可以理解为，费用的细化是精细化运营的必然结果，另外用户也需要知道为什么收这么多钱。订单完结后就需要给司机做结算，就需要再进行一次计算，计算出这一单应该给司机多少钱，平台抽多少钱，要不要实时扣税，有没有其他费用，比如保险费等，即可以得出如下的清算结果。前面讲了交易场景和费用的定义，现在进行费用设计的分析，设计费用有三个关键点：费用编码、费用名称、费用结构。当然，围绕费用可以展开非常深的研究，如与科目的关联、费用的资金方向、用途等，本部分仅从简单的原理进行设计，不做过于复杂的分析。设计办法常见的有2种：一级枚举型，就是费用之间没有关系，对所有费用进行枚举，如下表；另一种是多级结构，可以对费用进行分组，在不同的使用场景下展示不同级别的名称。以上两种方式可能第二种更好一些，特别是在核算和统计时，可以进行总分分别进行统计分析和核算。2.5.5入账规则管理
在交易的每一个节点都会产生费用，或者计算出相关的费用，例如司机收入。计费之后就需要计入相关的账户，如司机收入要计入司机的结算账户；有时候一个费用要计入多个账户，又比如司机奖金可能要同时计入平台的运营账户和司机的结算账户。入账规则的设计有两个关键点，一个是匹配条件，要以入账请求的传参为条件匹配到相关的入账规则条目，需要定义每类记账请求需要什么条件，比如司机收入入账，一个“费用类型”作为条件就够了；另一个是入账规则，就是这个条目指定入什么账户，比如司机收入匹配到的规则是要记入司机结算账户，则入账规则如下：基于上面的规则，上游系统在申请入账时必须传几个参数：费用类型、主体类型、主体id。基于司机收入这个费用，就可以匹配出一条规则，应该入司机的结算账户，利用司机ID找到相关的结算账户ID然后计入账户，这个流程如下图所示。业务系统请求入账以后，基于费用类型以及入账规则就可以知道应该入哪个账户；那么问题就来了，因为账户余额也是分结构的，有冻结余额和可用余额，要是想将入账金额先冻结起来怎么办呢？这就需要冻结规则去实现。2.6.1冻结规则
冻结就是一个费用请求入账时暂时冻结起来，计入冻结余额。冻结规则是基于入账规则设置的，也就是这笔入账需不需要冻结，如何冻结，是全部冻结还是部分冻结，所以一个入账规则要关联一个冻结规则，入账的时候就需要同时获取冻结规则；入账规则和冻结规则是一对一的关系，费用类型和入账规则是一对多的关系，因此，费用类型、入账规则、冻结规则三者之间的关系如图所示，陈天宇宙。冻结规则有2部分组成，一个是关联的入账规则；另一个是冻结规则。也就是说在配置入账规则的同时就需要关联性的去配置一条冻结规则，如下表所示。配置规则的新增规则原型如图所示，冻结模式为固定时间和固定时长的规则配置内容不同，具体看图例，冻结规则的配置有以下几个关键点：2.6.2账户流水
账户有2个核心部分组成，一个是账户余额，另一个就是账户流水。账户流水是账户的历史变动明细。为了记录资金的变动明细，账户流水需要记录最基本的明细信息，一般必须包含以下内容：2.6.3更新账户余额
这里有一个账务处理任务流，每笔入账都需要从头执行到尾，不能遗漏，任何一个处理失败了这笔入账就宣布失败，进行入账失败的处理流程，入账任务流如下：检查账户流水合法性；
账户流水表插入账户流水；
- 基于账户流水信息更新余额表对应账户的冻结余额或者可用余额；
自洽校验：总余额=冻结余额+可用余额；
经过上述的处理流程，成功的完成了入账，并通知请求方，本次入账结束。2.6.4余额解冻
因为入账的时候有的流水处于冻结状态，所以需要按照冻结的规则进行解冻。此时，需要一个解冻处理的任务对流水进行扫描，至于扫描的模式要基于冻结模式去设计，我们以冻结固定时长最小单位为天为例，那么任务就需要每日凌晨去扫描遍历所有处于冻结状态的账户流水，满足解冻条件的流水就变更冻结状态为未冻结，然后对余额进行处理，即减少冻结余额并增加可用余额，账户总余额不变。 3.账务层解决问题
特别是企业的清结算业务，账务是其核心部分；另外现在支付体系的基础也可以说是站在账务核心之上，不同机构的账务管理着不同资金属性的“账户”，管理着不同的信用货币。市面上的账户种类主要有三方支付机构的支付账户、银行的结算账户、央行的清算账户、合规监管账户体系、数字货币钱包体系、跨主体清算的往来账户、区块链的分布式账务等。不难看出发现，支付的创新和变革，支付产品的设计很多都是建立在一套新账务模式之上；如果你想做一个支付业务，那么先把账务想清楚，基本事情就成功了一半。3.1账务作为突破口
作为一名支付产品经理，工作中经常会遇到新的业务形式或者业务变化，任何新的业务和变化基本上都会触碰到资金的问题，任何资金的问题又会涉及到财务和法务以及公司主体的资金问题，这些问题更多的是“规矩”，交给法务、财务去解决。另一个问题是技术问题，这个事情如何去落地，很多场景我们都会有很多的选择；而最后总会有一个耀眼的明星脱颖而出“从账务上去解决问题”，其实也可以说是“从信息层去解决问题”，换而言之就是“先把账捋清楚，把账务处理搞明白”事情可能就解决了。怎么把账搞清楚呢，无外乎，这是谁的账，要记到什么账户，使用什么样的费用去记录，什么时候去记录，谁来请求记录等。所以说，精通财务会让产品设计容易很多，因为无论是技术还是产品还是运营，大家的挡箭牌都是“我不太懂财务”,为什么财务这么重要，因为它基本是支付的终点，任何支付问题，最后都会从业务问题收敛到财务问题，系统上收敛到“账务核心”。大家可以回想一下，自己工作中遇到的各种支付问题，哪些跟账务相关。我们去理解很多支付产品，或者接入不同的支付解决方案，最关注的还是对方的账户体系怎么建设的，就会涉及到支付的两个核心问题，一个是信息流的问题，另一个是资金流的问题。很多时候，通过“玩转账务”会让工作如鱼得水；从信息层解决问题，可以凸显自己不可替代的专业性，会让事情脉络非常清晰，也会让项目成本极大的降低，简单的说会让事情做的很漂亮。当一个新业务像毛线球一样一团糟时，可以考虑从账务模型上把事情抽象出来，事情会清晰很多；账务就像心脏一样将血液有条不紊的输送出去，业务就像各个脏器一样，他们赖以生存的血液又会有条不紊的回流回心脏。如果做线下结算体系的线上化，那么请先把“账”想明白；那些结算对象，他们都要结算什么款项，由哪些主体给他们结算，分别使用什么资金；结算后财务又需要什么样的报表去记账；如何为结算对象设计“账户体系”。3.2从“账”上解决业务问题
很多企业的某些业务会需要缴纳保证金，比如在淘宝开店，需要缴纳店铺保证金，骑共享单车需要缴纳保证金，在抖音开店需要缴纳保证金；在支付机构接入支付产品同样也需要缴纳保证金。保证金的用途其实就是担保，就是增加对象在平台的信用兜底；在淘宝经营出了问题，那么保证金就可以作为最后的兜底手段，如果因为退款出现了欠款，就可以用保证金偿还。但是，很多企业的保证金是单独存在的，跟某些业务或者说业务账户并不能互通；比如淘宝，你的经营结算账户出现了欠款，不能直接从保证金转入进行抵偿；这个过程会涉及到很多问题；一个是两个账户的业务属性不同，资金属性也不同，法律问题也不同，同样在公司的财务层面上科目也不同，在资金层面上也在不同的银行账户中，或者在不同的监管账户中。这种情况下，要想将保证金扣一部分用于抵扣结算账户欠款，会面临很多问题，那么这时候，可以换个思路，先从“账务”上去把问题解决，从“账务”上去梳理对应的其他事物；因为账务跟公司主体，所属对象，财务科目，背后管理的银行资金相互关联，账务理清楚了这个事就清楚了；账务动了，每一个关联的环节都会顺势而动。例如：某B2B电商给商家提供商家贷，给个人用户提供消费贷，其C2C电商业务中商家或者个人有用于经营结算的账户；所以大家有没有发现这个体系里存在着资金的闭环，同样也存在着风控的闭环。用户在其消费端申请消费贷款，然后在其电商平台购买商品，钱最终结算给了商家；同样商家又可以在平台申请商家贷，然后到B2B采购平台去采购商品。如果商家在B2B的贷款还不上了，就可以用商家在电商平台的经营结算款去强制偿还。如此就降低了商家贷的坏账；陈天宇宙总之，这套供应链金融体系，让资金极大的在内部形成闭环，流动性在内部进行控制，支付效率可以说极高，风控能力可以说极强。这个闭环效率，其实就可以从账务层完成，相关的合规问题，法务问题，以及其他更多问题不在这里探讨，比如不同主体间债权债务关系转移的协议等，实际工作中请严格遵循财务和法务意见以及当地的相关法律和监管制度。在工作中遇到问题，尝试着从账务层寻找突破口，很多时候会事半功倍。4.热点账户
经常听到“热点账户”的概念，很多人对什么是热点账户并不陌生，但是对如何解决热点账户问题并没有系统性的完整的思路；事物总是发展的，事物所处的场景也是在不断变化的，基于有限的经验去解决无限的可能性是很好的技能，本小节将从认识热点账户开始，解析几个常见的解决热点账户问题的思路，彻底掌握热点账户的内容。4.1认识热点账户
认识热点账户之前先简单回顾一下账户，了解账户的结构是“入账请求、账户流水、账户余额”，入账请求产生了账户流水，账户流水更新账户余额，其中我们要关注账户流水的创建以及账户余额的更新，要重点关注账户余额更新，这是造成热点账户问题的主要环节账户的账务处理主要分三类：收钱、付钱、账户之间转账；收钱针是增加余额，付款是余额减少，转账是两个账户之间一个增加一个减少。4.1.1热点账户定义
账户处理存在最大并发量，超过这个并发量时账务处理就会出问题。账务处理过程中需要进行线程控制，无论是收钱、付钱还是转账，为了保证账务的准确性，每次账务处理都是一个单独的事务，就算是多个请求同时发生，对账户的操作也需要一个一个的进行处理，当一笔入账请求开始处理时账户资源会被加锁，等该笔请求处理完以后会释放锁。这就意味着每一笔账务处理都会占用一定的时间，在这个时间内其他入账是不能操作的，这就出现了资源的瓶颈，即账户入账必然存在一个并发的最大阈值，一旦超过这个阈值，就会出现账户的性能问题。在交易并发过程中，有些字段的使用频率很高，比如流水号、余额、发生额等字段，这些使用频率很高的字段称为热点字段；导致热点字段的事件称为热点事件，比如商家结算日，需要给商家结算付款，这时候造成付款专户的付款并发，这就是一个热点事件。业务发生以后会产生业务事件，如下单进行支付时，而业务事件发生后需要申请入账；当在短时间内产生了大量的业务事件，或者有大量的交易产生时，就会造成高并发的入账请求，此时高并发的账务处理将会引起账户系统的性能瓶颈从而产生性能问题，进而造成入账延迟、失败、账务准确性等各种账务问题，这个过程中涉及到的账户我们就称为热点账户。因此，热点账户是由于高并发交易发生时，账户系统频繁更新账户产生性能问题而造成的，一个关键的前提是“高并发”，一些文献里提到形成热点账户需要满足两个标准：账户每秒有10次以上更新需求，串行化时账户处理延迟高于1秒以上。4.1.2常见热点账户发生场景
既然热点账户是由于高并发频繁更新账户造成的，所以探索热点账户的发生场景就转换成了探索交易高并发的场景，这些高并发场景都有可能造成热点账户，很容易想到“双11购物节”“微信发红包”“某自营电商平台的秒杀抢购”“小米官网新品的预售”等等。高并发场景有的是因为高并发收款造成的，有些是高并发付款造成的；而且收款和付款的热点账户解决方案往往会存在差异，不同场景的收款和付款解决方案也会有差异。就像淘宝双11收款，淘宝中间账户因为不外漏给用户，后续商家履约周期也长，所以时效性要求并不高，可以考虑批量定时入账、异步入账、缓存入账等模式，不采用实时入账。因此，可以将业务场景分为高频入账场景和高频扣款场景；像淘宝双11的中间担保账户就是高频入账造成的热点账户。在淘宝购物时，钱并不会直接给到商家，而是先收到中间担保账户，等商家履约完成以后才会由担保账户结算给商家。担保账户有两个过程，一个是用户购买商品时的收款，另一个是服务履约结束后的结算付款。双11期间用户付款是一个热点事件，从而中间担保账户的收款就使得担保户成了热点账户。担保账户是内部账户，并不外漏给用户或者商家，这样的话，只需要实时告诉用户和商家已经付款成功即可，至于担保账户的入账可以慢慢的处理；从这里可以得到一个思路，就是解决热点账户应该关注两个问题：一个是对交易参与者的反馈策略：参与者需不需要实时知道账户的处理情况，是只需要知道结果即可还是需要实时看到账户余额的变化，显然对于淘宝中间账户来说，账户参与者是不需要知道其账户余额更新情况的，只需要知道支付成功的反馈结果即可，而这个结果可以依赖渠道的反馈通知，而内部记账可以不反馈给用户，这样的话担保账户就有了足够的时间来规避并发问题。另一个是账务要求：账务更新时效性要求高不高，账务的准确性要求高不高，对于中间担保户来说对时效性要求不高，而所有账户对准确性要求都高。如此一来，可以采用批量处理，延迟更新中间担保账户的方式来规避双11高并发交易的入账请求，从而规避热点账户的发生。数据库插入数据的并发支持是非常大的，一般不会造成数据库性能问题，批量插入即可，只是更新账户余额需要进行锁处理，会造成性能问题，所以解决淘宝中间账户的关键是解决账户余额更新问题。先将高并发入账请求插入到入账流水表，这时并不着急去更新中间担保账户余额，此时这些流水我们标记一个入账状态“未入账”；定时的去扫描这个流水表，将扫描到的数据进行加锁，确保不会被后续入账或其他处理影响，然后汇总求和，用这个求和的总值去更新中间担保账户的余额，将这一批“未入账”流水更新为已入账，最后释放锁，这样就以很小的并发完成了对中间账户的更新。接下来介绍几种常见的热点账户解决方案，并且针对每个方案列举一个实际的案例为补充；对于热点账户的方案设计，需要重点关注几个问题：收支：账户是收入热点账户还是支出热点账户。
内外：账户是用户热点账户还是内部热点账户。
时效：账户是高时效性实时入账还是不需要高时效性。
结果：用户是否需要实时知道入账结果。
4.2热点账户解决方案
不难发现，热点账户产生的根本机理跟城市交通高峰时段的拥堵地段是相同的，怎么解决高峰问题，错峰出行、限号限流、分流等等方法都可以缓解拥堵；解决热点账户的思路类似，既然是高并发造成的拥堵，就可以以降低账户的并发为解决热点问题的抓手，也就是降低热点账户的操作并发以降低账户热度。如可以采用缓存记账、批量汇总记账、将账户拆分分摊并发、进行记账排队等等手段来降低对账户的高并发操作，从而降低账户热度。4.2.1限号限流直接控制并发
不想太多，陈天宇宙直接解决产生问题的问题本身；既然热点账户是有高并发造成的，那么反向思考，这个并发阈值是多少，在账户之前设一道屏障控制这个阈值，就像很多城市的限号限流一样，最终的结果肯定是损害一部分车主的体验；虽然是立竿见影的效果，但是这也是自损800的方案；这里我们不妨称之为“热点阀”。所以给账户安装“热点阀”可以解决热点账户问题，但问题比较明显的，除非账户系统很强势，比如交通控制，否则以“客户优先”为宗旨的企业这种方式一般不会采用。
4.2.2变多为少明细汇总入账
数据库插入数据是可以支持非常高并发，所以插入流水不是热点账户瓶颈所在，而是余额更新。因此可以将“降低账户的单位并发”设计思路缩小到了“降低余额更新并发”的范围，余额更新就是基于流水去增加或者减少余额，即“balance=balance+发生额”。 新余额等于当前余额加上或减去该流水的发生额，要想降低余额的更新频率，可以从降低发生额的更新频率入手，也就是你们这个多流水来更新我，我实在是忙不过来了，都堵在门口了，不如你们派一个代表10分钟进来一次，汇总大家的要求，我一次性解决。这样就是我们说的“汇总明细记账”的方法，这样的话这个函数就变成了：balance=balance+sum（一段时间内全部明细的发生额）。该方案适用于不需要实时更新余额的场景，且主要是增加账户余额的场景，如果是扣款类场景，可能汇总入账会造成账户余额透支，不过如果允许账户透支，出款类场景也是可以考虑，只不过资金管理的时效就会变差，你无法通过账户余额直接看到剩余可用余额。4.2.3排队处理缓冲记账
现在大家经常做核酸，因为并发人数较大，检测人员有限，所以大家需要排一个很长的队伍。同时因为一个人一个人的检测成本也高，效率也低，因此将10个人分成一组进行混采，混采就像我们上面说的指派代表的汇总记账一样。所以说可以为账户设置一个排队机制，当出现高并发账户更新不过来时大家进行排队办理。就算排队可以解决账户的并发问题，但是同样是存在瓶颈的。就像10个人采样，100万人排队，那要做到什么时候，也可能发生抱怨和投诉。所以怎么办呢？增加检测点是一个很好的办法，1000个人采样，就可以分摊这么多的检测样本；这就是下面要介绍的“子账户拆分”分摊压力。4.2.4增加点位子账户拆分
当即要解决高并发的热点账户问题又要保证实时性时，上面的方案因为会影响账户的更新时效，自然就不是首选了，就需要一个能够支持实时余额更新的方案。既然一个账户的更新出现了瓶颈，那是不是可以考虑为他找更多的帮手分摊压力呢？答案是肯定的。我们可以将账户进行按需拆分，拆分成多个子账户，将高并发请求分配给各个子账户，从而单个账户的并发就降下来了。这里要明确一个问题，子账户是不能让用户感知的，只是内部的处理方案，对用户来说还是一个账户，所以反映给用户的流水和账户余额还是一个，这就意味着账户作为一个整体被用户感知。该方案势必增加账户设计的复杂程度，如入账的时候入哪个子账户？是平均入账还是按序入账？出账的时候怎么出？有个别子账户余额不足但是总账户余额充足时怎么处理？所以说这里会有一个复杂的账务处理模型；不管这个模型怎么设计，要保证金业务上顺利完成账务记录要求，以及保证用户的使用体验，从而确保业务的正常进行。之前设计的账户系统，每个商家可能会有七八个子账户，出款的时候是按照顺序出款，就是先扣完一个账户扣下一个账户。4.2.5临时存放缓存记账
高并发请求可以先进行缓存，然后定时将缓存更新到数据库。这个看起来跟缓冲记账异曲同工，但这里有个区别，缓冲记账时账务请求还在排队入账，而缓存记账实际上账务请求已经实时在缓存中完成了记账。缓存记账具备缓冲记账和汇总明细记账的双重优点。
需要注意，因为缓存需要具备账户余额部分的管理，所以账户系统的余额要赋予缓存模块，缓存模块在此余额基础上进行出金和入金的记账操作；定期将缓存同步到账户系统完成最终的记账，记账完成的缓存部分可以进行清空，然后获得最新的账户余额，以此循环。4.2.6小弟先上前置缓冲
为解决备付金集中存管所形成的热点账户问题，实现对已映射额度管理，网联构建了“备付金热点账户前置系统”即“RCMP”，用于支付机构通过网联平台（EPCC）的业务办理。前置系统分为额度管理模块及账户管理模块，网联将为各支付机构在前置系统中建立账户，用于可用额度的监控、已映射额度的管理。因为网联是“实时清算，定时结算”，在一个清算周期内净额轧差了支付机构的支付指令，最后提交给人行的结算请求笔数一个周期从每个机构的上千万笔到一笔，这个看起来有点像汇总明细记账，而这个汇总处理的操作是网联代人行支付系统完成的。如此看来，我们工作当中也可以设置这样一个前置系统，来帮助账户系统完成压力的分担，比如要求业务方建设前置模块，按照要求进行处理加工后请求入账；特别是账户中台，面对众多业务线时，是不是可以考虑每个业务线在某些场景下都做账户前置，完成初步加工后再请求中台账户系统，这样就可以分担中台的压力，又不损害中台的账户核心能力，业务线也不用完整的建设账户系统；这里的思路就是中台不能一揽子打包，一些能力要分摊给业务线，比如业务线的个性化部分，需要业务线做前置层。4.2.7技术性能升级
技术层面就不过多讨论了，作为非专业人士，或者说从产品视角提些建议“能多增加几台服务器么，可以扩充下硬盘么，你这个cpu可不可以换成顶尖的......”。事物总是变化的，场景也会不断地更新，面对新的场景，新的问题，历史的经验只能作为解决新问题的参考；不妨在遇到虚拟问题时多思考一下真实的世界，也许会有意料之外的答案。5.账户合并
这是事物的发展规律，只要公司业务在发展，人员在流动，运营者的理念总会发生变化，变化的过程中就会有人提出合并一些账户；同样也会有运营人员提出拆分一些虚拟账户。那么合并和拆分账户就要考验产品经理的综合把控能力和全面的知识储备，需要知道合并和拆分会涉及到哪些方面的改造，如何改造，通过本小节的案例，可以清楚的掌握虚拟账务、会计账务、实际资金、业务等之间的关联和协同关系，对虚拟记账有一个更立体的认识。5.1合并场景分析
保证金是一个很常见的平台用于控制风险或者制衡外部参与者的资金手段，比如共享单车的保证金就是为了保证车的安全，外卖员缴纳的保证金就是为了制约其服务质量，代理商的保证金同样也是这样的目的。对于一个多业务线的平台来说，每个业务线都可能需要缴纳不同种类的保证金，比如用户在A业务线需要缴纳A保证金，在B业务线需要缴纳B保证金，这种情况下，用户就需要在钱包里分别充值A、B两类保证金。同样，在平台的账户中心也会有A、B两个虚拟账户，每个保证金账户独立存在，单独管理。保证金的账务不只是在账户中心，在多处都有记录，而且相互对应，互为核算关系。首先就是支付系统的充值和提现记录；其次是账户系统的保证金开户、保证金余额、保证金流水的相关记录；然后是会计系统对应的保证金科目以及会计记录，和保证金资金管理账户的银行存款科目；最后就是保证金的资金存储的银行结算账户的资金账务记录。
如果一个用户或者商家在一个平台缴纳多种保证金的话，其实就意味着平台是以业务为颗粒度来管理保证金，这样对于用户来说势必要缴纳更多的保证金；一方面会造成用户不满，另一方面也会造成招商的难度，影响业务的发展。其实，可以以个人或者商家主体为维度来管理保证金，就是一个用户在平台只需要缴纳一份保证金，实现“一金多用，事后核算”的模式，也就是缴纳的保证金属于平台总部统一管理，当各业务线发生保证金扣款时再计入各业务线名下，而不是在账户维度就计入业务线名下。这样就可以很大程度的降低保证金账户数量以及提升用户满意度，同样也降低了资金账户数量以及会计的管理成本。
合并账户需要关注什么，做保证金账户合并不是简单的将账户中心的虚拟账户合并到一起，而是要将保证金相关的多层账务完成合并，首先是账户中心的多个保证金账户余额合并到一个账户中去，另一个就是会计系统的多个保证金明细科目结转到一个科目中去，然后就是将存储在多个专用银行账户中的资金调拨到对应的一个银行账户当中，这样操作完成以后，才真正实现保证金的合并。5.2账户合并方案
在合并虚拟账户时，有很多种选择，一种是将原来的一个保证金账户作为合并后的总账户，另一种是新开通一个统一保证金账户，将原来的所有账户里的余额转入。我比较推荐用后者，账务更加清晰，不必背负历史的众多账务问题，以新账户为起点重新出发。同理会计系统也要新建相应的保证金科目，将原来的A类保证金科目余额和B类保证金科目余额全部结转到新的统一保证金科目当中，至于结转多少，这个要依据账户中心提供的“余额转出”的系统账务统计进行结转。这样的动作也会间接的进行一次系统账务和会计账户的核算，比如系统账务的“A类保证金余额转出=X”，假如会计系统的A类保证金科目余额不等于X，说明这个科目的余额没办法结转为0，即系统账务跟会计账务核算不一致，这就需要一定的策略进行差错处理，以使得会计科目余额最终结转为0。假如结转完X以后，B类科目余额还有△X，则可以再结转一次△X，可以定义为保证金调整。前期不同业务线的保证金可能存放在不同的银行账户中，既然业务系统以及会计系统都完成了账务合并和余额的转移，那么对应的银行账户的资金也应该做相应的调拨合并。假如又开了一个新的银行账户T，这就需要根据系统记录转移的余额X进行资金的调拨，如果资金不足或者调拨后有结余，就需要进行历史资金账务的核算，以找到账务出现差错的原因，进行对应的差错处理，比如资金剩余了，可以确认资金为营业外收入-保证金未知结余；这就属于天上掉馅饼了，如图所示。最后陈天宇宙要处理另一个事情，就是不同业务线成员对系统的操作，因为保证金已经合并了，那么如果用户因为在不同业务线出现了违规要扣除一部分保证金，那么这时候就需要知道这笔保证金扣除应该归属那个业务线。实现方法有很多，我们可以在扣除流水上标记业务线，怎么识别业务线呢？可以在操作扣除时要求选择什么业务线要扣除。6.“倒扣”的博弈
某些情况下在还没有获得任何收益时，让用户去预支付一笔资金是非常困难的，就算这笔钱在满足条件后可以退还。特别是用工市场，如家政阿姨、外卖员、出行司机等。什么还没干呢，上来就交一笔保证金，或者购买一些工具包，大家会有一些抵触。如果是比较大的平台可能还好一点，如果是一些小的机构或者组织就很难收上来这笔钱了。这种情况下就出现了一个这样的模式：你先干着，这笔钱先不用自己交，从后面的收入里慢慢扣除，直到扣足了为止。暂且称这个模式为“倒扣”模式。倒扣模式从一定程度上可以降低招募服务人员的难度，但同时也会增加资金风险，特别是在需要服务人员领取工具的情况下。如果劳动者领取了工具，但是没有挣得足够的收入，那么这个工具费用是有可能成为损失的，所以这里面就是二者的博弈，用风险博取商业上的利益。如何实现倒扣模式的系统设计呢？系统需要实现“清楚每个用户应该倒扣多少钱，然后在后续的收入中进行扣除，多余的部分结算给商家”。6.1两个记账模式
首先解决规则和记账的问题，需要制定一套规则从而知道每一类用户应该交多少钱；其次需要知道每一个用户本次结算应该倒扣多少钱，因此从期初的规则值开始，后面逐渐倒扣了一部分，每次应扣的金额就变了，成了：规则值-累计已扣。所以这里要解决2个问题，一个是规则配置问题，另一个是剩余代扣金额问题，因此这一部分需要建立规则的管理，即设定好不同类型的用户应该交多少钱。知道了哪些商家总共应该扣到少的规则以后，还需要记录已经扣了多少，还需要再要扣多少。有2种实现方式，第一种用结算单进行记录，另一种是用账户实现。6.1.1结算单模式
结算单的模式是为每个商家每个结算周期生成一个结算单，记录关键信息，这些关键信息相当于他的账务信息。表所示内容有一个自洽关系：剩余待缴=规则-累计已缴。在商家结算之前，先查看信息表里商家是否还有“剩余待缴”，如果有的话要先清分出一部分进行扣减计入累计已缴，剩余部分结算给商家，如下表所示，示例中，张三的收入需要全部扣掉，而李四的收入足够倒扣，剩余700打款给商家。另一种模式是账户的模式，认证以后平台为每个商家开通一个待缴账户，这个账户的期初余额为0，记录后续缴纳的金额。同样商家的货款结算也采用账户模式，这样商家就有了2个账户。如表中数据，收入已经结算了结算账户中；接下来要将一部分结算款扣减到保证金账户中。查询到李四的保证金规则是1500，所以现在账户还需要再转入1000。因此，要做一个账务处理操作，将其结算账户中的1000转入其保证金账户，会计分录如下所示：6.2返还和优化
保证金满足一定条件以后需要返还给商家，因此要有一个返还的操作，就需要一个事件来触发这个返还，比如合同结束且没有其他待办事情后，可以通知账务系统进行返还，做如下的账务处理：这里的风险并不是钱没有交齐，而是发生了违规事项，扣除保证金造成的负余额，这个负余额就有资损的风险，后续需要商家缴纳更多来填补。当平台有数百万商家时，这个模式就暴露出了很大的风险，如果很多账户都出现了欠款的情况，就需要想办法杜绝这种情况发生。这里提供两种思路：一种方法是从根本上解决问题，取缔这种倒扣模式，采用先充值，这样就可以解决这个模式的问题；另一种办法就是设定可透支阈值，当被透支到一定金额以后封禁商家，需要充值偿还欠款以后才可以继续经营，所以需要增加对该账户进行充值的能力。7.子账户之道
一个企业在经营过程中，或者一个平台在运营过程中，所有的业务都需要记账。从支付宝的担保账户体系变革了线上零售以后，建立一套虚拟账户体系去解决交易流、支付流、资金流的匹配问题成为了很多平台都在遵从的“账户之道”。好的账户模型，往往是解决复杂交易，实现模式创新的突破点，而好的账户模型，往往从“分割子账开始”。7.1交易多样性与账户拆分
账户的本质是电子货币的载体，存储着账户货币的数量以及流动变化信息，而这种流动的源动力来自交易的驱动，所以不同的交易流必然造成不同的账户货币的流动性。这就是账户的本质，建立交易流与资金流的匹配；而这种匹配关系的清晰性，决定了账户体系的效率和灵活性。以上是在做账户设计时要关注的账户最核心的部分，可以通过一个账户解决基础问题，通过交易分类解决账户流动性的清晰问题。当交易模型复杂，交易流繁多时，可能会造成资金属性的不同，比如存款、信用额度、理财资金往往是无法混合，这时就可以用多个账户来管理。同样，当资金的来龙去脉不同，不同的用途时，为了交易的效率，也可以用多个账户来管理。不同的行业有各自不同的交易特点，如航旅、教育、保险、基金、游戏等，他们的参与者不同，交易流不同，支付流不同，资金流不同，而且在时间、空间、政策很多维度都存在不同。这种不同的特点，衍生出不同的行业痛点和难点；如果想去攻克这些难点，拆分子账户，提升行业资金管理效率和交易效率是重要的突破口，通过账户方案建立线上交易基础，通过账户拆分提高资金效率。7.2拆分案例
账户最终要解决行业问题，那么必然要基于行业的交易模型特点，分割出子账户，让账户体系能够清晰反映出行业的交易脉络。以航旅为例：代理商从航司购买机票，分销给二级代理商，再通过三方平台或者线下代理点到达消费者。以支付为切入点，通过支付的变革实现行业的变革，改变行业的交易成本和效率；将交易电子化、资金电子化、并实现交易信息流和支付资金流线上高度统一；交易电子化可以将机票电子化，用户可以线上选票、购票、出票。
实现资金电子化可以基于交易模型为各参与者建立与交易相匹配的账户体系；以代理商角色为例，分析在上述交易模型的资金行为。我们发现在整个交易模型里有三处存在明显边界的资金往来：代理商与航司的资金往来，代理商与二级代理商的资金往来，代理商与资金开户行的资金往来。所以将代理商的虚拟业务账户进行拆分，通过子账户体现出这层关系，并将账户内资金的流动性通过子账户之间的业务关系完成。环境是变化的，行业也是变化的，痛点也是变化的，在变化的商业环境里必然产生新的变化的交易特征，新的模式，新的方案。
一个子账户解决一个问题，那么更多的问题就可以用更多的子账户去解决；比如代理商资金流动性不足，就有了信贷的场景，就可以为其提供信贷；有的代理商资金充足，可能就有了理财的场景，可以为其提供理财，子账户又可以进行拆分；付款账户拆分出信用账户，资金账户拆分出理财账户。未来还有更多场景，未来还有更多可能，无论遇到何种问题，通过子账户拆分，再拆分，合并再合并，切换再切换，用这种可伸缩的灵活性，变通性，将交易流，支付流，资金流的脉络结构完美的反映和契合，从资金结构中反映出业务结构，让资金管理效率更高，核算更便捷，让支付解决方案更具魔力。对日切这个概念，我想很多人都不陌生，但日切究竟是如何实现的，日切前后及过程中都发生了什么，需要做哪些事情，不同的年代，不同的机构情形下，日切的实现模式会有一些差异，本小节将讲清楚日切的实现原理。所谓日切就是切换到下一个记账日期，这里要先搞清楚一个事情，日切就意味上一个交易日结束，下一个交易日开始，也就是日切总是伴随着日终，二者形影不离。那么介绍日切就必须聊日终处理，我们把它当成一件事来看。为了深刻理解日切模式，先看一下日切的发展史。有些人觉得，我现在就在做账务系统，但是对日切的感知并不明显，如果是这样，那是因为：时代变了，日切的方式也变了，要想深度理解一个事物，就要站在历史发展的视角看它，当前感知不到，只是因为，它变得更加简洁和高效了，不像早些时候那样繁重。支付发展程度越高，效率越高，成本越低，其中就包括日切的处理，日切随着支付的发展，也在变得简单。早期的钱庄，货币是金属实物性质的，做账是手工实现的，加上没有现代会计方法作为记账依据，那么账务登记和管理效率也相对较低，造成两个交易日之间的日终处理工作相对繁琐，可以理解为非常重的“日切/日终处理”的时期。同样，银行也经历了多个时期，例如最早期的手工账时期，用算盘算账，纸质账簿做账务登记，那么日切过程势必要处理的事务也相对较多，而且人力成本较高，用时较长。1979年，国务院批准银行业可以引进外国计算机进行试点，1987年开始，工行、中行、建行开始引入IBM的大型机和业务应用系统，结束了手工记账的时代，开启了信息化进程。很多工作交给了计算机去做，这时候的日终处理效率相比手工账时代就高多了，但是日切和日终的事务依然耦合在一起，需要停止联机交易进行日切和日终处理。这个阶段，每年的12月31号，一年最后一天的日切/年终也就是银行年终决算是最忙的一天，需要进行全年损益结转利润。因为银行的账目很多，例如现金账、日记账、柜员账、网点的账等等都需要实现平衡，一分钱都不能错，这就导致每次年终决算就像打仗一样，全行联动，为确保数据无缺失、准确，需要进行大量的检查。听说每圆满完成一次年终决算，是要庆祝甚至放鞭炮的。而现在的年终决算，相比之前要轻松容易多了，陈天宇宙。现代银行一般都可以提供7*24交易服务，那么银行系统是如何实现即可以7*24小时不间断联机交易，又可以同时进行日切、日终处理的呢？这是这个时期需要重点解决的问题，这个时期的日切可以认为是极轻的日切时代，即然轻，那对它的感知就弱了。这里要掰扯清楚一点，就是虽然现在大部分银行都实现了7*24小时联机交易，但银行依然需要进行日终维护，二者之间并不是冲突的关系，不是说，交易可以7* 24进行，就不休息了，不维护了，只不过是“系统维护”和“7* 24小时不间断交易”可以实现并行。上面讲到了“7*24小时不间断交易”处理是当下的流行，那么系统怎么兼顾实时交易不间断，而日终处理又可以顺利进行呢？就成了这个阶段最重要的课题。二者重点产生耦合的地方是在日切点附近的“实时交易和日终处理”，二者存在依赖关系，例如日终处理需要用到“上日终的静态日末余额”，而实时交易的余额是动态实时更新不停息的。那么，切断二者的耦合而形成轻联系，建立让彼此单独运行的模式，就是突破口。而上一日的日末余额和上一日数据的完整性是日终处理依赖的关键，所以，实时交易要确保能够提供这两个数据的保证即可。常见的模式是双余额模式和双表模式。可以这么理解，将实时交易和日终处理进行隔离，7*24小时实时交易独立运行，而日终处理在另一个区域单独进行，不阻碍也不干扰实时交易的进行，实时交易只需要保证提供日终处理需要的内容即可，也就是所谓的：“实时联机交易+日终批量处理”双模式。这时候，日切和日终的强耦合日切模式，演变到了二者实现隔离的简日切模式，也就意味着，如果交易不需要关注日终，那么日切将变得极其简单。当然对于支付机构、交易平台，这是很容易实现，因为属于弱账户模式，哪怕没有日切和日终的概念，也可以实现数据的自然切割，按照自然日进行处理即可。而对于银行要实现这一点相对复杂，因为存在客户存款计息、贷款计息的管理，对静态余额强依赖，所以即需要维持动态余额的更新，又需要确保静态余额的生成和不变。日切简单的说就是记账日期的切换，变更系统的记账时间；也就是人为的将时间轴根据设定的“日切时间点”切割成一个一个的区间，从前一个区间到下一个区间的过程就是切换的过程；这里的切换时间点就是“日切点”。所以，通过日切点将连续的时间进行了切割，同时也对数据进行了切割，形成了一个个的数据集，例如23:00作为日切点，那么[T：23:00，T+1:23:00)就构成了一个记账日。虽然自然时间是连续的，但是很多事务的处理需要按周期进行或者以周期为单位进行管理，例如饭馆到了晚上21:00要打烊，然后盘点当天的账目，打扫卫生，为下一个营业日准备，这里的21:00就是日切点，日切后进行日终处理。同样银行也要上下班，下班后柜面业务收取的现金等线下业务需要进行盘点，入库。而核心系统的线上业务等也要进行一系列的日终处理，例如生成日末余额、生成总账、账目核算、计息等等，那么需要“日切点”作为两个周期的分割点。特别在手工账年代，日切及日终处理的工作量尤其庞大，只不过随着科技的发展、随着电子化的普及，这个过程大部分都交给电脑来做了。这里要清楚一点，日切完成不一定会着立刻进入了下一个交易日，例如日切完成了，但是下一个周期的交易要等待次日9:00才开始，那时间上，日切点23:00到次日9:00这个区间算是“日终处理+休息时间+营业准备”时间，不营业，但有事做。虽然现在的交易大部分都是7*24小时不间断进行，但是日切后还是会涉及一些日终的处理，例如清算文件的生成、结算数据的生成与下发等，日终与与日间的实时交易处理明显不同，存在明显的周期性和集中性，需要以“日切点”作为日终事务处理开始的信号。这里也涉及到数据的切割问题，例如一个交易日的数据做为一个信息单元，我们的利息按日计算，众多系统之间、各个机构之间的数据都需要按照相同的切割规则完成，这样才能实现按周期的核算，例如渠道的清算文件以日为周期进行提供，那么这个区间的起始点，就是两个连续的“日切点”。所以，需要“日切”这样一个动作，执行日期的切换，实现数据分割，作为日终处理的标志，起到调度的作用。日切时间在时间点选择上，往往选择在夜间交易低估时段进行，因为日切前后需要进行一系列的事务处理，避免影响正常业务，例如有些银行选择23:00作为日切点，那么23:00以后的交易将划归到下一个交易日。从系统实现上，日切只是将记账日期进行变更，但是日切前后及日切过程中需要执行一系列的事务，还要协调众多系统之间的配合。例如全部系统切换记账时间，全部采用最新的记账时间；进行多系统间数据的核对，保证每个系统都完成数据的登记，进行账务的入账、生成总账等。普通交易平台、支付机构、银行业务、清算、央行等在日切点关注重点和实现上存在差异。银行因为涉及到大量的账户，所以银行日切要重点关注账务处理的完整性和准确性以及日终处理。另外就是按日计息等工作，又需要重点关注日终余额或者日均余额，那么每日的日终静态余额显得很重要。同时银行又因为涉及到柜面、ATM等线下业务，监管申报和合规性检查等等，所以，银行的日切处理相对复杂，要做的工作较多。清算机构因为主要做信息转接，所以清算机构日切的重点在交易数据的清分、汇总与清算处理上，没有那么重的账户处理业务，甚至清算机构会存在场切，每小时一个场次，场次之间也存在固定时间点的切换。央行的日切或者日终要确保清算场次内所有机构都可以完成清算，例如头寸不足的交易要排队撮合、银行可以拆解或者贷款，那么央行各系统的日切要保证清算完成避免出现系统性金融风险，当然清算文件的生成和下发也是日切工作之一。而支付机构或者交易平台相比金融机构，对于日切就没有那么明确的诉求了，他们日切的核心目的就是确保完成对商户的记账和按周期准确的结算，这也就意味着数据切割是重点。不同机构的日切和联系。除了不同类型机构之间的日切实现模式存在差异，即使是同一类机构，不同的企业之间也会存在差异，一个纯线上交易的平台和一个涉及线下门店业务的交易平台在日终处理上会有很多不同。所以，虽然日切在原理实现上有通用性，但是不同的场景、不同的企业，需要根据实际的业务特点，选择适合自己的日切和日终模式。如果日切执行过程中交易系统停止工作，那事情就好办了，在这个期间没有交易，把所有要做的日终处理都做完，再开启下一个工作日的交易，那么日切其实就是一个日切的切换。但是，实际上的日切业务不止是时间的切换，还存在一连串的挑战。业务和系统是7*24小时不间断运行的，采用什么样的模式处理实时不间断交易和日终批处理之间的协同，是一大挑战。一个交易体系所涉及系统数量众多，其中包括交易系统、支付系统、清结算系统、账务系统、会计系统、财务系统等。而日切不只是账务系统记账日切的切换，还需要各个系统执行相应的日切任务。这里最大的挑战就是调度问题，因为系统之间的日切和日终处理存在顺序和依赖关系，谁先谁后，什么时候开始，什么时候结束，大家怎么知道上游已经结束了轮到自己了。例如，当交易系统没有完成日切，没有确保所有上日交易都推送至账务核心，这时候，账务核心执行日切就会出问题，如记账数据不全，日终余额不准确，与上游核对存在差异等问题。众多系统的存在，意味着同一份数据会登记在很多系统中，就会存在多个时间属性，例如交易时间、清算时间、记账时间等。那么在进行上下游核对时，就需要确保彼此数据切割一致，否则会存在数据集合不同的问题，与外部渠道间也存在这个问题，例如银行日切点是23:00，而机构日切实00:00，那么二者同一个交易日期的数据集不同。除了数据切割时间不一致造成的差异之外，不同系统之间，即使日切点一致，也可能会存在差异，这里要了解一个现象：记账漂移——就是系统之间传递数据的时间差造成的时间整体向后推移，系统间在日切时间点附近造成了同一笔交易，交易日期和记账日期不同的现象。如下图所示，从图中可以看出来，即使实时记账，因为系统延迟等原因，会造成交易时间和记账时间存在△t的时间差异，这个差异就是记账漂移。如果交易的时间远离日切点，这种差异并不明显，因为很少会核对数据间的具体时间的一致性。但是在日切点附近的交易就可能飘逸到下一个记账日期，也就是T日的交易，记账日期飘逸到了T+1，那么整个数据集合就形成了错配。当以日为单位进行数据核算时，发现，交易和账务层的数据并不一致，即所谓的时间差差异。所以需要通过一个模式来解决这个问题，如何确保全局数据切割的一致，按那个时间切割，交易按交易时间切割，账务按记账时间切割，如果这样，这里就会天然存在时间差。这里的切割一致性涉及到交易、账务、会计、提供给客户的交易文件等，他们之间的一致性。开始前先理解2个概念：动态实时账户余额、静态的账户日终余额。所谓动态即会随着交易的产生而不断变化，例如账户余额，这个是随着收入、支出的产生而动态变化的，用户需要实时看到这个余额，而且需要足够准确。所谓静态数据即数据一旦产生便不再变化，例如日终余额，一旦完成日切，日终余额生成，那么这个余额就不能再变了，像计息、总账核对等需要用到这个静态余额。接下来我们从日切架构、双余额法、双表法等方面详细介绍日切的系统实现。数据在系统之间的传递存在顺序性，交易不会绕过账务系统直接将数据提交给会计系统；其次，系统之间的“日切处理”也存在顺序性以及依赖关系；而且，每个系统的日切任务不同，如图所示，是日切子系统的业务架构。为了不让各个系统的日切处理各自为政，采用统一调度的模式，由日切子系统进行全局管理，通知各个系统执行日切，并监控日切进程和结果，按照预先设定的日切顺序和任务监管各个系统的日切业务。日切子系统需要统一管理各类日切点，以及当前记账日期，作为公共参数，提供给各系统查询使用。同样，这里的日切点和记账日期可以按照业务线、产品、商户等多维度进行配置，以便实现更加灵活的日切业务和数据切割模式，陈天宇宙。例如，即使全业务都是0:00日切，但是像酒吧、ktv等夜场业务，可以选择在交易量最小的12:00进行日切，因为这类场所，夜间是交易量最大的时候。为了更好的日切任务，控制日终处理的进程，可以将全局时段进行切割，切割成时区段，在不同的时段执行对应的任务。例如银行系统日终处理经常被分割成三段:日切(Cut-Off)、日终批量(End-Of-Day)、 日初准备(Begin-Of-Day)。因此，可以将整个时间轴切割成如下阶段：正常交易、日切、日终处理、交易准备等。并将各阶段规划出系统状态，维护在日切子系统中进行统一控制。在整个7X24小时不间断交易周期中，可以划分为日间联机交易和日终处理期间的交易，其中，将日终处理期间的交易时段成为特殊时期，因为这个阶段要兼顾日终批处理和实时交易处理，而日切设计的重点就是该时段。前面介绍了在24小时交易中，日切点的实时和批处理会存在冲突，那么，能不能实现7*24小时连续交易的前提，是在日切期间和日终处理阶段能不能进行交易。可以考虑将实时交易的动态处理和日终批处理的静态处理进行隔离。中间依靠隔离区通过“日切处理”建立起联系，这样就可以确保面向客户的7*24小时联机交易不间断，同时对内的日终处理又可以并行进行。那么，在日切阶段，如何处理此时的交易所产生的账务处理就成了关键，而这个阶段主要是账户余额的更新处理。日切过程会产生两个余额数据，一个是动态账户余额数据，一个是静态日终余额数据。而动态余额和静态余额都是账户的属性，动态账户余额受交易驱动实时变化，而静态日终余额受日终批处理生成。所以二者之间都依赖“账户”，同时日终余额又依赖动态的账户余额。对同一个账户在日切期间会同时受到实时交易和日终处理的影响，可能会被两个事务同时更新，那么要确保这种并发更新不会造成问题，需要一个处理机制，例如账户双余额法、影子账户并行法、应入账日期标记法等。这里要重点理解4个时间：交易时间、记账时间、最后动账日期、当前记账日期；2余额：账户当前余额、账户上日终余额。- 记账时间：账务系统账务登记的时间，是交易数据推送至账务系统，按账务规则登记为凭证的时间；
- 最后动账日期：账务系统一个账户最后更新的记账日期是什么时间，通过这个时间可以判断出，当前账户的账务变动情况，例如当前记账日期是10号，但是账户的最后动账日期是3号，那就意味着，4-10号之间没有进行过记账；
- 当前记账日期：即日切子系统维护的当前的记账日期，这个日期所有系统是统一的，都遵循日切子系统的配置；
- 账户当前余额：即当前这一个时刻，账户的余额，这是一个动态实时更新的余额，发生记账，这个余额就会实时变化，所以说这个余额由交易驱动实时更新；
- 账户上日终余额：这个是上一日最后一笔交易记账完成后的账户余额，这个余额一旦生成，原则上不再发生变化，即是一个静态的余额，所以这个余额由日切驱动，在哪一刻完成更新。
将每个账户设置3个参数：最后动账日期、上日终余额、当前余额。tx是交易登记时间、ty`是账务记账时间，Balance代表账户余额。如图可以看出来最后一笔记账的时间就是最后动账日期，一天最后一笔记账的账户余额就是上日终余额，而最后一笔记账的余额就是账户当前余额。在日期子系统维护着“当前记账日期”。这里要做一个模式的选择，就是上日终余额如何更新，因为当前余额的更新是动账才更新，而日终余额的更新方式有多种，可以动账时更新，也可以选择在日终处理时更新。即当账务有新的入账时，根据“最后动账日期和当前记账日期”来判断上日终余额更新。如果“最后动账日=当前记账日”，即当前入账是当天的入账，只需要更新当前账户余额即可：Balance7=Balance6+本笔发生额，如下图所示，记录7入账时当前记账日期与最后动账日相同，那么说明还没进行日切，则无需更新上日终余额，只需更新账户余额。如果“最后动账日≠当前记账日”，说明已经发生了日切，本笔入账时日切后的第一笔入账，则需要更新上日终余额和当前账户余额：上日终余额更新为当前的账户余额Balance6；并再将当前余额更新为：Balance7=Balance6+本笔发生额；并将最后动账日更新为新的记账日期。这种更新模式下，因为没有动账的情况下上日终余额是不会更新的，所以日终余额的查询也要根据最后动账日和当前记账日期的关系进行逻辑查询。如果“最后动账日=当前记账日”：则直接取上日终余额字段的值即可。如果“最后动账日≠当前记账日”：说明已经完成日切了，但是新的记账日还没有入账，那么账户登记的上日终余额已经不是昨日了，而是更久之前的，此时应该取当前的账户余额作为“上日终余额”。动账时更新上日终余额会造成“上日终余额”的更新不及时，所以可以执行日切时更新上日终账户余额，不管有没有动账发生，每次发生日切都进行上日终余额的更新，而且同时更新最后动账日期，这样每次直接取上日终余额字段即可，无需进行逻辑判断。因为在日终处理过程中，联机交易也在进行，且日终处理需要一定的时间，所以，为了确保联机交易正常对账务的更新，那么依然保持“动账更新余额的模式”。这就意味着，在日切期间有可能出现联机交易和日终处理同时更新账户余额的情形，那么为了解决这一问题，就需要进行账户余额的加锁，谁先发起更新，谁执行，另一方等待，直到锁解除了，等待的一方再执行余额更新。日终处理和联机交易同时更新账户余额时就是冲突期，通过加锁和解锁确保每次只有一方操作账户余额的更新。双余额方法看起来逻辑简单，但是表结构比较复杂，而且按日更新余额模式下，可能存在日终处理和实时处理的账户余额更新冲突，会形成一个排队期，这样就会在日切点造成一定的账务延迟，那么为了确保联机交易和批量处理完全并行处理，而且不冲突，可以采用双账户法。即为每个分户设置一个影子临时账户，来处理日切和日终处理的冲突期的联机交易记账。当系统运行状态进入日切和日终阶段时，临时影子账户开始运行，联机交易实时记账不再更新主账户，而是登记在这个临时账户中。在这种模式下，整个账务处理可以分成3个阶段：正常记账期，双账户记账期，调账期。确保在双账户记账期主账户处于静止状态，临时账户为动态更新状态。双账户记账期：日终操作主账户，更新上日终余额，当前账户余额保持静止，此时期“当前账户余额=上日终账户余额”。该阶段需要注意一点，就是对外的账务服务，例如用户看到的“当前账户余额=主账户当前账户余额+临时账户发生额”。调账期：在这个时期，日间交易开始更新主账户，同时临时账户的临时登记交易也要调账到主账户，其实临时账户的调账跟联机交易更新主账户没有区别，调账完成以后，清空临时账户，开启下一个正常记账期。前面介绍了一个记账漂移的现象，会造成系统间数据切割的不一致。可以通过要求上游系统标记该笔交易的“应入账日期”，来规避记账的漂移。例如在日切运行状态期间的记账，交易系统先执行了日切，那么最后5分钟的交易标记上“应入账时间”，这样，账务系统对于打上了应入账时间的交易执行记账时间修复机制，将其记账时间特殊处理标记为上一个记账日，来规避时间差问题，如下图，T日的交易记录7，在T+1日请求账务登记，被记账修复登记为T日的交易。对于一些支付机构、交易平台，因为不涉及到计息、罚息、贷款预期等的业务处理，对日终余额没有过多依赖，甚至有的机构本身就不存在上日终余额这个数据，那么可以选择不设置日切机制，按照自然日自然日切即可。如果用户下单时用了券应该怎么记账？平台发的券和商家发的券记账有啥区别？如果券需要平台和商家共同分摊呢，怎么记账？假如这张券又是用户用钱买的呢？这么一假设是不是账务处理难度瞬间升高了几个维度，别着急，把逻辑理清楚了，就容易了。这里要建立一个非常明确的认知，交易层记得是平台应该收用户的账以及应该结给商家的账，而支付层记得是平台跟渠道之间应清算的账，理解这一点非常重要。券的本质是补贴给用户的，因此补贴了券，就意味着用户会少支付一些，那么跟渠道之间就会少清算这部分券的金额，但是交易的总额没变，那么券的钱找谁清算呢？——谁发的券，找谁清算，所以，券+渠道支付=交易总额。因此，当用户在交易时使用了券、卡、积分等非渠道支付方式时，清算部分就多了这些“渠道”，而清算对象就是谁提供的营销补贴找谁清算，也就是这笔账记到谁的账上，而券本质上是营销成本。有了上面的原理，我们还应该知道下面这些营销的“账务”性质，才能知道该如何编排“借·贷”符号。如果是平台发的券，那么对平台来说这是一笔“销售费用”，所以平台的券是平台的费用。如果是商家发的券，那么这个券走商家的营销款，而商家营销款，是平台的负债。看一个公式：资产+费用=负债+所有者权益+收入。这就意味着，用户用了平台发的券，因为是平台的费用，费用增加了，所以记借方，就记“借 平台营销费用”。如果用了商家发的券，为了更好地理解，我们走商家营销预充值款，这笔商家营销资金，是平台的负债，用户用了商家的券，那么商家营销账户要出钱，所以负债减少记借方“借 商家营销费用”，这就是券的最基本记账方法。你可能会觉得奇怪，怎么上面全是“借”，不是应该“有借必有贷，借贷必相等”么？因为这是收款侧，也就是钱从哪来，还有结算侧，钱要到哪去，收上来的钱要结给商家，平台还要抽佣，这就是贷方。贷应结商户，贷平台佣金收入，贷合伙人分成等，陈天宇宙。有了上面的基础认知，再看交易用了券以后怎么记账，就容易理解了，下面从5个场景来解析交易使用了优惠券的账务处理方法。如果一笔订单100元，用户支付成功了100元，那记账就很简单了，交易=支付，用户支付的钱也就是后面要清结算的总量，最后结算给商家80以及平台抽一部分佣金20，这也是最基础的账务处理，如图图一所示。会计分录如下图二所示。如果一笔订单100元，用户用了一张20元平台券，渠道实际支付80元，账务处理如下图一所示。会计分录如图二所示。如果一笔订单100元，用户用了一张20元平台券，渠道实际支付80元，但是因为联合营销，商家承担20%的券成本，也就是承担了4元，账务处理如下图所示。如果一笔订单100元，用户用了一张20元商家券，渠道实际支付80元，账务处理如下图所示。如果这张优惠券不是平台免费发放给用户的，而是用户自己花钱买的，例如用户花5元买了一张20元的平台优惠券，交易逻辑如图所示。用户下了一个100元的订单，用了这张买的20元的优惠券，实际支付80元，这个账怎么记呢？如图所示。这里有两个问题需要思考，问题1：这张券究竟应该记20呢？还是15元呢？毕竟平台实际上并没有补贴20元，而是净补贴了15元；问题2：再复杂一点，如果这张券使用时，商家又分摊了20%成本，那商家究竟是分摊了15的20%呢？还是分摊了20的20%呢？假如，考虑“券净额”去记账，怎么记能够满足呢？很明显这张20元的券，可以认为是平台和用户共同承担了成本，即平台承担了15元，用户承担了5元，这么看的话其实也能记，平台直接记净额。但是，这里有个问题，原来的5元怎么记，从财务视角来看，卖券是平台获得了收入了，应该记一笔收入才对，那收入什么时候记呢？......到这里其实就开始糊涂了。这里要明确一个知识点，券的费用记账是在核销的时候才会记，而发给用户的时候一般是不记账的。因此，平台在卖券的那一刻银行账户中已经收到钱了，所以，银行存款已经增加了，那另外一方记什么呢？其实就是券的销售收入。按照权责发生制，银行的钱增加了，不能不记账，不能等用户用券的时候再记收入，这样的话如果用户一直不用券，那这笔收款就一直都无法确认收入。所以，一般我们在卖券完成权益交割以后就记账了，可以看出来，这个时候就登记了收入，只不过，用户还没用券，要不要确认收入呢？这个其实可以确认的，只不过后续如果券能退的话，收入被券退款冲销即可，用户买券记账逻辑如图所示。这样的话，用户在用这张券的时候就不用关注这张券是不是花钱买的了，当用户用了这张券平台自然会记20元的补贴成本，如图所示。可能你会问，明明是只补贴了15元，记20元不就虚增成本了么，其实不用担心，还有一个环节呢，就是会计周期末的结账，所有损益类账务全部结转到利润中，神奇的事情就发生了，如下图所示。卖券收入和用户用券补贴成本在利润中核算出补贴15元的净额。将以支付机构场景为例，解析通过账务体系的清结算全局实现，以及各环节数据的产生，各类账户的设置，以及各类场景的账务处理方法。支付机构的主业务是帮助交易平台代收代付交易款，那么就需要先从消费者发卡行把钱拿过来，然后再结算给交易平台；对于交易平台侧来说也是一样的道理，要帮店家卖东西，需要通过支付机构代商户收款，从支付机构拿到钱以后再结算给自己的商家。这是典型的2个不同的清结算场景，一个是支付机构的清结算，一个是交易平台的“清结算”，虽然交易平台没有清结算资质，但其需要在信息层完成清结算业务，上述业务模式如图所示。了解一个公司的清结算所涉及的全量业务环节，才能彻底明白，如何下手搭建清结算体系，涉及哪些系统，这些系统之间都有什么关系，将上图浓缩抽象以后，清结算涉及的资金处理业务如图所示。
所谓清结算，就是从渠道那拿到全部的钱、给商户正确的完成了全部结算，从上图可以看出来，清结算全局主要涉及到以下几个部分：无论是交易还是支付，或者是对账、渠道清算、结算，都离不开各类数据，可以将全链路的最原始数据分成四类，分别是：账务数据、支付数据、清算数据、结算数据。并分别定义为1段数据、2段数据、3段数据、4段数据，如表所示。数据分段以后，从数据编号既可以看出该数据的全量信息，来自那个系统，是什么支付业务产生的数据，在后续凭证规则中就可以基于数据段设置凭证规则，那个数据段的数据生成什么凭证，操作哪些账户，例如2001的支付数据要操作清算收款往来账户和商户待结算账户将所有数据段以及核对差异产生的差错处理数据的账务处理关系绘制出来，就得到了如下图所示的，各段数据源与账务核心的账务处理关系。这么多数据，是如何从业务系统流向账务系统的，系统之间的数据流转关系，数据从各业务系统产生以后经过对账系统、转换中心、计费中心、财务处理中心到最后的会计核心。对账中心从渠道获取清算文件解析出清算数据，并从交易平台获取到交易数据用于交易对账；交易中心推送账务核心进行记账，对账中心的清算数据也会推送至账务系统进行过渡清算类账户的账务处理。交易对账数据和账务数据会按照各段数据的格式要求转换成文件数据，然后推送至成本计费中心，完成通道成本的计算，并在清算数据上绑定结算账户、结算日期等信息，然后推送至财务处理中心准备资金对账。资金对账产生的长短款数据以及长短款核销数据也是新的数据段，会推送至会计核心生成长短款等挂账数据。最后备付金账套的手续费收入和通道成本会结转给财务账套，进行内部资金的核算。至此，整个数据就从业务产生到核算完成，实现了全链条的流转。清结算业务离不开账务和账户，为此，需要设置一套账户，为支付交易和清结算等业务提供账务支持。设置的账户及用途如表所示。整个账户体系包含5套账户，分别是商户结算户、结商户账户、清算往来户、已核银行收付、银行存款，其中共同类账户又分成了收款类和付款类，这样的账户设置共同完成了基于支付交易的向内结算和向外清算的支付业务框架有了上述科目以后，要想搞清楚账务处理，需要搞明白账务处理的要素和基础原理。账务处理要素：账务处理的要素就是要做账务处理，需要关注那几个维度的信息，主要是5个维度：什么业务、什么时候记、用什么数据记、记账规则是什么。什么业务：常见的业务种类有收款/退款、打款/打款退回、差错即差错处理、长短款及核销、客户账务调整、结算结转财务等等；什么时候记：即记账的时机，如支付成功、打款成功、退款成功、渠道清算对账成功、资金对账成功、账务记账成功等等；用什么数据记：用于记账的数据有支付数据、账务数据、清算数据、结算数据、差错数据、长短款核销数据等；记账规则是什么：有了记账数据，如何记账就需要记账规则，记账规则内容主要包括借贷方向以及涉及到的账户。账务处理的基础原理就是通过借贷记账法利用业务数据操作相应的账户，如上图中所示的那样，主要的记账数据是支付交易记录、账务记录、渠道清算记录、渠道结算记录，他们相应的借贷符号也如图中所示，例如收款的支付记录要借记清算往来收款、贷记待结商户账户，以此类推。同样也要特别关注差错类的记账，包括交易类差错、资金处理类差错、客户调账了差错等。因为过渡账户的借方和贷方使用的是2份相关的数据源，因此其余额反映了这2份数据源之间的差异，因此当过渡户存在余额时，则意味着存在在途，主要有三大在途：客户在途、支付在途、资金在途，在途可以理解为各类挂账，各类差错处理的记账就是抹平挂账。
渠道待清算往来账户余额反映的是支付在途，清算完成以后余额应该为0，否则平台与渠道清算数据之间存在差异。从原理上看，该账户的余额上是平台支付记录和渠道清算记录的差额，即该账户的期末余额就是“支付在途”，那么一个清算周期内，该账户的余额会存在3中情况：- 余额在借方：说明平台支付记录多，总体来说属于平台挂账；
- 余额在贷方：说明银行清算记录多，总体来说属于渠道挂账；
当余额不为零时，则意味着存在平台单边或者银行单边，单边数据在交易对账中心，可以通过相应的差错处理抹平差异。例如银行单边，则要不进行平台补单，要不进行银行退款，或者平台确认收入，这部分差错处理也会操作该账户，进而抹平账户的余额，完成最终核算。已核应收银行的账户余额为长短款数据，资金对账完成后，该科目余额应该为0，如果不为0则存在长短款，余额在借方则存在短款，银行少结钱了，如果余额在贷方，则存在长款，银行多结钱了，陈天宇宙。待结算商户账户余额意味着没有完全结算，如果余额在借方则说明多结给商户了，如果余额在贷方说明少结给商户了，少结的情况下，可以通过调增客户账户余额进行补入账，多结的情况下可以调减客户账户余额进行平账。先看整个全局核算是如何做账务处理的，我们以收款业务为例，整个收款业务的账务处理涉及到4个环节、3类差错：支付交易环节、渠道清算核算环节、商户结算环节、渠道结算核算环节、客户差错、交易差错、资金差错环节，每个环节都有相应的记账源数据，以相应的记账规则操作相关账户，具体环节说明和记账规则如表所示。我们根据一个实际收款例子加深对上述各环节账务处理的理解。
案例：平台收了2笔钱，都是10元，渠道T+1结算，给商户也是T+1结算，然后各环节数据情况及账务处理如下：用户支付了2笔，各10元，成功了1笔，另一笔支付处理中，支付核心生成了相应的支付数据交易驱动账务进行记账，以支付数据为记账数据，借记渠道清算往来，贷记待结算商户对账中心获取到渠道清算文件以后，与平台记录进行核对，渠道清算成功了2笔，因此核对结果如下表所示，出现了一笔渠道单边。其中清算文件数据做为渠道清算记账数据，借记“已核对应收银行”，贷记“渠道清算往来”，记账情况如下可以看出，清算完成以后，渠道清算往来-收款存在贷方余额，也就是交易对账的渠道单边造成的。经排查，是平台的支付系统状态更新异常，在对账中心进行了“平台补单”的差错处理，原来的处理中的支付状态，更新成了成功补单成功的支付记录将驱动账务再次记账，因为平台补单的数据属于平台支付记录，因此，其账务处理规则与平台支付记录的账务处理规则相同从图中可以看出来，此时待结算商户20元，与渠道清算成功，应收渠道20元，商户结算户和银行存款户还没有余额。假设，开始支付成功的一笔交易是没有完成账务记账的，而次日对账补单成功的交易完成了客户记账，那么也只有补单成功的完成了向商户的结算基于补单成功的交易，推动账务完成了记账，在T+1执行结算以后，完成了向商户的结算可以看到待结算商户-收款，存在贷方余额，即应结商户的在途资金，这是因为存在交易未入账的情况。触发交易发起补入账操作，补入未入账的交易记录，如表，状态是未结算
未结算的账务明细重新执行结算，完成商户结算入账，至此待结商户余额为0，完成商户在途资金的处理。也完成了向商户的结算，如图8-28所示。
资金对账模块获取到银行结算账单以后，进行资金对账，假设渠道结算文件记录只有一笔，因此在资金对账时出现了短款资金对账结果产生了10元的短款，系统会自动生成长短款记录 可以看出来，渠道资金对账以后，已核应收银行存在借方余额，即有短款挂账，这个与短款记录是一致的，因此过渡户科目余额的反映与对账结果的反映含义是一样的。经人工排查，收单账户已经完成了资金入账，是结算文件数据丢失，因此对短款进行“银行补入账”的核销，数据如表 至此，就完成了收款清结算的全部环节的账务处理了，涉及到的全部账户的记账情况如图所示。可以看出通过这5组账户的借贷账务处理，完成了从交易到内外清结算的全链路核算以及最后的记账，中间过渡户的最终余额为0，代表着完成了渠道的清算往来核算以及商户的结算核算。通过该账户体系可以非常高效和准确的实战清结算业务的全局处理。推荐阅读
业财一体化全局掌握
陈天宇宙，高级支付产品专家，专注支付写作5年，输出近100万字；代表作《支付核心系统》《支付清算生态》《上帝视角看支付》《84张支付架构图》《支付32真经》等，为您提供深度支付内容和服务！点击查看：支付全集-珍藏版V9.0![]()
