系统对账怎么对「对账报表」
今天给大家普及一下系统对账怎么对「对账报表」相关知识，最近很多在问系统对账怎么对「对账报表」，希望能帮助到您。
第一部分：对账介绍想必大家对“对账”这个词都不陌生，单从字面意思就能略知一二；其实就是字面意思；“对”就是核对，“账”就是账目；“对账”就是核对账目；账目核算是财务工作的必要部分，随着线上交易体量越来越大或者说对财务自动化线上化的效率提升需求越来越高；为了提升核对效率以及准确性，势必要将核对业务系统化线上化自动化；那么如何构建设计一套不同业务场景下的对账系统呢？
希望在做对账相关系统的产品同学可以参考借鉴以及交流沟通
生活中的对账
日常生活中我们每天都在对账，比如去餐馆吃饭付款，会对老板说一声“老板，钱付过去了”；老板检查过收款或者听到语音播报后回复一声“好嘞，下次再来”；这就是最简单的一次对账
再比如你在淘宝开了一个店铺，每个月几千单的交易，发货；每次月末都拿着所有的订单明细和支付宝收款账户收款记录逐笔的做一次核对，保证发过货的订单都收到款了，这就是一次更复杂的核对了
什么是对账
对账概括来说就是“账证实”核对，“账”就是账目，“证”就是凭证，“实”就是实际资金
核对模式有三种：账证核对，账账核对，账实核对；确保账证实两两的一致性；比如吃了一碗面点菜单就是原始凭“证”，付了10元钱是“账”，老板电脑点菜记录小票10元是“账”，老板看到账户中余额增加了10元是“实”
财务范畴来看，证就是会计凭证，比如发票，小票，出货单，收据，交易系统的支付记录等都是原始凭证；而账呢就是财务的账目，账务系统的账务记账，金蝶的科目余额等都是不同的账目；而一笔交易会记录在很多的环节，比如账务系统，金蝶等
另外脱离财务范畴来看，其实账目本身抽象出来就是数据，商品数据，用户数据，卡券数据等，那么账证实需要核对，很多时候很多非财务范畴数据也需要核对，比如今天应到10人实到8人，军训时的报数等其实也可以称为对账，我们暂且称为“广义的对账”
那么我们来为对账下一个定义：为了确保同一个事务的数据描述在不同场所下的记录一致而进行的相互之间的一致性比对
为什么要对账
首先在财务范畴，这是一个必要做的工作
另外从业务范畴，现在交易链条越来越长，数据在众多系统之间难免会出现丢失或者差错，所以为了业务的正常运转及时发现问题，需要确保系统间数据的一致性
从公司的角度，需要确保“不少收一分钱，不多付一分钱”，保证资金的安全，不然卖了多少货，收了多少钱相互之间谁也不鸟谁，最后全是糊涂账
综上所述，对账是必不可少的；对于交易体量巨大的互联网公司更是必不可少，而且系统化也是必须的，单靠人工难以满足需要
几个常见对账场景
三方支付公司：主要是核对自家的交易记录和银行清算数据之间的一致性；银行清算数据（应收应付）和银行结算数据（实收实付）的一致性；同样也要核对与金蝶账务数据的一致性
电商等服务平台：主要是核对自家的交易数据和三方支付公司或者微信支付宝的清算数据的一致性；三方清算和结算的一致性；三方结算到对公户实际资金的一致性
另外还有红包：比如用户支付100元发10个红包，有6个用户领了6个一共8元，有4个超时没领退回给了用户；那么对于平台的这个红包中间账户的进出也要核对：
{ 用户充值1笔100元
中间户入了1笔100元
中间户出了10笔100元
中间户被退回4笔2元
中间户退给用户1笔2元
这样对于中间户来说100-100 2-2=0 }
还有一些其他的领域对账，比如航司的机票，机票代理商的购票出票，中间券商的上下游之间等等
常见的对账模型
交易对账模型：数据之间的按照唯一标识进行一对一，一对多，多对多核对
资金对账模型：将交易数据按照款项类型进行汇总之后进行核对，比如收款，手续费
余额调节核对：对系统记账余额和实际资金账户余额在经过在途调整后进行一致性核对
比如：系统记账昨日日终余额100元，截止昨日日终提现中100元；出款账户昨日日终200元；此时该账户：系统账100元=出款账户200元-100元应付未付；这样余额是平的，说明资金没有问题
其他更复杂的核对模型：比如多链条之间进行关联核对像三份数据进行一次性比对等，这里不再过多阐述；本系列文章重点介绍的是1和2,至于3会在今后有机会讲解，如果有朋友感兴趣可以单独交流
什么是对账系统
对账系统就是通过系统解决方案，对需要核对的数据按着设定好的规则进行核对校验，并产出核对结果；并且可以对核对结果进行对应的差错处理
通俗来说就是传统上用Excel来通过人工vlookup做的事情，完全交给系统去做，只需要预先配置好规则就行了
对于对账系统来说最基本应具备以下几个能力
可以便捷的获取需要核对的原始数据，如平台数据，三方数据
可以对文件数据进行解析或者二次加工
可以灵活配置核对规则
可以查看核对的结果
可以对差异进行追踪管理和处理
可以对外提供核对结果
可以对外输出数据
如何搭建一个对账系统
首先就是要先明确对应的业务模型
其次需要抽象出业务的核对模型
然后针对核对模型选择合适的核对方案
最后针对核对方案设计系统方案，然后进行研发和上线
第二部分：架构图和流程图01
标准业务架构
如果企业整体业务架构完整，系统建设完善的情况下建议对账采用该架构
有完善的账务核心和会计核心
对账先完成交易数据和三方清算数据的核对
交易完成了账务和会计层的资金账记账
汇总清算数据和银行账单数据
完成平台资金账和银行账单的资金核对
对账系统通知账务核心银行待清算资金的结转，如下
02
简化架构
如果企业没有账务和会计核心；可以通过对账中心先时间交易数据和三方清算数据的核对；然后汇总清算数据与三方账单数据核对；保证金业务记账以及银行清结算数据的一致性
按核对频率获取业务支付数据
T 1或其他频率获取三方清算文件和结算文件
将清算和结算文件进行解析存储
根据对账项目配置完成交易数据和清算的核对
完成清算数据和结算数据的核对
对交易的单边数据和资金核对差异进行管理和处理
03
伽马金融资金管理核对架构
资金管理框架的资金账和银行账核对业务架构图
该图略，课程里会介绍该体系
核心几个关键点
统一收付平台收口收款、退款、调拨等资金业务
对资金业务统一记账形成统一资金账务
对集团的资金账户进行统一管理
余额调节对账完成资金账和银行的核对勾兑
账户的余额调节表
04
伽马支付核对业务架构
伽马支付为公众号案例中心虚拟的支付公司
05
通用对账系统架构
第一篇文章介绍过，我们可以脱离财务范畴，抽象出数据核对的通用架构，对数据逐笔准确性校验，实时监控；资金期初期末及发生额的资金校验核对；在这个理念下我们形成如下一个应用范围更广的通用架构
第三部分：对账文件获取和解析支付交易的通道提供方，例如微信、支付宝、网联、银联等，都是按照约定频率和时间提供交易的记录文件，一般都是2份，一个清算文件“记录支付明细”；另一个是“结算文件”记录资金账户的实际的资金变动；对于文件的获取大部分在提供通道时会提供下载接口，另外如果没有接入下载接口，可以采用人工下载的方式获得文件，将文件传到对账系统获得对账数据；下面主要介绍渠道方的对账文件获取以及解析和管理
01
对账文件类型
主流类型还是Excel和txt，本文主要介绍的也是这2种
excel（csv）
支付宝,常见支付公司；这类文件最方便查看
txt
微信，银联个别通道，一些银行；这类文件很不便于查看
xml报文
网联；这类文件人工很难查看和处理
其他类型
银联还有一些通道文件
02
对账文件获取方式
接口获取
通过机构提供的文件查询和下载接口获取对账文件
支付宝下载接口示例
人工下载
如果技术能力资源不足，或者暂时没有接入接口，可以采用人工下载的方式，然后在对账中心上传对账文件进行解析
03
对账文件管理
文件管理方式
文件一般存放在对账系统指定的ftp内，并且对文件夹设定一定的命名规范，通过路径查询和下载文件
文件管理后台页面
在后台页面查看和下载文件，便于处理和排查对账问题
04
对账文件解析器配置设计
对账文件解析是指将文件里的数据解析到数据库内，形成数据库数据，因为文件数据不能直接被系统处理
原样解析
不改变文件的数据列数和内容，对文件数据保证不减少列数的前提下进行全量解析，可以根据需要增加列内容，比如账号，对账时间等
优点：不需要配置解析器，每一个文件研发好固定的解析器进行复用
缺点：每个文件类型需要建一套数据表，维护成本高
适用：通道少的平台，一般商户都仅有微信支付宝，可以采用原样解析
通用板式解析
所有对账文件数据按照映射关系解析到固定的数据表当中；例如以下的表结构
核对单号支付方式交易类型金额状态支付时间例如如下对账文件
解析规则应该
列数条件表字段名单位格式A支付时间yyyy-MM-dd hh:mm:ssGF=收入金额元略略解析器配置管理
该部分不做过多介绍，记住一个原则公式：在X列满足什么条件时将Y列的数解析到数据表的W字段内；在第6第7篇中的对账项目设计中会有类似的配置页面设计
05
对账数据查看
数据解析到数据库里了，为了便于运营排查问题，还需要做一个查看数据的运营页面，页面样式如下
第四部分：平台对账文件的获取和存储01
平台对账需求获取方式
拿到三方文件账单数据以后需要与平台自己的相关数据做核对，比如平台交易数据与清算数据的核对；平台账务数据与银行账单数据的核对；平台自有数据获取方式常采用如下形式
文件获取
业务系统需要按照要求定期（如每日凌晨2:00）生成文件，按照约定规范进行命名后，将文件推送至对账系统指定位置（ftp）；这种方式需要各业务系统有一定开发量，业务调整时也需要调整文件的生成策略，维护成本略高
接口接收
对账系统提供对账数据接收接口，类似账务记账接口一样，业务系统按照约定在相应业务节点发送业务数据到对账中心
MQ
业务方按照要求在交易成功时发送约定格式的MQ消息，对账系统订阅该MQ，对MQ进行解析后获得业务数据
SQL
通过SQL定期捞取业务数据，并将数据存储到对账系统数据库中；该方式调整灵活，可以选择在业务并发小的凌晨进行
人工上传
对于一些采购的外部应用，比如金蝶系统，数据无法通过以上方式获取的情况下，就需要对账人员定期下载应用内数据，然后上传到对账系统
02
数据分类管理
对账系统数据会越来越多，类型也越老越多，支付数据，卡券数据，订单数据，三方清算数据，三方结算数据等等；每类数据的数据字段有各有不同；如何对众多类型数据进行管理呢？下面介绍一个方法：对数据进行分类管理，每类数据单独设置表结构
数据分类设置
设置数据的大类，或者说是一级分类；就像商品类目一样管理数据
设置数据类型
在数据分类下面设置数据的子类，并且数据子类关联数据库表名，便于存储数据，查询数据，对账取数
03
取数规则配置
配置好了数据分类和类型以及关联好了数据表之后，接下来就是配置获取数据的规则了，我们以通过文件或者SQL两个可选择的形式获取数据为例
为每个数据分类配置取数方式，如果是文件的话就配置文件路径，如果是SQL的话就配置取数sql，这样系统会按照任务配置基于取数规则定期获取对账的数据，并且插入到数据类型关联的数据表当中
数据分类以及数据表在后面的对账项目规则设置起到了非常重要的作用
第五部分：对账数据管理对账数据
通过前几篇文章我们已经了解了什么是对账，对账外部数据和内部数的获取方式以及查看方式，除了这两类对账源数据，还有一类数据：对账结果数据；对账结果数据也需要存储和管理，以及相应的用途
01
对账结果数据
交易对账结果
支付数据与三方清算的核对，或者其他数据的两两核对，会得出核对结果；并且每一组核对都会有一个组别的名字，这个下一节会详细介绍，比如“会员支付VS微信清算”，核对结果如下表
会员支付记录微信清算结果流水号金额类型流水号金额类型119.00支付单边219.00支付219.00支付对平319.00支付319.00支付对平419.00支付419.00支付对平支付519.00支付单边619.00支付620.00支付错账我们可以看出来“1,5,6”三条记录是有问题的，2条是一方有一方没有，另外一条是都有但金额不一致；这就是交易对账结果，“对平，单边，错账”，对于对账有问题的数据需要进行排查找出原因，并进行差错处理（后面会详细介绍）
资金对账结果
交易对账结果是源数据本身在某个对账项目里的核对结果；而资金对账结果是某资金账号某交易日的资金收付的一致性；比较平台的资金账收付结果与银行的收付结果是否一致，或者说是银行自己本身的清算与结算的款项及金额是否一致；比如
微信清算微信结算差异款项金额款项金额收款100.00收款100.000手续费0.60手续费0.600退款50.00退款49.70-0.30退款手续费0.30退款手续费00.3其他其他从对账结果我们可以看出来，微信在退款和退款手续费存在差异，而发现二者正好正负相抵，原因是微信退款和退款手续费是轧差出现在账单里的，所以实际上并没有差异，但是既然已经对出差异，并且排查出原因，就需要对差异进行处理，资金对账的差异是“长款，短款，应收未收，应付未付”；在确认对账结果后，会生成差异表，在差异表中对差异进行核销处理
02
对账管理
上面我们介绍了交易对账和资金对账的核对结果，那么如何存储差异结果呢？
差异结果可以存储在源对账数据的表中，也可以单独存储
存储在源对账表
该种方式适合与数据单一的对账体系，且同一份数据不会在多个对账项目中进行核对，比如支付数据只与清算核对，这时候数据的核对结果就是默认与另一方的核对情况
支付数据：1 对平 清算数据：1 对平存储在单独的对账表中
该种方式适合复杂的核对场景，同一份数据会在多个对账项目中与多组数据完成核对，产生多个对账结果，比如支付数据与上游的订单进行核对得出一个对账结果，支付数据又会与下游的清算数据核对得出另一个对账结果
与订单对：订单数据：1 对平 支付数据：1 对平与清算对：支付数据：1 单边 清算数据：无我们发现支付数据的对账结果有2个，一个是与订单的核对的对平，另一个是与清算的核对的单边，此种情况，我们的对账结果就需要单独存储“某数据在每一个对账项目组中的核对结果表”，对账结果有2个，如下
支付数据对账结果表
与订单对：对平
与清算对：单边
第六部分：交易对账配置对账配置化
企业业务在不断变化，新的业务也在不断出现，对账数据因为业务的变化也在发生变化；如果接入了新的支付渠道对账设置也需要新增；如果每次都通过开发实现，那么成本会很高；本篇文章我们将介绍如何实现交易对账项目的配置化设计，极大的提升对账项目的管理效率
01
交易对账项目
做对账并不是简单的一方与另一方比对；实际会基于业务情况，存在很多组进行核对；比如与微信的核对，与支付宝的核对等；每一组又可能分成更细的组，比如与微信核对，可以分成微信收款核对，微信退款核对；又可能微信收款有很多账号，我们又可能会按照微信账户进行分组进行核对；例如微信收款一共有两个微信账号：微信1，微信2；那么我们可以设置4个对账的组，如下
对账项目1：微信1-收款
对账项目2：微信1-退款
对账项目3：微信2-收款
对账项目4：微信2-退款
对账项目就是我们设定的核对组；当然以上的对账项目我们可以简化成2个
对账项目1：微信-收款
对账项目2：微信-退款
具体如何设置核对组，这个因公司而已，因喜好而已，核心目的只要能完成全量的核对即可；对账项目越少越容易管理，对账项目越多越清晰，各有利弊
02
对账项目命名
为了便于管理我们还需要为每个对账项目命个名字，如何起名这个也看自己喜好；原来在易宝支付，因为对账组的同学基本都是女生，都是吃货，所以所有对账项目都命名称跟吃相关的“如：工商9876-卤煮火烧”；命名的一个关键原则
要能从名字中看出具体核对的业务
基于这个原则我们为1中的几个项目进行命名如下
对账项目1：会员购买微信支付-收款
对账项目2：会员购买微信支付-退款
这样我们可以清晰的知道对账项目1是用户使用微信支付购买会员的收款核对项目
03
对账项目管理
一个企业可能会存在很多个对账项目，像原来在某支付，高达几百个核对项目；为了便于管理，我们就需要一个菜单专门管理对账项目；示例如下
该页面可以查看所有的对账项目；点击设置可以进行该对账项目的配置设置；右上角的新增可以新增新的项目
04
对账项目新增
在对账项目列表点击新增会有一个弹窗可以添加一个对账项目；新增时需要先填写基本信息即可，比如对账项目的名称，对账启用时间，对账的频次，对账的类型等；确定后在对账项目列表就会有一个新增的项目，点击设置即可以进入设置页面，具体看5
05
对账项目设置
对账项目的设置主要设置对账项目的执行时间，核对双方的对应数据，核对的唯一标识，一些处理规则等；下面是一个基础的设置页面；实际工作中需要基于业务场景以及数据特点，对设置器进行一些调整；但是在这配置基础之上一般难度不大；配置页面如下
该配置器最终的实现是
我们从页面可以看出来，该配置是设置卡系统的消耗数据与订单中的消耗记录进行核对
为数据两方配置数据的选择条件
A方数据为卡数据
数据筛选条件是”交易类型=消耗购买”
B方数据是订单数据
对比设置两方以订单号进行核对，金额进行核对
订单数据的金额如果存在多条则进行汇总
对账差异的报警接受人，可以填邮件，办公账号等
这样完成配置后，一个对账项目就配置完成了；会照着配置的时间每天完成订单数据和卡数据关于消耗明细的核对
未完待续......·················END·················
不会弹吉他的算命先生不是个好产品-您好我是陈晓光，一个会弹吉他会算命的产品经理老司机，为您提供优质的产品内容和服务，(我的微信公众号: 陈晓光)
北京十几年，曾经是一名创业者，开过三家公司，服务过美团，糯米，借贷宝；拿过千万级融资；做了十年产品，大小厂都奋斗过
未来5年将“前十年在产品领域的所见·所学·所做·所想”分享给读者
