对账系统设计详解（下）

本文由作者 陈天宇宙 发布于社区，业务图较多，建议PC端阅读
上篇指路：对账系统设计详解（上）

07
资金对账项目配置设计完成线上支付交易以后，虽然通道方告知支付成功，但是钱是不是真的能给，还需要打一个问号？资金对账就是应收应付和实收实付之间的核对；什么是应收应付，什么是实收实付呢？哪些数据与之对应呢，本文会详细介绍
1、资金对账项目
通过对账系统设计（上）我们已经明白对账项目的概念；今天我们要介绍的资金对账项目可能更容易理解：一个实体的银行或者三方资金账户为一个资金对账项目
所以说资金对账，我们按照银行账户的维度进行核对；因为在会计科目中银行账户已经是叶子科目了，虽然一个资金账户可能有很多业务类型的收款，但是我们这里不再细分了；如果因为公司需要想细分也是可以实现，只需要按着业务类型区分账户的资金变动项即可
这里我们按照一个实体的资金账户设置为一个资金对账项目，比如平台有微信平台2个收款账户1和2，支付宝平台两个收款账户3和4，招商对公5，一共5个资金账户，那么我们就可以设置5个资金对账项目，如下

资金对账项目1：微信账户1

资金对账项目2：微信账户2
资金对账项目3：支付宝账户3
资金对账项目4：支付宝账户4
资金对账项目5：招商对公户5


2、对账项目命名
为了便于管理我们还需要为每个对账项目命个名字，如何起名这个也看自己喜好；命名的一个关键原则：要能从名字中看出具体核对的那个账户
基于这个原则我们为1中的几个项目进行命名如下

规则：通道方+通道类型+账户号

资金对账项目1：微信-收款-账户1

资金对账项目2：微信-收款-账户2
资金对账项目3：支付宝-收款-账户3
资金对账项目4：支付宝-收款-账户4
资金对账项目5：招商对公-收款-公户5
这样我们可以清晰的知道对账项目1是微信开的的账户号为1的收款账户

对账文件管理前面已经讲过了，每个账户次日都会提供相应的清算文件和结算文件；那么文件要跟资金资金对账项目对应上，最后为对账文件命名上可以知道对应的所属账户，比如   
规则：通道方+账号+文件类型+交易日期
资金对账项目1：wx-1-pay-20210204


3、对账项目管理
一个企业可能会存在很多个资金账户；为了便于管理，我们就需要一个菜单专门管理资金对账项目；示例如下


该页面可以查看所有的资金对账项目，每个项目就是一个实体资金账户；点击设置可以进行该对账项目的配置设置；右上角的新增可以新增新的项目



4、资金对账模式的选择
资金对账我们知道是核对应收应付和实收实付，实收实付我们知道就是银行实际资金的变动，使用银行结算账单即可；那么应收应付的选择其实有2种方法一个是使用通道的清算文件作为应收应付，另一个是使用平台的资金账务作为应收应付
1）使用银行清算文件
就是银行记录应收应付与实收实付进行核对，但是有个缺陷就是平台的支付记录需要跟银行的清算文件进行核对，所以核对模型如下

看3中的新增对账项目中有一个关联交易对账，就是看一下平台的支付记录和清算文件核对有没有差异，如果没有且资金对账没差异，那么就没有问题

2）使用平台资金账务核对
就是如果公司有账务中心的话，可以直接拿资金变动账务与实际银行的资金结算账单核对，这个不做具体介绍了



5、对账维度
交易对账是按照逐笔核对的，资金对账我们不按照逐笔核对，因为存在轧差以及线下汇入等情况，我们按照费用维度进行核对，就是将应收应付和实收实付解析成款项，对相同款项进行核对，比如收款，收款手续费，退款，退款手续费，打款等


6、对账项目设置
我们以核对清算数据和结算数据为例，资金对账项目解析就是将文件里的数据解析汇总到对应的款项上去，知道一个账户今天每一个款项上的金额

该配置器最终的实现是

我们从页面可以看出来，该配置是将文件里的数据先通过“条件组”的筛选，然后取目标数据的金额，并且对金额进行运算汇总；比如例子中的第一条就是：取交易状态=success的数据，取订单金额作为结算金额
如文件数据

通过原型中的配置条件

条件组：交易状态=success，
金额：正直汇总  订单金额
我们得到了：收款=100+90=190
其他费用逻辑类似
一定要枚举一个资金账户里的每一类型费用，不能遗漏，不然会出现资金差异
这样完成配置后，一个对账项目就配置完成了；会照着配置的时间每天完成账单数据的汇总，得到该账户每一方数据的每个款项的金额


08
对账引擎设计和结果管理
前面的文章都是建设工作，对账的基础，今天我们就来聊一聊怎么动起来，就像发动机一样要让组织转动起来，同样对账也是，需要一个核心的处理流来完成每天和每个对账项目的核对，我们今天来聊一下几个关键的处理
在对账执行前还有最后几个重要的问题没有解决，那就是对账的核心处理逻辑是什么；对账有几个关键的处理引擎


1、对账连续性控制引擎
对账不能跨日，比如2号对完才能对3号，如果今天是10号，2号还没对账，那么3-9号的账都不会核对；因为前一天的单边会循环进入下一天的核对



2、对账时间控制引擎
如上表，我们需要管理对账的时间；这里有3个时间概念需要知道

• 对账日期：就是对的那一天的账，也是交易成功时间或者资金变动日期

• 对账启用日期：一个对账项目的第一个对账日期

• 最后对账日期：一个对账项目的最后一个对账日期

3、对账状态控制引擎

需要管理可查每一个对账项目在每一天的对账状态

4、对账任务流程控制引擎和报警

主流程控制对账项目的任务执行，并在流程变更更新其他控制环节参数；如果主流程某一个处理失败那么进行任务报警，人工干预重启流程

5、对账核心引擎

对账最核心的引擎就是数据间逐笔核对的过程

比如经过上面的逻辑，对账项目1在x日的对账结果如下

6、对账结果查看

通过上面的对账执行，我们就得到了对账的结果，每个对账项目的对账总笔数，总差异

1）交易对账结果

该结果是每个对账项目按笔数核对的结果

2）资金对账结果

该结果是每个资金账户对账项目，按照费用款项核对的结果

好了，得到了对账结果之后，下一步就是针对不同的差异进行排查和差错处理了

09
差错处理和差错配置设计

对账有两个核心目的，一个是发现错误，另一个是改正错误；今天我们说一下对账差异的处理
对账结果如果有差异，就需要有排查差异的原因，差异原因千奇百怪，但存在必是有原因的，如果时查不到就先挂着，至少我们知道了有一个差异待处理；（下文提到的差异我们代表交易对账对出的单边或者错账以及资金对账对出的资金长短款）
 

1、关于差错处理差错处理其实就是消除差异的过程

• 发现差异：对账结果对出了差异

• 排查差异原因：排查差异原因，是掉单了，bug，时间差等具体的原因

• 按照实际处理差异：找到原因后对差错进行处理，掉单的补单，bug就修复，时间差的话就不用处理，等待第二天对平

• 消除差异：这一步是在对账系统对差异进行标记处理，说明差异已经排除了
  

2、交易差错处理

交易对账是数据的逐笔核对，会出现三类结果

• 对平：无需处理

• 单边：需要处理

• 错账：需要处理

1）差错列表

对账的差异会单独出现在差异列表等待处理

点击处理，弹窗选择处理类型，提交之后可以走一个流程，也可以直接处理完成

2）差错处理类型

就是我们用什么样的方式消除了差异，比如如果是银行成功，我方平台掉单了，那么就进行补单，补完后就对平了，这样也是保证用户的权益；这时因为是我方掉单了，所以对账结果是银行单边；等我方补完单后，银行的这笔单边就出错了“平台补单”

我们可以预设一些差错处理类型，形成每个类型的处理流程，便于在处理的时候直接选择使用

3）差错处理接口

有些差错处理是可以让相关系统包装接口直接进行处理的；比如平台掉单补单，可以让订单系统包装一个补单接口，对账系统调用进行补单

3、资金差错处理

资金对账的差异是费用的差异，收款，退款，手续费；在账户对完结果后，如果确认不是解析等技术层面的差异，可以对结果进行一个确认，确认之后差异会生成长短款数据，后面对资金进行长短款处理时就对长短款进行核销

1）资金对账结果确认

2）长短款管理

比如微信的一个资金账户，资金同事直接在微信商户后台操作了一笔转账，或者用户直接用微信转给给了这个账户，这时候都会出现微信收款比平台收款多的情况

微信账单收款1000----------平台记账收款900

此时资金对账就会有100元的长款，就是微信多收了

确认结果以后，长短款模块就会生成一笔该账户的 100元长款记录；长款款记录要有账户信息，对账日期信息，费用信息等

3）长短款核销

对于生成的长短款差异，同时也会生成账务凭证，算是一个挂账凭证，为了让账务是平衡的；后续针对每笔资金差异进行排查核销；比如如果确认是人工微信做了转账，那么可以直接核销“资金人工转出确认”，直到长短款没有待核销长短款，我们的资金就是准确的了

4、其他对账场景案例

除了常见的三方支付，电商等的普通的在线交易的对账，还有一些其他领域的核对，虽然行业不同，交易数据特点不同，但是对账的本质是相通的；唯一不同的就是交易数据的结构千奇百怪，导致数据的解析，核对逻辑会有变化，下面我们举几个场景

1）红包中间账户对账

我们都知道，红包场景算是比较复杂的，因为发红包的支付一笔红包款，会发出几十个红包，最后有些红包没被领取又退回了，这个核对场景最复杂的是一对多，我们站在红包的中间账户角度看这个交易场景，对中间账户的进出进行核对

案例：用户A用招商银行卡通过红包发了10个红包共100元，3天后一共领了7个80元，退回20元到招商银行卡

• 红包发放充值流入：+100元

• 红包流出付款流出：一共8笔共80元

• 超时未领取退回流出：一笔20元

你觉得该如何做核对呢？

2）机票代理对账

我们都知道去哪网，携程，飞猪，这些卖机票的平台；可能不太清楚这些平台上的众多机票代理商，他们的交易体量也是非常巨大了，每个月卖出几万账票的很多；

我帮助很多机票代理商实现了自动化对账的系统建设；他们的对账相对来说是非常复杂的，在鹤壁有一家代理商是从深圳搬过来的，他们一共有5个财务每天进行对账，5个财务的年薪资支出有二三十万之多，可想而知如果实现系统化对账，能节省多少费用

机票代理商的交易模型：

从模型中我们可以看出来，主要是有三个环节

1）售票平台

代理商入住后，就像淘宝已经，会有个结算账户，记录卖票记录和结算款记录，卖出去10张票，平台抽取佣金剩余部分结算给代理商结算账户；平台会提供2分文件：机票销售明细文件，结算明细文件；这两份数据要做核对

2）机票代理商

机票代理商有一个机票管理系统，购买的第三方服务公司的，可以记录在每个平台的卖票情况以及付款出票情况

3）付款通道

机票代理商要卖机票需要向航司去买，卖票付款的话航司签约了一些三方支付公司，比如支付宝，易宝支付，代理商选择这些付款通道进行签约向航司付款，先把钱充值到指定付款账户中，易宝支付是航旅行业觉得的第一名，付款通道会给机票代理付款文件

机票代理的对账模型：

• 售票平台的售票明细与结算明细核对

• 售票平台的售票明细与代理商系统的售票明细核对

• 代理商系统的付款明细与通道的付款账单核对
  

机票行业数据特点：

这个行业的文件是很复杂的，特别是几家ota平台，文件形式各不相同，一个用户买7张票，一个订单对应7个人，对应7张票；有的平台的一个订单一票记录，票号塞在一个单元格里，有的平台是一张票一条数据....

大家可以思考一下，对账怎么对呢：按照订单号对？还是按照票号对？

3）还有一个行业是券商对账

什么是券商呢，我们在招商信用卡，中移动积分商城里兑换的商家优惠券其实不是直接由商家提供的，而是中间券商；就像电子支付一样，中间券商汇集采购商家的优惠券，然后通过接口提供售卖给信用卡平台或者中移动等平台；用户在中移动或者信用卡商城兑换后到商家去消费，然后进行层层的核销和结算

招商银行和中移动与券商结算，券商再把结算款结算给商家

这个对账模式我就不再细说了，大家可以思考一下如何建设券商的对账系统

结束语

好的，对账系列我们就完结了，对账系统大家会设计了么？

实际工作中，每个行业，每家公司的业务场景和业务模型都会有差异，对账模式以及系统设计也需要相应的针对性设计，在通用对账的基础上进行调整，比如因为数据结构特点设计解析器，因为业务流程不同设计对账流程和差错处理流程。

虽然文章尽可能详尽，但难免有疏漏，欢迎交流讨论~

↘好文推荐：
对账系统设计详解（上）

大厂没有方法论（上）
阿里设计师出品！B端产品文案指南

点个“在看”吧