一文搞懂“对账系统”

账目核算是财务工作的必要部分，随着线上交易体量越来越大或者说对财务自动化线上化的效率提升需求越来越高，为了提升核对效率以及准确性，要将核对业务系统化、线上化、自动化。如何构建设计一套不同业务场景下的对账系统是本文的重点。

1.对账概述

日常生活中每天都在对账，比如去餐馆吃饭付款，会对老板说一声“老板，钱付过去了”，老板检查收款情况或者听到语音播报后回复一声“好嘞，下次再来”，这就是一次最简单的对账。再比如在淘宝开了一个店铺，每个月几千单的交易、发货；次月末都拿着所有的订单明细和支付宝收款记录逐笔做一次核对，保证发过货的订单都收到款了，这是一次更复杂的核对。

1.1对账的定义

对账就是“账证实”的核对，“账”是账目，“证”是凭证，“实”是实际资金或者商品。常见的核对模式有三种：账证核对、账账核对、账实核对，确保账证实两两的一致性。如在饭馆吃了一碗面，其中点菜单就是原始凭“证”，付了10元钱是“账”，老板电脑记录10元是“账”，老板看到账户中余额增加了10元是“实”。

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

从广义的时间看核对一致性，核对的就是数据，其中包括商品数据、用户数据、卡券数据等。财务范畴的账证实需要核对，而非财务范畴数据也需要核对，比如今天应到10人实到8人，军训时的报数等其实也可以称为对账，我们暂且称为“广义的对账”。

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

为什么要对账呢？首先在财务范畴，这是一个必要做的工作；其次，从业务视角看，如今的交易链条越来越长，数据在众多系统之间难免会出现丢失或者差错的情况，所以为了业务的正常运转并及时发现问题，需要确保系统间数据的一致性。最后，从公司的角度看，需要确保“不少收一分钱，不多付一分钱”，保证资金的安全，不然卖了多少货，收了多少钱相互之间无法自洽，最后全是糊涂账。

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

1.2对账场景和模型

常见的对账场景包括三方支付公司内的对账、电商平台内部的对账、金融及清算机构等机构内部的核对等，其中：

三方支付公司的对账：主要是核对自家的交易记录和银行清算数据之间的一致性；

银行清算数据（应收应付）和银行结算数据（实收实付）的一致性；

同样也要核对与账务系统数据的一致性。电商等服务平台的对账：主要是核对自家的交易数据和三方支付公司的清算数据的一致性；三方清算和结算的一致性；三方机构结算到企业对公户的资金的一致性。

（1）对账模型

对账模型根据核对的数据种类以及核对模式的不同可以分为交易对账、资金对账、余额调节对账、其他对账等，其中：

交易对账模型：交易数据之间通过唯一标识进行一对一、一对多、多对多核对业务；

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

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

（2）搭建对账系统

对账系统是通过系统解决方案，对需要核对的数据按着设定好的规则进行核对校验，产出核对结果，并对核对结果进行对应的差错处理的自动化信息系统。通俗来说就是将人工核对数据一致性的事情交给系统去做，只需要预先配置好各项规则即可。对账系统应具备以下基础能力：

• 可以便捷的获取需要核对的原始数据，如平台数据、渠道数据；
• 可以对文件数据进行解析或者二次加工；
• 可以灵活配置核对规则；
• 可以查看核对的结果；
• 可以对差异进行追踪管理和处理；
• 可以对外提供核对结果；
• 可以对外输出数据。

如果要实现一款对账系统，首先应该明确相关的业务模型，其次需要抽象出业务的核对模型，然后针对核对模型选择合适的核对方案，最后针对核对方案设计系统方案、研发、上线、投入使用。

1.3对账架构图

本部分将提供一个通用的核对架构，可以满足大部分的核对诉求，如图1所示。

图1 对账系统业务架构图

整个架构图包括左中右三大部分，左部分位业务系统层，为平台的内部数据，例如订单数据、交易数据、卡券数据、支付数据等；右部分为外部渠道层，为外部支付数据，例如三方支付渠道的清算数据和结算数据；中间部分为对账系统层，核心职能就是完成左右两部分数据在何种模型下的核对业务，包括数据管理、数据解析、交易核对、资金核对、核对结果管理等一系列的能力，整个核对业务主流程如下：

• 按核对频率获取业务支付数据；
• T+1或其他频率获取三方清算文件和结算文件；
• 将清算和结算文件进行解析存储；
• 根据对账项目配置完成交易数据和清算的核对；
• 完成清算数据和结算数据的核对；
• 对交易的单边数据和资金核对差异进行管理和处理。

2.对账数据管理

对账离不开原始数据的获取和管理，对账数据主要包括渠道的数据、平台的自有数据，当然也应该包括核对之后的结果数据。如何获取个管理渠道数据，以及平台数据通过什么模式和规则获得，对账结果数据如何存储和查看，是本小节的重点。

2.1渠道数据获取与解析

支付交易的通道提供方，例如微信、支付宝、网联、银联等，都是按照约定频率和时间提供交易文件，一般是2份，清算文件和结算文件，其中清算文件记录支付明细，结算文件记录账户的实际资金变动明细。一般可以通过通道方提供的专属接口下载对账文件，如果没有接入下载接口或者通道侧本身就不提供下载接口，可以暂时采用人工下载的方式获得文件，获得文件以后传到对账系统解析出对账数据并存储，以待核对。

（1）对账文件类型

主流文件类型以Excel和txt为主，其中Excel是常见的文件类型，这种类型的文件阅读性强，如图2所示，为从支付宝后台下载的结算文件。

图2 Excel类型的对账文件

某些通会提供Txt格式的对账文件，这种类型的对账文件阅读性比较差，数据列的分割符种类也比较多，在文件解析时存在一定难度，如图3所示。

图4 txt格式的对账文件

还存在一些其他格式的文件，例如xml报文格式、csv格式、pdf格式等。无论什么格式的对账文件，核心用途都是为了获得交易数据进行核对。

（2）对账文件获取方式

常见的获取渠道对账文件的方式是通过接口，通过机构提供的文件查询和下载接口获取对账文件，如图5、6所示，是从支付宝开放平台截取的对账文件下载接口示例。

图5 对账文件获取接口的请求参数 图6 对账文件获取接口的返回参数

同样可以通过人工下载的方式获得对账文件，如果技术能力资源不足，或者暂时没有接入接口，可以采用人工下载的方式，然后将文件上传至对账中心，通过解析文件生成系统需要的数据。

（3）对账文件管理

从渠道获取到的文件一般存放在对账系统指定的ftp内，并对文件或者文件夹按照命名规范进行命名，通过文件路径查询和下载该文件，如图7所示。

图7 对账文件管理

（4）对账文件解析器配置

对账文件解析是指将文件里的数据进行处理，转换成数据库数据，以某种形式存储在数据库内，因为文件数据不能直接被系统读取，文件解析模式有原样解析和通用模板解析。

原样解析是不改变文件的数据列数和内容，在不减少文件数据列数的情况下原汁原味的把数据解析出来，可以根据需要增加列内容，比如账号、对账时间等。该种解析方法有以下的优缺点和适用性。

• 优点：不需要配置解析器，每一个文件研发好固定的解析器进行复用；
• 缺点：每个文件类型需要建一套数据表，维护成本高；
• 适用：通道少的平台，一般的商户都仅有微信、支付宝，可以采用原样解析。

通用板式解析是将所有对账文件数据按照映射关系解析到固定的数据表中，例如表1的表结构所示，所有的文件解析以后都要存储在这张表里，表字段是固定的，文件中的数据怎么对应的存储到指定字段上，是该种解析模式最关键的地方。

表1 存储对账数据表

例如图8中所示的是某对账文件中的部分数据，如何配置一个规则将这些数据解析到表1中？

图8 示例对账文件数据

可以设定如表2中所示的解析规则，根据该规则可以将图8中的数据解析到表1中，表中第一行的规则的含义是将图8中的A列数据解析到表1中的“支付时间”字段上，第二行的含义是将图8中F列值为“收入”的数据行解析到表1的“金额”字段上，单位是元。

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

（5）对账数据查看

数据解析到数据库里以后，为了便于排查问题直接查看数据或者其他用途，还需要提供查看数据的后台工具，分别按照数据类型展示相应的数据，例如平台的支付数据、微信的清算数据、微信的结算数据、支付宝的清算数据、支付宝的结算数据、易宝支付的付款数据等，如图9所示是平台业务数据的后台页面。

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

2.2自有数据获取与管理

获得渠道文件账单数据以后需要将其与平台自己的相关数据做核对，如平台的交易数据与清算数据做核对，平台账务数据与银行账单数据做核对。

（1）平台对账数据获取方式

平台自有数据的获取方式常采用如下形式：

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

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

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

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

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

（2）数据分类管理

随着业务的发展，对账系统数据会越来越多，类型也越来越多，包括支付数据、卡券数据、订单数据、三方清算数据、三方结算数据等；每类数据的数据字段有各有不同，如何对众多类型的数据进行管理呢？可以对数据进行分类管理，每类数据单独设置表结构。

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

图10 数据分类设置

然后设置数据子类，在数据分类下面设置数据的子类，并将数据子类关联到数据库表，便于存储数据，查询数据，对账取数，如图11所示。

图11 数据子分类设置

（3）取数规则配置

配置好了数据分类和类型并关联好了数据表之后，接下来就是配置获取数据的规则了，以通过文件或者SQL两种获取数据的形式为例，如图12所示。

图12 取数规则设置

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

2.3对账数据管理

支付数据与三方清算的核对，或者其他数据的两两核对，会得到核对结果，且每一组核对都会有一个组别的名字，这一部分会在下一节详细介绍。

首先是交易对账的核对结果，主要是展示平台支付数据与渠道的清算数据之间的差异，或是可以理解为信息流的差异，如表3所示的案例数据。

表3 交易对账结果示例

上表中“1、5、6”这三条记录是有问题的，第1、5条数据是一方有一方没有，第6条是双方都有数据但金额不一致，这就是交易对账结果，一般有“对平、单边、错账”三种核对结果，对于核对存在问题的数据需要进行排查找出差异的原因，并进行差错处理。

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

表4 资金对账结果示例

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

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

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

存储在单独的对账表这种方式适合复杂的核对场景，同一份数据会在多个对账项目中与多组数据完成核对，产生多个对账结果，比如支付数据与上游的订单进行核对得出一个对账结果，支付数据又会与下游的清算数据核对得出另一个对账结果。此时支付数据的对账结果有2个，一个是与订单的核对的结果，另一个是与清算的核对的结果，这种情况，对账结果就需要单独存储“某数据在每一个对账项目组中的核对结果表”。

3.对账项目设计

业务总是在不断变化，新的业务也在不断出现，对账数据也会因为业务的变化发生变化，当接入了新的支付渠道对账设置也需要新增，如果每次都通过研发实现，那么产研成本会很高，本部分将介绍如何实现交易对账及资金对账的对账项目的配置化设计，会极大提升对账项目的管理效率。

3.1.交易对账项目

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

• 对账项目1：微信1-收款
• 对账项目2：微信1-退款
• 对账项目3：微信2-收款
• 对账项目4：微信2-退款

对账项目是按照一定维度设定的核对组，如果上述的4个核对项目组仅按照收付方向分组还可以简化成2个核对项目组，如下所示：

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

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

（1）对账项目命名

为了便于管理还需要为每个对账项目命个名字，如何起名也看自己喜好。比如，如果对账组的同学都是女生，都是吃货，因此所有对账项目的名称都可以跟吃相关，如工商9876-卤煮火烧，命名的一个关键原则是要能从名字中看出具体核对的是什么业务。基于这个原则为开头的几个项目起一个如下的名字：

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

通过对账项目的名称便可以清晰的知道对账项目1是会员购买的收款核对项目，对账项目2是会员购买退款的核对项目。

（2）对账项目管理

一个企业可能会存在很多个对账项目，有的甚至高达几百个核对项目。为了便于管理，就需要一个菜单专门管理对账项目，该页面可以查看所有的对账项目；点击设置可以进行该对账项目的配置；右上角的新增可以新增项目，如图13所示。

     图13 交易对账项目管理

（3）对账项目新增

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

图14 对账项目新增

（4）对账项目设置

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

从页面可以看出来，该配置是设置卡系统的消耗数据与订单中的消耗记录进行核对，为数据两方配置了如下的数据选择条件：

• A方数据为卡数据，数据筛选条件是”交易类型=消耗购买”；
• B方数据是订单数据，设置以订单号为唯一标识进行核对；
• 订单数据的金额如果存在多条则进行汇总；
• 对账差异的报警接受人，可以填邮件，办公账号等。

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

         图15 交易对账项目设置

3.2资金对账项目

线上支付完成以后，虽然通道方已经返回支付成功，但是钱最终是不是能正确结算，还需要打一个问号，资金对账就是应收应付和实收实付之间的核对，其中应收应付就是交易记录所记录的成功交易，而实收实付就是收款账户实际的资金入账。

（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的文件命名：wx-1-pay-20210204。

（3）对账项目管理

一个企业可能存在多个资金账户，为了便于管理，就需要一个菜单专门管理资金对账项目，该页面可以进行对账项目的新增、配置、修改等一系列的操作，如图16所示。

图16 资金对账项目管理

点击右上角的新增可以新增资金对账项目，要填写的信息如图17所示，包括账户名称、关联的交易对账编号、对账起始时间、对账类型、对账频率等基本信息，配置好基本信息以后确定新增即可增加一个对账项目，然后通过设置进行资金对账项目规则的配置。

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

（4）资金对账模式选择

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

使用银行清算文件做为应收应付的数据源有个缺陷，就是平台的支付记录需要跟银行的清算文件进行核对确保没有差异，然后确保清算文件和结算文件之间的核对没有差异，核对模型的实现如图18所示。 图18 资金对账业务模式

在新增对账项目时需要关联交易对账，目的就是看一下平台的支付记录和清算文件之间的核对有没有差异，如果没有且资金对账没差异，那么整个对账就没有问题了。

交易对账是按照交易明细进行逐笔核对的，而资金对账并不按照资金明细进行逐笔核对，因为存在轧差以及线下汇入等情况，资金对账需要按照费用维度进行核对，也就是将应收应付和实收实付数据解析成费用项的汇总，对相同款项进行核对，其中的费用项如收款、收款手续费、退款、退款手续费、打款等。

（6）对账项目设置以核对清算数据和结算数据为例，资金对账项目设置就是设置如何将文件里的数据解析汇总到对应的款项上去的解析规则，将一个资金账户在某一个交易日的资金变动明细进行汇总，得到每一个款项的变动金额，该配置设置如图19所示。

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

从页面可以看的出来，该配置中的每一个费用项的配置规则就是将文件里的数据先通过该费用项的“条件组”进行筛选获得属于该费用项的数据，然后取目标数据的金额，并且对金额进行运算汇总。比如例子中的第一条就是：取交易状态=success的数据，取订单金额作为结算金额，如表10-5所示为一部分案例数据。

通过原型中的配置条件组“交易状态=success”，金额配置“正直汇总  订单金额”，可以得到收款=100+90=190。

表5 对账文件部分数据

其他费用的配置逻辑类似，一定要枚举一个资金账户里的每一类费用，不能遗漏，不然会出现资金差异。如此全部配置完成以后，一个资金对账项目就配置完成了，对账系统会按照配置的时间进行账单的解析，得到资金对账所需要的核对源数据。

4.对账引擎

在执行对账前还有几个重要的问题没有解决，即对账的核心处理逻辑，例如对账的连续性控制、时间控制、状态控制、对账核心逻辑、对账结果查看等。

4.1对账控制

首先是对账的连续性控制，对账不能跨日，如2号对完才能对3号，如果今天是10号，2号还没对账，那么3至9号的账都不会核对，因为前一天的核对结果会循影响下一天的核对结果，这种控制如图20所示。

图20 对账连续性的控制

其次是对账的时间控制，如图10-20所示，系统内需要维护对账的相关时间，主要是对账日期、对账启用日期、最后对账日期，他们的含义如下：

• 对账日期：交易成功时间或者资金变动日；
• 对账启用日期：对账项目设定的第一个对账日；
• 最后对账日期：对账项目的最后一次执行对账的日期。

然后是对账的状态控制，对账状态即每个对账项目在每一个日期是否执行了对账，已经完成对账的项目不需要重复执行对账，除非需要重对，如图21所示是对账状态的管理页面。

图21 对账状态管理

最后是对账任务流的控制，控制对账项目的任务执行，并在流程中更新其他环节的相应参数。如果主流程的某一个处理关节失败了，那么应该进行任务报警，人工干预重启核对流程，控制流程如图22所示。 图22 对账流程控制

4.2核心处理引擎

对账最核心的流程就是对账执行流程，实现数据间的逐笔核对的过程，如图23所示。本逻辑流程主要包含三大核心逻辑：实现每一天都完成核对，实现每天的每一个对账项目都完成核对，实现每一个对账项目的每一条数据都进行了核对。并且产出每条数据的核对结果，是对平、单边、还是错账。     图23 交易对账逻辑

举个例子，经过上面的逻辑处理，对账项目1在x日的对账结果如表6所示，其中单号2是对平，单号1和4是单边，单号3是错账。

表6 对账结果示例

4.3对账结果

通过上面的对账执行，就得到了每一个对账项目的对账结果，包括每个对账项目的对账总笔数、总差异。对账结果包括交易对账结果和资金对账结果2类。

交易对账结果是交易对账项目执行对账之后得到的结果，每个对账项目按笔数核对，如图24所示。从页面中可以看到每个交易对账项目的核对日期、总笔数、单边数、错账数、待处理数等，并且可以查看该对账项目在该核对日期的平台明细数据和清算明细数据。

图24 交易对账结果查看

资金对账结果是资金对账项目执行对账之后得到的结果，每个对账项目按照费用项核对，如图25所示。从页面中可以看到每个核对账户在该核对日期的每一个款项是否存在差异，并且可以直接查看到该账户关联的交易对账是否存在差异。

  图25 资金对账结果查看

5.差错处理

对账有两个核心目的，一个是发现错误，另一个是改正错误，即对账差异的处理。对账结果如果有差异，就需要有排查差异的原因，差异原因千奇百怪，但存在必是有原因的，如果暂时查不到具体原因就先挂着，至少我们知道了有一个差异待处理。

差错处理就是消除差异的过程，主要包括发现差异、排查原因、处理方案制定、消除差异等环节：

• 发现差异：对账对出了差异；
• 排查原因：排查差异原因，是掉单了、bug、时间差还是其他原因；
• 处理方案：制定差异处理方案，如时间差造成的不用处理，等待第二天对平；
• 消除差异：这一步是在对账系统对差异进行标记处理，说明差异已经处理完成了。

5.1交易差错处理

交易对账是交易数据的逐笔核对，会出现对平、单边、错账等三类结果。对账的差异会单独出现在差异列表等待处理，如图26所示。

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

点击处理，在弹窗中选择处理类型，提交之后可以走一个设定好的流程，也可以直接处理完成，如图27所示。
图27 差错处理操作弹窗

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

有些差错处理可以实现自动化，让相关系统包装接口直接进行调用处理，比如平台补单可以让订单系统包装一个补单接口，对账系统直接调用进行补单。

图28 差错类型管理

5.2资金差错处理

资金对账的差异是费用的差异，即收款、退款、手续费等于平台记录的不一致。资金核对完成得出结果后，如果不是解析等技术层面的差异，可以对结果进行一个确认，确认之后差异会生成长短款数据，后面对长短款进行排查原因、进行核销。资金对账结果详情页面如图29所示。

图29 资金对账结果详情

什么是长短款呢？比如微信的一个资金账户，资金同事直接在微信商户后台操作了一笔转账，或者用户直接用微信转账100元给了这个账户，这时候就会出现微信收款比平台记录收款多的情况，即微信账单的收款总额比平台的记账总额多100元，资金对账就会发现这100元的长款，就是渠道多收了。但经过排查是可以找到这个具体原因的，本质上是平台没有获得这笔转账数据，也就无法记录，通过排查可以操作核销差异。

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

图30 长短款核销管理

点击核销可以对该笔差异进行核销处理，在弹窗里选择相应的核销类型，本次要核销的金额，同时也可以选择与前期其他差异进行双边核销，如图31所示。

图31 长短款核销处理弹窗

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

           图32 核销记录

6.坑位解析器

获取文件并解析文件是对账系统非常重要的环节，也是后续进行对账的基础。因此，解析文件是对账系统设计中非常核心的一部分，上文中所采用的是原样解析文件数据，本小节将提供另一种解析模式做为补充。为什么叫坑位解析器呢，因为本模型的数据库表是固定的，而是将文件数据按照对应关系解析到固定的字段上去。

对账所需要解析的文件主要有三类：平台的支付数据、渠道的清算数据、渠道的结算数据，其中，平台数据可以通过SQL、MQ、接口、文件等形式获取，而渠道文件一般会通过接口获取，或者人工下载文件以后导入到对账系统内，如图33所示。 图33 坑位解析器模型

交易对账主要核对平台的支付数据记录与渠道下发的清算文件中的记录的一致性，而平台数据可以通过SQL获得，而清算数据可以通过接口获得，获得文件以后进行解析，对账项目、文件、解析器之间的关系如图34所示。

图34 解析器关联关系

一个对账项目的解析器和清算文件是绑定关系，这样就意味着该对账项目的清算文件是由该对账项目绑定的解析器所设置的规则进行解析。如何设计配置工具呢？如图35所示是某支付渠道的清算文件示例。

图35 清算文件示例

文件中的商户订单号是平台的请求唯一单号，也是渠道数据与平台数据进行核对的唯一标识，所以要解析出来，另外的交易状态代表了退款和支付类型，后面还有金额等对账需要的字段都需要解析出来。如何设置将这些字段解析到数据库表中的规则，就需要用到如下的配置工具，如图36所示。

图36 解析器配置页面

其中基础配置是配置该解析规则的基础信息，主要配置实现“我们需要哪些数据”，比如解析器的编号，所属对账项目，文件的格式、编码等内容。过滤字段设置的是“哪些数据不要”，比如示例中的含义就是通过文件中的第9列和第10列进行过滤，第9列是“未知、失败”或者第10列是“01”的数据不需要进行解析。数据开始行的用途是指定从哪一行开始解析，因为有些渠道的文件开头有表头或者有些统计类信息不需要解析，应该刨除掉，如图37所示的文件就应该填“6”，从第6行数据开始解析，前5行数据不需要。数据列数的配置用途其实也是用于设定解析哪些数据，可以跟“数据开始行”的配置同时使用，属于加强条件，比如填写了“12”，就代表只解析哪些有12个字段的数据行。

图37 结算数据示例

然后是解析规则的配置，这部分是规则部分，主要是配置文件中的“数据如何放到数据表里”的问题。配置一共有3列：第一列是数据库表的固定字段，例如银行订单号、交易类型、卡类型等；第二列是字段位置，也就是这个字段取文件中那一列的数据，比如原型中银行订单号填写的是1，就是将文件中的第一列解析到银行订单号；第三列是说明文件中的数据格式、单位或者数值。

需要强调的是，整个规则配置主要可以分3大类：

第一类是取数型配置，如银行订单号等，只需要填写数据列“数”即可，不需要配置格式、单位、数值，直接将文件中的数据取过来即可。

第二类是映射型配置，如交易类型、卡类型，二者在数据库里是固定的枚举值，分别是“支付、退款”、“借记卡、贷记卡”，原型示例的配置含义是卡类型根据第“13”列判断，如果是01则代表借记卡、02代表贷记卡，解析到数据库里时，卡类型字段会设置成“借记卡”或者“贷记卡”，而不是文件中的数值；同样原型中的交易类型字段，由第“10”列决定，当是“S13、S22、S23、S36、S37、S46、S54、S56、S64”时代表支付，当是“REFUND”时代表退款。

第三类是单位和格式型配置，比如原型中的金额需要配置文件中是什么单位，时间要配置说明文件中的时间格式是什么。