其他分享
首页 > 其他分享> > 支付系统难点全面梳理剖析:核算对账核心

支付系统难点全面梳理剖析:核算对账核心

作者:互联网

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

清算对账系统

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

1. 资金流入与银行的对账

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

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

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

2. 资金流出与银行的对账

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

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

什么是对账?

什么是资金对账?

在会计上的概念:指为了保证账簿记录的正确性而进行的有关账项的核对工作,做到账证相符、账账相符、账实相符。

在支付机构的概念:资金对账,在对账中心进行,将系统保存的账务流水与银行返回的清算流水和清算文件进行对账,核对系统账务数据与银行清算数据的一致性,保证支付机构各备付金银行账户每日的预计发生额与实际发生额一致。即核对银行实际清算资金如充值、充退、提现等业务的银行处理结果是否一致。

对账中心的作用?

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

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

对于勾兑结果中银行清算流水多于系统入账流水的,而操作人员不明确资金的来源,需要根据所设定的分类规则将暂不明确的资金进行挂账处理。而后我们认为该部分资金已经系统入账,可以入历史流水库。

因为此时的银存实际账户的余额增加,与之对应的是支付系统内部户余额也增加了,比如: T 日的挂账可能会在 T+N 日后进行销账确认,而后续的销账行为是对明细流水的业务分流处理,我们不应将 T+N 日的销账所产生的账务流水作为入账流水,不再需要到对账中心体现。

对账内容和数据来源

第一步

入账流水和清算流水进行核对,目的是保证对每一笔订单银行的处理结果和我们系统的业务处理结果一致。

第二步

对账汇总确认单和银行对账单进行核对,目的是通过轧余额等方式,核对各类业务的银行处理结果是否与银行实际清算给我们的资金一致。

1. 对账业务流程

对账业务流程图

2. 对账中心主要功能

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

这样做的目的是让待清算与入账流水在日切点保持等额,比如:提现 T 日会员申请提现,生成文件后会员账户提现金额转入待清算提现款项,与此同时发送流水到对账中心,此时待清算与对账中心入账流水是保持平衡的。

而 T+1 日银行处理失败,系统会回充带清算提现款,如果此时不发送失败流水到对账中心与其对应的流水进行购销的话,则入账流水就会不变,和带清算提现不平衡。

Tips:

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

对账流程图

对账中心功能模块分析

获取资金对账数据:

清算流水对账:

对账逻辑:

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

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

满足一对一的业务如下:

Tips:

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

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

满足多对多的业务如下:

Tips:

一对多对账:入账流水有多条,和银行的一条去对账。

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

涉及的业务:境外收单

Tips:

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

需要购销的业务如下:

对账汇总确认单:

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

举例说明:A 操作员导入了一笔流水,系统对账成功,银行清算流水与账务入账流水状态都被置为成功状态;B 操作员再次导入该相同流水,由于入账流水处于成功状态的可以继续对账,所以再次对账成功。系统在对账环节认为正常,但在入历史清算流水时必须做每组流水数据的平衡检查:必须是清算流水总额与入账流水总额匹配才可以进历史数据。

对于上述的场景,如复核员针对 B 操作员的对账成功流水确认后,可以正常进入历史流水,对账批次号认最后操作的批次。而继续对 A 操作员的成功对账流水确认,则系统将认为是不合法的入历史流水行为。或者不对特定操作员的汇总确认,系统必须检验出所存在的重复银行清算流水,并将对应的明细数据显示复核员。此时可将该重复对账的清算流水删除即可。

流水分类和分类汇总挂账:

清算/入账/历史流水管理:

清算流水管理

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

入账流水管理

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

历史流水管理

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

银行余额录入功能:

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

银行余额登记:选择对应日期以及银行账户录入后,保存,此时去银行余额查询是看不到录入余额的,需要复核导入核对完毕后才能看到,保证核对的有效性。登记后系统记录一个临时余额。系统每天凌晨 1:15 的时候会跑批,取上一日已复核过的余额自动带入下日临时余额,如果不登记的话,就取上日余额。

银行余额导入:标准格式是一个填写银行余额的 excle 模板,导入后的核对逻辑,对复核员导入的数据进行检测该帐户是否有临时余额。根据银行账号、银行日期、银行余额等条件查询银行余额表。

判断 1 :如果查询出结果为空那么将返回给用户:“这个银行帐号找不到对应的银行临时余额!”。

判断 2 :如果查询结果大余一条,将返回给用户:“这个银行帐号的一天有多个银行临时余额,不正常!”

判断 3 :检测该银行帐号对应的银行余额是否相等。如果不相等将返回给用户:“临时余额和实际余额不相等,核对失败!”当余额核对成功后,将复核员导入的余额写入该对应帐户的实际余额,并修改余额状态为已复核。实际余额更新成功后,将删除当天日期的临时余额。

银行余额查询:对操作员登记余额的信息,以及复核员复核过的余额进行查询,查询条件:银行名称、银行帐户、帐户状态、银行日期、余额状态。帐户状态:分为正常、废除、和销户三个状态,默认为正常状态。余额状态:分为未录入(N)、已录入(A)、已复核(Y)三个状态,默认为全部。

内部账户登账:

业务简述

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

业务校验规则

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

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

待查收入挂账:

业务简述

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

业务校验规则:

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

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

待查收入确认:

业务简述

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

业务校验规则:

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

待查支出挂账:

业务简述:

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

业务校验规则:

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

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

待查支出确认:

业务简述

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

业务校验规则:

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

意外数据恢复逻辑

1. 意外数据恢复逻辑

重复支付:对同一内部订单号进行了二次或二次以上的支付。

支付失败,金额不等:买家实际支付的金额与交易金额不等。一般产生的原因是,买家在支付时,产生了掉单,卖家随后修改了交易价格。 在进行网银对账的时候,即会出现订单金额和交易金额不等的情况,且是一笔掉单。2、3 两类情况只发生在支付上。

支付成功,金额不等(这一类异常,偶尔有发生):商户订单状态为成功,后台订单状态也为成功,并且交易状态是买家已付款,等待卖家发货。

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

2. 对帐及异常恢复逻辑

以商户成功订单为准:

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

不重复恢复:

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

时间性差异:

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

商户数据与后台数据的关系为:

商户数据-(商户有,后台无)+(商户无,后台有)= 后台数据

标签:难点,入账,银行,业务,对账,流水,清算,核算
来源: https://www.cnblogs.com/sea520/p/11635047.html