对账系统从入门到精通

想必大家对“对账”这个词都不陌生，单从字面意思就能略知一二。其实就是字面意思，“对”就是核对，“账”就是账目；“对账”就是核对账目。

账目核算是财务工作的必要部分，随着线上交易体量越来越大或者说对财务自动化线上化的效率提升需求越来越高。为了提升核对效率以及准确性，势必要将核对业务系统化线上化自动化。那么如何构建设计一套不同业务场景下的对账系统呢？接下来的“对账系统设计”十个章节将带领大家学习如何设计一个对账系统。

全文分十个部分，共13596字，预计阅读时间20分钟

第一部分：对账概述

1.1 生活中的对账

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

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

1.2 什么是对账

1. 对账概括来说就是“账证实”核对，“账”就是账目，“证”就是凭证，“实”就是实际资金
2. 核对模式有三种：账证核对，账账核对，账实核对；确保账证实两两的一致性；比如吃了一碗面点菜单就是原始凭“证”，付了10元钱是“账”，老板电脑点菜记录小票10元是“账”，老板看到账户中余额增加了10元是“实”
3. 财务范畴来看，证就是会计凭证，比如发票，小票，出货单，收据，交易系统的支付记录等都是原始凭证；而账呢就是财务的账目，账务系统的账务记账，金蝶的科目余额等都是不同的账目；而一笔交易会记录在很多的环节，比如账务系统，金蝶等
4. 另外脱离财务范畴来看，其实账目本身抽象出来就是数据，商品数据，用户数据，卡券数据等，那么账证实需要核对，很多时候很多非财务范畴数据也需要核对，比如今天应到10人实到8人，军训时的报数等其实也可以称为对账，我们暂且称为“广义的对账”
5. 那么我们来为对账下一个定义：为了确保同一个事务的数据描述在不同场所下的记录一致而进行的相互之间的一致性比对

1.3 为什么要对账

1. 首先在财务范畴，这是一个必要做的工作
2. 另外从业务范畴，现在交易链条越来越长，数据在众多系统之间难免会出现丢失或者差错，所以为了业务的正常运转及时发现问题，需要确保系统间数据的一致性
3. 从公司的角度，需要确保“不少收一分钱，不多付一分钱”，保证资金的安全，不然卖了多少货，收了多少钱相互之间谁也不鸟谁，最后全是糊涂账
4. 综上所述，对账是必不可少的；对于交易体量巨大的互联网公司更是必不可少，而且系统化也是必须的，单靠人工难以满足需要

1.4 几个常见对账场景

1. 三方支付公司：主要是核对自家的交易记录和银行清算数据之间的一致性；银行清算数据（应收应付）和银行结算数据（实收实付）的一致性；同样也要核对与金蝶账务数据的一致性
2. 电商等服务平台：主要是核对自家的交易数据和三方支付公司或者微信支付宝的清算数据的一致性；三方清算和结算的一致性；三方结算到对公户实际资金的一致性
3. 另外还有红包：比如用户支付100元发10个红包，有6个用户领了6个一共8元，有4个超时没领退回给了用户；那么对于平台的这个红包中间账户的进出也要核对：{ 用户充值1笔100元中间户入了1笔100元中间户出了10笔100元中间户被退回4笔2元中间户退给用户1笔2元这样对于中间户来说100-100+2-2=0 }
4. 还有一些其他的领域对账，比如航司的机票，机票代理商的购票出票，中间券商的上下游之间等等

1.5 常见的对账模型

1. 交易对账模型：数据之间的按照唯一标识进行一对一，一对多，多对多核对
2. 资金对账模型：将交易数据按照款项类型进行汇总之后进行核对，比如收款，手续费
3. 余额调节核对：对系统记账余额和实际资金账户余额在经过在途调整后进行一致性核对比如：系统记账昨日日终余额100元，截止昨日日终提现中100元；出款账户昨日日终200元；此时该账户：系统账100元=出款账户200元-100元应付未付；这样余额是平的，说明资金没有问题
4. 其他更复杂的核对模型：比如多链条之间进行关联核对像三份数据进行一次性比对等，这里不再过多阐述；本系列文章重点介绍的是1和2,至于3会在今后有机会讲解，如果有朋友感兴趣可以单独交流

1.6 什么是对账系统

1. 对账系统就是通过系统解决方案，对需要核对的数据按着设定好的规则进行核对校验，并产出核对结果；并且可以对核对结果进行对应的差错处理
2. 通俗来说就是传统上用Excel来通过人工vlookup做的事情，完全交给系统去做，只需要预先配置好规则就行了
3. 对于对账系统来说，最基本应具备以下几个能力可以便捷的获取需要核对的原始数据，如平台数据，三方数据可以对文件数据进行解析或者二次加工，可以灵活配置核对规则，可以查看核对的结果，可以对差异进行追踪管理和处理，可以对外提供核对结果，可以对外输出数据

1.7 如何搭建一个对账系统

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

第二部分：对账架构图

2.1 标准架构

如果企业整体业务架构完整，系统建设完善的情况下建议对账采用该架构

1. 1. 有完善的账务核心和会计核心
   2. 对账先完成交易数据和三方清算数据的核对
   3. 交易完成了账务和会计层的资金账记账
   4. 汇总清算数据和银行账单数据
   5. 完成平台资金账和银行账单的资金核对
   6. 对账系统通知账务核心银行待清算资金的结转，如下

2.2 简化架构

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

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

2.3 伽马金融管理核对架构

资金管理框架的资金账和银行账核对业务架构图

该图略，课程里会介绍该体系

核心几个关键点：

1. 统一收付平台收口收款、退款、调拨等资金业务
2. 对资金业务统一记账形成统一资金账务
3. 对集团的资金账户进行统一管理
4. 余额调节对账完成资金账和银行的核对勾兑
5. 账户的余额调节表

2.4 伽马支付核对业务架构

伽马支付为公众号案例中心虚拟的支付公司

2.5 通用对账系统架构

第一篇文章介绍过，我们可以脱离财务范畴，抽象出数据核对的通用架构，对数据逐笔准确性校验，实时监控；资金期初期末及发生额的资金校验核对；在这个理念下我们形成如下一个应用范围更广的通用架构

第三部分：对账文件获取和解析

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

3.1 对账文件类型

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

excel（csv）支付宝,常见支付公司；这类文件最方便查看

txt微信，银联个别通道，一些银行；这类文件很不便于查看

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

其他类型银联还有一些通道文件

3.2 对账文件获取方式

接口获取通过机构提供的文件查询和下载接口获取对账文件支付宝下载接口。

示例：

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

3.3 对账文件管理

• • 文件管理方式文件一般存放在对账系统指定的ftp内，并且对文件夹设定一定的命名规范，通过路径查询和下载文件
  • 文件管理后台页面在后台页面查看和下载文件，便于处理和排查对账问题

3.4 对账文件解析器配置

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

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

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

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

例如如下对账文件：

解析规则应该：

解析器配置管理该部分不做过多介绍，记住一个原则公式：在X列满足什么条件时将Y列的数解析到数据表的W字段内；在第6第7篇中的对账项目设计中会有类似的配置页面设计。

3.5 对账数据查看

数据解析到数据库里了，为了便于运营排查问题，还需要做一个查看数据的运营页面，页面样式如下：

第四部分：平台自有数据的获取

4.1 平台对账数据获取方式

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

• 文件获取业务系统需要按照要求定期（如每日凌晨2:00）生成文件，按照约定规范进行命名后，将文件推送至对账系统指定位置（ftp）；这种方式需要各业务系统有一定开发量，业务调整时也需要调整文件的生成策略，维护成本略高
• 接口接收对账系统提供对账数据接收接口，类似账务记账接口一样，业务系统按照约定在相应业务节点发送业务数据到对账中心
• MQ业务方按照要求在交易成功时发送约定格式的MQ消息，对账系统订阅该MQ，对MQ进行解析后获得业务数据
• SQL通过SQL定期捞取业务数据，并将数据存储到对账系统数据库中；该方式调整灵活，可以选择在业务并发小的凌晨进行
• 人工上传对于一些采购的外部应用，比如金蝶系统，数据无法通过以上方式获取的情况下，就需要对账人员定期下载应用内数据，然后上传到对账系统

4.2 数据分类管理

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

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

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

4.3 取数规则配置

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

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

第五部分：对账数据管理

5.1 对账结果数据

5.1.1 交易对账结果

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

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

5.1.2 资金对账结果

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

比如：

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

5.2 对账管理

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

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

支付数据：1 对平 清算数据：1 对平

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

与订单对：订单数据：1 对平 支付数据：1 对平与清算对：支付数据：1 单边 清算数据：无

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

支付数据对账结果表

与订单对：对平

与清算对：单边

第六部分：交易对账项目设计

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

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 对账项目管理

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

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

6.4 对账项目新增

在对账项目列表点击新增会有一个弹窗可以添加一个对账项目；新增时需要先填写基本信息即可，比如对账项目的名称，对账启用时间，对账的频次，对账的类型等；确定后在对账项目列表就会有一个新增的项目，点击设置即可以进入设置页面，具体看5。

6.5 对账项目设置

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

该配置器最终的实现是：

我们从页面可以看出来，该配置是设置卡系统的消耗数据与订单中的消耗记录进行核对。

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

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

第七部分：资金对账项目设计

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

7.1 资金对账项目

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

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

这里我们按照一个实体的资金账户设置为一个资金对账项目，比如平台有微信平台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 对账项目管理

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

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

7.4 资金对账模式选择

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

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

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

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

7.5 对账维度

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

7.6 对账项目设置

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

该配置器最终的实现是：

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

如文件数据

通过原型中的配置条件

条件组：交易状态=success，

金额：正直汇总订单金额

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

其他费用逻辑类似

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

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

第八部分：对账引擎及对账结果查看

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

8.1 对账连续性控制

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

8.2 对账时间控制

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

• 对账日期：就是对的那一天的账，也是交易成功时间或者资金变动日期
• 对账启用日期：一个对账项目的第一个对账日期
• 最后对账日期：一个对账项目的最后一个对账日期

8.3 对账状态控制

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

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

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

8.5 对账核心处理引擎

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

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

8.6 对账结果查看

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

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

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

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

第九部分：差错处理和差错配置设计

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

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

9.1 关于差错处理

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

• 发现差异：对账结果对出了差异
• 排查差异原因：排查差异原因，是掉单了，bug，时间差等具体的原因
• 按照实际处理差异：找到原因后对差错进行处理，掉单的补单，bug就修复，时间差的话就不用处理，等待第二天对平
• 消除差异：这一步是在对账系统对差异进行标记处理，说明差异已经排除了

9.2 交易差错处理

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

• 对平：无需处理
• 单边：需要处理
• 错账：需要处理

差错列表：

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

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

差错处理类型：

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

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

差错处理接口：

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

9.3 资金差错处理

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

资金对账结果确认：

长短款管理：

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

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

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

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

长短款核销：

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

9.4 其他对账场景案例

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

红包中间账户对账：

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

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

• 红包发放充值流入：+100元
• 红包流出付款流出：一共8笔共80元
• 超时未领取退回流出：一笔20元

你觉得该如何做核对呢？

机票代理对账：

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

机票代理商的交易模型：

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

• 售票平台代理商入住后，就像淘宝已经，会有个结算账户，记录卖票记录和结算款记录，卖出去10张票，平台抽取佣金剩余部分结算给代理商结算账户；平台会提供2分文件：机票销售明细文件，结算明细文件；这两份数据要做核对
• 机票代理商机票代理商有一个机票管理系统，购买的第三方服务公司的，可以记录在每个平台的卖票情况以及付款出票情况
• 付款通道机票代理商要卖机票需要向航司去买，卖票付款的话航司签约了一些三方支付公司，比如支付宝，易宝支付，代理商选择这些付款通道进行签约向航司付款，先把钱充值到指定付款账户中，易宝支付是航旅行业觉得的第一名，付款通道会给机票代理付款文件

机票代理的对账模型所以对账我们要对这几个维度售票平台的售票明细与结算明细核对售票平台的售票明细与代理商系统的售票明细核对代理商系统的付款明细与通道的付款账单核对。

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

还有一个行业是券商对账：

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

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

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

第十部分：银行存款余额调节对账

你有账户里有多少钱，有多少钱可用？这个问题是不是很莫名其妙，钱都是我的，当然都能用啊！那再换个说法，如果你10号会发2万工资，4号要支付1万房贷，现在银行卡里还剩1.1万，如果你对象说有急事3号要先用你2000块钱，你怎么办，在每次要花钱的时候，是不是有一个经典问题困扰着你，我是谁，我在那？当然不是，“我还有多少钱能用？” ！这就是我们今天要解决的问题，银行账户还有多少钱，还有多少钱能用 ！

10.1 什么是余额调节表

银行存款余额调节表，就是将企业的账面余额和银行的账单余额，经过未达款项调整后，核对调整余额是否一致的核对工具；验证调节后的存款余额是否相等的核对方法；如果想等则表明企业和银行的账目都没有问题；反之，则说明记账有错误，或者有未达账没找到；需要进一步查明原因，进行修正；余额调节表调整后的余额是银行存款当日可以动用的最大值。

日期：xxxxxx ，账户：银行存款-工行1122

未达是怎么产生的呢，比如打款一般企业先扣账，然后走审批；如果在对账时还没完成审批，这时就会有银行还没到达，但企业已操作账务；另一个场景就是用户直接线下汇入账户的资金，企业账务还没进行记账，对企业账来说就形成未达；

特别提醒要区分资金对账的应收应付和实收实付概念；未达这里是个余额对账的概念；应收付是资金清算的概念。

10.2 如何编制余额调节表

就如第一部分介绍的概念，编制余额调节表就是在两方余额之上进行未达账的加减，获得调整余额。

第一步：

获得两边的余额作为基础余额以及账务明细作为未达素材；企业账从账务系统获得资金账明细，银行账从银行获得对账单并解析入库；待勾兑。

第二步：

通过可勾兑唯一表示，勾兑双方账务明细；未匹配上的明细即是对方未达。

第三步：

按照调整公式计算出调整余额。

银行调整余额=银行对账单存款余额+企收银未收－企付银未付

企业调整余额=企业账面银行存款余额+银收企未－银付企未付

调节后，如果双方余额相等，一般可以认为双方记账没有差错。调节后双方余额仍然不相等时，原因还是两个，要么是未达账项未全部查出，要么是一方或双方账簿记录还有差错。无论是什么原因，都要进一步查清楚并加以更正，一定要到调节表中双方余额相等为止。

调节后的余额既不是企业银行存款日记账的余额，也不是银行对账单的余额，它是企业银行存款的真实数字，也是企业当日可以动用的银行存款的极大值。

10.3 如何余额调节表系统

余额调节表系统就是通过系统实现账户的日末账户余额调节核对；要想实现系统化要解决一下问题。

资金账：

平台要对支付交易和打款进行规范的资金账记录，企业通过oa走的其他费用，例如报销，补贴等也要进行资金账记录；资金调拨也要进行资金账记录；所以综合来讲需要有平台所有账户的所有资金账务的系统记账处理；那么就是需要一个账务系统，这个后面会讲，这里就不在赘述。

账户管理：

对平台所有银行存款或者其他类账户，如微信支付宝账户进行通过管理，可以通过财务主数据也可以在对账系统维护；并且最好可以关联会计科目；最后就是要设定账户的余额调节启用日期。

账户的期初余额：

在账户管理里设定账户的期初余额，系统会基于该期初余额加减资金账的明细获得任何一个时间区间的期初，发生，期末；所以该期初余额一定要正确。

获取银行账单：

通过人工上传或者银企直联以及三方接口，每日获取上一期的对账单，并解析入库，用于进行资金勾兑。

企业资金账单：

从资金账获取本次核对日期要核对的资金账明细，备用，用户与银行账进行勾兑。

核对：

执行企业账单和银行账单的勾兑，为勾兑上的认为是对方未达，进入余额调节表。

获取余额：

从账户余额表获取企业账该账户的余额，用银行对账单或者接口查询获得银行对应账户的日终余额。

余额调节表结果：

结果是基于账户维度，得到每个账户的日终调整余额两边的核对结果以及调整明细。

详情：

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

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

虽然文章尽可能详尽，但难免有疏漏，文章完结了，对账系统设计的征途还在继续，可以加入学习群，继续交流探讨更多设计问题 ！卡! 对账系统杀青。

作者：陈晓光，一个会弹吉他会算命的产品经理老司机，微信公众号：陈天宇宙

本文作者 @陈天宇宙

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！