-
想必大家对“对账”这个词都不陌生,单从字面意思就能略知一二;其实就是字面意思;“对”就是核对,“账”就是账目;“对账”就是核对账目;账目核算是财务工作的必要部分,随着线上交易体量越来越大或者说对财务自动化线上化的效率提升需求越来越高;为了提升核对效率以及准确性,势必要将核对业务系统化线上化自动化;那么如何构建设计一套不同业务场景下的对账系统呢?接下来的“对账系统设计”10篇文章将带领大家学习如何设计一个对账系统。
-
陈老师设计过某支付以及某金融的对账系统,不仅是交易的核对,资金的核对;更有更复杂的红包场景中间账户的核对,余额调节表的余额核对等;也做过一个创业项目“云对账”为各行业提供行业核对系统解决方案;所以在对账系统的设计上有一定的经验;本系列文章讲解的对账中心是经过改良之后的,拥有更合理的架构和核对策略
-
希望在做对账相关系统的产品同学可以参考借鉴以及交流沟通
全文分十个部分,共13596字,预计阅读时间20分钟
第一部分:对账概述
1.1.生活中的对账
-
日常生活中我们每天都在对账,比如去餐馆吃饭付款,会对老板说一声“老板,钱付过去了”;老板检查过收款或者听到语音播报后回复一声“好嘞,下次再来”;这就是最简单的一次对账
-
再比如你在淘宝开了一个店铺,每个月几千单的交易,发货;每次月末都拿着所有的订单明细和支付宝收款账户收款记录逐笔的做一次核对,保证发过货的订单都收到款了,这就是一次更复杂的核对了
1.2.什么是对账
-
对账概括来说就是“账证实”核对,“账”就是账目,“证”就是凭证,“实”就是实际资金
-
核对模式有三种:账证核对,账账核对,账实核对;确保账证实两两的一致性;比如吃了一碗面点菜单就是原始凭“证”,付了10元钱是“账”,老板电脑点菜记录小票10元是“账”,老板看到账户中余额增加了10元是“实”
-
财务范畴来看,证就是会计凭证,比如发票,小票,出货单,收据,交易系统的支付记录等都是原始凭证;而账呢就是财务的账目,账务系统的账务记账,金蝶的科目余额等都是不同的账目;而一笔交易会记录在很多的环节,比如账务系统,金蝶等
-
另外脱离财务范畴来看,其实账目本身抽象出来就是数据,商品数据,用户数据,卡券数据等,那么账证实需要核对,很多时候很多非财务范畴数据也需要核对,比如今天应到10人实到8人,军训时的报数等其实也可以称为对账,我们暂且称为“广义的对账”
-
那么我们来为对账下一个定义:为了确保同一个事务的数据描述在不同场所下的记录一致而进行的相互之间的一致性比对
1.3.为什么要对账
-
首先在财务范畴,这是一个必要做的工作
-
另外从业务范畴,现在交易链条越来越长,数据在众多系统之间难免会出现丢失或者差错,所以为了业务的正常运转及时发现问题,需要确保系统间数据的一致性
-
从公司的角度,需要确保“不少收一分钱,不多付一分钱”,保证资金的安全,不然卖了多少货,收了多少钱相互之间谁也不鸟谁,最后全是糊涂账
-
综上所述,对账是必不可少的;对于交易体量巨大的互联网公司更是必不可少,而且系统化也是必须的,单靠人工难以满足需要
1.4.几个常见对账场景
-
三方支付公司:主要是核对自家的交易记录和银行清算数据之间的一致性;银行清算数据(应收应付)和银行结算数据(实收实付)的一致性;同样也要核对与金蝶账务数据的一致性
-
电商等服务平台:主要是核对自家的交易数据和三方支付公司或者微信支付宝的清算数据的一致性;三方清算和结算的一致性;三方结算到对公户实际资金的一致性
-
另外还有红包:比如用户支付100元发10个红包,有6个用户领了6个一共60元,有4个超时没领退回给了用户;那么对于平台的这个红包中间账户的进出也要核对:
{ 用户充值1笔100元
中间户入了1笔100元
中间户出了10笔100元
中间户被退回4笔40元
中间户退给用户1笔40元
这样对于中间户来说100-100+40-40=0 }
-
还有一些其他的领域对账,比如航司的机票,机票代理商的购票出票,中间券商的上下游之间等等
1.5.常见的对账模型
-
交易对账模型:数据之间的按照唯一标识进行一对一,一对多,多对多核对
-
资金对账模型:将交易数据按照款项类型进行汇总之后进行核对,比如收款,手续费
-
余额调节核对:对系统记账余额和实际资金账户余额在经过在途调整后进行一致性核对
比如:系统记账昨日日终余额100元,截止昨日日终提现中100元;出款账户昨日日终200元;此时该账户:系统账100元=出款账户200元-100元应付未付;这样余额是平的,说明资金没有问题
-
其他更复杂的核对模型:比如多链条之间进行关联核对像三份数据进行一次性比对等,这里不再过多阐述;本系列文章重点介绍的是1和2,至于3会在今后有机会讲解,如果有朋友感兴趣可以单独交流
1.6.什么是对账系统
-
对账系统就是通过系统解决方案,对需要核对的数据按着设定好的规则进行核对校验,并产出核对结果;并且可以对核对结果进行对应的差错处理
-
通俗来说就是传统上用Excel来通过人工vlookup做的事情,完全交给系统去做,只需要预先配置好规则就行了
-
对于对账系统来说最基本应具备以下几个能力
可以便捷的获取需要核对的原始数据,如平台数据,三方数据
可以对文件数据进行解析或者二次加工
可以灵活配置核对规则
可以查看核对的结果
可以对差异进行追踪管理和处理
可以对外提供核对结果
可以对外输出数据
1.7.如何搭建一个对账系统
-
首先就是要先明确对应的业务模型
-
其次需要抽象出业务的核对模型
-
然后针对核对模型选择合适的核对方案
-
最后针对核对方案设计系统方案,然后进行研发和上线
第二部分:对账架构图
2.1.标准架构
如果企业整体业务架构完整,系统建设完善的情况下建议对账采用该架构
-
有完善的账务核心和会计核心
-
对账先完成交易数据和三方清算数据的核对
-
交易完成了账务和会计层的资金账记账
-
汇总清算数据和银行账单数据
-
完成平台资金账和银行账单的资金核对
-
对账系统通知账务核心银行待清算资金的结转,如下
2.2.简化架构
如果企业没有账务和会计核心;可以通过对账中心先时间交易数据和三方清算数据的核对;然后汇总清算数据与三方账单数据核对;保证金业务记账以及银行清结算数据的一致性
-
按核对频率获取业务支付数据
-
T+1或其他频率获取三方清算文件和结算文件
-
将清算和结算文件进行解析存储
-
根据对账项目配置完成交易数据和清算的核对
-
完成清算数据和结算数据的核对
-
对交易的单边数据和资金核对差异进行管理和处理
2.3.伽马金融管理核对架构
资金管理框架的资金账和银行账核对业务架构图
该图略,课程里会介绍该体系
核心几个关键点
-
统一收付平台收口收款、退款、调拨等资金业务
-
对资金业务统一记账形成统一资金账务
-
对集团的资金账户进行统一管理
-
余额调节对账完成资金账和银行的核对勾兑
-
账户的余额调节表
2.4.伽马支付核对业务架构
伽马支付为公众号案例中心虚拟的支付公司
2.5.通用对账系统架构
第一篇文章介绍过,我们可以脱离财务范畴,抽象出数据核对的通用架构,对数据逐笔准确性校验,实时监控;资金期初期末及发生额的资金校验核对;在这个理念下我们形成如下一个应用范围更广的通用架构
第三部分:对账文件获取和解析
支付交易的通道提供方,例如微信、支付宝、网联、银联等,都是按照约定频率和时间提供交易的记录文件,一般都是2份,一个清算文件“记录支付明细”;另一个是“结算文件”记录资金账户的实际的资金变动;对于文件的获取大部分在提供通道时会提供下载接口,另外如果没有接入下载接口,可以采用人工下载的方式获得文件,将文件传到对账系统获得对账数据;本文主要介绍渠道方的对账文件获取以及解析和管理
3.1.对账文件类型
主流类型还是Excel和txt,本文主要介绍的也是这2种
-
excel(csv)
支付宝,常见支付公司;这类文件最方便查看
-
txt
微信,银联个别通道,一些银行;这类文件很不便于查看
-
xml报文
网联;这类文件人工很难查看和处理
-
其他类型
银联还有一些通道文件
3.2.对账文件获取方式
-
接口获取
通过机构提供的文件查询和下载接口获取对账文件
支付宝下载接口示例
-
人工下载
如果技术能力资源不足,或者暂时没有接入接口,可以采用人工下载的方式,然后在对账中心上传对账文件进行解析
3.3.对账文件管理
-
文件管理方式
文件一般存放在对账系统指定的ftp内,并且对文件夹设定一定的命名规范,通过路径查询和下载文件
-
文件管理后台页面
在后台页面查看和下载文件,便于处理和排查对账问题
3.4.对账文件解析器配置
对账文件解析是指将文件里的数据解析到数据库内,形成数据库数据,因为文件数据不能直接被系统处理
-
原样解析
不改变文件的数据列数和内容,对文件数据保证不减少列数的前提下进行全量解析,可以根据需要增加列内容,比如账