我对账系统

将从以下几个方面进行，每部分都有详细的数据结构解析以及原型：对账的整体概述、对账数据源管理、交易对账、资金对账、余额调节对账、对账引擎、差错处理、对账账务处理、先对账还是先结算等

1.对账概述

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

1.1.对账的定义

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

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

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

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

1.2.对账场景和模型

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

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

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

1.2.1.对账模型

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

图片（1）交易对账模型

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

图片（2）资金对账模型

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

图片（3）余额调节核对

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

图片1.2.2.搭建对账系统

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

可以便捷的获取需要核对的原始数据，如平台数据、渠道数据；可以对文件数据进行解析或者二次加工；可以灵活配置核对规则；可以查看核对的结果；可以对差异进行追踪管理和处理；可以对外提供核对结果；可以对外输出数据。如果要实现一款对账系统，首先应该明确相关的业务模型，其次需要抽象出业务的核对模型，然后针对核对模型选择合适的核对方案，最后针对核对方案设计系统方案、研发、上线、投入使用。

1.3.对账架构图

本部分将提供一个通用的核对架构，可以满足大部分的核对诉求

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

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

只有弄清楚对账的数据关系，才能彻底理解对账系统。

可以用一张图来清晰呈现从源数据出发，历经多种对账操作后所衍生出的结果数据之间的关系。

图片其中比较重要的是两份文件：清算文件、结算文件；四份数据：清算数据、结算数据、平台支付数据、账务数据

图片文件数据一个最关键的参数就是“标识”，以那个标识作为文件的唯一，可以是“商户号+日期”，也可以是“支付通道+日期”

解析出来的数据，至少需要包含核对需要的参数，例如商户订单号、支付类型、金额等

2.对账数据管理

对账离不开原始数据的获取和管理，对账数据主要包括渠道的数据、平台的自有数据，当然也应该包括核对之后的结果数据。

图片如何获取各管理渠道数据，以及平台数据通过什么模式和规则获得，对账结果数据如何存储和查看，是本小节的重点。

2.1.基础数据配置

2.1.1.配置接入的支付渠道方

图片2.1.2.配置接入的支付通道

当对账模式以支付通道为维度进行时，该配置需要用到，如果以账户为维度进行对账，该配置不会被用到

图片2.1.3.资金账户配置

资金账户是支付业务的根基，无论是支付通道、清算文件还是结算文件，余额调节表等，都离不开资金账户，

图片资金账户我们要关注商户号、账号、启用日期、启用余额等关键信息，特别是这个启用日期和启用金额，在资金对账、余额校验表、余额调节表对账都需要用到资金账户的基本信息，尤其是启用日期和期初余额至关重要，需要保证100%准确

图片2.1.4.业务类型配置

业务类型作为对账全局的引用，在交易对账、资金对账等环节的数据解析、存储及核对，均统一使用该处的枚举配置

图片2.1.5.数据获取任务

数据的获取，可以通过渠道的文件申请接口等多种模式获取，需要预先进行任务配置

图片图片图片2.1.6.数据解析配置

每个获取任务，需要关联一个解析规则，通过解析规则将文件数据解析到指定到数据库中

图片图片2.1.7.划付规则配置

因为不用通道签约的结算模式不同，手续费的收取方式不同，因此实际结算到账的时间不同，不用费用项的到账时间和模式也不用，因此需要配置一个划付规则，设定不同账户或者通道的结算规则

图片在配置模式上，可以支持按账户、按文件、按通道等模式配置其资金划付规则，同样在规则配置上可以一次性全业务类型配置，也可以按照单业务类型配置，这适用于该账户某些费用存在特殊结算规则，比如手续费按月汇总收取且走单独的手续费账户等，这种情况下需要单独为手续费配置一个划付规则

图片2.1.8.数据类型、表、存储

在支付经典模式下，平台支付数据payment、渠道清算数据clearing、渠道结算数据settlement为基础数据，以及基于划付规则生成的清结算汇总数据，该数据是资金对账的预加工数据

图片2.2.渠道数据获取与解析

支付交易的通道提供方，例如微信、支付宝、网联、银联等，都是按照约定频率和时间提供交易文件，一般是2份，清算文件和结算文件，其中清算文件记录支付明细，结算文件记录账户的实际资金变动明细。

图片一般可以通过通道方提供的专属接口下载对账文件，如果没有接入下载接口或者通道侧本身就不提供下载接口，可以暂时采用人工下载的方式获得文件，获得文件以后传到对账系统解析出对账数据并存储，以待核对。

2.2.1.对账文件类型

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

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

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

2.2.2.对账文件获取方式

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

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

2.3.自有数据获取与管理

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

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

（1）文件获取

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

（2）接口接收

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

（3）MQ

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

（4）SQL

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

（5）人工上传

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

2.4.对账结果数据

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

首先是交易对账的核对结果，主要是展示平台支付数据与渠道的清算数据之间的差异，或是可以理解为信息流的差异，针对不同支付类型的差异进行差错处理。

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

如何存储核对结果呢？核对结果可以存储在源对账数据的表中，也可以单独存储。

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

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

3.对账项目设计

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

3.1.交易对账项目

主要核对清算数据和平台的支付数据，然后产生核对结果数据，针对结果数据进行差错处理获得了差错数据

图片该模式基础上，可以实现两方数据1v1核对，以及多方数据的111串行、1vN汇总核对、平衡核对等各类的核对模式

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

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

3.1.1.交易对账项目命名

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

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

3.1.2.交易对账项目管理

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

图片3.1.3.交易对账项目新增

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

图片3.1.4.交易对账项目设置

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

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

A方数据为卡数据，数据筛选条件是”交易类型=消耗购买”； B方数据是订单数据，设置以订单号为唯一标识进行核对；订单数据的金额如果存在多条则进行汇总；对账差异的报警接受人，可以填邮件，办公账号等。完成配置后，一个对账项目就配置完成了；对账系统会照着配置的任务时间每天完成订单数据和卡数据关于消耗明细的核对。

3.1.5.更复杂的交易核对模式

当要核对2方以上数据组时，可能会出现111串行、1vN汇总核对、平衡核对等模式，来迎合特殊业务场景的核对逻辑

图片3.2.资金对账项目

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

核对清算数据和结算数据，或者核对平台资金账和渠道的结算账单数据，核对结果生成长短款数据，长短款数据的处理生成核销数据

图片该模式需要对核对的原始数据进行预加工，按照预设维度进行不同程度的分组和分割，该过程需要确保汇总的完成性和准确性，通过设置相应的一个校验模式实现；该模式主要用于资金对账处理

3.2.1.资金对账项目

明白了对账项目的概念以后，接下来要介绍的资金对账项目就容易理解了：一个实体的银行或者收付款账户就是一个资金对账项目，所以说资金对账是按照收付款账户的维度进行核对的。

将一个资金账户设置为一个资金对账项目，比如平台有2个微信收款账户1和2，有两个支付宝收款账户3和4，一个招商对公户5，共5个资金账户，那么就可以设置5个资金对账项目，如下设置：

资金对账项目1：微信账户1；资金对账项目2：微信账户2；资金对账项目3：支付宝账户3；资金对账项目4：支付宝账户4；资金对账项目5：招商对公户5。3.2.2.资金对账项目命名

为了便于管理，还需要为每个对账项目进行命名，如何起名看业务需求或者个人喜好，同交易对账项目命名类似，命名的一个关键原则是要能从名字中看出具体核对的那个账户。基于这个原则为（1)中的几个项目按照“通道方+通道类型+账户号”的命名规则规则进行命名，具体命名如下：

资金对账项目1：微信-收款-账户1；资金对账项目2：微信-收款-账户2；资金对账项目3：支付宝-收款-账户3；资金对账项目4：支付宝-收款-账户4；资金对账项目5：招商对公-收款-公户5 。对账文件管理在前文已经介绍过了，账户方一般会在次日提供相应的清算文件和结算文件，那么文件要跟资金对账项目对应上，通过对账文件命名可以知道对应的所属账户，比如制定这样命名规则：通道方+账号+文件类型+交易日期，按照该规则可以得到资金对账项目1的文件命名：wx-1-pay-20210204。

3.2.3.资金对账项目管理

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

图片设置余额校验表，用于校验结算账单解析的完整性和正确性

图片重点需要说明的是余额表最重要的是获得“各类余额”，其关键数据获取的基本逻辑如下

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

图片3.2.4.资金对账模式选择

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

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

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

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

3.2.5.资金对账项目设置

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

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

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

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

3.3.余额调节对账

该模式主要核对平台资金账与渠道动账的一致性，需要将在途资金进行调整后，核对调整后的双方余额的一致性，并将渠道未达账登记到我方资金账

图片主要是解决平台登记的日末账户余额和银行资金账户日末余额经过未达账调整后的一致性，这里最关键的是要确保资金账户维护的启用余额的准确性

图片4.对账引擎

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

4.1.对账控制

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

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

对账日期：交易成功时间或者资金变动日；对账启用日期：对账项目设定的第一个对账日；最后对账日期：对账项目的最后一次执行对账的日期。然后是对账的状态控制，对账状态即每个对账项目在每一个日期是否执行了对账，已经完成对账的项目不需要重复执行对账，除非需要重对，如图所示是对账状态的管理页面。

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

图片4.2.核心处理引擎

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

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

图片4.3.对账结果管理

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

4.3.1.交易对账结果

交易对账的核对结果，主要是展示平台支付数据与渠道的清算数据之间的差异，或是可以理解为信息流的差异，针对不同支付类型的差异进行差错处理。

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

图片4.3.2.资金对账结果

资金对账结果是某资金账号某交易日的资金收付的一致性核对结果；比较平台的资金账收付结果与银行的收付结果是否一致，或者说是银行自己本身的清算与结算的款项否一致

图片每个对账项目按照费用项核对。从页面中可以看到每个核对账户在该核对日期的每一个款项是否存在差异，并且可以直接查看到该账户关联的交易对账是否存在差异。

图片图片5.差错处理

对账有两个核心目的：一是发现错误，二是改正错误，即处理对账差异。

如果对账结果存在差异，就需要排查差异的原因。

差异的原因可能千奇百怪，但存在必有其原因。如果暂时无法查到具体原因，就先将差异挂起，至少我们已经知道有一个差异待处理。

差错处理是消除差异的过程，主要包括以下几个环节：

发现差异：通过对账发现存在差异；排查原因：深入排查差异的原因，可能是掉单、系统bug、时间差或其他原因；制定处理方案：根据差异原因制定相应的处理方案，如时间差造成的差异可不用立即处理，等待第二天自动对平；消除差异：在对账系统中对差异进行标记处理，说明差异已经得到妥善处理。5.1.差错处理概述

所谓差错，就是与客观事实不符的情况。

那么，什么是客观事实呢？客观事实就是实际发生的情况，比如“交易100元，支付80元，用券20元，且渠道交易成功”，这就是一个客观存在的事实。

如何标记和证明这个客观存在呢？清算文件、我方支付记录、账户动账通知等，都可以作为客观事实发生的依据。这些依据是多方面的，就像打官司时需要多方证据一样。

因此，差错就是指某一处的登记结果与这个客观事实不一致，比如我方记录的交易状态为“处理中”，而实际上交易已经成功完成。

图片可能是状态不一致，银行交易已成功，但我方记录未显示成功；银行有相关数据，而我方却无此数据记录。我们告知商户收款成功了10笔，但商户最后发现只结算了9笔，金额少了1000元。

5.1.1.做差错处理原则

即使面对同一个差错和同一个事实，最终的差错处理方法也可能不同。

例如，前阵子支*宝因“政府补贴”配置错误，导致了大量异常补贴的发放。这与公司的营销事实不符，因此被认定为差错。

在差错处理上，支*宝的做法是：既然是我们的错，我们就承担，不向用户追回。因此，这批补贴差异被处理为“确认损失”的差错类型。

然而，如果换了一家公司，可能会选择向用户追回这笔款项，那么差错类型就会被标记为“向用户追款”。

所以，每一类差错的具体处理方法，取决于公司的制度设定。

5.1.2.差错处理设计

所谓差错处理设计，就是对可能出现的差错情况进行全面列举，并为每一种差错场景设定一个对应的“差错处理类型”。

如下图所示，这是某头部支付机构在交易对账环节所设定的部分差错处理类型，它们按照不同的分组和类型进行了清晰的设置。

图片如上图所示，业务类型分为“支付”和“退款”两种。在支付类型中，又进一步根据是平台单边账还是银行单边账进行细分。对于银行单边账，其在线业务和POS业务的差错处理类型是不同的。

在实际操作中，我们还需要考虑打款、鉴权、垫资等多种业务种类。

5.1.3.差错处理的执行

当出现差错后，我们需要进行差错处理操作，并选择一个差错处理类型，这实际上就是选择了一个标准化的操作流程（SOP）。

每个差错处理类型背后，都对应着一个标准化的处理流程，这个流程的目标是将数据修复成与事实相符的状态。

例如，在支付业务中，如果遇到银行单边账且为在线业务，我们选择“补单”的差错处理类型，那么系统就会调用交易核心的补单接口，修复订单状态，将其改为“成功”。

图片同时，在进行差错处理时，我们还需要考虑账务的处理方式。如上文所示，银行单边凭证和平台补单凭证属于逆向凭证，处理流程通常是先单边挂账，再进行补单核销。

5.2.账务类差错处理

即平台在支付记录登记账务时出现了错误，具体表现为多记或少记了。

例如，用户充值成功后，系统未能成功记账，导致用户在钱包中看不到余额增加；或者商户收到的对账单与实际收单账户余额变化不一致等。

5.2.1.划线更正法

在结账前，如果发现账簿记录中存在文字或数字错误，而记账凭证本身无误，应采用划线更正法进行更正。

更正时，需在错误的文字或数字上划一条红线，然后在红线上方填写正确的文字或数字。更正完成后，需由记账人员和会计机构负责人在更正处盖章，以明确责任。

5.2.2.红字更正法

记账后，若发现记账凭证中应借、应贷的会计科目有误，导致记账错误，应采用红字冲销法。即用红字填写一张与原凭证相同的凭证，摘要栏注明“冲销XXX凭证”，然后再用蓝字填写一张正确的凭证。

若记账后发现凭证和账簿中应借、应贷科目无误，只是所记金额大于应记金额，同样采用红字冲销法。即用红字填写一张多记金额的相同凭证，摘要栏注明“冲销XXX多记金额”。

5.2.3.补充登记法

记账后发现记账凭证和账簿记录中的科目无误，但所记金额小于应记金额时，应采用补充登记法进行更正。

即按少记的金额，用蓝字填制一张与原始凭证及记账凭证应借应贷科目完全相同的记账凭证，摘要栏写明“补记XXXX记账凭证少记金额”。

5.3.交易类差错处理

交易对账模型是指通过唯一标识将交易数据之间进行一对一、一对多或多对多的核对，以验证业务的一致性和准确性。

图片交易对账的结果主要体现为单边账和错账。

图片对于具体的差错处理，需根据支付类型（如线上支付、线下支付、退款、打款、打款退回、退票等）的不同，按照公司相关制度进行相应设定。

图片下图是对出来的单边账。

图片根据实际排查结果，对差错进行处理

图片差错处理执行以后，会得到差错处理记录

图片5.4.资金类差错处理

资金对账模型是将交易数据按照款项类型（如收款、手续费等）进行汇总，然后进行核对的过程。

图片资金对账的结果可能表现为长短款，即收单结算金额少于应收金额，或者错误地对外支付了不应支付的款项，又或者应该退还的款项没有成功退还等。

对于资金对账中的差错处理，主要是对长短款进行核销，并根据具体情况确认是收入、损失，还是需要通过向银行或客户追回等方式进行处理。

图片点击“核销”按钮，可对该笔差异进行核销处理。在弹出的窗口中，选择相应的核销类型，并输入本次要核销的金额。同时，也可选择与前期其他差异进行双边核销，具体操作如图所示。

图片长短款差异产生的同时，会相应生成一笔挂账凭证，以确保账务的平衡。随后，我们需要对每笔资金差异进行排查并核销。

例如，如果确认是人工通过微信进行了转账，那么可以直接核销“资金人工转入确认”项。如此操作，直至所有长短款均完成核销，资金即达到准确状态。每笔核销操作均需生成核销记录，具体如图所示。

图片5.5.差错处理的账务处理

对账的本质是发现与实际不相符的登记，而不相符本身也是一项“账务”，即挂账，挂在过渡账户中，所以对出差异要记账，这里就选取《清结算的全局实现原理》中的跟挂账相关的部分，如下所示，分别是“结算挂账”“支付挂账”“资金挂账”

图片图片图片那么，差错处理就是对挂账的消除，因此，进行差错处理也要记账

图片对账系统需要在某些场景下向账务系统推送记账数据，登记指定的记账类型，完成记账，比如交易差错处理记账、渠道清结算数据的记账、资金挂账与核销的记账等

图片在配置中需要设定场景、数据类型、触发事件、记账协议以及记账的模式；与账务的交互关系可以参考下图

图片6.先对账还是先结算

最后聊一个实际问题：究竟是先对账呢？还是先结算呢？

我们就借一个小案例，聊聊这个门道，重点不是“方案结果”而是“策略方法”，你用了什么思维方法比你做成了什么样更重要！

6.1.一个刁钻需求

一位朋友跟我聊了一个她当前面临的“刁钻需求”，之所以说“刁钻”，是因为她觉得不该做，但是又被需求方骚扰的实在受不了，不尽其烦，但是又没有足够的理论支撑和办法去说服和拒绝需求方

这是工作中常见的困境，不想做，又没足够的论据去拒绝，做吧，又感觉会掉坑里

其实，能做与不能做，怎么做，做成什么样，都随着“价值观”的改变而改变，做就推出做的价值观，不能做就表达不能做的价值观，你说不能做，我看他能做！

不要太纠结于方案，而是想明白你的“产品价值观”

6.2.需求背景与分析

她的场景是这样的，她们是一家银行，做收单业务，当前给商户的结算是根据成功的订单，但是经常出现长款，也就是清算机构清给他们的多，但是给商户结算的少

这里有很多原因，比如因为自己系统不稳定造成的平台掉单

出了长款怎么办呢？她们财务就给商户补款，补来补去，烦了，非得要求他们做一套对账体系，而且是“先对账，再结算，给商户结算准确的渠道清算结果”

这个需求初看没什么问题，再一看好像还是没问题；不过在场的很多人都觉得有问题，大家觉得对账肯定要对，但与渠道的对账不应该影响给商户的结算

单挖问题的本质，其实是银行系统不稳定造成的，并不是对不对账造成的，如果要治本的话，应该优化收单系统，但是，这也不是一朝一夕就能解决的，需要很长一个过程

财务头疼头医头也可以理解，但是即使对账上了也会带来新的问题和风险，比如对账做的不好，到了给商户结算的时间点时依然没有完成对账的全部处理，你说要不要结算？

结吧，账还没对，不结吧，商户能答应么？商户会骂娘么？为什么你们银行总是不能按点结算呢？

不做也不是，做也不是，该如何是好

究竟该不该先对再结呢？一般情况下并不建议这么做，对和结还是要独立分开，避免与上游渠道的纠缠影响与下游商户的良好关系

但是，对于银行来说，你老是结错，每次都给我补账，是不是你们不行啊！其实丢钱是小事，商户对你失去信任是大事，特别是银行，信用比天大

特事特办，既然现阶段咱系统不是很强，那就不能中规中矩，必须出奇制胜，捡走偏门，咱就先对再结算，这样，不就保住面子了么

话说面子都是自己挣的，你先对再结，如果不能按点结算，不照样丢人吗？

这就是上面这位小姐姐的困境，做也不是，不做也不是

不过在我看来，困境还有另外一层，做，好像是财务逼你做的，并不是你的初衷，，等再换一波财务就可能觉得“你怎么能先对再结呢？”，你不就掉坑里了么

需求可以做，但不能为“某个部门做”，不能因为她强势你就做，不然，回旋镖早晚会打到自己，所以，我们一定要将价值，转换到公司价值层面，这样，不会因为团队变化而峰回路转

那么怎么把“先对再结”转换到公司价值上，得到一个无法被拒绝的理由，而值得去做呢？我们要从痛点出发

一痛：业务痛

收单登记总是不准，总是有长款，我们需要能够及时发现并调整长款，所以，我们需要对账，确保平台的收单记录准确

二痛：商户痛

对商户来说需要给我结算的准确，不能总是调账，不然我跟你合作心里不踏实，我们自家的账也得跟着你不断地调，不仅要准确，还得按时，不然就太难受了

三痛：银行痛

而银行自己呢？就是“面子”，面子上挂不住啊，信用受损，品牌力受到影响，无论是结算的不准确还是结算的不及时，都会伤面子

以上三痛，就是“数据准确、商户体验、银行形象”，三个方面的痛，要想解决所有痛点，皆大欢喜就需要

通过对账确保数据准确，但又不能影响商户按时结算，从而维护银行形象

先对再结，虽然结算准确，但有可能不能按时结算，进而影响商户体验，损害银行形象；如果不对就结，虽然结算及时，那就会结算的不准确，也会损害银行形象

6.3.方案设计思路

这也不是，那也不是，难道就没有解法了么，肯定有，价值百万的方案来了：即能确保数据准确，又能确保按时结算，同时还能让银行保住面子

图片为了数据准确，我们要先对再结；为了结算及时，我们要预留阈值，到点结算，也就是到点你对不完，不好意思，我先结为敬

图片这个方案另一个妙处是，不一口吃成个胖子，也不躺平做咸鱼

有多大能力，解决多大的问题，能解决多少解决多少，先对起来，确保结算准确；但是早期对账能力不强，我们还保留原有结算模式，确保按时结算，但是我们要不断的提升对账能力，逐渐降低超过结算时间而对不完的发生概率，直至100%的结算是“先对再结”

等到有一天，我们的收单系统能力提升了，能做到100%准确，那么再“对·结分离”

合为了更好，分也是为了更好，只不过，在不同的时间，有不同的选择

所以，先对账还是先结算，建议对账与结算“既关联又独立”的灵活关系，审时度势，根据局势而变——可串行联动也可并行协同，但要以业务目标为导向，保钱还是保体验，还是都保；产研能力强还是弱，当前什么最重要

总之，我们不是要给一个结果，而是一个态度，从态度中彰显手段；我们不是要做正确的选择，而是最合适的选择

啥是最合适的选择，你好、我好、公司好！