认真看了下前面几个答案,感觉各有优劣我这里说的也只是从清结算、产品、运营、系统等几个方面触发对第三方支付与银行对账清算的过程大致说下对于第三方支付公司对账来说主要分跟商户对账、跟银行对账,两者既有重叠的部分也有不同的地方,既然这个问题是说跟银行对账的,那我就直说如何跟银行对账。
跟银行对账主要包括两方面1:出金 2:入金一:出金,大家可以比较简单的理解为商户通过接口发送指令给第三方支付公司,将暂时保存在第三方支付公司备付金账户里的备付金提走那么在资金流上就是“第三方支付支付公司备付金。
银行账户”----》"商户指定的一个银行账户"信息流上在第三方支付公司的支付系统中会生成一笔代付订单,理论上这笔代付订单需要在第二天银行发来的对账文件进行信息流对账,信息流对账无问题后,在用对账文件跟银行流水
进行核对这中间会有以下几个问题:a、对账是发送在T+1(如果碰到假期,很可能变成T+3
b、跟银行对账的实际运营中,并不是所有银行都会提供代付对账文件给第三方支付公司的,银行一般比较强势可以不提供对账文件,只提供银行流水,因为银行流水实际就是该笔代付订单的最终状态c、大家别以为银行就了不起,银行就不会出错,我可以很负责的告诉大家,银行系统也会出错,而且错的很离谱。
银行如果给你的是对账文件,那对不起,对账文件不是他核心系统出的,如果一旦出错,内部人员可以很快的更新对账文件,这对银行的人来说不算大问题,但是银行流水必然银行核心系统出具的,所以正常情况下不会随意改动,就算变动也是在原有基础上增加一条调账的流水,但不会将原来错误的流水删除。
综合以上几个原因,一般的支付机构的出金(代付交易)对账想通过传统的先信息流再资金流核对是不怎么实际可行的,除非你是支付宝或者企鹅,那当然另说,谁知道银行给两位大佬开了什么样的接口,就差把分行搬进别人总部了,有啥特殊对待我都不奇怪哈。
所以代付出金对账我认为目前有两种比较可靠的模式1:在交易量小的时候,可以通过人工下载银行流水、系统下载每个银行出款的代付订单,人工进行核对,如果支付量小切备付金帐号不多的情况,这样对账还是可行的2:当然随着交易体量的变大,稍微大点的。
支付公司都会有四五十个备付金账户,出款账户少说也有十几个,这样就对人工核对增加一定压力,而且人工核对易出错,对账数据没有保存,对于将来财务审计查账都不是一个好的信号所以我一直在考虑的是跳过信息流对账,直接从订单---银行流水,新的对账模式。
正常的一笔代付订单都应该有一笔银行流水进行对应,那么我们只需要通过银企直连系统将银行流水下载好放进对账系统,同时在代付订单成功后自动将也放入对账系统进行勾兑当然我在实践的时候也遇到了一定的问题:代付交易量过大,银企直连系统接口下载银行流水不堪重负(看看银行给我们开的都是什么接口);。
订单和银行流水进行勾兑的时候找不到对账要素,正常对账过程中我们的代付渠道订单会收到银行返回的成功标识,并返回一个银行订单号之类的东西,如果是信息流对账我们都是通过银行订单号和对账文件中的订单进行核对,但是银行流水中不一定会有交易成功的时候返回银行订单号,这样就没有对账要素了。
苦闷啊但是最终还是克服各种技术
免费申请POS机,费率低至0.38%秒到账
二:入金入金可以比较简单的理解为代扣、快捷支付、认证支付、网银支付、跨境支付等等收单产品的汇总在资金流上:从持卡人银行账户---》第三方支付公司的备付金账户在入金对账上不能参照上面所说的订单--银行流水对账方式,原因如下:。
1:大部分情况收单订单银行都是汇总一笔总金额入账到第三方支付公司的银行备付金,如果通过订单-银行流水的对账方式,是无法知道银行流水对应到支付系统中哪些收单订单2:银行入账都会有个日切,在交易量放大的时候这种日切会变大,从而导致时间差导致的对账差异变得很不稳定,而且不能判断是否真是差错还是时间差导致的差异。
所以在入金对账上必须按照传统的对账模式:先信息流对账,再资金流对账信息流对账我看了前面几位大大的回答已经说的很好了,其实就是个订单勾兑,无法勾兑的拉出来进行人工处理同时放到后面一个对账周期进行滚动对账,有部分差异订单会通过滚动对账对平,但有部分差异订单确实是差异需要清算人员进行人工处理。
资金流对账就是通过解析银行对账文件进行汇总,然后根据银行流水到账金额和对账文件汇总进行进行比对简单的说:信息流对账是验证银行说今天该要给我多少钱,是不是该给我这么多钱 资金流对账是验证银行说今天要给我100元,我是不是已经真的收到100元。
但是在实际的运营中对账最麻烦的问题就在于,银行不会那么OK,不会出现任何问题,我举几个实际的例子说明:渠道是指实际的银行渠道,系统是指第三方支付公司的支付系统场景1:渠道订单失败,系统订单成功,渠道未结算
处理意见:跟商户沟通,商户同意后将该笔成功订单做系统中做内部退款处理(不做接口请求)底层账务系统按照正常的业务流程进行记账:订单成功:借:XXX渠道应收款 贷:XXX商户余额。
订单退款:借:XXX商户余额 贷:XXX渠道应收款场景2:系统掉单,渠道订单成功,系统订单失败,渠道结算款已结算处理意见:将该笔系统订单补单场景3:系统的订单号与渠道对账文件中上游订单号不匹配,但渠道银行款项已结算;
处理意见:经过人工确认我司系统订单与渠道对账文件订单是同一笔订单后场景4:系统测试直接调用接口,测试订单在渠道系统没有订单,无法与渠道对账文件中的订单进行匹配处理意见:经过人工确认渠道对账文件订单是我司的一笔测试订单
场景5:渠道机构系统问题导致少清算处理意见:银行一般比较强势,金额小的话,支付公司自己认赔把认赔也需要记账的,这样时间一长想知道今年我们被银行黑了多少钱蔡一目了然哈当然不只是这种认赔,其他退款、风险事件。
的发生都有可能发送赔付的,所以设置一个专门的赔付科目是相当有必要的 借:XXX公司赔付账款 贷:XXX渠道应收款场景6:渠道对账文件问题,渠道对账文件中没有这笔,但是这笔订单的钱已经结算给我司处理意见:经过人工确认渠道订单这笔金额实际银行已经结算给我司,但是在渠道对账文件中未体现该笔订单,清算人工在对账系统中处理
场景7:测试异常,系统与渠道订单均为失败,渠道订单也未结算,但是渠道订单在上游给的对账文件中显示为成功订单处理意见:经过人工确认渠道订单实际结算款未结算给我司,清算人工在对账系统中处理场景8:渠道出了问题,渠道订单反馈给我们是失败的,过几天后订单成功,钱已结算,但是我们系统的订单是失败的
处理意见:参照场景1场景9:系统测试款项成功后当日直接操作退款,渠道直接将此交易撤销,故对账文件里没有这笔处理意见:清算人工在对账系统中处理PS:以上不同情况的会计分录一定要按照财务实际做帐同学要求设置哈,这个不是怀疑其他人的专业水平,因为每个公司做帐的方式都不一样,一定要实际财务做帐方式去设置特殊情况下会计分录。
以上是我总结的几种实际对账差异以及如何处理的情况,其实对账最麻烦的就是对账差异处理的,对账差异处理最麻烦就是针对不同的业务情况导致的差异,需要不同的财务科目和系统账户来记录下这些差异,不然时间一久就没了记录了,一旦哪天你们公司要上市回头来查这些数据会把财务同学逼死的。
这就是我对支付机构与银行对账清算的理解,希望对你有帮助哈,一看写了还不少哈,花了我快1个半小时哈
绍兴pos机办理热线:18127011016