收单记账 - Cocolian Framework

本文描述在电商支付系统的支付记账和会计处理流程。注意，这个流程和第三方支付平台以及银行等渠道的处理是不一样的。主要表现在：

电商支付系统的支付记账处理，不需要考虑备付金的情况。用户的扣款是通过银行直接入账的，不考虑担保交易的场景。
第三方平台支付系统的记账处理，支持担保交易。用户交易资金是通过备付金来进行周转。
这两个流程区分的关键在于是否有备付金。本文考虑第一种情况，即无备付金，不需要支付牌照时的支付收单账户和账务的处理。

一、支付流程

接着之前的小明购买会员卡的案例，不考虑优惠券和卡采购的情况。为了完成支付，支付系统需要预先在支付渠道开通收单账户，用来接收业务方的的收单请求。注意，有些第三方平台，如微信支付，对不同业务类型的收单费率是不一样的，会要求设置不同的商户号里完成。

在线上的实时处理流程如下：

用户购买会员卡，提交订单，会员卡向订单系统请求生成订单，订单系统向支付系统发出支付请求；
支付系统生成支付记录，并向银行发出扣款请求。
银行实时从小明的银行卡账户上扣款100元，通知支付系统小明支付成功；
支付系统账务子系统在自己的账户体系中记录小明的这一笔消费支出，给会员卡业务账户增加对应的资金，通知会员卡系统发送卡给小明。
支付系统发送消息异步通知会计系统进行记账。

注意，在这里，渠道（银行）从小明账户上的扣款并不是直接到渠道的收单账户上。

这5个步骤都是线上的流程，在此过程中，各个子系统之间的交互如下图所示。我们逐步分析这里涉及到的对象。

二、账户设置

借： 应收账款-工行收款 100-100*0.1% = 99.9
     服务成本-工行手续费 100*0.1% = 0.1
贷： 主营业务收入-会员卡 100

二、支付订单

这个流程中，首先生成的是支付订单。这是一个比较简单的订单，仅涉及到一个商家和一个商品。在比较复杂的电商场景中，一个订单会涉及到多个商家、多种商品以及对应的优惠活动。也就是，一个总订单会被拆分为多个子订单。这部分内容将在后续的订单系统设计一文中详细介绍。而订单中和资金相关的内容，都需要在账户体系中建立对应的科目和账户。在请求支付时，只会将总订单提交支付，拆分子订单是在订单系统中完成的。

针对上述场景，为了简化处理，假定老熊公司当天总共完成了三笔会员卡交易，支付订单如下：

三、支付记录

在这个流程中，订单系统向支付系统请求支付时，支付系统将产生支付记录（支付订单）。支付记录内容比较多，这些数据是后续进行记账的基础。

上述的三个订单，两笔通过工行支付，一笔通过支付宝支付，其产生的支付记录如下，此处省略了其他和记账无关的字段内容：

这里需要注意的几个属性：

订单号: 这是总订单号。支付系统不再对订单进行拆分。订单拆分是订单系统的功能。
支付流水号：在支付记录中，针对每个（总）订单号，会有对应的支付流水号。如果用户使用组合支付，如上述场景，小明使用余额支付了20元，使用银行卡支付了剩余的80元，那这将产生2个支付流水号。为了避免洗钱风险，简化订单处理，包括淘宝在内，现在一般都不再提供组合支付的支持。
支付方式和支付渠道：用户选择的支付方式和实际执行支付的渠道可以是不一样的。比如用户选择了广发信用卡来支付，但实际上电商公司没有直接对接农行，而是通过支付宝来对接，那对应的支付渠道就是支付宝。
本条记录在支付成功后，会产生记账凭证和对账凭证。这一条记录将产生多条会计分录，记账凭证是关联这些会计分录和支付记录的字段。对账凭证是根据对账周期来分配的。在日切后，对账凭证号相应的也会做更新。

在产生支付记录后，在上述流程的第5步通过消息机制来异步触发记账流程。账务系统接收到记账消息后，开始更新账户信息。记账分为两个阶段：

支付记账，针对线上的账户实时更新的需求，需要让用户及时看到账户余额和订单状态，账务信息记录到用户和商户上，采用单边账的形式。
会计记账，采用复式记帐法，满足会计记账需求，记录会计分录和余额，为对账和清结算提供支持。

四、支付记账

支付记账是在支付流程中完成的，目的是让用户完成购买后，能够立即看到支付结果和账户余额。为了提升性能，支付记账一般采用单边账的形式，即将会计分录登记在用户侧或者商户侧。

在上述案例中，第6步处理，在服务器上与银行侧同步登记一笔从小明银行卡的支出，并在会员业务账户上登记一笔收入。如果使用的是零钱支付，这一个步骤就很重要，从零钱账户上扣除费用计算余额，添加对应的消费记录，是在一个事务中完成。

五、会计记账

会计记账采用复式记账，不同业务记账方式也不一样。小明买卡的案例中，需要记录的条目有：

在工行收款账户下，登记 99.9的借记条目
在工行手续费的账户下，登记0.1元的借记条目
在主营业务收入-会员卡的账户下，登记100元的贷记条目。

这3条记录是通过事务处理一次生成。当天发生的三笔交易，产生的记账内容如下：

实际实现上，科目一列，使用账号ID来替代。每个账户的本期发生额，可以在另一个表中单独异步计算。

六、对账

在会计上，对账分三个部分：账证核对、账账核对和账实核对，做到账证相符、账账相符和账实相符。在电商支付系统中，需要完成的对账工作包括内部对账、外部对账和资金对账。其中外部对账又分为和支付渠道的对账、和商户的对账以及和用户的对账。这里简单介绍每个对账流程以及对记账的影响，详细的对账和轧账流程，将在下一篇文章中说明。

内部对账

内部对账的内容包括：

核实账户系统中的账务与支付记录的一致性；
核实会计系统中的账务与支付记录的一致性。
这是后续账账核对和账实核对的基础，也是对外对账的基础。这两个对账任务一般是在后台定时运行（5分钟运行一次），除非系统有bug或者发生故障，内部对账一般不会出现差错。如有差错，也需要人工处理。

渠道对账

一般银行、第三方支付提供T+1的对账单，这是执行渠道对账的依据。在上述案例中，支付系统每天拉取工行前一天的对账单，核对交易流水。与此同时，按照从工行获取的对账单，记录资金归集的账务。

接收到工行对账单后，按照对账单生成凭证：

注意上述的日期、凭证号，以及借贷关系。

账账核对

完成渠道对账后，需要进行日结和试算平衡：

总分类账各账户本期借方发生额合计与贷方余额合计是否相等；
总分类账各账户借方余额合计与贷方发生额合计是否相符；
核对各种明细账及现金、银行存款日记账的本期发生额及期末余额同总分类账中有关账户的余额是否相等。

从科目维度，计算：
科目期初余额+科目当日发生额=科目期末余额
下级科目余额总和=上级科目余额（科目总分检查）

账实核对

对电商公司来说，最重要的账实核对，是验证银行存款的变化和实际资金流向是一致的。一般是需要登录到银行网银系统中来人工核实。如果对接的银行多，银行提供网银对账单，也可以自动进行，查询出入款总额。

详细的对账和轧账流程，将在下一篇文章中说明。

结束语

本文主要介绍支付清结算中的账户和账务的处理。在此期间，有不少同学询问是否可以详细介绍某一个记账或者账户应该如何设计，希望能够针对某一主题做进一步说明。清结算是一个很专业的话题，这个专业不是计算机专业，而是会计专业。每个公司的账户和账务处理都有自己的要求和特点。这一系列文章，主要是从软件开发的角度来协助大家梳理清结算相关的基础知识，让大家和会计同学对话的时候有一个基础，或者说共同语言。具体的账户、账务、会计处理流程，需要和公司会计详细沟通。关于清结算系统的设计和实现，将在支付系统设计系列中介绍。

感谢您对本文的关注，如需要及时收到凤凰牌老熊的最新作品，或者有相关问题探讨，请扫码关注“凤凰牌老熊”的微信公众号，在公众号里留言或者回复，可以尽快处理，谢谢。

本文欢迎转载，转载时请注明本文来自微信公众号“凤凰牌老熊”。