于每天都需要对账的生意来讲，如果遇上大的额数，就会出现困难，为了提升核对效率以及准确性，对账系统有一定的改变是避免不了的，下面是笔者整理的关于“对账系统”的内容分享，想要了解相关内容的可以接着继续往下了解了解哦！

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

一、对账概述

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

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

1. 对账的定义

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

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

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

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

为什么要对账呢？首先在财务范畴，这是一个必要做的工作；其次，从业务视角看，如今的交易链条越来越长，数据在众多系统之间难免会出现丢失或者差错的情况，所以为了业务的正常运转并及时发现问题，需要确保系统间数据的一致性。

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

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

2. 对账场景和模型

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

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

1）对账模型

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

• 交易对账模型：交易数据之间通过唯一标识进行一对一、一对多、多对多核对业务；
• 资金对账模型：将交易数据按照款项类型进行汇总之后进行核对，比如收款，手续费；
• 余额调节核对：将系统记账余额和实际资金账户余额经过在途调整后进行一致性核对的业务。

2）搭建对账系统

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

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

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

3. 对账架构图

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

图1 对账系统业务架构图

整个架构图包括左中右三大部分。

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

整个核对业务主流程如下：

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

二、对账数据管理

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

1. 渠道数据获取与解析

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

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

1）对账文件类型

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

图2 Excel类型的对账文件

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

图3 txt格式的对账文件

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

2）对账文件获取方式

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

图4 对账文件获取接口的请求参数

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

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

3）对账文件管理

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

图6 对账文件管理

4）对账文件解析器配置

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

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

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

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

表1 存储对账数据表

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

图7 示例对账文件数据

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

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

5）对账数据查看

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

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

2. 自有数据获取与管理

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

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

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

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

2）数据分类管理

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

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

图9 数据分类设置

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

图10 数据子分类设置

3）取数规则配置

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

图11 取数规则设置

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

3. 对账数据管理

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

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

表3 交易对账结果示例

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

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

表4 资金对账结果示例

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

确认对账结果后，会生成差异表，在差异表中对差异进行核销处理。

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

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

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

此时支付数据的对账结果有2个，一个是与订单的核对的结果，另一个是与清算的核对的结果，这种情况，对账结果就需要单独存储“某数据在每一个对账项目组中的核对结果表”。

三、对账项目设计

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

1. 交易对账项目

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

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

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

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

1）对账项目命名

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

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

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

2）对账项目管理

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

图12 交易对账项目管理

3）对账项目新增

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

图13 对账项目新增

4）对账项目设置

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

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

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

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

图14 交易对账项目设置

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

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

图15 资金对账项目管理

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

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

4）资金对账模式选择

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

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

图17 资金对账业务模式

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

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

5）对账项目设置

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

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

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

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

表5 对账文件部分数据

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

四、对账引擎

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

1. 对账控制

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

图19 对账连续性的控制

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

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

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

图20 对账状态管理

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

图21 对账流程控制

2. 核心处理引擎

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

图22 交易对账逻辑

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

表6对账结果示例

3. 对账结果

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

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

图23 交易对账结果查看

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

图24 资金对账结果查看

五、差错处理

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

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

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

1. 交易差错处理

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

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

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

图26 差错处理操作弹窗

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

系统可以预设一些差错处理类型，设定每个类型的处理流程，便于在处理的时候直接选择使用，如图27所示。

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

图27 差错类型管理

2. 资金差错处理

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

图28 资金对账结果详情

什么是长短款呢？比如微信的一个资金账户，资金同事直接在微信商户后台操作了一笔转账，或者用户直接用微信转账100元给了这个账户，这时候就会出现微信收款比平台记录收款多的情况，即微信账单的收款总额比平台的记账总额多100元，资金对账就会发现这100元的长款，就是渠道多收了。

但经过排查是可以找到这个具体原因的，本质上是平台没有获得这笔转账数据，也就无法记录，通过排查可以操作核销差异。

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

图29 长短款核销管理

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

图30 长短款核销处理弹窗

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

图31 核销记录

六、坑位解析器

获取文件并解析文件是对账系统非常重要的环节，也是后续进行对账的基础。因此，解析文件是对账系统设计中非常核心的一部分，上文中所采用的是原样解析文件数据，本小节将提供另一种解析模式做为补充。

为什么叫坑位解析器呢，因为本模型的数据库表是固定的，而是将文件数据按照对应关系解析到固定的字段上去。

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

图32 坑位解析器模型

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

图33 解析器关联关系

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

图34 清算文件示例

文件中的商户订单号是平台的请求唯一单号，也是渠道数据与平台数据进行核对的唯一标识，所以要解析出来，另外的交易状态代表了退款和支付类型，后面还有金额等对账需要的字段都需要解析出来。

如何设置将这些字段解析到数据库表中的规则，就需要用到如下的配置工具，如图35所示。

图35 解析器配置页面

其中基础配置是配置该解析规则的基础信息，主要配置实现“我们需要哪些数据”，比如解析器的编号，所属对账项目，文件的格式、编码等内容。

过滤字段设置的是“哪些数据不要”，比如示例中的含义就是通过文件中的第9列和第10列进行过滤，第9列是“未知、失败”或者第10列是“01”的数据不需要进行解析。

数据开始行的用途是指定从哪一行开始解析，因为有些渠道的文件开头有表头或者有些统计类信息不需要解析，应该刨除掉，如图36所示的文件就应该填“6”，从第6行数据开始解析，前5行数据不需要。

数据列数的配置用途其实也是用于设定解析哪些数据，可以跟“数据开始行”的配置同时使用，属于加强条件，比如填写了“12”，就代表只解析哪些有12个字段的数据行。

图36 结算数据示例

然后是解析规则的配置，这部分是规则部分，主要是配置文件中的“数据如何放到数据表里”的问题。

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

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

• 第一类是取数型配置，如银行订单号等，只需要填写数据列“数”即可，不需要配置格式、单位、数值，直接将文件中的数据取过来即可。
• 第二类是映射型配置，如交易类型、卡类型，二者在数据库里是固定的枚举值，分别是“支付、退款”、“借记卡、贷记卡”，原型示例的配置含义是卡类型根据第“13”列判断，如果是01则代表借记卡、02代表贷记卡，解析到数据库里时，卡类型字段会设置成“借记卡”或者“贷记卡”，而不是文件中的数值；同样原型中的交易类型字段，由第“10”列决定，当是“S13、S22、S23、S36、S37、S46、S54、S56、S64”时代表支付，当是“REFUND”时代表退款。
• 第三类是单位和格式型配置，比如原型中的金额需要配置文件中是什么单位，时间要配置说明文件中的时间格式是什么。

专栏作家

陈天宇宙，微信公众号：陈天宇宙，人人都是产品经理专栏作家。多平台支付领域专栏作者，十年资深产品；专注为10万支付产品经理和支付机构以及企业提供深度支付内容和服务！

本文原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。

到这个题目，有些人可能觉得这是无脑的话题，现在都什么年代了，餐饮都使用收银系统了，资金还核对不了？对于这个我最开始也没想明白，但我最初来到餐饮行业后，还真发现这个问题。我记得我来餐饮行业后，我们的出纳没有哪一个月是把资金核对清楚了的，每个月都还要老板娘帮忙才能把资金核对清楚，且至少都要花四五天的时间，那个时候收银结算方式还不多，就微信、支付宝、现金和POS，连美团和外卖这些都没上，门店也就三十来家，更不用说每天把资金核对清楚了。

以前资金核对效率

看到此种情况我实在是看不下去了，不就是恒等式嘛，期初资金+上月挂账应收+本期实收（不含上月挂账应收）-本期支出=期末资金余额。涉及到收银T+1或T+3的，看挂账金额和下月初到账金额是否一致，就自己针对公司收银情况建立了一个套表，此套表分：银行卡归集情况表；挂账情况表；门店资金营业报表；实际收款；应收金额；各种收银方式后台数据分类导出，收银系统营业额情况表，后面再分每个门店建立统一的资金表格，门店的报表按天记录，门店报表包含了所有收银方式的信息，再把所有表与表之间通过强大的EXCEL函数公式链接起来。

此工作我花了两天时间把所有的数据库都建立起来，并亲自去操作可操作性，当我把所有数据导出来放在套表中后，其结果也并不是一目了然出结果，但收银结算方式至少是对的，不对的就是各银行卡之间的内部转款没有剔除，导致收入不准确，故再根据公司各卡的用途剔除内部转款，神奇出现了，结果套表计算出来的结果和各银行卡的余额一致。后面我就把此套表发给出纳自己操作，以前她搞不定的，现在只需要半天时间就可以搞定了，而且数据还准确，偶尔也会出现状况，但都是因为结算或异常状况导致。这个工作后面最耗时的就是导各种收银后台数据，再根据套表的要求进行加工整理，比如必须保证门店名称的统一，日期格式的统一等。

现在的资金核对效率

曾经我也天真地想过用收银系统或上银行的银企直连可以解决这个枯燥的对账方式，但现实一次次被打击，银行只能对接像微信支付宝之类的，不能对接银行、外卖或者其他活动，而且很多接口都需要付费，动辄几万十几万，银行也不想成为冤大头。银行即使能对接，但其导出的数据也不一能满足管理需求，我记得2020年上云闪付的时候，找过一家银行来做，但结果很悲剧，合作银行导出来的数据不能分门店，都是一坨账，满足不了管理需求。

收银系统更不靠谱，我用过餐行健和天之星，收银方式少还好，但涉及多了，就老火，特别是美团买单、线上活动券，招行一招过或线下券等结算，这些都需要人为操作，只要是人操作，都会出现错误，比如把美团买单结算成微信，把POS结算成现金等，而且微信和支付宝涉及退款也会和后天数据出现时间差，故收银系统只能作为参考。最终还是要看结算后台数据作为参考。

接下来谈下实践中如何操作？

1、首先建立银行卡归集情况表（表1），此表就是把公司所有门店或管理公司用的银行卡放在此表上，格式也是期初金额，本期收入，本期支出，银行卡内部归集金额，计算期末余额，实际银行卡余额，余额差异，这里面的本期收入，和本期支出直接取银行卡当月发生数。这里面有些银行卡就包含了后面各种收银方式的收入，需要和后面的校验，用公式可以对有差异的突显出来。

2、建立挂账情况表（表2），此表就按门店进行归集，分期初挂账金额（这里面包含各种收银方式），本期应收金额（包含各种收银方式），本期实收金额（包含各种收银方式），期末挂账金额（包含各种收银方式），此表是按月汇总，目地在于计算各门店当月收入情况。

3、建立实收收款和应收金额表格（表3），此表也是按门店进行按天归集，这里面就会涉及到各种收银方式因结算导致时间不一的问题，此表中的所有数据都会归集到（表2）中，此表可以看到有多少天的营业款没有收到，下个月初是否收到应收款中没收到的营业款。而（表3）的数据来源于下面的（表5）

4、各种收银方式后台分类表格（表4，这里不止一个表，会出现很多表格，都是收银方式或收银系统的营业报表）以及门店资金报表（表5）。表4也是按天，按门店进行统计整理，整理后会链接到表5中，表5中就会生成每天的营业报表，且会展示各种收银方式实收和应收情况，中间会有手续费和折扣的展示。

5、以上5个表做好后，会链接到门店资金营业报表（表6）中，此表和表1有点类似，只是这个表是按照各核算单位建立，即门店或管理公司来建立的，表格也分期初金额，本期收入，本期支出，期末余额。本期收入来源于表2中期初挂账金额+本期实收金额，本期支出，就根据公司各卡支付支付功能进行归集到门店，最后计算得出期末余额，看期末余额与表1中的各卡期末余额是否一致。同样用公式做校验突显，错误标红，正确自己选择方式即可。

6、以上只是操作方法，中间肯定会出现数据不一致的情况，这个就得需要自己的经验了，怎么去检查自己错误，当然经验多了或者头脑转得快，对于自己的错误会很快检查出来，不是自己算错了，而且有些时候对办公软件的操作不熟悉所致。

此方法我们一直延续用到现在，最多的时候六七十家门店，也是采用的此方法，没办法想上软件提升效率，但找了很多，都无法满足，可能也跟企业自身管理有关系，活动越多，收银越复杂，对账就越繁琐，收银系统或对账软件也就更难找。我记得我们的收银结算方式最多的时候有七八十种，每个商场都有自己的活动，疫情后还有微生活上的各种活动，数不胜数。我也去乡村基或其他餐饮了解过，有些收银方式很正规，也就十来种，有些也跟我们一样。对此我也问过公司品牌运营部，说实在的疫情后，来客数降低是不争的事实，如何引流也是他们的难题。

本想发个套表在上面，但限于初学以及表中数据，待未来权限可以的时候，会分享自己的心得。以上的分享只是我这种原始手工制作者，我相信会有很多大咖有更简洁的方法，在此班门弄斧实在不该，但只是我自己来到餐饮行业后，接触了几十家同行后大家的共识而已，当然还是有更好的，也希望遇到高手能个月更好的方法和方式。

　餐饮业越来越注重客户体验和管理效率，纳客餐饮收银系统就是为餐饮门店提供全方位解决方案的管店利器，它涵盖扫码点餐、菜品管理、KDS厨显、后厨打印、外卖对接、团购核销、财务报表等功能，让您轻松实现高效、便捷、智能的餐饮经营管理。

　　首先，我们来看看扫码点餐功能，这是饭店使用频次很高的一个功能，尤其是对于那些有自助扫码点餐需求的餐厅来说更是如此。顾客到店用手机扫点餐码开始点餐，后厨自动打印小票，开始备餐，省去了服务员人工点单的步骤，节省了人力成本的同时，避免漏单错单。桌台管理：实时显示餐馆内各桌台的占用情况，方便服务员和管理人员进行管理和调度。

菜品管理：数据实时更新，前台每销售一单，菜品库存自动扣减，菜品售完自动下架，可以帮助您清晰地了解餐厅菜单上所有菜品的库存情况，避免出现断货或过量供应的情况，而且还可以根据销售数据进行调整，优化菜品结构，提高顾客满意度。KDS智能后厨系统，主要用于将后厨的流程系统化，规范化，提高后厨工作效率，集配菜一制作一划菜整套后厨流程，根据实际情况灵活设置流程。除了这些功能外，纳客餐饮收银系统还支持外卖对接、团购核销等功能。如果您的餐厅需要开展外卖业务，那么这个系统可以帮您轻松处理订单、外卖平台统一对账等问题；如果您想要开展团购活动，那么这个系统同样可以帮您快速完成团购券核销工作。

财务报表功能可以帮助您实时了解餐厅的财务状况，包括营业收入、每日对账单、菜品销量等方面的数据，通过这些报表，您可以更好地分析市场趋势，制定相应的营销策略，提高餐厅的盈利能力。
纳客餐饮收银系统是一个功能强大、操作简单、性价比高、售后有保障、数据安全的餐饮管理系统，无论是中餐馆、西餐厅、快餐店还是食堂等各类餐饮门店都能适用。
以上就是饭店会员管理系统哪个好的相关回答，有需要的餐饮店商家可以下载使用。