第三方支付账务体系三个阶段.docx

最近有很多朋友在知乎上私信我询问有关支付系统账务功能实现方面的问题， 但 鉴于私信回复实在无法把实际问题进行很好的表述， 所以我纠结了半天， 还是决 定在 donews 上单独开几篇博客， 分享一下我的经验。 整套博文将从业务和技术 实现两个维度阐述当前主流支付系统假设过程中账务处理的方案， 文中为方便理 解将支付公司指定为支付宝， 还请多多谅解。基本属于想到哪说到哪， 如有谬误， 还请各位专家多多指正。 直入正题， 第三方支付从无到有发展到现在， 其实就账务体系这块经历了三大阶 段。 第一个阶段，我称为清算一体阶段。 早期支付公司的商户通过在线支付收取货款后， 向支付公司发起结算时， 支付公 司根据数据库中交易流水关联的商户号查找到所有该商户的未结算资金明细， 汇 总无误后将资金结算给商户。这个过程中，支付公司将清分 (clearing) ，结算 (settlement) 两个动作放到一个事物中先后进行。 在这里补充一个小知识点：所谓清分 (Clearing) 是清算过程中的数据准备阶段 , 对支付公司而言，主要是将需要结算给商户的资金进行汇总，整理，分类；所 谓结算( settlement )可以看做是完成交易双方价值转移的过程。 通俗一点说，有一大堆商户在淘宝开店，最后资金都落到了支付宝，他们都向 支付宝发起提现要求。支付宝首先要算清楚扣除手续费后每个商户可以提现多 少资金(清分)，然后根据计算来的数据，把钱汇给这些商户(结算)。也就 是说，清分就是算钱的过程，结算就是给钱的过程，不知这样说各位看官是否 明白？ 后来，随着支付公司商户的急剧增多以及交易量的暴涨， 假如每次商户发起提现 支付公司的清结算部门都一条一条数据汇总轧张后进行出款， 不仅员工叫苦连天， 效率也十分低下， 服务很差。 所以不知道哪个聪明人第一个想出来这个方案： 针 对每个商户开立一个虚拟账户， 每次交易完成后咱们就在商户的账户上进行余额 的加减，这样子每次商户发起提现时我们的清算人员只要看一眼商户的账户余额 就可以进行出款， 然后把商户的余额给调账就可以了。 这个阶段我称之为虚拟账 户阶段，顺带一提，据我所知目前仍然有很多支付公司的系统停留在这一阶段。 再后来， 大家发现这种单式记账法进行记账， 经常丢数据不说， 追查起来还难得 一比。于是又有高人将银行金融体系的基于系统科目的记账方案搬了出来， 由此 进入当前阶段： 基于会计核算体系的账务阶段， 这几篇博文的重点也是讲这个阶 段。 聊完了这三个阶段， 相信大家对支付系统账务模块的历史演变， 应该有了一个相 对清晰的认识， 那么在说正题之前， 我们先简单了解一些基本的财务知识。 这些 知识不一定会帮助你飞黄腾达， 但如果想深耕支付系统的建设， 最好还是掌握这 些知识。以下只是我的抛砖引玉， 希望通过了解这些内容读者可以没有障碍地读 更后续的内容。 首先是一些术语： 会计科目 ：会计科目是指对各项会计要素按其反应的经济内容和管理要求不同所 进行科学分类的项目。 不掉书袋的说法，会计科目就是记账的基础，所有的 “帐”其实都是会计科目余额 的一种展现。 会计科目通常会分为很多类， 假设我们现在只建设最简单的支付系统， 那么至少 我们需要熟知以下三个科目大类： 资产类科目： 通常余额反映在借方， 银行存款、固定资产等通常记录在资产类科 目下。 负债类科目： 通常余额反映在贷方， 客户负债，应付款等通常记录在负债类科目 下。 共同类科目：根据实际业务不同， 具体的科目余额既可以反映在借方也可以在贷 方，通常来说待清算款项会记录在共同类科目中。 为了让会计科目既反映总体核算数据， 又体现细节核算数据， 所以一般会分层次 设置。例如在资产类科目下， 我们设立一个一级科目叫做银行存款 （科目号 110）， 在银行存款科目下设置二级科目叫做工商银行存款（科目号 110 01 ），在工商 银行存款科目下设置三级科目叫做工商银行 XX 支行银行账户（科目号为 11001 01 ）。大家注意看括弧里的黑体字，下级科目号 =上级科目号 +自己本身 独立分配的科目号，这样就能很轻松地通过一个下级科目号推断出其上级科目。 另外顺带一提，假如一个会计科目不存在子科目， 那么我们就认为其是底层科目， 所有反应实际业务活动的账务必须记录在底层科目中。 资金平衡关系： 学过会计恒等式的同学都知道，资产 =负债 +所有者权益。对我们上述假定的支 付系统而言，由于没有所有者权益，所以恒等式变更为资产 +共同类借方余额 = 负债+共同类贷方余额。整体而言，无论什么业务状况下，我们必须保证系统内 所有借方余额正好等于贷方余额，否则系统可以判定为有 BUG 。 记账规则： 既然设置了科目用来进行账务的记录， 那么接下来咱们就必须明确在不同业务活 动