账证核对,账账核对,账实核对,账证核对指的是核对会计账簿记录与原始凭证

企业管理中，财务对账是一个关键环节，它确保了交易的准确性和资金的安全。本文通过访谈和分析，识别了当前对账流程中存在的问题，如难以读取的屏幕布局、操作复杂性等，并提出了一系列优化措施，包括布局优化、视觉优化和交互优化，供大家参考。

每到月末财务都需要对发票的进行对账，来核对分公司的差旅业务是否与总公司的账单能够齐平，确保交易的准确性，接下来分享一下是如何优化这个场景的。

财务对账是对企业或个人财务账目进行核对的过程。

目的包括保证财务数据准确、防范财务风险、满足外部审计要求。

内容有账证核对、账实核对。方法分为日常对账、定期对账、专项对账。其重要性在于为企业管理提供决策依据、维护企业信誉和形象、促进企业健康发展。

自研的平台能够满足业务部门需求以及提高业务部门对产品的满意度成为重要的任务，其中财务部门就是重要的一环，往往资金安全、高效筹集与优化配置资金的特性。决定着各个部门有效资金筹划的合理性，随着业务的发展，财务人员机构化改革变动较频繁，每个部门/财务对于产品的现状越来越不满，影响到了团队的满意度。

为了找到其中的优化点，找了5 位财务人员进行访谈，结合在相关的事业群里面的诉求，将优化点分为：

难读取：

难操作：

优化措施分解为：布局优化、视觉优化、交互优化

贴合业务场景提高屏效果

首先分离场景，分成首次对账场景以及二次确认的场景

动作分析：

首次对账目标：财务操作如今是对总账-分账，筛选（修改）生成子账单

二次对账目标：查看对账概览、开票、结算

将原有上下布局改为左右布局，便于财务直观并行比较费用明细，清晰呈现不同费用项目，对比差异、了解费用构成和分布，同时提高表格在首页的信息展示效率，减少滚动操作，方便用户获取费用数据，为财务分析和决策提供支持。

静态状态下，常规滚动场景有布局改动补充，滚动时系统自动收起总账卡片，增加表格信息曝光率，提升操作效率，避免遮挡，提高表格可见性，让财务同学便捷获取数据，系统自动调整，减少操作步骤和时间成本，使查看和操作表格更流畅高效。在对账情境下，折叠二次对账，使表格内容最大化，提高用户对账专注度和效率，营造简洁操作环境，方便用户浏览分析数据，提升工作质量和效果。

集成总账与分账，增强对账易读性

优化视觉之前优先优化了整体的布局，将总分账单进行区分，并且对总账数字进行加粗和字号加高进行强化。表格减少分割线，弱化表格分割感，降低阅读成本。

上面讲完了布局的优化，下一步优化视觉，视觉优化主要在顶部的卡片和账单概览。

顶部卡片品牌感设计，提升财务对账愉悦感

旧版使用了3种底色色块背景过强，新版则参考了字节跳动现有产品的设计风格采用了毛玻璃质感，融入了产品品牌基因。

当时的设计理念是：虚实之美，细腻通透质感。在满是扁平风格的境况下，大胆采用了新拟态的质感，希望能在扁平风格中打造一种有拟物层次与差异化的视觉体验，运用通透玻璃的磨砂材质打造真实&理想之“虚”，产生隐约之美，构建界面主次、虚实、冷暖的平衡感。

设计流程：

账单概览具象化呈现，降低理解成本

在对账单概览进行设计优化时，引入了线下票据的样式。线下票据在财务的日常生活和工作中较为常见，对其有着一定的熟悉度。通过引入线下票据样式，能够让账单概览的呈现更加直观、贴近财务的工作日常认知。财务在查看账单概览时，能够迅速理解其中的内容和结构，极大地降低了用户的理解成本。

财务无需花费过多的时间去适应新的界面和格式，就能够轻松地获取账单信息，提高了用户的使用体验和效率。

交互优化

新增折叠看板，收纳三栏

这个折叠看板具有强大的收纳功能，能够将三栏内容巧妙地收纳其中。当不需要查看这三栏内容时，可以将看板折叠起来，不占用过多的空间，使页面更加简洁整洁。

高级筛选优化

打造财务千人千面的筛选需求，提高筛选效率

随着业务发展，财务人员因工作内容、重点及习惯差异有特定筛选逻辑。为满足个性化需求实现千人千面筛选，开放高级筛选功能。财务人员次月进入系统，一键点选标签即可筛选数据，操作便利，提升效率，便于进行财务分析、决策及日常业务处理，为企业财务管理提供支持。

管理高级筛选更轻量

明确区分增删改操作，设独立路径以优化流程。增有专门入口和流程，确保准确录入；删有独立路径且严格验证提示，保数据安全完整；改有独立流程及历史记录。此举优化流程，提效率降风险。

自定义优化

分组展示自定义列，高效选取多列表格

通过Tab交互方式，为用户带来了极大的便利，进一步提升了用户操作的效率和准确性。在使用系统或浏览页面时，迅速将财务引导至特定的位置或功能模块。它就像是一个精准的指南针，始终为用户指明方向在复杂的操作环境中不会迷失。

上线后针对对账效率进行相关的埋点，2 个月后单次对账效率提高说11.67%，财务部门的满意度从 7.2 提升到 7.5，因为页面涉及到的内容较多各种接口较为复杂，只能 2 期发布。

本文从布局、视觉、交互三方面进行优化，作为设计师在设计的时候，需要有属于自己的设计流程。我自己一般的思路一般从大颗粒度到小颗粒度：业务分解-场景拆分-布局-视觉-交互。

希望能给到同行借鉴思路，如果有其他的设计流程的思路可随时沟通互相学习。

专栏作家

一只鸡腿，微信公众号：B端设计一只鸡腿，人人都是产品经理专栏作家。一个吃货的B端设计师。

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

题图来自 Unsplash，基于 CC0 协议

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

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

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

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

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

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

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

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

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

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

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

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

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

1）对账模型

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

2）搭建对账系统

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

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

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

图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 业务平台对账数据查询

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

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

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

2）数据分类管理

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

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

图9 数据分类设置

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

图10 数据子分类设置

3）取数规则配置

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

图11 取数规则设置

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

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

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

表3 交易对账结果示例

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

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

表4 资金对账结果示例

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

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

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

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

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

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

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

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

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

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

1）对账项目命名

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

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

2）对账项目管理

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

图12 交易对账项目管理

3）对账项目新增

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

图13 对账项目新增

4）对账项目设置

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

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

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

图14 交易对账项目设置

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

1）资金对账项目

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

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

2）对账项目命名

为了便于管理，还需要为每个对账项目进行命名，如何起名看业务需求或者个人喜好，同交易对账项目命名类似，命名的一个关键原则是要能从名字中看出具体核对的那个账户。

基于这个原则为（1)中的几个项目按照“通道方+通道类型+账户号”的命名规则规则进行命名，具体命名如下：

对账文件管理在前文已经介绍过了，账户方一般会在次日提供相应的清算文件和结算文件，那么文件要跟资金对账项目对应上，通过对账文件命名可以知道对应的所属账户，比如制定这样命名规则：通道方+账号+文件类型+交易日期，按照该规则可以得到资金对账项目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 对账文件部分数据

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

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

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

图19 对账连续性的控制

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

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

图20 对账状态管理

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

图21 对账流程控制

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

图22 交易对账逻辑

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

表6对账结果示例

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

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

图23 交易对账结果查看

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

图24 资金对账结果查看

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

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

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

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

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

图26 差错处理操作弹窗

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

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

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

图27 差错类型管理

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

专栏作家

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

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

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

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