想必大家对“对账”这个词都不陌生，单从字面意思就能略知一二；其实就是字面意思；“对”就是核对，“账”就是账目；“对账”就是核对账目；账目核算是财务工作的必要部分，随着线上交易体量越来越大或者说对财务自动化线上化的效率提升需求越来越高；为了提升核对效率以及准确性，势必要将核对业务系统化线上化自动化；那么如何构建设计一套不同业务场景下的对账系统呢？

1 对账概述

日常生活中我们每天都在对账，比如去餐馆吃饭付款，会对老板说一声“老板，钱付过去了”；老板检查过收款或者听到语音播报后回复一声“好嘞，下次再来”；这就是最简单的一次对账。

再比如你在淘宝开了一个店铺，每个月几千单的交易，发货；每次月末都拿着所有的订单明细和支付宝收款账户收款记录逐笔的做一次核对，保证发过货的订单都收到款了，这就是一次更复杂的核对了。

1.1什么是对账

对账概括来说就是“账证实”核对，“账”就是账目，“证”就是凭证，“实”就是实际资金

核对模式有三种：账证核对，账账核对，账实核对；确保账证实两两的一致性；比如吃了一碗面点菜单就是原始凭“证”，付了10元钱是“账”，老板电脑点菜记录小票10元是“账”，老板看到账户中余额增加了10元是“实”

财务范畴来看，证就是会计凭证，比如发票，小票，出货单，收据，交易系统的支付记录等都是原始凭证；而账呢就是财务的账目，账务系统的账务记账，金蝶的科目余额等都是不同的账目；而一笔交易会记录在很多的环节，比如账务系统，金蝶等

另外脱离财务范畴来看，其实账目本身抽象出来就是数据，商品数据，用户数据，卡券数据等，那么账证实需要核对，很多时候很多非财务范畴数据也需要核对，比如今天应到10人实到8人，军训时的报数等其实也可以称为对账，我们暂且称为“广义的对账”

那么我们来为对账下一个定义：为了确保同一个事务的数据描述在不同场所下的记录一致而进行的相互之间的一致性比对

1.2为什么要对账

首先在财务范畴，这是一个必要做的工作

另外从业务范畴，现在交易链条越来越长，数据在众多系统之间难免会出现丢失或者差错，所以为了业务的正常运转及时发现问题，需要确保系统间数据的一致性

从公司的角度，需要确保“不少收一分钱，不多付一分钱”，保证资金的安全，不然卖了多少货，收了多少钱相互之间谁也不鸟谁，最后全是糊涂账

综上所述，对账是必不可少的；对于交易体量巨大的互联网公司更是必不可少，而且系统化也是必须的，单靠人工难以满足需要

1.3几个常见对账场景

三方支付公司：主要是核对自家的交易记录和银行清算数据之间的一致性；银行清算数据（应收应付）和银行结算数据（实收实付）的一致性；同样也要核对与金蝶账务数据的一致性

电商等服务平台：主要是核对自家的交易数据和三方支付公司或者微信支付宝的清算数据的一致性；三方清算和结算的一致性；三方结算到对公户实际资金的一致性

另外还有红包：比如用户支付100元发10个红包，有6个用户领了6个一共8元，有4个超时没领退回给了用户；那么对于平台的这个红包中间账户的进出也要核对：

用户充值1笔100元中间户入了1笔100元中间户出了10笔100元中间户被退回4笔2元中间户退给用户1笔2元这样对于中间户来说100-100+2-2=0

还有一些其他的领域对账，比如航司的机票，机票代理商的购票出票，中间券商的上下游之间等等

1.4常见的对账模型

交易对账模型：数据之间的按照唯一标识进行一对一，一对多，多对多核对

资金对账模型：将交易数据按照款项类型进行汇总之后进行核对，比如收款，手续费

余额调节核对：对系统记账余额和实际资金账户余额在经过在途调整后进行一致性核对

比如：系统记账昨日日终余额100元，截止昨日日终提现中100元；出款账户昨日日终200元；此时该账户：系统账100元=出款账户200元-100元应付未付；这样余额是平的，说明资金没有问题

其他更复杂的核对模型：比如多链条之间进行关联核对像三份数据进行一次性比对等，这里不再过多阐述；本系列文章重点介绍的是1和2,至于3会在今后有机会讲解，如果有朋友感兴趣可以单独交流

1.5什么是对账系统

对账系统就是通过系统解决方案，对需要核对的数据按着设定好的规则进行核对校验，并产出核对结果；并且可以对核对结果进行对应的差错处理

通俗来说就是传统上用Excel来通过人工vlookup做的事情，完全交给系统去做，只需要预先配置好规则就行了

对于对账系统来说最基本应具备以下几个能力

可以便捷的获取需要核对的原始数据

可以对文件数据进行解析或者二次加工

可以灵活配置核对规则

可以查看核对的结果

可以对差异进行追踪管理和处理

可以对外提供核对结果

可以对外输出数据

1.6如何搭建一个对账系统

首先就是要先明确对应的业务模型，其次需要抽象出业务的核对模型，然后针对核对模型选择合适的核对方案，最后针对核对方案设计系统方案，然后进行研发和上线

2 对账架构图

如果企业没有账务和会计核心；可以通过对账中心先时间交易数据和三方清算数据的核对；然后汇总清算数据与三方账单数据核对；保证金业务记账以及银行清结算数据的一致性，如图1所示

按核对频率获取业务支付数据

T+1或其他频率获取三方清算文件和结算文件

将清算和结算文件进行解析存储

根据对账项目配置完成交易数据和清算的核对

完成清算数据和结算数据的核对

对交易的单边数据和资金核对差异进行管理和处理

3 对账文件获取和解析

支付交易的通道提供方，例如微信、支付宝、网联、银联等，都是按照约定频率和时间提供交易的记录文件，一般都是2份，一个清算文件“记录支付明细”；另一个是“结算文件”记录资金账户的实际的资金变动；对于文件的获取大部分在提供通道时会提供下载接口，另外如果没有接入下载接口，可以采用人工下载的方式获得文件，将文件传到对账系统获得对账数据；本节主要介绍渠道方的对账文件获取以及解析和管理。

3.1对账文件类型

主流类型还是Excel和txt，本节主要介绍的也是这2种

excel（csv）：支付宝,常见支付公司；这类文件最方便查看，如图2所示

Txt：微信，银联个别通道，一些银行；这类文件很不便于查看，如图3所示

xml报文：网联，这类文件人工很难查看和处理

3.2对账文件获取方式

接口获取，通过机构提供的文件查询和下载接口获取对账文件，支付宝下载接口示例如图4，5所示

人工下载，如果技术能力资源不足，或者暂时没有接入接口，可以采用人工下载的方式，然后在对账中心上传对账文件进行解析

3.3对账文件管理

文件管理方式，文件一般存放在对账系统指定的ftp内，并且对文件夹设定一定的命名规范，通过路径查询和下载文件，如图6所示

3.4对账文件解析器配置

对账文件解析是指将文件里的数据解析到数据库内，形成数据库数据，因为文件数据不能直接被系统处理

1）原样解析

不改变文件的数据列数和内容，对文件数据保证不减少列数的前提下进行全量解析，可以根据需要增加列内容，比如账号，对账时间等

优点：不需要配置解析器，每一个文件研发好固定的解析器进行复用

缺点：每个文件类型需要建一套数据表，维护成本高

适用：通道少的平台，一般商户都仅有微信支付宝，可以采用原样解析

2）通用板式解析

所有对账文件数据按照映射关系解析到固定的数据表当中；例如以下的表结构，如表1所示

表1 存储对账数据表

例如图7所示的是对账文件中的部分数据

图7 示例对账文件数据

预先设定好表2中的解析规则，根据该规则可以将图7中的数据解析到表1中

表2 预先设定好的解析规则

3.5对账数据查看

数据解析到数据库里了，为了便于运营排查问题，还需要做一个查看数据的运营页面，页面样式如图8，9，10，11，12所示

图8 业务平台对账数据查询

图9 微信清算账单数据查询

图10 微信结算账单数据查询

图11 支付宝清算账单数据查询

图12支付宝结算账单数据查询

4 平台自有数据的获取

4.1平台对账数据获取方式

拿到三方文件账单数据以后需要与平台自己的相关数据做核对，比如平台交易数据与清算数据的核对；平台账务数据与银行账单数据的核对；平台自有数据获取方式常采用如下形式

1）文件获取

业务系统需要按照要求定期（如每日凌晨2:00）生成文件，按照约定规范进行命名后，将文件推送至对账系统指定位置（ftp）；这种方式需要各业务系统有一定开发量，业务调整时也需要调整文件的生成策略，维护成本略高

2）接口接收

对账系统提供对账数据接收接口，类似账务记账接口一样，业务系统按照约定在相应业务节点发送业务数据到对账中心

3）MQ

业务方按照要求在交易成功时发送约定格式的MQ消息，对账系统订阅该MQ，对MQ进行解析后获得业务数据

4）SQL

通过SQL定期捞取业务数据，并将数据存储到对账系统数据库中；该方式调整灵活，可以选择在业务并发小的凌晨进行

5）人工上传

对于一些采购的外部应用，比如金蝶系统，数据无法通过以上方式获取的情况下，就需要对账人员定期下载应用内数据，然后上传到对账系统

4.2数据分类管理

对账系统数据会越来越多，类型也越老越多，支付数据，卡券数据，订单数据，三方清算数据，三方结算数据等等；每类数据的数据字段有各有不同；如何对众多类型数据进行管理呢？下面介绍一个方法：对数据进行分类管理，每类数据单独设置表结构

1）数据分类设置

设置数据的大类，或者说是一级分类；就像商品类目一样管理数据，如图13所示

图13 数据分类设置

2）设置数据类型

在数据分类下面设置数据的子类，并且数据子类关联数据库表名，便于存储数据，查询数据，对账取数，如图14所示

图14 数据子分类设置

4.3取数规则配置

配置好了数据分类和类型以及关联好了数据表之后，接下来就是配置获取数据的规则了，我们以通过文件或者SQL两个可选择的形式获取数据为例，如图15所示

图15 取数规则设置

为每个数据分类配置取数方式，如果是文件的话就配置文件路径，如果是SQL的话就配置取数sql，这样系统会按照任务配置基于取数规则定期获取对账的数据，并且插入到数据类型关联的数据表当中。

5 对账数据管理

5.1对账结果数据

1）交易对账结果

支付数据与三方清算的核对，或者其他数据的两两核对，会得出核对结果；并且每一组核对都会有一个组别的名字，这个下一节会详细介绍，比如“会员支付VS微信清算”，核对结果如表3所示

表3 交易对账结果示例

我们可以看出来“1,5,6”三条记录是有问题的，2条是一方有一方没有，另外一条是都有但金额不一致；这就是交易对账结果，“对平，单边，错账”，对于对账有问题的数据需要进行排查找出原因，并进行差错处理（后面会详细介绍）

2）资金对账结果

交易对账结果是源数据本身在某个对账项目里的核对结果；而资金对账结果是某资金账号某交易日的资金收付的一致性；比较平台的资金账收付结果与银行的收付结果是否一致，或者说是银行自己本身的清算与结算的款项及金额是否一致，如表4所示

表4 资金对账结果示例

从对账结果我们可以看出来，微信在退款和退款手续费存在差异，而发现二者正好正负相抵，原因是微信退款和退款手续费是轧差出现在账单里的，所以实际上并没有差异，但是既然已经对出差异，并且排查出原因，就需要对差异进行处理，资金对账的差异是“长款，短款，应收未收，应付未付”；在确认对账结果后，会生成差异表，在差异表中对差异进行核销处理。

5.2对账管理

上面我们介绍了交易对账和资金对账的核对结果，那么如何存储差异结果呢？差异结果可以存储在源对账数据的表中，也可以单独存储

1）存储在源对账表

该种方式适合与数据单一的对账体系，且同一份数据不会在多个对账项目中进行核对，比如支付数据只与清算核对，这时候数据的核对结果就是默认与另一方的核对情况

支付数据：1 对平

清算数据：1 对平

2）存储在单独的对账表中

该种方式适合复杂的核对场景，同一份数据会在多个对账项目中与多组数据完成核对，产生多个对账结果，比如支付数据与上游的订单进行核对得出一个对账结果，支付数据又会与下游的清算数据核对得出另一个对账结果

与订单对

订单数据：1 对平

支付数据：1 对平

与清算对

支付数据：1 单边

清算数据：无

我们发现支付数据的对账结果有2个，一个是与订单的核对的对平，另一个是与清算的核对的单边，此种情况，我们的对账结果就需要单独存储“某数据在每一个对账项目组中的核对结果表”，对账结果有2个，如下

支付数据对账结果表

与订单对：对平

与清算对：单边

6 交易对账项目设计

企业业务在不断变化，新的业务也在不断出现，对账数据因为业务的变化也在发生变化；如果接入了新的支付渠道对账设置也需要新增；如果每次都通过开发实现，那么成本会很高；本篇文章我们将介绍如何实现交易对账项目的配置化设计，极大的提升对账项目的管理效率

6.1.交易对账项目

做对账并不是简单的一方与另一方比对；实际会基于业务情况，存在很多组进行核对；比如与微信的核对，与支付宝的核对等；每一组又可能分成更细的组，比如与微信核对，可以分成微信收款核对，微信退款核对；又可能微信收款有很多账号，我们又可能会按照微信账户进行分组进行核对；例如微信收款一共有两个微信账号：微信1，微信2；那么我们可以设置4个对账的组，如下

对账项目1：微信1-收款

对账项目2：微信1-退款

对账项目3：微信2-收款

对账项目4：微信2-退款

对账项目就是我们设定的核对组；当然以上的对账项目我们可以简化成2个

对账项目1：微信-收款

对账项目2：微信-退款

具体如何设置核对组，这个因公司而已，因喜好而已，核心目的只要能完成全量的核对即可；对账项目越少越容易管理，对账项目越多越清晰，各有利弊

6.2.对账项目命名

为了便于管理我们还需要为每个对账项目命个名字，如何起名这个也看自己喜好；原来在易宝支付，因为对账组的同学基本都是女生，都是吃货，所以所有对账项目都命名称跟吃相关的“如：工商9876-卤煮火烧”；命名的一个关键原则

要能从名字中看出具体核对的业务

基于这个原则我们为1中的几个项目进行命名如下

对账项目1：会员购买微信支付-收款

对账项目2：会员购买微信支付-退款

这样我们可以清晰的知道对账项目1是用户使用微信支付购买会员的收款核对项目

6.3.对账项目管理

一个企业可能会存在很多个对账项目，像原来在某支付，高达几百个核对项目；为了便于管理，我们就需要一个菜单专门管理对账项目；如图16所示

图16 交易对账项目管理

该页面可以查看所有的对账项目；点击设置可以进行该对账项目的配置设置；右上角的新增可以新增新的项目

6.4.对账项目新增

在对账项目列表点击新增会有一个弹窗可以添加一个对账项目；新增时需要先填写基本信息即可，比如对账项目的名称，对账启用时间，对账的频次，对账的类型等，如图17所示

图17 对账项目新增

6.5.对账项目设置

对账项目的设置主要设置对账项目的执行时间，核对双方的对应数据，核对的唯一标识，一些处理规则等；下面是一个基础的设置页面；实际工作中需要基于业务场景以及数据特点，对设置器进行一些调整；但是在这配置基础之上一般难度不大；配置页面如图18所示

图18 交易对账项目设置

该配置器最终的实现是，我们从页面可以看出来，该配置是设置卡系统的消耗数据与订单中的消耗记录进行核对，为数据两方配置数据的选择条件

A方数据为卡数据

数据筛选条件是”交易类型=消耗购买”

B方数据是订单数据

对比设置两方以订单号进行核对，金额进行核对

订单数据的金额如果存在多条则进行汇总

对账差异的报警接受人，可以填邮件，办公账号等

这样完成配置后，一个对账项目就配置完成了；会照着配置的时间每天完成订单数据和卡数据关于消耗明细的核对。

7 资金对账项目设计

完成线上支付交易以后，虽然通道方告知支付成功，但是钱是不是真的能给，还需要打一个问号？资金对账就是应收应付和实收实付之间的核对；什么是应收应付，什么是实收实付呢？哪些数据与之对应呢？

7.1.资金对账项目

已经明白对账项目的概念；要介绍的资金对账项目可能更容易理解：一个实体的银行或者三方资金账户为一个资金对账项目。

所以说资金对账，按照银行账户的维度进行核对；因为在会计科目中银行账户已经是叶子科目了，虽然一个资金账户可能有很多业务类型的收款，但是这里不再细分了；如果因为公司需要想细分也是可以实现，只需要按着业务类型区分账户的资金变动项即可

这里我们按照一个实体的资金账户设置为一个资金对账项目，比如平台有微信平台2个收款账户1和2，支付宝平台两个收款账户3和4，招商对公5，一共5个资金账户，那么就可以设置5个资金对账项目，如下

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

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

资金对账项目3：支付宝账户3

资金对账项目4：支付宝账户4

资金对账项目5：招商对公户5

7.2.对账项目命名

为了便于管理，还需要为每个对账项目命个名字，如何起名这个也看自己喜好；命名的一个关键原则

要能从名字中看出具体核对的那个账户；基于这个原则为1中的几个项目进行命名如下：规则：通道方+通道类型+账户号

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

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

资金对账项目3：支付宝-收款-账户3

资金对账项目4：支付宝-收款-账户4

资金对账项目5：招商对公-收款-公户5

这样可以清晰的知道对账项目1是微信开的的账户号为1的收款账户

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

资金对账项目1：wx-1-pay-20210204

7.3.对账项目管理

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

图19 资金对账项目管理

图20 资金对账项目新增弹窗

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

7.4.资金对账模式选择

资金对账我们知道是核对应收应付和实收实付，实收实付我们知道就是银行实际资金的变动，使用银行结算账单即可；那么应收应付的选择其实有2种方法一个是使用通道的清算文件作为应收应付，另一个是使用平台的资金账务作为应收应付

1）使用银行清算文件

就是银行记录应收应付与实收实付进行核对，但是有个缺陷就是平台的支付记录需要跟银行的清算文件进行核对，所以核对模型如图21所示

图21 资金对账业务模式

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

2）使用平台资金账务核对

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

7.5.对账维度

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

7.6.对账项目设置

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

图22 资金对账项目规则设置

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

表5 对账文件部分数据

通过原型中的配置条件

条件组：交易状态=success，

金额：正直汇总订单金额

我们得到了：收款=100+90=190

其他费用逻辑类似，一定要枚举一个资金账户里的每一类型费用，不能遗漏，不然会出现资金差异

这样完成配置后，一个对账项目就配置完成了；会照着配置的时间每天完成账单数据的汇总，得到该账户每一方数据的每个款项的金额

8 对账引擎及对账结果查看

在对账执行前还有最后几个重要的问题没有解决，那就是对账的核心处理逻辑是什么；对账有几个关键的处理引擎

8.1.对账连续性控制

对账不能跨日，比如2号对完才能对3号，如果今天是10号，2号还没对账，那么3-9号的账都不会核对；因为前一天的单边会循环进入下一天的核对，如图23所示

图23 对账连续性的控制

8.2.对账时间控制

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

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

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

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

8.3.对账状态控制

需要管理可查每一个对账项目在每一天的对账状态，如图24所示

图24 对账状态管理

8.4.对账任务流程控制引擎和报警

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

图25 对账流程控制

8.5.对账核心处理引擎

对账最核心的引擎就是数据间逐笔核对的过程，如图26所示

图26 交易对账逻辑

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

表6 对账结果示例

8.6.对账结果查看

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

1）交易对账结果

该结果是每个对账项目按笔数核对的结果，如图27所示

图27 交易对账结果查看

2）资金对账结果

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

图28 资金对账结果查看

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

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

对账有两个核心目的，一个是发现错误，另一个是改正错误；今天我们说一下对账差异的处理

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

9.1.关于差错处理

差错处理其实就是消除差异的过程

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

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

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

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

9.2.交易差错处理

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

对平：无需处理

单边：需要处理

错账：需要处理

1）差错列表

对账的差异会单独出现在差异列表等待处理，如图29所示

图29 交易对账差错处理列表

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

图30 差错处理操作弹窗

2）差错处理类型

就是我们用什么样的方式消除了差异，比如如果是银行成功，我方平台掉单了，那么就进行补单，补完后就对平了，这样也是保证用户的权益；这时因为是我方掉单了，所以对账结果是银行单边；等我方补完单后，银行的这笔单边就出错了“平台补单”。我们可以预设一些差错处理类型，形成每个类型的处理流程，便于在处理的时候直接选择使用，如图31所示

图31 差错类型管理

3）差错处理接口

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

9.3.资金差错处理

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

1）资金对账结果确认

资金对账结果详情页面如图32所示

图32 资金对账结果详情

2）长短款管理

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

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

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

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

图33 长短款核销管理

图34 长短款核销处理弹窗

3）长短款核销

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

图35 核销记录

9.4.其他对账场景案例

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

1）红包中间账户对账

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

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

图36 发红包

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

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

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

你觉得该如何做核对呢？

2）机票代理对账

我们都知道去哪网，携程，飞猪，这些卖机票的平台；可能不太清楚这些平台上的众多机票代理商，他们的交易体量也是非常巨大了，每个月卖出几万账票的很多；我帮助很多机票代理商实现了自动化对账的系统建设；他们的对账相对来说是非常复杂的，在鹤壁有一家代理商是从深圳搬过来的，他们一共有5个财务每天进行对账，5个财务的年薪资支出有二三十万之多，可想而知如果实现系统化对账，能节省多少费用，如图37所示

图37 机票代理商的交易模型

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

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

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

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

机票代理的对账模型

所以对账我们要对这几个维度

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

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

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

机票行业数据特点，这个行业的文件是很复杂的，特别是几家ota平台，文件形式各不相同，一个用户买7张票，一个订单对应7个人，对应7张票；有的平台的一个订单一票记录，票号塞在一个单元格里，有的平台是一张票一条数据…大家可以思考一下，一下对账怎么对呢：按照订单号对？还是按照票号对？

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

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

万字长文详解对账系统设计，推荐收藏相关推荐

【技术综述】万字长文详解Faster RCNN源代码
文章首发于微信公众号<有三AI> [技术综述]万字长文详解Faster RCNN源代码作为深度学习算法工程师,如果你想提升C++水平,就去研究caffe源代码,如果你想提升python水 ...
边缘计算：万字长文详解高通SNPE inception_v3安卓端DSP推理加速实战
本文是在以下文章的基础上编写,关于SNPE环境部署和服务器端推理可以参考上一篇文章: 边缘计算:万字长文详解高通SNPE inception_v3推理实战_seaside2003的博客-CSDN博客 ...
万字长文详解如何用Python玩转OpenGL | CSDN 博文精选
作者 | 天元浪子来源 | CSDN博文精选 [编者按]OpenGL(开放式图形库),用于渲染 2D.3D 矢量图形的跨语言.跨平台的应用程序编程接口,C.C++.Python.Java等语言都能支 ...
万字长文详解文本抽取：从算法理论到实践
导读:"达观杯"文本智能信息抽取挑战赛已吸引来自中.美.英.法.德等26个国家和地区的2400余名选手参赛,目前仍在火热进行中(点击阅读原文进入比赛页面,QQ群见上图或文末二维码) ...
万字长文详解如何用 Python 玩转 OpenGL | CSDN 博文精选
作者 | 天元浪子责编 | 伍杏玲出品 | CSDN 博客 [CSDN 编者按]OpenGL(开放式图形库),用于渲染 2D.3D 矢量图形的跨语言.跨平台的应用程序编程接口,C.C++.Pyth ...
万字长文详解 Go 程序是怎样跑起来的？| CSDN 博文精选
作者 | qcrao 责编 | 屠敏出品 | CSDN博客刚开始写这篇文章的时候,目标非常大,想要探索 Go 程序的一生:编码.编译.汇编.链接.运行.退出.它的每一步具体如何进行,力图弄清 Go ...
万字长文详解文本抽取：从算法理论到实践（附“达观杯”官方baseline实现解析及答疑）...
[ 导读 ]"达观杯"文本智能信息抽取挑战赛已吸引来自中.美.英.法.德等26个国家和地区的2400余名选手参赛,目前仍在火热进行中(点击"阅读原文"进入比赛页 ...
万字长文详解：2023年手机银行MAU和AUM双增实操宝典
随着金融科技不断发展,银行向数字化转型加速推进.近几年,手机银行应用(Application,简称App)逐渐成为商业银行大零售板块各展风采的重要阵地. 截至2022年12月手机银行服务应用活跃人数已 ...
万字长文详解场景金融风险识别与管控
本文围绕场景金融的"三层风险金字塔"风险识别与管控,先对场景金融进行多视角分析,然后从场景"四要素"(流量.数据.交易.信用)入手,进行场景分类(泛场景.浅场景 ...

万字长文详解对账系统设计，推荐收藏