如何设计财务对账系统 —— 从 0 到 1 搭建对账中心实战
第一章：对账系统概览
一、什么是对账？
1.生活中的对账场景 - 煎饼摊老板的故事
对账在我们的生活中非常常见。
举个例子：下班回家路上，你有点饿，看到路边有个煎饼。于是过去买了个煎饼，老板把煎饼递给你，然后指着墙上的二维码贴纸说「8 块」。
你拿出手机，扫码支付 8 元后，和老板说「8 块 ，过去啦」。紧接着老板听到自己手机播报说「微信收款：8 元。」老板心里确认了这笔钱到账了。你宣称「已付 8 元」，老板收款账户确认「已收 8 元」，这就是一次最简单的对账。
2.互联网公司中常见的对账场景 - 支付对账系统
在互联网公司中，只要带交易，就需要对账。不论是售卖实体物品的淘宝店、虚拟物品的在线课程，还是销售各种会员服务的视频网站，都需要对账，对账是整个交易流程中最后一道安全防线。
我们来举个淘宝店的例子，为了方便理解，这家淘宝店，只卖一种杯子，一个杯子 20 元，一个月只有 1 单生意，1 单卖 1 个杯子。
当用户下单购时，打印机自动打印出一份发货订单，老板根据这份纸质订单到库房拣货，然后交给快递公司发货。用户收到杯子，确认收货。20 元转入老板的账户。
（1）发货次日，老板盘点库房，发现少了一个杯子。于此同时，发现自己的账户里多了 20 元，正好是 1 个杯子的售价。这个对账过程叫账实核对。
（2）老板根据打印的订单对账，手里有一张纸质订单，订单总额 20 元，再看自己账户金额，多了 20 元。这个对账过程叫账证对账。
（3）月底对账时，发现账户只多了 10 元，于是老板翻出全部账本，发现订单账多了 20 元，快递发货账因发货减少 10 元（快递费）。一计算，收入 20 元（增加），快递费 10 元（减少），即账户账应增加 10 元。这个对账叫账账对账。
3.对账方式 - 杯子店出现的三种对账方式
（1）账实对账：是指我们记录的账与实物资产的实际数量进行对账。
（2）账证对账：是指将自己的账本与记账凭证进行核对。一般记账凭证由与你业务合作的第三方公司提供，在上面的杯子店的例子里，记账凭证由淘宝提供（订单）。
（3）账账对账：是指在上下游相互关联的账本之间进行对账。在整个交易过程中，一般会涉及上下游多套账，上游比如外部进货账、内部采购账，下游比如快递发货账、第三方服务费等。这些账和总账之间有非常多的关联性，所以一般账账核对，通常用于修正内部账的数据不一致。
「账证实」是对账的基础，后面我们会结合实例来讲解在对账系统搭建的过程中，如何把「账证实」融入进对账系统中。
二、为什么要对账
1.对账是整个支付系统中，最后一道安全防线。是交易流程中重要的纠错机制。
2.避免意外和人为错误发生
（1）意外错误：网络稳定性、内部系统（订单、支付、风控）的健壮性。
（2）人为错误：人为操作失误、上游、内部恶意修改等行为。
3.对账是财务流程中重要的一环，特别是当交易量上万/天，人工手动对账毫无可能时，为了避免订单差错越积越多，变成糊涂账，我们需要日日结清，对账也是保证公司财务健康的必要环节。
第二章：对账系统的架构
无论多么复杂、多么宏大的对账系统，都是由一个个「账与账」之间最简单的对比核查构成。我们只要搞清楚每一组账怎么核对，然后再将此逻辑应用至多组账即可，万变不离其宗。
为了缩减案例复杂度，方便大家理解，本案使用大多数电商都会接入的「支付宝」、「微信」两个支付渠道来举例。
其实不论是接入互联网风格的「支付宝」，还是接国企风格的「银行」，又或者是海外支付渠道「paypal」都是类似的。他们除了接口、文件格式、鉴权等细节上的差异外，在抽象层面，对账逻辑是一致的，一通百通。
一、如何搭建一套对账系统
1.设置对账的目标账
对账的核心是在不同系统中找到记录相同事件的账本，用这些关联账进行对比，发现其中的差错。
比如
（1）我方后台订单系统中的日结算金额与第三方支付系统中的日结算金额进行对比。
（2）我方库存系统中的库存量与我方订单系统中订单中发出的货品数量进行对比
2.获得账单数据（账单获取模块）
（1）出账时间：各渠道日结算账单生成时间不同，有凌晨生成的，也有上午 9 点生成的。搞清楚出账时间，设定好抓取/下载时间，让系统自动下载（或手动下载后再上传至对账系统）。
（2）账单文件格式：各渠道账单格式并不统一，有 csv、xml、txt、json 等，针对不同渠道，设定好对应的格式解析程序。
3.账单格式标准化（数据标准化模块）
各渠道账单针对同一个数据有不同的字段和命名方式。比如同一个「订单号」，支付宝叫「商户订单号」，我方系统中同样的数据叫「商城订单号」。再比如，同一个订单的支付金额，支付宝中叫「商家实收」，我方系统中叫「结算金额」。他们虽然命名不同，实际上是同一个数据在两套系统的反映。
所以我们首相要将来自支付宝、微信、银行系统、银联、paypal 等三方机构的账单数据统一口径，使数据可读，可对比。这个过程我们叫账单数据标准化。
4.账单核对（账单核对模块）
这一步大家一定要结合自己公司的业务逻辑来设计，不同的业务逻辑、财务管理方式会有不同的设计方法。但最基本的宗旨不会变，找出两套系统中对同一个订单的数据，对比这两个数据是否一致，找出差异，标记差异，在下一个模块处理。账单核对的细节，我们在第六章展开讲。
5.对账单差错处理（差异处理模块）
如果差错是可预见和可自动修复的，我们可使用机器自动处理，比如经典的「跨日支付」问题，订单创建在当日 23:59 分，支付时间在次日 00:01。这时，第三方支付渠道对应我方系统中订单的支付信息，会在 T+1 日出现。这种情况，等待拿到次日账单后，再对一次即可解决。
如果差错不可以自动处理，那么进入人工处理流程。人工处理首先要对比两组数据，找到问题所在，再手动执行解决方案，使两边对平。如果当下无法对平，可选择「挂起」，暂时存档差错，未来合适的时间再解决。关于差错处理，我们会在第七章详解。
第三章：对账文件获取
对账文件获取是整个对账系统的起点，我们首先要将支付宝、微信、银行、银联、第三方支付等支付渠道的对账单下载到本地，解析入库后，才能进行后续对账动作。每个支付渠道都有自己的结算周期和结算文件生成时间，以及文件格式，我们首先要查看支付渠道文档，把这些问题搞清楚。
一、对账文件下载
目前常见的渠道对账单下载方式主要有这几种
调用 API 下载账单：这种方式简单干净，设定好接口鉴权及每日下载时间即可。非常友好，支付宝、微信均为此种方式。
SFTP/FTP 下载账单：也是比较简单直接的获取方式，设定好本地目录及命名逻辑后，直接下载即可。
手动下载：少数渠道仍然需要手动下载，虽然也可以写前端自动代码去拿，但总归不太直接。
二、对账文件获取时间
每一家支付渠道，会根据自己的情况，约定日对账单生成时间，我们要搞清楚每一家支付渠道生成账单的时间，然后在这个时间之后一段时间再去拉账单，才能高效的让对账系统运转起来。
比如：微信支付，一般在次日上午9点左右出账单，我们 10 点以后拉取微信支付的对账单会比较合适。
更多信息还请前往渠道支付对应的官网文档中确认。总会有些特殊情况，比如银联的清分时间就跟大家不同，所以一定要看清文档。各支付渠道文档，见本文最后扩展资料部分。
三、对账文件的格式
不同渠道对账文件的格式也不同，总体来说分为 CSV、json、txt、xml 等格式。下面列举两类常见文件格式，供大家参考。
1.微信对账单： txt 文件
2.支付宝对账单：csv 格式
四、对账文档 API 获取
通过 API 获取支付机构对账文件，本文文末附支付渠道文档
微信支付下载交易账单的API 文档
第四章：对账文件标准化入库
每天从各第三方支付渠道获取的对账文件均为原始对账数据，一定要保存好这些原始文件，方便在未来整个支付或对账系统出错时，可以追根溯源。
一、原始对账文件标准化命名
我们需要将各个渠道的原始对账文件根据自身属性来重新统一命名，方便未来查找与使用。
例：「业务类型_支付渠道_清算日期_序列号.文件格式：alipay_20210721_03.csv」
当然，我们要根据自己公司接入的所有支付渠道的情况，更宏观的找到一套合适的命名方法。
二、对账文件数据统一标准化
由于各支付渠道有自己一套字段体系，我们需要将各渠道对账单中字段统一起来，标准化后再入库存储。
我们可以根据自己内部系统使用的字段为原点，来设计转化后的字段。对于多余和暂时用不到的字段可直接丢弃，减少冗余。未来需要时，我们可以从对账文件存储管理器中找到源数据。
通用对账单字段参考
注：上图字段引用无敌码农的总结，感谢前辈分享。文字版点这里下载
如果公司未来业务需要接入更多支付渠道，可以提前考虑对账系统的扩展性问题，设计一套解析流程，财务人员在后台即可设置新增对账账单的字段与公司内部订单系统字段是如何对应关联。
三、对账数据入库查看
各渠道对账数据清洗冗余信息，统一格式，解析入库后。我们可以在后台方便的查看每一天，各渠道对账数据，清晰明了。当在对账的任何环节出现问题，财务人员都可以在这里查询到对账系统，在对账时使用的数据，便于定位问题。
第五章：账单核对逻辑理解
本地对账数据与第三方支付对账数据就绪后，接下来我们可以将两边数据进行核对了。对账一般只有四种状态，两边一致（对平）、支付渠道多收了一笔（长款）、支付渠道少收一笔（短款）、本地和支付渠道两边都有，但数字不同（金额不一致）。其他错误都是这几种状态的扩展。
一、核对模块几种错误状态及处理方法
1.收款类交易对账
短款差错：我们的订单中有记录，但支付渠道对账单中没有记录。简单讲就是少收钱了。一般此类错误通常是碰到「跨日交易」，用户在 23:59 分下单，在 00:01 分支付。
长款差错：我们的订单中没有记录，但支付渠道收到钱了。简单讲就是多收钱了。一般此类错误多是我们的系统未正确接受支付渠道下发的支付成功返回信息。这种手动调整交易状态即可。
错账：两边都有记录，但金额对不上。
2.退款类对账
退款类对账的错误，其实和收款大同小异。一般有这几种情况。
本地未退款，渠道已退款：一般是渠道返回数据异常，按照渠道状态修改本地退款状态即可。
本地已退款，渠道无记录（或反过来本地无记录，渠道已退）：可能是「跨日交易」问题，如不是，只能人工排查处理。
本地与本地均为退款状态，但两边金额不同：需要人工排查处理。
如果会计的思路不好理解，我们也可以按数据组来分。如下表
我们来看这两张表，左表为我方订单数据，右表为支付渠道数据。两表之间由订单 ID 关联。
我们可以看到 ID1 两边数据一致，即「对平」 ；ID2 和 ID4 两表格分别缺失，即「单边」；ID3 虽然两边都有数据，单交易金额不一致，即「错帐」。
对账系统会自动标记「单边」和「错帐」的订单，这些订单需要进入「差错处理」来人工处理。
第六章：对账引擎逻辑设计
一、起终日期在对账系统中的作用
1.按时间顺序对账
因为订单付退款关联顺序、跨日等因素，对账必须按时间顺序，顺序对账，不能跨日对账。如项目其实日为 1 号，虽然今天已经是 15 号，对账时，也必须从 1 号开始对。因为 t 天单边账，需要在 t+1 天里继续核对。跳跃对账会产生非常多不必要的麻烦。
2.对账引擎设计
请务必从「开始」沿箭头方向走一遍这张图，此图信息量较大，请先仔细查看流程图，然后再继续阅读。
以「我方对账数据」作为基点，用「订单号」作为关联键，将我方对账数据与渠道方对账数据进行逐条对比。对比结果包含「对平」、「单边（长短款）」、「错账」。
3.对账任务创建与查询
整个对账引擎跑在服务器内，前端是看不到的，也不需要看。财务人员在创建任务时，只需要设定对账的起始日期和终止日结，勾选需要对账的订单库即可，剩下的交给对账引擎来完成。对账完毕后，财务人员再继续差错处理。
第七章：对账差错处理
自动对账执行完毕后，总会有一些系统无法自动匹配的错误。这些错误会在对账过程中被标记出来。在上一章我们已经讲过，差异错误包含「长款」、「短款」、「错帐」三个大类，实际对账过程中，出现对账差异的原因，千奇百怪，但不论差异有多奇怪，我们设计的差错处理流程，都应该能覆盖到。
一、差错处理逻辑设计
对于常见的有规律的差错单，我们可以设计一些规则来自动处理，比如跨日交易问题、三方渠道优惠券减免计算规则细微差异、货币转化等问题。
各家都有自己独特的交易流程，财务管理办法，业务特性，所以对账中出现的差错也是千奇百怪，好在这些差错均可以穷尽，我们只需要将碰到的差错归类，设计好解决方案，一个问题解决了，这一类问题就都解决了。
当自动规则无法平账时，需要我们手工处理。当下无法处理的，可以考虑挂起账单，未来合适的时间再处理。
二、差错处理业务规则系统化
当差错无法自动处理，需要人工手动处理时，我们需要把一套规范的流程和标准步骤写在系统里。
举例：当对账差错为「长款」时，支付渠道显示支付成功，我方订单查询为空，我方掉单。这时，财务人员需要发起「补单」，这个「补单」补单审核流程，我们可以把它当作一个处理选项，放在「人工手动处理」。
三、核对模块四种状态
对平正常：两边对比无异常，标记为正常。
差错未处理：两边对比异常，标记异常等待人工处理。
差错已处理：人工处理后标记已处理。
差错已挂起：某些暂时无法处理或永久忽略的问题标记挂起。
第八章：如何快速搭建对账系统
我用卡拉云（https://kalacloud.com）按照本文思路搭建了一套对账系统，几个月的活，5 天干完。卡拉云帮助后端程序员解决了数据库接入、API 调用等问题，前端组件拖放即用，可快速构建企业内部工具。
卡拉云接入数据库及 API 的页面，支持常见的数据库和 API ，只需简单填写表单即可完成复杂的数据接入。
第九章：扩展资料
一、支付对账系统快速搭建工具
卡拉云 - 支持快速接入数据库、API，前端组件即拖即用。可快速搭建对账系统。
二、支付渠道接入文档
三、对账系统搭建参考资料及拓展阅读
版权声明: 本文为 InfoQ 作者【蒋川】的原创文章。
原文链接:【http://xie.infoq.cn/article/5f4b4b4ddfcacbc4c22f70acd】。
本文遵守【CC BY-NC-ND】协议，转载请保留原文出处及本版权声明。
我的微信：HiJiangChuan 2020.09.08 加入
卡拉云 CMO 卡拉云是一套帮助后端程序员搭建企业内部工具的系统，欢迎试用 kalacloud.com
评论