精华内容
下载资源
问答
  • 第一章:对账系统概览 一、什么是对账? 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.对账任务创建与查询

    整个对账引擎跑在服务器内,前端是看不到的,也不需要看。财务人员在创建任务时,只需要设定对账的起始日期和终止日结,勾选需要对账的订单库即可,剩下的交给对账引擎来完成。对账完毕后,财务人员再继续差错处理。

    第七章:对账差错处理

    自动对账执行完毕后,总会有一些系统无法自动匹配的错误。这些错误会在对账过程中被标记出来。在上一章我们已经讲过,差异错误包含「长款」、「短款」、「错帐」三个大类,实际对账过程中,出现对账差异的原因,千奇百怪,但不论差异有多奇怪,我们设计的差错处理流程,都应该能覆盖到。

    一、差错处理逻辑设计

    对于常见的有规律的差错单,我们可以设计一些规则来自动处理,比如跨日交易问题、三方渠道优惠券减免计算规则细微差异、货币转化等问题。

    各家都有自己独特的交易流程,财务管理办法,业务特性,所以对账中出现的差错也是千奇百怪,好在这些差错均可以穷尽,我们只需要将碰到的差错归类,设计好解决方案,一个问题解决了,这一类问题就都解决了。

    当自动规则无法平账时,需要我们手工处理。当下无法处理的,可以考虑挂起账单,未来合适的时间再处理。

    二、差错处理业务规则系统化

    当差错无法自动处理,需要人工手动处理时,我们需要把一套规范的流程和标准步骤写在系统里。

    举例:当对账差错为「长款」时,支付渠道显示支付成功,我方订单查询为空,我方掉单。这时,财务人员需要发起「补单」,这个「补单」补单审核流程,我们可以把它当作一个处理选项,放在「人工手动处理」。

    三、核对模块四种状态

    • 对平正常:两边对比无异常,标记为正常。
    • 差错未处理:两边对比异常,标记异常等待人工处理。
    • 差错已处理:人工处理后标记已处理。
    • 差错已挂起:某些暂时无法处理或永久忽略的问题标记挂起。

    第八章:如何快速搭建对账系统

    卡拉云低代码工具

    我用卡拉云按照本文思路搭建了一套对账系统,几个月的活,5天干完。卡拉云帮助后端程序员解决了数据库接入、API 调用等问题,前端组件拖放即用,可快速构建企业内部工具。

    卡拉云可添加的数据源

    卡拉云接入数据库及 API 的页面,支持常见的数据库和 API ,只需简单填写表单即可完成复杂的数据接入。

    第九章:扩展资料

    一、支付对账系统快速搭建工具

    • 卡拉云 - 支持快速接入数据库、API,前端组件即拖即用。可快速搭建对账系统。

    二、支付渠道接入文档

    三、对账系统搭建参考资料及拓展阅读

    本文作者

    蒋川,卡拉云联合创始人,B 端产品经理,专注研究企业内部效率工具实施搭建。
    个人微信:HiJiangChuan,欢迎一起交流。
    卡拉云面向产品与技术的企业内部工具开发平台,只要会写SQL,即可快速上手。
    如果本文对你有帮助,想了解更多,欢迎访问我们的网站「卡拉云

    展开全文
  • 支付系统-对账系统

    万次阅读 多人点赞 2019-04-08 14:17:04
    在支付系统中,资金对账在对账中心进行,将系统保存的账务流水与银行返回的清算流水和清算文件进行对账,核对系统账务数据与银行清算数据的一致性,保证支付机构各备付金银行账户每日的预计发生额与实际发生额一致。...

           在支付系统中,资金对账在对账中心进行,将系统保存的账务流水银行返回的清算流水和清算文件进行对账,核对系统账务数据与银行清算数据的一致性,保证支付机构各备付金银行账户每日的预计发生额与实际发生额一致。

    一、清算对账系统

           支付公司提供的所有金融服务是建立在银行资金体系之上的,支付公司账务系统内账户的资金都与其在银行的存款资金一一对应,为了保证真实的资金账户和虚拟账户的资金转换正确,支付公司必须及时与银行进行各类业务的资金核对,所有资金核对都依赖于银行的系统。

    1.1、资金流入与银行的对账

           从银行流入的资金是由银行侧控制资金结转清算与对账时间,即每日客户通过银行向支付机构充值的资金是由银行实时通知支付机构充值指令的发生,银行在每日晚间经过汇总后向支付机构的银行收款账户入账,同时提供入账清算文件。支付机构获取该文件后,与业务数据进行核对。

           对账结果若相符,则没有问题。若出现对账结果不符,很有可能是系统或者业务在某些环节发生问题,存在两种情况:

    (1)、银行充值明细多,支付机构充值明细少;即银行向支付机构入账资金多于支付机构业务发生情况,一般采取临时挂账处理,查出原因后再具体解决;
    (2)、银行充值明细少,支付充值明细多;即银行向支付机构入账资金少于支付机构业务发生情况,则可能对支付机构产生资金损失,一般采取临时挂账处理,查出原因后再具体解决。

    1.2、资金流出与银行的对账

           从支付公司流出的资金是由银行侧控制资金结转清算与对账时间,即每日客户向支付机构申请提现的资金是在每日支付公司批量向银行发起提现请求时,从支付公司银行存款账户扣转,但扣转的结果一般需要一段时间才能从银行侧得到反馈。

           当银行侧提供扣转成功和失败的清算文件,支付公司获取这些文件进行明细核对,对于提现失败的申请,由支付公司后台发起直接将资金回充入客户账户,不在对账中心进行对账处理

    二、什么是对账

    2.1、什么是资金对账

    在会计上的概念:指为了保证账簿记录的正确性而进行的有关账项的核对工作,做到账实相符(正确性)、账证相符(真实性)、账账相符
    在支付机构的概念:资金对账在对账中心进行,将系统保存的账务流水与银行返回的清算流水和清算文件进行对账,核对系统账务数据与银行清算数据的一致性,保证支付机构各备付金银行账户每日的预计发生额与实际发生额一致。即核对银行实际清算资金如充值、充退、提现等业务的银行处理结果是否一致

    2.2、对账中心的作用

           对账中心是主要处理对账的系统模块,主要业务是清算对账。对账中心部署于工作平台,分别接受会计系统和清算系统的数据输入进行对账处理。

           对账中心最主要的职责是勾兑银行清算流水与支付系统入账流水,用以检查反映银存实际账户的余额变化支付系统内部户余额变化是否平衡。对于已经核对无误的银行清算流水和支付系统入账流水,分别进入相应的历史银行流水库历史入账流水库

           对于勾兑结果中银行清算流水多于系统入账流水的,而操作人员不明确资金的来源,需要根据所设定的分类规则将暂不明确的资金进行挂账处理。而后我们认为该部分资金已经系统入账,可以入历史流水库。
           因为此时的银存实际账户的余额增加,与之对应的是支付系统内部户余额也增加了,比如: T 日的挂账可能会在 T+N 日后进行销账确认,而后续的销账行为是对明细流水的业务分流处理,我们不应将 T+N 日的销账所产生的账务流水作为入账流水,不再需要到对账中心体现。

    三、对账内容和数据来源

    第一步:入账流水和清算流水进行核对,目的是保证对每一笔订单银行的处理结果和我们系统的业务处理结果一致。
    第二步:对账汇总确认单和银行对账单进行核对,目的是通过轧余额等方式核对各类业务的银行处理结果是否与银行实际清算给我们的资金一致。

    3.1、对账业务流程

    对账业务流程图


    3.2、对账中心主要功能

           银行发生资金变动的入账流水,包括:充值、提现、提现失败、充退、充退失败、退票、购汇、信贷放款、信贷还款、还贷失败一系列业务引起的账务变动信息。这些业务流水在账务系统入账后,会计核心接收到登记分录请求并处理完毕,发送该流水至对账中心,对账中心对于某个业务的反向资金变动所产生入账流水也同步至对账中心。
            这样做的目的是让待清算与入账流水在日切点保持等额,比如:提现 T 日会员申请提现,生成文件后会员账户提现金额转入待清算提现款项,与此同时发送流水到对账中心,此时待清算与对账中心入账流水是保持平衡的。
    而 T+1 日银行处理失败,系统会回充带清算提现款,如果此时不发送失败流水到对账中心与其对应的流水进行购销的话,则入账流水就会不变,和带清算提现不平衡。

    (1)、完整的日结流程支持:银行清算流水入库 → 流水对账 → 流水分类 → 汇总确认单 → 自动挂账 → 销账确认 → 操作员轧账 → 总账日结以及登记银行余额等。
    (2)、完善的报表模型输出:如按入账日期 / 银行日期 / 清算日期等的统计报表、银行账户余额报表、未达款项报表等;
    (3)、提供日切服务:在经确认后进入历史清算流水的,同步汇总该部分数据进入历史流水汇总表中保存,所以在日切时,只需直接将该汇总数据再次汇总即可。
    (4)、外围业务功能支持:提供对于银行账户( 独立于对账中心之外,不参与处理逻辑 )的管理功能,支持与内部户的映射管理,用以满足部分报表需求;提供基于账务核心所提供的业务代码查询功能;提供对于财务系统的交互支持,包括与财务科目的对应关系管理、通知流水数据等;提供用以校验订单与清算流水匹配状态的错账核实功能。

    对账流程图

    四、对账中心功能模块分析

    4.1、获取资金对账数据

    (1)、获取方式:需要进行清算流水导入的文件一般通过人工在页面上导入,另外有些业务的流水文件通过系统自动匹配或者定时获取的方式得到。
    (2)、清算流水导入渠道:需要统一各清算流水导入功能到一个页面入口, 同时引入清算通道对账的逻辑,将清算流水导入过程需要映射清算通道( 包含新增清算流水等 )。
    (3)、各类业务的清算流水文件的解析和导入逻辑不一样。

    4.2、清算流水对账

    4.3、对账逻辑

    (1)、一对一对账

           入账流水只可能存在一条,银行入账流水也仅存在一条,然后一对一去对。目前按照一对一对账的业务涉及到:网银 B2C 充值、网银 B2B 充值、VISA、网汇E、卡通充值、正常提现、认证提现、银企互联提现、卡通提现、卖家信贷、信用卡还款提现、COD、网点支付。

    对账标准(清算通道 + 订单号 + 金额) Or (银行名称 + 业务代码 + 订单号 + 金额)

    满足一对一的业务如下:

    提现成功:500401
    认证提现:500402
    还贷:500404
    卡通提现:500403
    个人网银充值:400301
    企业网银充值:400302
    VISA:400314
    网汇e:400315
    卡通充值:400304
    贷款:400307
    银企互联提现:500405
    信用卡还款提现:500407
    后台强制提现500406
    COD
    网点支付

    Tips:
    (1)、清算流水有,入账流水也有,金额一致,对账成功,清算流水、对账流水打上 ‘对账成功’ 标志,记录对账日期为系统当日;
    (2)、清算流水有,入账流水也有,金额不一致,清算流水记金额不等,记录对账日期为系统当日,入账流水不变;
    (3)、清算流水有,入账流水该订单号没有,清算流水打上 ‘银行多帐’ 的标志,记录对账日期为系统当日;
    (4)、清算流水有,入账流水没有该业务代码初始状态的,清算流水打上 ‘银行多帐’ 的标志,记录对账日期为系统当日;
    (5)、清算流水有,入账流水没有该银行的初始状态的记录,清算流水打上 ‘银行多帐’ 的标志,记录对账日期为系统当日;
    (6)、对账之前需要判断 1 对 1 的流水中是否有重复,有重复的返回失败不进行后续对账

    (2)、多对多对账

           入账流水里相同订单号,相同清算渠道,相同,金额相同业务代码的流水存在对条(比如充退);而银行清算流水也可能是存在多条的情况的,这种情况下是多对多去对账的,遵循先到的先对的原则。

    对账标准:(清算通道 + 订单号 + 金额) Or (银行名称 + 业务代码 + 订单号 + 金额)

    满足多对多的业务如下:

    充退:410401
    银企互联充退:410402
    Motopay 充退:410403

    Tips:
    (1)、清算流水有,入账流水有,满足对账标准,则对账成功,清算流水、对账流水打上 ‘对账成功’ 标志,记录对账日期为系统当日;
    (2)、清算流水有,入账流水有,金额不等,清算流水打上 ‘金额不等’ 的标志,记录对账日期为系统当日,入账流水不变;
    (3)、清算流水有,入账流水没有该订单号,清算流水打上‘银行多帐’ 的标志,记录对账日期为系统当日;
    (4)、清算流水有,入账流水没有初始状态 410401 的流水,清算流水打上 ‘银行多帐’ 的标志,记录对账日期为系统当日;
    (5)、清算流水有,入账流水没有这个银行初始状态 410401 的流水,清算流水打上 ‘银行多帐’ 的标志,记录对账日期为系统当日;
    (6)、清算流水有,入账流水没有初始状态的 ‘410401’ 的流水,清算流水打上 ‘银行多帐’ 的标志,记录对账日期为系统当日。

    (3)、一对多对账

           入账流水有多条,和银行的一条去对账。
    对账标准(清算通道 + 订单号 + 金额) Or (银行名称 + 业务代码 + 订单号 + 金额)

    涉及的业务:境外收单

    境外收单购汇扣款(520101)
    购汇益回补购汇账户(400319)

    Tips:
    (1)、入账流水存在 2 条 520101 的,清算流水存在 1 条 520101 的,将入账流水的 2 条加和后的金额和清算流水的进行对账,一致的为对账成功;
    (1)、入账流水存在 1 条 520101 的,1 条 400319 的,那么要将 2 条金额之差和清算流水的 1 条 520101 的进行对账。不会出现 3 条 520101 或者 2 条 400319 的情况。

    4.4、对账功能

    (1)、内部流水购销

           内部流水购销是针对那种有入账流水表来说的,比如提现业务,提现文件生成就会扣款此时会同步一笔入账流水;而回导失败之后又会回充,此时也会同步一笔反向的业务流水,这两条流水不用再去和银行的资金流水进行对账,直接在入账流水这边进行购销即可。
    需要购销的业务如下:


    (1)、购销的规则:非已勾销状态下,同一银行同一订单号,金额一致而业务代码相反的正向流水进行勾销,而且一条反向流水只勾销一条;
    (2)、日终轧账时候的购销:日终轧账的时候会对未购销的流水再次进行购销确保当天的流水都购销完全。(这个情况是为了解决反向流水先于正向流水先出现的逻辑错误情况而加的并提示流水号);
    (3)、如果业务代码相反,而金额不等的情况,就无法进行购销,这种情况原来是作为违反逻辑规则来进行标记的。这部分数据进行查明之后,可以修改流水之后,在日终轧账的时候从新进行购销;
    (4)、购销分 ‘一对一’(提现)和 ‘多对多’ (充退)的购销;
    (5)、勾销的流水不入历史库。

    (2)、对账汇总确认单

           显示对账结果,选择后续的相应的处理界面,复核员在此模块进行流水的确认,还有的功能就是对于已经对账处理的银行清算流水与系统入账流水进行后续业务分流推进。

    (1)、对于大部分对账成功的数据,可以将这些流水确认,确认后该部分流水将进入历史清算流水,只有进入历史清算流水的才认为银行与支付系统数据对平。对账成功的银行清算流水、账务入账流水全部进入各自历史清算流水表保存,相应的银行清算流水与入账流水同步删除。
    (2)、金额不等的流水,可能是银行清算流水文件有误,也可能是错账,采取的做法是操作员手工修改金额,在银行清算流水管理里操作或直接删除,将其推进到下一轮的对账处理环节,对账是可以重复对的,只要满足初始状态要求的流水即可。
    (3)、多账部分,由于各种已明确/未明确的原因,银行已经实际清算给支付公司了,但支付公司的账务系统并没有入账,需要提供一个流水分类和分类汇总挂账的操作入口。系统默认多账的流水给出的菜单是流水分类,金额不等的流水给出的流水管理页面。区别在于,在点流水分类时,只允许修改业务类型、银行日期,而且改完后不改变多账状态;流水管理,修改状态后,流水的对账状态将变成初始状态,需要进行重新对账。
    (4)、流水进入历史库的校验规则。

           举例说明:A 操作员导入了一笔流水,系统对账成功,银行清算流水与账务入账流水状态都被置为成功状态;B 操作员再次导入该相同流水,由于入账流水处于成功状态的可以继续对账,所以再次对账成功。系统在对账环节认为正常,但在入历史清算流水时必须做每组流水数据的平衡检查:必须是清算流水总额与入账流水总额匹配才可以进历史数据。
           对于上述的场景,如复核员针对 B 操作员的对账成功流水确认后,可以正常进入历史流水,对账批次号认最后操作的批次。而继续对 A 操作员的成功对账流水确认,则系统将认为是不合法的入历史流水行为。或者不对特定操作员的汇总确认,系统必须检验出所存在的重复银行清算流水,并将对应的明细数据显示复核员。此时可将该重复对账的清算流水删除即可。

    (3)、流水分类和分类汇总挂账

    (1)、对于多账的流水对账中心提供一个单独的处理入口,首先在此处进行分类,然后进行汇总挂账处理。操作人员可以根据多账流水的未确认类型修改成对应的业务代码,允许修改成业务类型为 7 的可挂账的类型(其他业务代码不允许挂账);流水可以重复分类,系统不做控制;但已申请挂账的除外,分类完毕的多账流水可直接提供分类汇总挂账操作。
    (2)、系统根据既定的业务代码判断是待查收入或待查支出挂账,页面跳转至相关凭证登记页面,此处业务规则同待查收支挂账;另一部分比如退票,因为不经过对账环节,所以需要直接在清算流水查询里面新增,业务代码 700106 未确认退票,不需要经过对账,直接去汇总确认单里将流水挂账。允许挂账的业务代码如下 :700101 其他应付款,700102 其他应收款,700103 银行错账,700104 未确认结汇款,700105 线下汇款,700106 未确认退票,700107 未确认收款,700108 未确认支出款。
    (3)、提交凭证登记申请相关校验:流水此刻状态是否是 ‘多帐’ ,申请提交人是否是当时的对账人,凭证登记成功,清算流水记录凭证号,流水状态改为 ‘已挂账’ ;
    (4)、汇总挂账的反交易同步入账流水,金额是负值,系统在清算流水里在做一条数据,自动对账。

    (4)、清算/入账/历史流水管理

    清算流水管理

    对于所有的清算流水,都可以在此模块下进行查询、修改、删除,同时也可以新增流水。

    (1)、查询功能,银行名称、业务代码、银行日期不能为空,业务代码和银行可以多选。
    (2)、修改功能,处于未对账(初始)、金额不等、多账、对账成功状态的流水可以进行单笔、批量修改操作,这里的批量修改动作与流水分类功能类似,只是该功能入口不仅支持对批量流水的业务代码、银行日期更新,也支持其他要素信息批量修改,作为(3)、提供给操作员在未对账前批量修改已知流水的手段之一;对已挂账的流水,不允许更新。
    流水删除:处于未对账(初始)、金额不等、多账、对账成功状态的流水可以进行单笔、批量删除操作,已挂账状态不允许删除。

    入账流水管理

    入账流水管理功能提供对账务入账流水的查询以及下载功能;为了杜绝对入账流水的人为变更操作,禁止支持对入账流水进行修改或删除处理

    (1)、查询时银行名称、业务代码、入账日期不能为空,业务系统流水号:针对某类业务的业务流水号,如充值业务就是充值流水号;账务流水号:账务处理的流水号,即账务操作记录数据的序号,在账户明细查询里可以获取。
    (2)、对于提现类失败回充的流水,在操作员进行对账动作后,系统自动进行购销,在入账流水查询时,将对账状态选为已购销可以查到,这些不进入历史库,根据数据量,系统定时清理这些数据。

    历史流水管理

           分为历史入账流水和历史清算流水,查询功能在同一页面,查询时可以一起查询,也可以单独查询。历史流水只供查询和下载,不允许进行修改和删除操作。选择历史银行流水和历史清算流水(清算日期的时间间隔不能超过 7 天)进行查询,历史入账流水中无银行日期,历史银行流水中无入账日期。

    (5)、银行余额录入功能

           在该模块下,实现对每个银行账户的实际余额录入,以此来和内部账户余额进行匹配校验。分为银行余额登记,银行余额导入(复核),以及银行余额查询功能。

    (1)、银行余额登记:选择对应日期以及银行账户录入后,保存,此时去银行余额查询是看不到录入余额的,需要复核导入核对完毕后才能看到,保证核对的有效性。登记后系统记录一个临时余额。系统每天凌晨 1:15 的时候会跑批,取上一日已复核过的余额自动带入下日临时余额,如果不登记的话,就取上日余额。
    (2)、银行余额导入:标准格式是一个填写银行余额的 excle 模板,导入后的核对逻辑,对复核员导入的数据进行检测该帐户是否有临时余额。根据银行账号、银行日期、银行余额等条件查询银行余额表。
           判断 1 :如果查询出结果为空那么将返回给用户:“这个银行帐号找不到对应的银行临时余额!”。
           判断 2 :如果查询结果大余一条,将返回给用户:“这个银行帐号的一天有多个银行临时余额,不正常!”
           判断 3 :检测该银行帐号对应的银行余额是否相等。如果不相等将返回给用户:“临时余额和实际余额不相等,核对失败!”当余额核对成功后,将复核员导入的余额写入该对应帐户的实际余额,并修改余额状态为已复核。实际余额更新成功后,将删除当天日期的临时余额。
    (3)、银行余额查询:对操作员登记余额的信息,以及复核员复核过的余额进行查询,查询条件:银行名称、银行帐户、帐户状态、银行日期、余额状态。帐户状态:分为正常、废除、和销户三个状态,默认为正常状态。余额状态:分为未录入(N)、已录入(A)、已复核(Y)三个状态,默认为全部。

    (6)、内部账户登账

           业务简述:针对日常结算工作中非银行待查类的内部账户进行登记,如:清算款、利息、手续费等;该业务登记不产生后续业务登记行为,即不具有作为初始凭证号的使用功能。对于批量销帐类业务处理中,多会员转帐失败的,导致过渡户上有剩余金额情况的,可通过此处进行内部户登账,将过渡户(负债)和银存(资产)余额同时减少,再通过待查收入挂帐实现平衡。

    业务校验规则:

    (1)、必须登记的是一借一贷帐户信息;
    (2)、借贷方帐户不能一致;
    (3)、金额必须大于 0 ;
    (4)、不允许任意一方是销帐帐户。

    是否同步对帐中心流水:不需要同步对帐中心流水

    (7)、待查收入挂账

           业务简述:应用于结算操作员针对日常结算工作中的银行待查收入进行登记,所产生的业务凭证号作为后续销帐业务的原业务凭证号,并且作为所有该登记所引发的后续业务登记的初始凭证号。其中待查收入挂帐业务凭证的借方(银存帐户)所对应的银行名称作为后续销帐业务的银行名称,包括差额重新挂帐部分再销帐的业务凭证,都递沿该银行名称。

    业务校验规则:

    (1)、必须登记的是一借一贷帐户信息;
    (2)、借贷方帐户不能一致;
    (3)、金额必须大于 0 ;
    (4)、借方帐户必须是银存帐户;
    (5)、贷方帐户必须是销帐帐户。

    是否同步对帐中心流水:不需要同步对帐中心流水

    (8)、待查收入确认

           业务简述:针对银行待查收入登账的挂帐,可以通过本模块进行销帐。此处采取销帐确认方式进行处理,需要选择相应的待查收入挂帐业务凭证进行销帐业务登记。该业务登记可能产生后续业务登记行为,如差额销帐情况下,系统会自动做不足额部分的重新挂帐并复核通过,所产生的挂帐凭证作为后续销帐凭证的销帐卡片号。

    业务校验规则:

    (1)、所销的原待查收入挂帐凭证必须合法;
    (2)、所销的原待查收入挂帐凭证必须已复核通过,处理完毕;
    (3)、所销的原待查收入挂帐凭证不能已被销帐;
    (4)、销帐总额(贷方发生额之和不得大于原待查收入挂帐凭证发生额)并大于 0 ;
    (5)、贷方必须是内部户。

    (9)、待查支出挂账

          业务简述:针对日常结算工作中的银行待查支出进行登记,所产生的业务凭证号作为后续销帐业务的原业务凭证号,并且作为所有该登记所引发的后续业务登记的初始凭证号。其中待查收入挂帐业务凭证的贷方( 银存帐户)所对应的银行名称作为后续销帐业务的银行名称,包括差额重新挂帐部分再销帐的业务凭证,都递沿该银行名称。

    业务校验规则:

    (1)、必须登记的是一借一贷帐户信息;
    (2)、借贷方帐户不能一致;
    (3)、金额必须大于 0 ;
    (4)、贷方帐户必须是银存帐户;
    (5)、借方帐户必须是销帐帐户 。

    是否同步对帐中心流水:不需要同步对帐中心流水

    (10)、待查支出确认

           业务简述:针对银行待查支出登账的挂帐,可以通过本模块进行销帐。此处采取销帐确认方式进行处理,需要选择相应的待查支出挂帐业务凭证进行销帐业务登记。该业务登记可能产生后续业务登记行为,如差额销帐情况下系统会自动做不足额部分的重新挂帐并复核通过,所产生的挂帐凭证作为后续销帐凭证的销帐卡片号。

    业务校验规则:

    (1)、所销的原待查支出挂帐凭证必须合法;
    (2)、所销的原待查支出挂帐凭证必须已复核通过,处理完毕;
    (3)、所销的原待查支出挂帐凭证不能已被销帐;
    (4)、销帐总额(借方发生额之和不得大于原待查收入挂帐凭证发生额)并大于0 ;
    (5)、借方必须是内部户。

    五、意外数据恢复逻辑

    5.1、意外数据恢复逻辑

    (1)、重复支付:对同一内部订单号进行了二次或二次以上的支付。
    (2)、支付失败,金额不等:买家实际支付的金额与交易金额不等。一般产生的原因是,买家在支付时,产生了掉单,卖家随后修改了交易价格。 在进行网银对账的时候,即会出现订单金额和交易金额不等的情况,且是一笔掉单。2、3 两类情况只发生在支付上。
    (3)、支付成功,金额不等:商户订单状态为成功,后台订单状态也为成功,并且交易状态是买家已付款,等待卖家发货。

           金额不等,支付成功:是因为会员对一个交易进行支付,但由于网络或银行系统等原因支付公司未接收到银行扣款信息,支付侧交易状态未予以变更,后卖家对该交易修改了价格,买家又对该修改过的价格进行了支付。但该支付成功的信息仍然没有被支付侧接收到,该交易状态仍未变更,后支付侧后台人员先对后面的那笔意外数据进行了恢复,后再对前面那笔意外数据恢复,就会出现这种“金额不等,支付成功”的数据

    5.2、对帐及异常恢复逻辑

    (1)、以商户成功订单为准

    用商户上的成功订单与后台的订单来核对:

    (1)、若商户订单为成功,后台为初始或者失败,则更改后台状态为成功;
    (2)、若后台为成功,商户成功订单中无该订单(时间差),则不更改后台状态;
    (3)、若后台为初始或失败,商户成功订单中无该订单,则不更改后台状态。

    (2)、不重复恢复

           T+1 日恢复T 日的订单,并且在 T+1 日后不再下载 T 日的订单进行二次或多次恢复。(为考虑会员感受,T 日下班前恢复 T 日 0 点到下班时点的订单)

    (3)、时间性差异

            由于各家银行系统日切点均不同,并且大多不会在每日的 24 点(或早或晚),所以下载到的 T 日的订单流水与后台T日( 0:00-24:00 )的订单流水并不能全部对应上。将商户订单流水与后台订单流水核对,会出现商户有,后台无商户无,后台有商户有,后台有三种情况。对于 1、2 两种情况为我们所说的时间性差异。

    商户数据与后台数据的关系为:商户数据-(商户有,后台无)+(商户无,后台有)= 后台数据

    展开全文
  • 在支付系统中,资金对账在对账中心进行,将系统保存的"账务流水"与银行返回的"清算流水"和"清算文件"进行对账, 核对系统账务数据与银行清算数据的一致性,保证支付机构各备付金银行账户每日的预计发生额与实际...

              支付系统:[ 支付系统]

              在支付系统中,资金对账在对账中心进行,将系统保存的"账务流水"与银行返回的"清算流水"和"清算文件"进行对账,

              核对系统账务数据银行清算数据的一致性,保证支付机构各备付金银行账户每日的预计发生额与实际发生额一致

             

    一、清算对账系统

           支付公司提供的所有金融服务是建立在银行资金体系之上的,支付公司账务系统内账户的资金都与其在银行的存款资金一一对应,为了保证真实的资金账户和虚拟账户的资金转换正确,支付公司必须及时与银行进行各类业务的资金核对,所有资金核对都依赖于银行的系统。

        1.1、资金流入与银行的对账

                      从银行流入的资金是由银行侧控制资金结转清算与对账时间,即每日客户通过银行向支付机构充值的资金是由银行实时通知支付机构充值指令的发生,银行在每日晚间经过汇总后向支付机构的银行收款账户入账,同时提供入账清算文件。支付机构获取该文件后,与业务数据进行核对。

           

        

           对账结果若相符,则没有问题。若出现对账结果不符,很有可能是系统或者业务在某些环节发生问题,存在两种情况:

        (1)  、银行充值明细多,支付机构充值明细少;即银行向支付机构入账资金多于支付机构业务发生情况,一般采取临时挂账处理,查出原因后再具体解决;
     (2)、银行充值明细少,支付充值明细多;即银行向支付机构入账资金少于支付机构业务发生情况,则可能对支付机构产生资金损失,一般采取临时挂账处理,查出原因后再具体解决。

         

      1.2、资金流出与银行的对账

                    从支付公司流出的资金是由银行侧控制资金结转清算与对账时间,即每日客户向支付机构申请提现的资金是在每日支付公司批量向银行发起提现请求时,从支付公司银行存款账户扣转,但扣转的结果一般需要一段时间才能从银行侧得到反馈。

                    当银行侧提供扣转成功和失败的清算文件,支付公司获取这些文件进行明细核对,对于提现失败的申请,由支付公司后台发起直接将资金回充入客户账户,不在对账中心进行对账处理。

            

    二、什么是对账

                                                  

                   

    2.1、什么是资金对账

    在会计上的概念:指为了保证账簿记录的正确性而进行的有关账项的核对工作,做到账实相符(正确性)、账证相符(真实性)、账账相符。
    在支付机构的概念:资金对账在对账中心进行,将系统保存的账务流水与银行返回的清算流水和清算文件进行对账,核对系统账务数据与银行清算数据的一致性,保证支付机构各备付金银行账户每日的预计发生额与实际发生额一致。即核对银行实际清算资金如充值、充退、提现等业务的银行处理结果是否一致。

    2.2、对账中心的作用

           对账中心是主要处理对账的系统模块,主要业务是清算对账。对账中心部署于工作平台,分别接受会计系统和清算系统的数据输入进行对账处理。

           对账中心最主要的职责是勾兑银行清算流水与支付系统入账流水,用以检查反映银存实际账户的余额变化与支付系统内部户余额变化是否平衡。对于已经核对无误的银行清算流水和支付系统入账流水,分别进入相应的历史银行流水库和历史入账流水库。

           对于勾兑结果中银行清算流水多于系统入账流水的,而操作人员不明确资金的来源,需要根据所设定的分类规则将暂不明确的资金进行挂账处理。而后我们认为该部分资金已经系统入账,可以入历史流水库。
           因为此时的银存实际账户的余额增加,与之对应的是支付系统内部户余额也增加了,比如: T 日的挂账可能会在 T+N 日后进行销账确认,而后续的销账行为是对明细流水的业务分流处理,我们不应将 T+N 日的销账所产生的账务流水作为入账流水,不再需要到对账中心体现。

                                                   

     

    三、对账内容和数据来源

    第一步:入账流水和清算流水进行核对,目的是保证对每一笔订单银行的处理结果和我们系统的业务处理结果一致。
    第二步:对账汇总确认单和银行对账单进行核对,目的是通过轧余额等方式核对各类业务的银行处理结果是否与银行实际清算给我们的资金一致。

     

                           

    3.1、对账业务流程

                       

    对账业务流程图

                                      

    3.2、对账中心主要功能

           银行发生资金变动的入账流水,包括:充值、提现、提现失败、充退、充退失败、退票、购汇、信贷放款、信贷还款、还贷失败一系列业务引起的账务变动信息。这些业务流水在账务系统入账后,会计核心接收到登记分录请求并处理完毕,

          发送该流水至对账中心,对账中心对于某个业务的反向资金变动所产生入账流水也同步至对账中心。
          这样做的目的是让待清算与入账流水在日切点保持等额,比如:提现 T 日会员申请提现,生成文件后会员账户提现金额转入待清算提现款项,与此同时发送流水到对账中心,此时待清算与对账中心入账流水是保持平衡的。
    而 T+1 日银行处理失败,系统会回充带清算提现款,如果此时不发送失败流水到对账中心与其对应的流水进行购销的话,则入账流水就会不变,和带清算提现不平衡。

               

    (1)、完整的日结流程支持:银行清算流水入库 → 流水对账 → 流水分类 → 汇总确认单 → 自动挂账 → 销账确认 → 操作员轧账 → 总账日结以及登记银行余额等。
    (2)、完善的报表模型输出:如按入账日期 / 银行日期 / 清算日期等的统计报表、银行账户余额报表、未达款项报表等;
    (3)、提供日切服务:在经确认后进入历史清算流水的,同步汇总该部分数据进入历史流水汇总表中保存,所以在日切时,只需直接将该汇总数据再次汇总即可。
    (4)、外围业务功能支持:提供对于银行账户( 独立于对账中心之外,不参与处理逻辑 )的管理功能,支持与内部户的映射管理,用以满足部分报表需求;提供基于账务核心所提供的业务代码查询功能;

                 提供对于财务系统的交互支持,包括与财务科目的对应关系管理、通知流水数据等;提供用以校验订单与清算流水匹配状态的错账核实功能。

                              

    四、对账中心功能模块分析

    4.1、获取资金对账数据

    (1)、获取方式:需要进行清算流水导入的文件一般通过人工在页面上导入,另外有些业务的流水文件通过系统自动匹配或者定时获取的方式得到。
    (2)、清算流水导入渠道:需要统一各清算流水导入功能到一个页面入口, 同时引入清算通道对账的逻辑,将清算流水导入过程需要映射清算通道( 包含新增清算流水等 )。
    (3)、各类业务的清算流水文件的解析和导入逻辑不一样。

    4.2、清算流水对账

                 

    4.3、对账逻辑

    (1)、一对一对账

           入账流水只可能存在一条,银行入账流水也仅存在一条,然后一对一去对。目前按照一对一对账的业务涉及到:网银 B2C 充值、网银 B2B 充值、VISA、网汇E、卡通充值、正常提现、认证提现、银企互联提现、卡通提现、卖家信贷、信用卡还款提现、COD、网点支付。

    对账标准:(清算通道 + 订单号 + 金额) Or (银行名称 + 业务代码 + 订单号 + 金额)。

    满足一对一的业务如下:

    提现成功:500401
    认证提现:500402
    还贷:500404
    卡通提现:500403
    个人网银充值:400301
    企业网银充值:400302
    VISA:400314
    网汇e:400315
    卡通充值:400304
    贷款:400307
    银企互联提现:500405
    信用卡还款提现:500407
    后台强制提现500406
    COD
    网点支付

    Tips:
    (1)、清算流水有,入账流水也有,金额一致,对账成功,清算流水、对账流水打上 ‘对账成功’ 标志,记录对账日期为系统当日;
    (2)、清算流水有,入账流水也有,金额不一致,清算流水记金额不等,记录对账日期为系统当日,入账流水不变;
    (3)、清算流水有,入账流水该订单号没有,清算流水打上 ‘银行多帐’ 的标志,记录对账日期为系统当日;
    (4)、清算流水有,入账流水没有该业务代码初始状态的,清算流水打上 ‘银行多帐’ 的标志,记录对账日期为系统当日;
    (5)、清算流水有,入账流水没有该银行的初始状态的记录,清算流水打上 ‘银行多帐’ 的标志,记录对账日期为系统当日;
    (6)、对账之前需要判断 1 对 1 的流水中是否有重复,有重复的返回失败不进行后续对账。

    (2)、多对多对账

           入账流水里相同订单号,相同清算渠道,相同,金额相同业务代码的流水存在对条(比如充退);而银行清算流水也可能是存在多条的情况的,这种情况下是多对多去对账的,遵循先到的先对的原则。

    对账标准:(清算通道 + 订单号 + 金额) Or (银行名称 + 业务代码 + 订单号 + 金额)。

    满足多对多的业务如下:

    充退:410401
    银企互联充退:410402
    Motopay 充退:410403

    Tips:
    (1)、清算流水有,入账流水有,满足对账标准,则对账成功,清算流水、对账流水打上 ‘对账成功’ 标志,记录对账日期为系统当日;
    (2)、清算流水有,入账流水有,金额不等,清算流水打上 ‘金额不等’ 的标志,记录对账日期为系统当日,入账流水不变;
    (3)、清算流水有,入账流水没有该订单号,清算流水打上‘银行多帐’ 的标志,记录对账日期为系统当日;
    (4)、清算流水有,入账流水没有初始状态 410401 的流水,清算流水打上 ‘银行多帐’ 的标志,记录对账日期为系统当日;
    (5)、清算流水有,入账流水没有这个银行初始状态 410401 的流水,清算流水打上 ‘银行多帐’ 的标志,记录对账日期为系统当日;
    (6)、清算流水有,入账流水没有初始状态的 ‘410401’ 的流水,清算流水打上 ‘银行多帐’ 的标志,记录对账日期为系统当日。

    (3)、一对多对账

           入账流水有多条,和银行的一条去对账。
    对账标准:(清算通道 + 订单号 + 金额) Or (银行名称 + 业务代码 + 订单号 + 金额)

    涉及的业务:境外收单

    境外收单购汇扣款(520101)
    购汇益回补购汇账户(400319)

    Tips:
    (1)、入账流水存在 2 条 520101 的,清算流水存在 1 条 520101 的,将入账流水的 2 条加和后的金额和清算流水的进行对账,一致的为对账成功;
    (1)、入账流水存在 1 条 520101 的,1 条 400319 的,那么要将 2 条金额之差和清算流水的 1 条 520101 的进行对账。不会出现 3 条 520101 或者 2 条 400319 的情况。

    4.4、对账功能

    (1)、内部流水购销

           内部流水购销是针对那种有入账流水表来说的,比如提现业务,提现文件生成就会扣款此时会同步一笔入账流水;而回导失败之后又会回充,此时也会同步一笔反向的业务流水,这两条流水不用再去和银行的资金流水进行对账,直接在入账流水这边进行购销即可。
    需要购销的业务如下:

                  

     


    (1)、购销的规则:非已勾销状态下,同一银行同一订单号,金额一致而业务代码相反的正向流水进行勾销,而且一条反向流水只勾销一条;
    (2)、日终轧账时候的购销:日终轧账的时候会对未购销的流水再次进行购销确保当天的流水都购销完全。(这个情况是为了解决反向流水先于正向流水先出现的逻辑错误情况而加的并提示流水号);
    (3)、如果业务代码相反,而金额不等的情况,就无法进行购销,这种情况原来是作为违反逻辑规则来进行标记的。这部分数据进行查明之后,可以修改流水之后,在日终轧账的时候从新进行购销;
    (4)、购销分 ‘一对一’(提现)和 ‘多对多’ (充退)的购销;
    (5)、勾销的流水不入历史库。

    (2)、对账汇总确认单

           显示对账结果,选择后续的相应的处理界面,复核员在此模块进行流水的确认,还有的功能就是对于已经对账处理的银行清算流水与系统入账流水进行后续业务分流推进。

    (1)、对于大部分对账成功的数据,可以将这些流水确认,确认后该部分流水将进入历史清算流水,只有进入历史清算流水的才认为银行与支付系统数据对平。对账成功的银行清算流水、账务入账流水全部进入各自历史清算流水表保存,相应的银行清算流水与入账流水同步删除。
    (2)、金额不等的流水,可能是银行清算流水文件有误,也可能是错账,采取的做法是操作员手工修改金额,在银行清算流水管理里操作或直接删除,将其推进到下一轮的对账处理环节,对账是可以重复对的,只要满足初始状态要求的流水即可。
    (3)、多账部分,由于各种已明确/未明确的原因,银行已经实际清算给支付公司了,但支付公司的账务系统并没有入账,需要提供一个流水分类和分类汇总挂账的操作入口。系统默认多账的流水给出的菜单是流水分类,金额不等的流水给出的流水管理页面。区别在于,在点流水分类时,只允许修改业务类型、银行日期,而且改完后不改变多账状态;流水管理,修改状态后,流水的对账状态将变成初始状态,需要进行重新对账。
    (4)、流水进入历史库的校验规则。

           举例说明:A 操作员导入了一笔流水,系统对账成功,银行清算流水与账务入账流水状态都被置为成功状态;B 操作员再次导入该相同流水,由于入账流水处于成功状态的可以继续对账,所以再次对账成功。系统在对账环节认为正常,但在入历史清算流水时必须做每组流水数据的平衡检查:必须是清算流水总额与入账流水总额匹配才可以进历史数据。
           对于上述的场景,如复核员针对 B 操作员的对账成功流水确认后,可以正常进入历史流水,对账批次号认最后操作的批次。而继续对 A 操作员的成功对账流水确认,则系统将认为是不合法的入历史流水行为。或者不对特定操作员的汇总确认,系统必须检验出所存在的重复银行清算流水,并将对应的明细数据显示复核员。此时可将该重复对账的清算流水删除即可。

    (3)、流水分类和分类汇总挂账

    (1)、对于多账的流水对账中心提供一个单独的处理入口,首先在此处进行分类,然后进行汇总挂账处理。操作人员可以根据多账流水的未确认类型修改成对应的业务代码,允许修改成业务类型为 7 的可挂账的类型(其他业务代码不允许挂账);流水可以重复分类,系统不做控制;但已申请挂账的除外,分类完毕的多账流水可直接提供分类汇总挂账操作。
    (2)、系统根据既定的业务代码判断是待查收入或待查支出挂账,页面跳转至相关凭证登记页面,此处业务规则同待查收支挂账;另一部分比如退票,因为不经过对账环节,所以需要直接在清算流水查询里面新增,业务代码 700106 未确认退票,不需要经过对账,直接去汇总确认单里将流水挂账。允许挂账的业务代码如下 :700101 其他应付款,700102 其他应收款,700103 银行错账,700104 未确认结汇款,700105 线下汇款,700106 未确认退票,700107 未确认收款,700108 未确认支出款。
    (3)、提交凭证登记申请相关校验:流水此刻状态是否是 ‘多帐’ ,申请提交人是否是当时的对账人,凭证登记成功,清算流水记录凭证号,流水状态改为 ‘已挂账’ ;
    (4)、汇总挂账的反交易同步入账流水,金额是负值,系统在清算流水里在做一条数据,自动对账。

    (4)、清算/入账/历史流水管理

    清算流水管理

    对于所有的清算流水,都可以在此模块下进行查询、修改、删除,同时也可以新增流水。

    (1)、查询功能,银行名称、业务代码、银行日期不能为空,业务代码和银行可以多选。
    (2)、修改功能,处于未对账(初始)、金额不等、多账、对账成功状态的流水可以进行单笔、批量修改操作,这里的批量修改动作与流水分类功能类似,只是该功能入口不仅支持对批量流水的业务代码、银行日期更新,也支持其他要素信息批量修改,作为(3)、提供给操作员在未对账前批量修改已知流水的手段之一;对已挂账的流水,不允许更新。
    流水删除:处于未对账(初始)、金额不等、多账、对账成功状态的流水可以进行单笔、批量删除操作,已挂账状态不允许删除。

    入账流水管理

    入账流水管理功能提供对账务入账流水的查询以及下载功能;为了杜绝对入账流水的人为变更操作,禁止支持对入账流水进行修改或删除处理。

    (1)、查询时银行名称、业务代码、入账日期不能为空,业务系统流水号:针对某类业务的业务流水号,如充值业务就是充值流水号;账务流水号:账务处理的流水号,即账务操作记录数据的序号,在账户明细查询里可以获取。
    (2)、对于提现类失败回充的流水,在操作员进行对账动作后,系统自动进行购销,在入账流水查询时,将对账状态选为已购销可以查到,这些不进入历史库,根据数据量,系统定时清理这些数据。

    历史流水管理

           分为历史入账流水和历史清算流水,查询功能在同一页面,查询时可以一起查询,也可以单独查询。历史流水只供查询和下载,不允许进行修改和删除操作。选择历史银行流水和历史清算流水(清算日期的时间间隔不能超过 7 天)进行查询,历史入账流水中无银行日期,历史银行流水中无入账日期。

    (5)、银行余额录入功能

           在该模块下,实现对每个银行账户的实际余额录入,以此来和内部账户余额进行匹配校验。分为银行余额登记,银行余额导入(复核),以及银行余额查询功能。

    (1)、银行余额登记:选择对应日期以及银行账户录入后,保存,此时去银行余额查询是看不到录入余额的,需要复核导入核对完毕后才能看到,保证核对的有效性。登记后系统记录一个临时余额。系统每天凌晨 1:15 的时候会跑批,取上一日已复核过的余额自动带入下日临时余额,如果不登记的话,就取上日余额。
    (2)、银行余额导入:标准格式是一个填写银行余额的 excle 模板,导入后的核对逻辑,对复核员导入的数据进行检测该帐户是否有临时余额。根据银行账号、银行日期、银行余额等条件查询银行余额表。
           判断 1 :如果查询出结果为空那么将返回给用户:“这个银行帐号找不到对应的银行临时余额!”。
           判断 2 :如果查询结果大余一条,将返回给用户:“这个银行帐号的一天有多个银行临时余额,不正常!”
           判断 3 :检测该银行帐号对应的银行余额是否相等。如果不相等将返回给用户:“临时余额和实际余额不相等,核对失败!”当余额核对成功后,将复核员导入的余额写入该对应帐户的实际余额,并修改余额状态为已复核。实际余额更新成功后,将删除当天日期的临时余额。
    (3)、银行余额查询:对操作员登记余额的信息,以及复核员复核过的余额进行查询,查询条件:银行名称、银行帐户、帐户状态、银行日期、余额状态。帐户状态:分为正常、废除、和销户三个状态,默认为正常状态。余额状态:分为未录入(N)、已录入(A)、已复核(Y)三个状态,默认为全部。

    (6)、内部账户登账

           业务简述:针对日常结算工作中非银行待查类的内部账户进行登记,如:清算款、利息、手续费等;该业务登记不产生后续业务登记行为,即不具有作为初始凭证号的使用功能。对于批量销帐类业务处理中,多会员转帐失败的,导致过渡户上有剩余金额情况的,可通过此处进行内部户登账,将过渡户(负债)和银存(资产)余额同时减少,再通过待查收入挂帐实现平衡。

    业务校验规则:

    (1)、必须登记的是一借一贷帐户信息;
    (2)、借贷方帐户不能一致;
    (3)、金额必须大于 0 ;
    (4)、不允许任意一方是销帐帐户。

                                             

    是否同步对帐中心流水:不需要同步对帐中心流水。

    (7)、待查收入挂账

           业务简述:应用于结算操作员针对日常结算工作中的银行待查收入进行登记,所产生的业务凭证号作为后续销帐业务的原业务凭证号,并且作为所有该登记所引发的后续业务登记的初始凭证号。其中待查收入挂帐业务凭证的借方(银存帐户)所对应的银行名称作为后续销帐业务的银行名称,包括差额重新挂帐部分再销帐的业务凭证,都递沿该银行名称。

    业务校验规则:

    (1)、必须登记的是一借一贷帐户信息;
    (2)、借贷方帐户不能一致;
    (3)、金额必须大于 0 ;
    (4)、借方帐户必须是银存帐户;
    (5)、贷方帐户必须是销帐帐户。

                                       

    是否同步对帐中心流水:不需要同步对帐中心流水。

    (8)、待查收入确认

           业务简述:针对银行待查收入登账的挂帐,可以通过本模块进行销帐。此处采取销帐确认方式进行处理,需要选择相应的待查收入挂帐业务凭证进行销帐业务登记。该业务登记可能产生后续业务登记行为,如差额销帐情况下,系统会自动做不足额部分的重新挂帐并复核通过,所产生的挂帐凭证作为后续销帐凭证的销帐卡片号。

    业务校验规则:

    (1)、所销的原待查收入挂帐凭证必须合法;
    (2)、所销的原待查收入挂帐凭证必须已复核通过,处理完毕;
    (3)、所销的原待查收入挂帐凭证不能已被销帐;
    (4)、销帐总额(贷方发生额之和不得大于原待查收入挂帐凭证发生额)并大于 0 ;
    (5)、贷方必须是内部户。

                                        

    (9)、待查支出挂账

          业务简述:针对日常结算工作中的银行待查支出进行登记,所产生的业务凭证号作为后续销帐业务的原业务凭证号,并且作为所有该登记所引发的后续业务登记的初始凭证号。其中待查收入挂帐业务凭证的贷方( 银存帐户)所对应的银行名称作为后续销帐业务的银行名称,包括差额重新挂帐部分再销帐的业务凭证,都递沿该银行名称。

    业务校验规则:

    (1)、必须登记的是一借一贷帐户信息;
    (2)、借贷方帐户不能一致;
    (3)、金额必须大于 0 ;
    (4)、贷方帐户必须是银存帐户;
    (5)、借方帐户必须是销帐帐户 。

                                         

    是否同步对帐中心流水:不需要同步对帐中心流水。

    (10)、待查支出确认

           业务简述:针对银行待查支出登账的挂帐,可以通过本模块进行销帐。此处采取销帐确认方式进行处理,需要选择相应的待查支出挂帐业务凭证进行销帐业务登记。该业务登记可能产生后续业务登记行为,如差额销帐情况下系统会自动做不足额部分的重新挂帐并复核通过,所产生的挂帐凭证作为后续销帐凭证的销帐卡片号。

    业务校验规则:

    (1)、所销的原待查支出挂帐凭证必须合法;
    (2)、所销的原待查支出挂帐凭证必须已复核通过,处理完毕;
    (3)、所销的原待查支出挂帐凭证不能已被销帐;
    (4)、销帐总额(借方发生额之和不得大于原待查收入挂帐凭证发生额)并大于0 ;
    (5)、借方必须是内部户。

                                     

    5.2、对帐及异常恢复逻辑

    (1)、以商户成功订单为准

    用商户上的成功订单与后台的订单来核对:

    (1)、若商户订单为成功,后台为初始或者失败,则更改后台状态为成功;
    (2)、若后台为成功,商户成功订单中无该订单(时间差),则不更改后台状态;
    (3)、若后台为初始或失败,商户成功订单中无该订单,则不更改后台状态。

    (2)、不重复恢复

           T+1 日恢复T 日的订单,并且在 T+1 日后不再下载 T 日的订单进行二次或多次恢复。(为考虑会员感受,T 日下班前恢复 T 日 0 点到下班时点的订单)

    (3)、时间性差异

            由于各家银行系统日切点均不同,并且大多不会在每日的 24 点(或早或晚),所以下载到的 T 日的订单流水与后台T日( 0:00-24:00 )的订单流水并不能全部对应上。将商户订单流水与后台订单流水核对,会出现商户有,后台无;商户无,后台有;商户有,后台有三种情况。对于 1、2 两种情况为我们所说的时间性差异。

    商户数据与后台数据的关系为:商户数据-(商户有,后台无)+(商户无,后台有)= 后台数据

                                     

     

       

    展开全文
  • 一、对账对账系统是什么 对账,就是核对账目,是指会计核算中,为保证账簿记录正确可靠,对账簿中的有关数据进行检查和核对的工作。传统的对账都是由财务手工线下进行的,使用账簿、凭证、表格等作为数据承载或...

    一、对账和对账系统是什么

    对账,就是核对账目,是指会计核算中,为保证账簿记录正确可靠,对账簿中的有关数据进行检查和核对的工作。传统的对账都是由财务手工线下进行的,使用账簿、凭证、表格等作为数据承载或辅助工具。随着时代发展,大量的交易数据再使用传统方式核对显然费时费力,不合时宜,所以产生了数据线上化和对账功能线上化的需求。

    在支付系统中,对账一般是支付发生后,将指定节点的账目进行核对的动作,达到监控数据一致性、发现差异账的目的。

    一般核对的对象是业务账单和支付系统的记录,称为业务对账,检查业务系统记录的交易内容和支付系统记录的交易信息是否有出入,保障链路、数据准确,是公司内部两大系统的间的数据核对;或者核对对象是支付系统的记录和各交易渠道的清算数据,称为渠道对账,检查支付系统记录的交易和第三方交易渠道(如银行、支付宝、网商银行、代扣系统、pos支付等)记录的正向逆向交易信息是否有出入,是公司支付系统和外部支付渠道之间的数据核对。

    对账系统,除了实现资金核对,也可以作为一个平台型产品服务,延伸到任意场景。只要指定对账的对象、数据、对账规则、输出结果等,均可进行对账,满足双方或多方核对的需求。

    本系列积累主要介绍的是个人工作中主要接触的渠道对账的内容。虽然对账中心也实现了业务对账和非资金对账(财税对账),但也是建立在整个对账系统上的,设计思想和流程处理基本相同,不同的是数据、规则不同,待另起篇幅进行积累。

    二、需要了解的对账名词

    名词说明
    渠道对账渠道网关的交易流水与外部渠道账单进行对账
    交易日期对账交易日期,交易完成时间
    单边对账以基准数据为准进行单向对账,只能对出多账,对不出少账
    双边对账对账数据双向对账,能对出多账和少账
    基准数据指定内部账单还是外部账单数据为基准数据,会影响到多账、少账所指的相对对象,一般指定外部账单为基准数据
    多账以外部账单为准,外部流水有,内部交易流水无
    少账以外部账单为准,外部流水无,内部交易流水有
    对账一致对账双方的核对字段一致
    挂账将对账,少账,对账不一致的流水进行挂起,同时进行账务记账,待查明原因后进行处理
    销账将挂账的明细进行冲销账务处理,同时对账明细更新销账状态
    跨日调整因为日切的原因,将不在同一交易日期的流水调整匹配
    展开全文
  • 微信自动对账功能

    千次阅读 2019-01-10 18:17:32
    微信自动对账功能--基于微擎系统自动对账功能项目说明项目大概逻辑:代码如下: 自动对账功能 对于有业务往来的公司之间, 公司与支付宝微信等支付平台之间, 几乎都需要对账。 项目说明 这是PHP代码(PHP是世界上最后的...
  • 支付系统对账设计

    千次阅读 2019-03-28 22:26:16
    对账系统作为支付系统中的基石系统,处于整个支付环节中的最后一层,主要用来保证我方支付数据与第三方支付渠道或银行的数据一致性。 在没有对账系统之前,财务在第二日手工核对前一日的应收与实收。倘若不一致,这...
  • 数据治理通用组件WeBankBlockchain-Data当前3个子组件——数据仓库组件Data-Stash、数据导出组件Data-Export、数据对账组件Data-Reconcile...
  • 传统企业间的对账依赖于对账双⽅的中心化账本。中心化账本在对账期间如果出现账不平的情况,排查会⾮常耗时耗力。区块链作为信任的机器,具有不可篡改、分布式账本等特性,基于区块链的对账能够在对账不一致的情况下...
  • 对账相关知识

    千次阅读 2009-03-03 15:56:00
    银联对账交易 会计结算机构一般都会有对账处理业务,与清算相关联的机构也会有对账处理。 对账交易是入网机构和银联(大陆境内)交易数据的一种清算过程,交易数据比如借/贷交易金额、借/贷交易笔数、借/贷冲正...
  • 对账的必知概念

    千次阅读 2018-11-04 10:40:52
    对账: 就是让每一笔交易,都要做到各参与者的记录能够吻合,没有偏差。 平账: 在对账过程中,如果发现有差异的记录,通过人工或者自动的方式,解决这些差异 这里会出现的问题有: ①本地未支付,支付渠道已支付。...
  • java后台实现支付宝对账功能

    万次阅读 热门讨论 2018-03-15 16:37:35
    完成支付宝支付、查询的接口之后,我们应该还需要定时与支付宝进行对账,以确保商户系统的订单信息是正确的,想知道支付宝支付、查询接口实现过程的亲们,可移步到上一篇有详细过程。现在我们来讲一下支付宝对账的...
  • 对账系统技术架构

    千次阅读 2018-11-15 20:46:05
     很多时候会碰到新业务上线之后,发现由于程序bug导致... 在做对账的时候要考虑这两点:第一是每一次资金入账都要符合预期,要能够准确识别出来哪些是异常入账并进行拦截,进入人工审核。另外还需要增加一种事...
  • 谈谈我理解的电商对账

    千次阅读 2019-07-02 12:15:00
    上周有同学加我咨询对账的问题,这里只是说说我的理解。由于每个公司的结算流程、系统组成和边界都不尽相同,重在领会精神。 1、什么是对账 对账是交易双方对一定周期内的交易明细进行确认,生成对账单(结算...
  • 最近要做支付对账,即检查第三方支付与数据库中账单是否一一对应,涉及到微信对账单的处理,成功时,微信账单接口返回数据以文本表格的方式返回,第一行为表头,后面各行为对应的字段内容,字段内容跟查询订单或退款...
  • 上周有同学加我咨询对账的问题,这里只是说说我的理解。由于每个公司的结算流程、系统组成和边界都不尽相同,重在领会精神。1什么是对账对账是交易双方对一定周期内的交易明细进行确认,生成对账单(结算单)供商家...
  • 支付宝对账单CSV解析

    千次阅读 2019-05-17 21:46:38
    支付宝对账单CSV解析 一、读取zip文件,不解压缩直接解析,支持文件名中文,解决内容乱码 import com.slx.outer.zip.ZipEntry; import com.slx.outer.zip.ZipInputStream; import org.junit.Test; import ...
  • 渠道对账及差错处理系统设计

    千次阅读 2017-12-28 11:31:55
    为什么要对账对账其实是对一定周期内的交易进行双方确认的过程,一般都是在第二天第三方支付公司对前一日交易进行清分,生成对账单供电商平台下载,并将应结算款结算给电商平台。 所以对账有以下作用: ...
  • 距离上篇对账文章也有几个月之久,对账二期系统早已如期上线。 对于该系统,目前只有两个字,稳定得一比。 对账二期针对支付宝和微信千万级订单量对账时间在3分钟内完成对账&缓存存储(根据订单号查询平台方...
  • 微信支付对账单查询获取 第一步:拼接请求参数(xml格式) 请求字段说明 appid 微信公众号开发者ID 必填 nonce_str 随机字符串 必填长度不长于32位(可用随机字符串生成工具类生成) mch_id 微信商户号id 必填 bill_...
  • 对账系统设计详解(上)

    千次阅读 2021-03-20 00:59:38
    本文由作者陈天宇宙发布于社区,业务图较多,建议PC端阅读 01 对账介绍想必大家对“对账”这个词都不陌生,单从字面意思就能略知一二;其实就是字面意思;“对”就是核对,“账”就是账...
  • 对账不平问题专题讲解内容 一.总账对账不平 二.模块间对账不平 其他模块与总账间的对账不平 其他模块间的对账不平 一.总账对账不平 总帐中大部分数据问题多出现在对账不平这个环节上,对账的形式主要有: 1、...
  • 本文由作者陈天宇宙发布于社区,业务图较多,建议PC端阅读 上篇指路:对账系统设计详解(上) 07 资金对账项目配置设计完成线上支付交易以后,虽然通道方告知支付成功,但是钱是不是真...
  • 传统企业间的对账,依赖于对账双方的中心化账本。中心化账本在对账期间如果出现账不平的情况,排查非常耗时耗力。区块链作为信任的机器,具有不可篡改、分布式账本等特性,基于区块链的对账能够在对账不一致的情况下...
  • 一、目前对账的算法: 1、从上游渠道(银行、银联等金融机构)获取对账文件,程序逐行解析入库 2、在存储过程中,以上游对账文件的表为基准,程序逐行读取并与我们系统的交易记录/账务记录(有账务系统情况下,...
  • 【工作日志】对账清算

    千次阅读 2014-07-09 21:35:36
    前置系统的对账部分,主要是两块,一是本代
  • 接口要求,SP务必部署订购关系对账程序,对账文件取走后删除VAC服务器上的文件,我们将每天核查对账文件的处理情况,对不按时取走对账文件的SP进行结算考核。 回执文件格式如(SubscribeInfo...
  • 对账系统设计和架构

    千次阅读 2018-05-30 22:43:00
    信息流对账也一般用在自己内部系统的对账,比如支付系统的支付数据和业务系统的业务数据进行对账,保证资金交易和业务交易的一致性。资金流对账也就是支付系统和银行或者第三方支付系统之间的资金交易对账对账...
  • 现在的电商平台一般会接入多家支付公司的支付产品,如支付宝、微信、银联等,那么接入多家公司的产品,是如何对账的呢? 本文以电商为例,讲解商户如何与多家支付公司对账。 一、为什么要对账对账其实是对一定...
  • 从0到1设计一个高可用数据对账系统

    千次阅读 2019-05-16 18:27:27
    在支付机构的概念:资金对账,在对账中心进行,将系统保存的账务流水与银行返回的清算流水和清算文件进行对账,核对系统账务数据与银行清算数据的一致性,保证支付机构各备付金银行账户每日的预计发生额与实际发生...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 4,677
精华内容 1,870
关键字:

对账中心